Client V3 - TypePolicy Results in DetailView Result being Cached Without ID

A related, but different, issue to #5709

I have a TypePolicy reference UserListView from a UserDetailView Query, as below:

export const UserTypePolicy: TypePolicies = {
        Query: {
          fields: {
            User_by_pk(existingData, { args, toReference }) {
              return existingData || toReference({ __typename: 'User', id: args!.id });
            },
          },
        },
      };

I execute a User DetailView query on a user that does not already exist in cache.

Intended outcome: I would expect the following to end up in cache:

User_by_pk({"id":"88cfac84-e76a-4920-a7b4-c5d32b266f87"}): {"__ref":"User:88cfac84-e76a-4920-a7b4-c5d32b266f87"}

Actual outcome:

The following entry ends up in Cache: User_by_pk: {"__ref":"User:88cfac84-e76a-4920-a7b4-c5d32b266f87"}

This causes several problems including, the existingData field for every hit to the above TypePolicy returning this single User entity, not matter what the actual ID.

How to reproduce the issue:

1. Setup TypePolicy as above
2. Execute a ListView Query to seed cache
3. Execute an Insert to create a new item (that will not be in cache)
4. Execute a Detail View Query
5. Observer the resulting cache

Versions System: OS: macOS 10.15.2 Binaries: Node: 12.12.0 - /usr/local/bin/node Yarn: 1.19.1 - /usr/local/bin/yarn npm: 6.9.0 - /usr/local/bin/npm Browsers: Chrome: 79.0.3945.88 Safari: 13.0.4 npmPackages: @apollo/client: ^3.0.0-beta.10 => 3.0.0-beta.16 @apollo/react-hooks: ^3.2.0-beta.0 => 3.2.0-beta.0 apollo-link-debounce: ^2.1.0 => 2.1.0

[jamshally]

This workaround should cover your use case

Yep, that sorted it. Thanks!

I’m open to debating the relative merits of different default behaviors

I don’t feel well placed to weigh in on the debate of what is best for most people. However, in case these are useful datapoints:

1. I am using a Hasura backend, which autogenerates an ‘<entity>_by_pk’ query for every Entity - so this use case will come up a lot
2. Without a TypePolicy, the ‘entity_by_pk’ queries would cache with a keyArg (as I was expecting). With a TypePolicy it does not. So, adding a TypePolicy changes the behavior of something only tangentially related (KeyArgs). This may catch a few people out
3. I am new to GraphQL and Apollo, so the above may be wrong-headed for reasons I am not yet aware of

Thanks for taking the time to respond

[benjamn]

Thanks, those are useful data points!

One of the goals of type policies and field policies is that it should be easy to write helper functions for common patterns, so you could do something like

function makeByPkFieldPolicy(__typename: string) {
  return {
    keyArgs: ["id"],
    read(existingData, { args, toReference }) {
      return existingData || toReference({ __typename, id: args!.id });
    },
  };
}

const cache = new InMemoryCache({
  typePolicies: {
    Query: {
      fields: {
        User_by_pk: makeByPkFieldPolicy('User'),
        Product_by_pk: makeByPkFieldPolicy('Product'),
        // and so on...
      },
    },
  },
});