Add updateQuery and updateFragment methods to ApolloCache

[wassim-k]

Checklist:

• If this PR is a new feature, please reference an issue where a consensus about the design was reached (not necessary for small changes)
• Make sure all of the significant new logic is covered by tests

Hi,

We love apollo client in our company and use it for all of our state management needs in our project.
With the help of graphql-code-generator, we're able to write 100% type-safe state management code, whether it's from server or client only schema and we quite like using the schema as the layer of abstraction for our state's structure.
This PR is about two helper methods we've been using for quite some time, they're just a more concise way to do common operations, like reading from state, modifying it then writing it back, I hope you find it useful for other users too.

From the example in the docs, this PR allows rewriting this logic:

const data = client.readQuery({ query });

client.writeQuery({
  query,
  data: {
    todos: [...data.todos, myNewTodo],
  },
});

Into:

client.modifyQuery({ query }, data => ({ todos: [...data.todos, myNewTodo] }));

Please let me know if you have any questions or suggestions.

[benjamn]

@wassim-k Thanks for suggesting and implementing and testing this API!

We are technically in the final (release candidate) phase of Apollo Client 3.4 testing (no new features before launch), but we should be able to add this API (or something similar) in the next minor version, v3.5. If you see us create a release branch/PR for v3.5 without revisiting this PR, please feel free to ping me here.

[brainkim]

Ben and I spoke about this off-GitHub and think there’s merit to functionality like this. Some thoughts:

• This kind of method is usually named something like updateXXX(); see lodash for example (https://lodash.com/docs/#update). Additionally, calling it modifyXXX() might be confusing because there is already a cache.modify() method, which does slightly different things.
• Why does this diverge from the cache.readXXX()/cache.writeXXX() APIs, by taking two parameters as opposed to one? The alternative would be to pass an update function as the data property of the first parameter (cache.updateQuery({ data: () => {}, query })).
  But then this raises the question, can we just detect if the data property is a function in the cache.writeXXX() methods? We use this pattern in a lot of places, though I hate it. For instance, nextFetchPolicy can be a function, and I’m sure I’ve seen this pattern used elsewhere.

[benjamn]

I took the liberty of renaming to updateQuery and updateFragment—same length as modifyXXX and less easily confused with cache.modify, as @brainkim pointed out.

I think the reason for the separate function parameter is just brevity: if you put that function into the options, it suddenly needs a property name:

cache.updateQuery({ query }, data => transform(data))
cache.updateQuery({ query, update: data => transform(data) })

We could later decide to support both ways of passing the function, but the shorter version has my vote (for now) if we have to pick one.

[benjamn]

I'm happy to merge and keep iterating on the release-3.5 branch (if need be). Thanks again for implementing this idea @wassim-k!

[wassim-k]

You're very welcome, thanks for merging it in :)

[benjamn]

Changes are now available in @apollo/client@3.5.0-beta.8, jfyi.