@apollo/client 3.6.0

on Node.js NPM

Note: for the most up-to-date version of this information, see CHANGELOG.md

Apollo Client 3.6.0 (2022-04-26)

Potentially disruptive changes

• Calling fetchMore for queries using the cache-and-network or network-only fetch policies will no longer trigger additional network requests when cache results are complete. Instead, those complete cache results will be delivered as if using the cache-first fetch policy.
  @benjamn in #9504

• Reimplement useQuery and useLazyQuery to use the proposed useSyncExternalStore API from React 18.
  @brainkim and @benjamn in #8785 and #9596

• Fixed bug where the useLazyQuery execution function would always use the refetch method of ObservableQuery, instead of properly reapplying the current fetchPolicy using the reobserve method.
  @benjamn in #9564

  Since this reobserve method is useful and used internally, we have now exposed it as use[Lazy]Query(...).reobserve (which optionally takes a Partial<WatchQueryOptions> of new options), to supplement the existing refetch method. Note that reobserve permanently updates the variables and other options of the ObservableQuery, unlike refetch({ ...variables }), which does not save those variables.

• The internal use of options.fetchBlockingPromise by useQuery and useLazyQuery may slightly delay the delivery of network results, compared to previous versions of Apollo Client. Since network results are already delivered asynchronously, these timing differences should not be disruptive in most cases. Nevertheless, please open an issue if the timing differences cause problems for your applications.
  @benjamn in #9599

React 18

In both its peerDependencies and its internal implementation, Apollo Client v3.6 should no longer prevent you from updating to React 18 in your applications.

Internally, we have refactored useQuery and useLazyQuery to be implemented in terms of React's new (shimmable) useSyncExternalStore hook, demonstrating Apollo Client can serve as an external store with a referentially stable, synchronous API, as needed by React.

As part of this refactoring, we also improved the behavior of useQuery and useLazyQuery when used in <React.StrictMode>, which double-renders components in development. While this double-rendering always results in calling useQuery twice, forcing Apollo Client to create and then discard an unnecessary ObservableQuery object, we now have multiple defenses in place against executing any network queries for the unused ObservableQuery objects.

In upcoming v3.6.x and v3.7 (beta) releases, we will be completely overhauling our server-side rendering utilities (getDataFromTree et al.), and introducing suspenseful versions of our hooks, to take full advantage of the new patterns React 18+ enables for data management libraries like Apollo Client.

Improvements

• Allow BatchLink to cancel queued and in-flight operations.
  @PowerKiKi and @benjamn in #9248

• Add GraphQLWsLink in @apollo/client/link/subscriptions. This link is similar to the existing WebSocketLink in @apollo/client/link/ws, but uses the newer graphql-ws package and protocol instead of the older subscriptions-transport-ws implementation. This functionality was technically first released in @apollo/client@3.5.10, but semantically belongs in the 3.6.0 minor version.
  @glasser in #9369

• Allow passing defaultOptions to useQuery to avoid clobbering/resetting existing options when useQuery is called repeatedly.
  @benjamn in #9563, superseding #9223

• Provide additional context to nextFetchPolicy functions to assist with fetchPolicy transitions. More details can be found in the nextFetchPolicy documentation.
  @benjamn in #9222

• Remove nagging deprecation warning about passing an options.updateQuery function to fetchMore.
  @benjamn in #9504

• Let addTypenameToDocument take any ASTNode (including DocumentNode, as before).
  @benjamn in #9595

• Set useMutation internal isMounted variable to true again when component remounted.
  @devpeerapong in #9561

New Contributors

• @levrik made their first contribution in #9299
• @julienfouilhe made their first contribution in #9339
• @ctataryn made their first contribution in #9434
• @hennessyevan made their first contribution in #9470
• @rkoron007 made their first contribution in #9500
• @jergason made their first contribution in #9419
• @devpeerapong made their first contribution in #9561