Client V3 - TypePolicy Generates Error on Cache Miss

[jamshally]

I have been following the Custom Field Policy example in the article Previewing the Apollo Client 3 Cache. I have create a TypePolicy reference UserListView from a UserDetailView Query, as follows:

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

Intended outcome:
If "User" entities are not available in cache, the logic flow progresses without error.

Actual outcome:

The following error is generated:
Attempted to match fragment UserFragment with type condition User against object with unknown __typename

How to reproduce the issue:

1. Setup TypePolicy per above
2. Initiate a DetailView Query before a ListView query
3. Observer error

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

[benjamn]

I see what you mean, and I agree that instead of throwing an exception, the behavior should be that the fragment simply doesn't match the (dangling) Reference.

Thanks for helping test the betas, by the way!

[jamshally]

@benjamn - thanks for the reply.

I see what you mean, and I agree that instead of throwing an exception, the behavior should be that the fragment simply doesn't match the (dangling) Reference.

So, if the fragment doesn't get a cache hit, I guess the query would then execute against the server? So, then, how should the subsequent result cache? Ideally it would it honor the TypePolicy and and cache per the provided reference.

Thanks for helping test the betas, by the way!

No problem. I really like the direction your team has taken with the V3 Client

[benjamn]

If the server supports the User_by_pk field, then it's safe to include that field in the query that would be sent to the server, and it will be cached as a { __ref } object when it comes back, which becomes existingData whenever User_by_pk is called.

If the server would be confused by the User_by_pk field, because it's a client-only thing, then you should annotate the User_by_pk field in your queries with the @client directive (something like this: User_by_pk(id: ...) @client), so it won't be sent to the server.

With this approach, since User_by_pk won't be coming back from the server, there's a good chance that existingData will never be defined, because no data is ever written into the cache for this field. That's fine; it just means you might not have to worry about existingData in the User_by_pk function at all.

In general, AC3 is moving away from special syntax that you have to include in your queries, so we might introduce a clientOnly: boolean property in the FieldPolicy API, so you could specify that certain fields are client-only in one place, and not have to modify any queries. For now, the @client directive is still the best way to keep client-only query fields from being accidentally sent to the server.