Apollo 3: optionally auto-merge the keyFields from typePolicies if they are missing from queries

[dimitar-nikovski]

Hi,

Due the nature of gql literals, when migrating to v3 in a larger project, it is easy to miss out to add the configured keyFields to every type in every query in the codebase and this will be bug prone in the future when making changes.

It would be nice if a config bool can be passed to the client to enable auto-adding of any missing keyFields for a type when it is being requested to ensure cache works as intended. However, this will be a bit difficult, because a typePolicy relates a __typename string result to the keys configured to use for caching it, but it has no way of knowing which __typenames are the types for field names in the schema (except via introspection?) although in practice they may often have the same names.

If we suppose that a field name in a schema which isn't a primitive type is expected to have the same name as the value of it's __typename by default and allow for explicit exceptions (just like with the default __typename:id cache key), then there can be a more robust cache without having to introspect a schema by passing a separate config to relate field names to __typenames and detect if any keyFields are missing from requests and merge them before sending them.

[sirugh]

I was just having this conversation with a coworker today. When you define values for keyFields you have to make sure that the all queries within the code for that object include the fields needed to create a key field. At a minimum it would be nice to have some linter error or warning, but ideally ApolloClient would just automatically include the necessary key fields for a given entity.

[pvinis]

how is this still not worked on? this needs to be part of apollo

[WonderPanda]

Plus one. This would be extremely useful. We've run into frequent runtime errors for operations exploding when they're missing keyfields that are already defined in the type policies