Mutate update function DataProxy/ApolloCache changes #5956
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR gives the mutate
update
function direct access to the cache, instead of using a scaled downDataProxy
. While theDataProxy
approach helped in the past as a way to batch cache updates, it is no longer necessary. We are only ever passing a cache instance intoupdate
, which means limiting the type to be aDataProxy
gives us no additional advantages. The only otherDataProxy
implementor in the AC codebase isApolloClient
, which is never passed to theupdate
function. Also, if we keep usingDataProxy
in the mutateupdate
function, then every method we want to expose from the cache throughDataProxy
has to be also added toApolloClient
. This doesn't always make sense to do, especially when considering cache functions likeidentify
(e.g.ApolloClient.identify()
seems off).This PR also exposes optional
identify
andmodify
API elements inApolloCache
. Sinceupdate
now has access to the fullApolloCache
instance passed in,identify
andmodify
can be used in the update function. Note that theApolloCache
implementations ofidentify
andmodify
do nothing of value; they should be overridden byApolloCache
subclasses that are interested in using them, likeInMemoryCache
does. By including them inApolloCache
as basically no-op methods, we're avoiding forcing alternative cache implementations that subclassApolloCache
to have to support them.