Release 3.3.0 #7015
Merged
Release 3.3.0 #7015
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
force-pushed
the
release-3.3
branch
from
40ded37 to
f2dd9c3
Compare
There's no harm in returning an empty TypePolicy object for an unrecognized type name, so we can simplify this code by removing the option to prevent initial policy creation. Future commits will allow type policies to be inherited according to possibleTypes, which means an intermediate subtype can have inherited policies even if it does not have its own entry in typePolicies. It will be simpler to implement that behavior if we always initialize the policy the first time we call getTypePolicy for a particular type.
Passing typePolicies to the InMemoryCache constructor is something that typically happens during application startup, so it's important that the processing of typePolicies does not become a performance problem. Fortunately, we don't have to do all the processing of typePolicies until we actually look up a given type policy for the first time, which might occur much later in the lifetime of the application for some types. Once we implement inheritance of typePolicies, there will often be supertype-subtype relationships among the types listed in typePolicies. Without the laziness introduced by this commit, it would be necessary either to keep typePolicies in supertypes-before-subtypes (topological) order, or for addTypePolicies somehow to sort the types topologically. Fortunately, that careful ordering/sorting becomes completely unnecessary thanks to the laziness, because none of the types can be used until all of them have been registered.
Support inheritance of typePolicies, according to possibleTypes.
Instead of recursively searching for FieldValueToBeMerged wrapper objects anywhere in the incoming data, processSelectionSet and processFieldValue can build a sparse tree specifying just the paths of fields that need to be merged, and then applyMerges can use that tree to traverse only the parts of the data where merge functions need to be called. These changes effectively revert #5880, since the idea of giving merge functions a chance to transform their child data before calling nested merge functions no longer makes as much sense. Instead, applyMerges will be recursively called on the child data before parent merge functions run, the way it used to be (before #5880).
We know what these functions do, so we can detect them by reference and then just do what they would have done, without creating a complete options object or actually calling mergeTrueFn or mergeFalseFn.
Preserve retained EntityStore root IDs across cache.{extract,restore}.
In the context of a larger cache read operation, accessing a reactive variable automatically associates the variable with the cache, so future updates to the variable can be broadcast to the cache. Outside this context, it may not be possible for the variable to discover the currently active cache. For example, there is no currently active cache in asynchronous ApolloLink code (#7338). Since we recently added a `reactiveVar.forgetCache(cache)` in #7279, I think it makes sense to have a manual way to do the opposite, which I have decided to call `reactiveVar.attachCache(cache)`. Although this attachment is manual at the moment, in a hypothetical future where the client/cache manage the persistence of reactive variables, it should be easy to attach the appropriate cache to those variables when they are first initialized, which would enable reactive updates from literally anywhere, with no additional effort by the developer.
Implementing the idea I described in this comment: #7324 (comment)
Follow-up to #7094, to avoid enabling validation by default, since @apollo/client@3.3.0 is not a major release.
This allows us to publish v3.3.0 without triggering a ton of updates just yet. When we're ready, we will switch the tag from `next` to `latest`.
Merged
2 tasks
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.
Like the Release 3.2.0 PR, this PR will serve to collect significant new features, deprecation warnings, and minor breaking changes that we intend to release in
@apollo/client@3.3.0.If you want to test these changes, run
in your application, where the
nin-beta.ncomes from the most recent commit message likeUntil v3.3.0 is released, we can continue merging smaller changes into
mainand releasing them, without worrying about larger changes on therelease-3.3branch.