Enable customization of cache normalization behavior. #5443
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
benjamn
commented
Oct 11, 2019
Comment on lines
+523
to
+526
| it("can define custom merge functions", function () { | ||
| const cache = new InMemoryCache({ | ||
| typePolicies: { | ||
| Person: { |
There was a problem hiding this comment.
In lieu of full documentation, this test case gives a pretty good illustration of how to use typePolicies and field policies to implement pagination.
benjamn
added a commit
that referenced
this pull request
Oct 11, 2019
This size will come back down once we remove the existing implementations of functionality replaced by PR #5443.
benjamn
force-pushed
the
cache-policies
branch
from
8c38aac to
a69591f
Compare
benjamn
added a commit
that referenced
this pull request
Oct 15, 2019
This size will come back down once we remove the existing implementations of functionality replaced by PR #5443.
benjamn
force-pushed
the
cache-policies
branch
2 times, most recently
from
39948f8 to
88c8ed9
Compare
benjamn
added a commit
that referenced
this pull request
Oct 15, 2019
This size will come back down once we remove the existing implementations of functionality replaced by PR #5443.
benjamn
force-pushed
the
cache-policies
branch
from
88c8ed9 to
1d6329e
Compare
benjamn
added a commit
that referenced
this pull request
Oct 16, 2019
This size will come back down once we remove the existing implementations of functionality replaced by PR #5443.
benjamn
force-pushed
the
cache-policies
branch
from
1d6329e to
f774ef2
Compare
Since we no longer have an independent readStoreResolver function, we no longer need a dedicated context type. Also took this opportunity to get rid of the pointless (and pointlessly cached) StoreReader#executeStoreQuery method.
This read hook replaces the need for cacheRedirects, and may eventually replace our local state implementation.
Instead of capturing the store:NormalizedCache object using a closure, we can pass it in as an additional context argument each time we call storeObjectMerger.merge, like we already do with mergeOverrides.
Although it was tempting to make the read function feel like a GraphQL
resolver function (parentObject, args, context, info), that signature
would not have been appropriate for the merge function, and having to
remember two totally different signatures for reading and merging did not
seem ideal.
Now, the only difference between the signatures is that the merge function
takes incoming data, to be merged with the existing data (if any):
read(existing, { args, parentObject, field, variables })
merge(existing, incoming, { args, parentObject, field, variables })
It would have been nice to use named options for everything, including the
existing and incoming parameters, but it's important for those parameters
to be positional so that the developer can specify their types, without
also having to provide a new type for the entire options object.
This size will come back down once we remove the existing implementations of functionality replaced by PR #5443.
Previously, defining a merge function for an ancestor field would prevent the merge functions of any descendant fields from being called.
hwillson
approved these changes
Oct 21, 2019
benjamn
force-pushed
the
cache-policies
branch
from
f774ef2 to
89eaf6f
Compare
|
While there's still a lot of related work I'd like to tackle—in particular, allowing |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Still a work in progress; expanded description coming soon.
In our What's new in Apollo Client 2.6 blog post, we promised:
apollo-cache-inmemorycache implementation promises to normalize your data, to enable efficient cache updates and repeated cache reads. However, not all data benefits from normalization, and the logic for deciding whether separate objects should be normalized together varies across use cases. Future versions of the Apollo Client cache will unify several related features—dataIdFromObject, the@connectiondirective, andcacheRedirects—so Apollo developers can implement specialized normalization logic, or even disable normalization for certain queries.This pull request implements (most of) those promises already, and some other related improvements are on the way. As an example, it should be possible for the Apollo Client 3.0 cache to implement local state as part of this new configuration API, allowing us to remove/unify much of the code that was added in Apollo Client 2.5.
Stay tuned for more details (and commits) next week!