[Plugin Request] Generate and verify @apollo/client@3 keyFields configuration

[SimenB]

@apollo/client@3 comes with a new config option called typePolicies passed to the cache's constructor, which can be used (amongst many different awesome things) to specify keyFields for each GraphQL type in your schema, so that the cache knows how to normalize the entries properly.

@benjamn talks about it in this great talk: https://youtu.be/n_j8QckQN5I, and specifically what I'm requesting is the code generation mentioned briefly here: https://youtu.be/n_j8QckQN5I?t=1347.

My hope for this potential new codegen plugin is:

• there would have some sort of directive (@id? @keyField?) that is applied to types in the schema
• the plugin would generate the config object with keyFields (and possibly other stuff in the future) defined, which would be splatted into the cache constructor
• throw an error if we request a type in a query without specifying all the keyFields (i.e. fields with the @id directive). This last one would be really awesome as we'd know when we define queries that we request all the relevant fields to properly normalize the cache, avoiding runtime errors/warnings

Docs: https://www.apollographql.com/docs/react/caching/cache-configuration/#generating-unique-identifiers

/cc @hwillson @benjamn would love your thoughts on this 🙂

[dotansimha]

That could be great! Thank you @SimenB !
Moving to Discussions (we track new plugins requests there).

[dotansimha]

@SimenB We have a new plugin for this :) see: #4973
Available as @graphql-codegen/typescript-apollo-client-helpers.

[SimenB]

Yay!

[dannycochran]

@dotansimha just saw this plugin, this is a great start, thank you for putting it together. I had a few thoughts, wondering what you think:

1. The keyFields function signature doesn't allow passing in the entity object, it always gets typed as:

    keyFields?: false | FooBarKeySpecifier | (() => undefined | FooBarKeySpecifier);

Some keyFields need to be computed based on object properties, but this function actually prohibits access to the object entirely. Is that by design? I think the logical thing to do would be to create a union of all fragment types that the consumer has on FooBar, e.g:

fragment FooBarFullInfo on FooBar {
  id
  name
  details
  bars {
    id
    name
  }
}

fragment FooBarMinimalInfo on FooBar {
  id
  name
  details
}

Would produce:

    type FooBarFragments = FooBarFullInfoFragment | FooBarMinimalInfoFragment;
    ...
    keyFields?: false | FooBarKeySpecifier | ((object: FooBarFragments) => undefined | FooBarKeySpecifier);

2. Nested keys aren't working properly for me (I'm using TS 4.2.2). I see from your PR you expect them to work, however. e.g:

  // E.g., given some type like this...
  type FooBarFragment = {
   name: string;
    bar: {
      id: string;
    }
  }
  
  ...
  FooBar: {
    // red squiggly over "keyFields" here, it doesn't index into FooBarFragment.bar for the nested array.
    keyFields: () => ['bar', ['id']]
  },