[Plugin Request]: Apollo-link-state InMemoryCache read* and write* method generator

[DanielMillerSEL]

Apollo-link-state uses client side resolvers to merge client and server responses, and the client methods readQuery, writeQuery, readFragment, and writeFragment on that object can be typed using existing gql-gen code generators. A generator that provides pre-baked methods that include those types would be useful to me as it can get a bit verbose as it stands.

All examples are with no-namespaces, I'm just more familiar with that flag being on at this point, I understand that some of the use cases get less crazy if you only have to deal with the namespace object, but it is still rather verbose.

As an example, given this client side schema for an apollo client

type Query {
  burgers: [Burger!]!
}
type Mutation {
  addBurger(name: String!): Burger!
}
type Burger {
  id: ID!
  name: String!
}

Generate client side resolvers (using typescript-common, typescript-server, and typescript-resolver), where the context type argument conforms to the Context type described like this:

import { InMemoryCache } from 'apollo-cache-inmemory';
interface Context {
  cache: InMemoryCache;
};

Now to make the resolver
Implementing the resolvers looks like this right now

//... other imports and such
import { IResolver, AllBurgersQuery, AllBurgersVariables, AllBurgersDocument } from 'gql generated bits';
import { Context } from 'above code snippet';
gql`
  query allBurgers {
    burgers { id, name } @client
  }
`

const resolvers: IResolver<Context> = {
  Mutation: {
    addUser(_, { name }, { cache }) {
      const { burgers }= cache.readQuery<AllBurgersQuery, AllBurgersVaraibles>({
        query: AllBurgersDocument
      });
      const newBurgers = [...burgers, { id: <something>, name } ];
      // Note, newBurgers conforms to the burgers field of AllBurgersQuery, as Data in writeQuery requires.
      cache.writeQuery<AllBurgersQuery, AllBurgersVaraibles>({
        query: AllBurgersDocument,
        data: { burgers: newBurgers }
      })
    }
  }
}

Quite a bit of duplicated code in there, adding a generator to auto provide a lot of these queries could simplify a lot of this.

As an example if it code gens something like this:

interface AllBurgersCacheReadParams {
  cache: InMemoryCache;
  variables?: AllBurgersVaraibles;
}
function AllBurgersCacheRead(args: AllBurgersCacheReadParams) {
  cache.readQuery<AllBurgersQuery, AllBurgersVaraibles>({ query: AllBurgersDocument, ...args });
}
interface AllBurgersCacheWriteParams {
  cache: InMemoryCache;
  variables?: AllBurgersVaraibles;
  data: AllBurgersQuery;
}
function AllBurgersCacheWrite(args: AllBurgersCacheWriteParams) {
  cache.readQuery<AllBurgersQuery, AllBurgersVaraibles>({ query: AllBurgersDocument, ...args });
}

the resolvers would pivot to looking like this:

const resolvers: IResolver<Context> = {
  Mutation: {
    addUser(_, { name }, { cache }) {
      const { burgers } = AllBurgersCacheRead({ cache });
      const newBurgers = [...burgers, { id: <something>, name } ];
      // Note, newBurgers conforms to the burgers field of AllBurgersQuery, as Data in writeQuery requires.
     AllBurgersCacheWrite({ cache, data: { burgers: newBurgers } });
    }
  }
}

I think fragments are in the same boat read and write wise, however I am not certain.

Please let me know what you think, I am not sure how complicated it would be to add.

[NickClark]

Ya, I agree. Something like this would be nice. I was needing the same except for using readFragment. Although I was thinking of another way.

Currently the signature for readFragment is readFragment<FragmentType, TVariables = any>(options: DataProxy.Fragment<TVariables>, optimistic?: boolean): FragmentType | null;

If we could get the Apollo team to also include FragmentType in DataProxy.Fragment, like DataProxy.Fragment<FragmentType, FTVariables>, then maybe we could add a type to the generated Fragments from this generator, and then just use readFragment as is and it could return the correct object. Perhaps this could be part of the ongoing issue: #713

[dotansimha]

That sounds like a great idea, @DanielMillerSEL @NickClark !
I think we can definitly generate this kind of output, maybe in a separate plugin.
@DanielMillerSEL any chance you wish to try to write this plugin? (https://graphql-code-generator.com/docs/custom-codegen/write-your-plugin)

[DanielMillerSEL]

I am curious to try, however I need to do some legal-foo on my end first. If someone hasn't taken it up by that point I will.

[dotansimha]

The solution for that will be with TypedDocumentNode. You can find more details here: #4580

[miller-productions]

The solution for that will be with TypedDocumentNode. You can find more details here: #4580

Hi @dotansimha ,

I just arrived here after reading about TypedDocumentNode and I had sort-of assumed it would be the solution, so this confirms it for me.

Would you be able to provide a small example here that summarises how you would use TypedDocumentNode in this scenario?

I suppose you would somehow replace the following line from @DanielMillerSEL 's example?

const { burgers }= cache.readQuery<AllBurgersQuery, AllBurgersVaraibles>({
        query: AllBurgersDocument
      });

[dotansimha]

If you are using TypedDocumentNode and Apollo-Client (>3.2) - you should have built-in support. Just by using readQuery({query: MyGeneratedDocument }) should give you complete type-safety :)