Release 3.2.0 #6774
Merged
Release 3.2.0 #6774
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
When I `npm pack`ed @apollo/client and `npm install`ed it into a test application, I found it simpler if @apollo/client depended directly on @graphql-typed-document-node/core, so that I didn't have to install that package explicitly in the test application. We already get complaints from folks who don't realize they need to install the graphql package (a peer dependency of @apollo/client), so I can easily imagine how much confusion would be caused by needing to explicitly install graphql-typed-document-node/core, too. @dotansimha Enjoy that boost in download counts!
feature: added support for automatic type inference with `typed-document-node`
When application code evicts an object or its fields from the cache, and those evictions trigger network requests, the network data is often vital for repairing the damage done by the eviction, even if the network data look exactly the same as the previously-written data. In other words, after any cache eviction, we should disable the logic introduced in PR #6448 to stop query feuds. This exception is reasonable because feuding queries only write additional data into the cache, rather than evicting anything, so we can safely assume evictions do not contribute to a cycle of competing cache updates. I freely admit the method of counting evictions that I've implemented here is a bit of a hack, but it works for any ApolloCache implementation, without requiring the public ApolloCache API to support any new functionality. If we identify any other potential consumers of this information, we might consider a more official API.
If result.partial is logically false, letting it remain undefined (and thus falsy) is also allowed by the ?:boolean type of the field. We should be consistent about omitting the partial field when it's falsy, unless we want to be consistent about making it always either true or false, which would likely be a more disruptive change.
PR #6221 began enforcing fetch policies more consistently/literally in response to cache updates (so we do not accidentally skip network requests that are required by policy). That consistency has been valuable, but there are some exceptions where we want to deliver a single result from the cache, but we do not want to use the fetchQueryObservable system to deliver it, because we do not want the delivery to have the side effect of triggering a network request under any circumstances, regardless of the fetch policy. For example, we want to deliver a { loading: true, networkStatus: NetworkStatus.fetchMore } result for the original query at the beginning of a fetchMore request (see #6583), but that one-off result should not cause the original query to fire a network request if the cache data happens to be incomplete, because that would likely interfere with the fetchMore network request. At the time I implemented #6583, it was the only exception that I knew of, so I kept things simple and fetchMore-specific. I've since found another example (not fetchMore-related this time), so I think it's time to make this pattern more official. Hence ObservableQuery#observe, whose name is meant to draw a contrast with the ObservableQuery#reobserve method. The observe method simply delivers the latest result known to the ObservableQuery, reading from the cache if necessary, whereas reobserve reapplies the chosen fetch policy, possibly making network requests.
I first attempted to solve this bug in #6419, but that approach was flawed, and we ultimately reverted it in #6493. Both of these changes happened shortly before the AC3 launch (rc.3 and rc.9, respectively). The key to this solution is that diff.fromOptimisticTransaction is only ever set by the InMemoryCache broadcast code, when we know that we've just performed an optimistic transaction, and we're broadcasting to a query watcher that requested optimistic data. The QueryInfo class receives this broadcast, and uses diff.fromOptimisticTransaction to decide whether to do a full reapplication of the chosen fetch policy by calling oq.reobserve(), or simply to deliver a single cache result by calling oq.observe().
This essentially undoes commit b239124, which was introduced as part of PR #6221. I remember thinking, as I made that commit, "This change shouldn't be necessary, but it seems harmless enough." As it turns out, changing these tests was not necessary, but was instead a symptom of overreacting to the delivery of optimistic mutation results. I'm happy to be putting things back the way they were.
This code was migrated from the `apollo-link-persisted-queries` repo, and modified to work with Apollo Client 3.
We've decided to avoid falling back in a particular SHA-256 function by default, to avoid bundling one with Apollo Client. `crypto-hash` is now only using for testing.
We're no longer providing a SHA-256 function by default, so these changes ensure that an appropriate function is provided by developers. Developers can choose to supply a SHA-256 function via the `sha256` option, if they want the default hash generation capabilities of the Link (e.g. sha256(print(query))), or they can override the hashing process completely by supplying a custom `generateHash` function.
These changes also ensure that the tests cover supplying a sync or async SHA-256 function.
Move apollo-link-persisted-queries functionality to @apollo/client/link/persisted-queries.
Using the default ErrorPolicy of "none" for queries means no data will be written to the cache when a GraphQL result has errors. Queries can use errorPolicy:"ignore" and errorPolicy:"all" to ensure data is written to the cache in spite of GraphQL errors, but mutations and subscriptions were previously limited to the default policy, "none". This commit makes mutations and subscriptions respect the non-default "ignore" and "all" ErrorPolicy values, just as queries do, hopefully addressing #6965.
glasser
reviewed
Sep 11, 2020
Merged
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.
This PR will serve to collect significant new features, deprecation warnings, and minor breaking changes that we intend to release in
@apollo/client@3.2.0.So far the list includes:
TypedDocumentNode<Data, Variables>(@dotansimha in feature: added support for automatic type inference withtyped-document-node#6720)useReactiveVarhook for consuming reactive variables in React components (@benjamn in Implement useReactiveVar hook for consuming reactive variables in React components. #6867)writeFragmentcannot identifyoptions.datawhen nooptions.idprovided (@jcreighton in Throw when writeFragment cannot identify object #6859)masterbranch tomaincache.modify:details.storageanddetails.INVALIDATE(@benjamn in Improvements for cache.modify: details.storage and details.INVALIDATE #6991)ObservableQueryinupdateObservableQueryeven ifskipistrue(@mu29 in fix: Initialize query on updateObservableQuery even if skip is true #6999)apollo-link-persisted-queriesfunctionality to@apollo/client/link/persisted-queries(@hwillson in Migrate apollo-link-persisted-queries functionality into Apollo Client #6837)errorPolicyfor mutation and subscription results (@benjamn in Respect errorPolicy for mutation and subscription results. #7003)If you want to test these changes, run
in your application, where the
nin-beta.ncomes from the most recent commit message likeUntil v3.2.0 is released, we can continue merging smaller changes into
mainand releasing them, without worrying about larger changes on therelease-3.2branch.