@apollo/client - npm Package Versions

3.13.1

Patch Changes

• #12369 bdfc5b2 Thanks @phryneas! - ObervableQuery.refetch: don't refetch with cache-and-network, swich to network-only instead

• #12375 d3f8f13 Thanks @jerelmiller! - Export the UseSuspenseFragmentOptions type.

3.13.0

Minor Changes

• #12066 c01da5d Thanks @jerelmiller! - Adds a new useSuspenseFragment hook.

  useSuspenseFragment suspends until data is complete. It is a drop-in replacement for useFragment when you prefer to use Suspense to control the loading state of a fragment. See the documentation for more details.

• #12174 ba5cc33 Thanks @jerelmiller! - Ensure errors thrown in the onCompleted callback from useMutation don't call onError.

• #12340 716d02e Thanks @phryneas! - Deprecate the onCompleted and onError callbacks of useQuery and useLazyQuery. For more context, please see the related issue on GitHub.

• #12276 670f112 Thanks @Cellule! - Provide a more type-safe option for the previous data value passed to observableQuery.updateQuery. Using it could result in crashes at runtime as this callback could be called with partial data even though its type reported the value as a complete result.

  The updateQuery callback function is now called with a new type-safe previousData property and a new complete property in the 2nd argument that determines whether previousData is a complete or partial result.

  As a result of this change, it is recommended to use the previousData property passed to the 2nd argument of the callback rather than using the previous data value from the first argument since that value is not type-safe. The first argument is now deprecated and will be removed in a future version of Apollo Client.

  observableQuery.updateQuery(
    (unsafePreviousData, { previousData, complete }) => {
      previousData;
      // ^? TData | DeepPartial<TData> | undefined
  
      if (complete) {
        previousData;
        // ^? TData
      } else {
        previousData;
        // ^? DeepPartial<TData> | undefined
      }
    }
  );
  

• #12174 ba5cc33 Thanks @jerelmiller! - Reject the mutation promise if errors are thrown in the onCompleted callback of useMutation.

Patch Changes

• #12276 670f112 Thanks @Cellule! - Fix the return type of the updateQuery function to allow for undefined. updateQuery had the ability to bail out of the update by returning a falsey value, but the return type enforced a query value.

  observableQuery.updateQuery(
    (unsafePreviousData, { previousData, complete }) => {
      if (!complete) {
        // Bail out of the update by returning early
        return;
      }
  
      // ...
    }
  );
  

• #12296 2422df2 Thanks @Cellule! - Deprecate option ignoreResults in useMutation. Once this option is removed, existing code still using it might see increase in re-renders. If you don't want to synchronize your component state with the mutation, please use useApolloClient to get your ApolloClient instance and call client.mutate directly.

• #12338 67c16c9 Thanks @phryneas! - In case of a multipart response (e.g. with @defer), query deduplication will now keep going until the final chunk has been received.

• #12276 670f112 Thanks @Cellule! - Fix the type of the variables property passed as the 2nd argument to the subscribeToMore callback. This was previously reported as the variables type for the subscription itself, but is now properly typed as the query variables.

3.13.0-rc.0

Minor Changes

• #12066 c01da5d Thanks @jerelmiller! - Adds a new useSuspenseFragment hook.

  useSuspenseFragment suspends until data is complete. It is a drop-in replacement for useFragment when you prefer to use Suspense to control the loading state of a fragment.

• #12174 ba5cc33 Thanks @jerelmiller! - Ensure errors thrown in the onCompleted callback from useMutation don't call onError.

• #12340 716d02e Thanks @phryneas! - Deprecate the onCompleted and onError callbacks of useQuery and useLazyQuery. For more context, please see the related issue on GitHub.

• #12276 670f112 Thanks @Cellule! - Provide a more type-safe option for the previous data value passed to observableQuery.updateQuery. Using it could result in crashes at runtime as this callback could be called with partial data even though its type reported the value as a complete result.

  The updateQuery callback function is now called with a new type-safe previousData property and a new complete property in the 2nd argument that determines whether previousData is a complete or partial result.

  As a result of this change, it is recommended to use the previousData property passed to the 2nd argument of the callback rather than using the previous data value from the first argument since that value is not type-safe. The first argument is now deprecated and will be removed in a future version of Apollo Client.

  observableQuery.updateQuery(
    (unsafePreviousData, { previousData, complete }) => {
      previousData;
      // ^? TData | DeepPartial<TData> | undefined
  
      if (complete) {
        previousData;
        // ^? TData
      } else {
        previousData;
        // ^? DeepPartial<TData> | undefined
      }
    }
  );
  

• #12174 ba5cc33 Thanks @jerelmiller! - Reject the mutation promise if errors are thrown in the onCompleted callback of useMutation.

Patch Changes

• #12276 670f112 Thanks @Cellule! - Fix the return type of the updateQuery function to allow for undefined. updateQuery had the ability to bail out of the update by returning a falsey value, but the return type enforced a query value.

  observableQuery.updateQuery(
    (unsafePreviousData, { previousData, complete }) => {
      if (!complete) {
        // Bail out of the update by returning early
        return;
      }
  
      // ...
    }
  );
  

• #12296 2422df2 Thanks @Cellule! - Deprecate option ignoreResults in useMutation. Once this option is removed, existing code still using it might see increase in re-renders. If you don't want to synchronize your component state with the mutation, please use useApolloClient to get your ApolloClient instance and call client.mutate directly.

• #12338 67c16c9 Thanks @phryneas! - In case of a multipart response (e.g. with @defer), query deduplication will now keep going until the final chunk has been received.

• #12276 670f112 Thanks @Cellule! - Fix the type of the variables property passed as the 2nd argument to the subscribeToMore updateQuery callback. This was previously reported as the variables type for the subscription itself, but is now properly typed as the query variables.

3.12.11

Patch Changes

• #12351 3da908b Thanks @jerelmiller! - Fixes an issue where the wrong networkStatus and loading value was emitted from observableQuery when calling fetchMore with a no-cache fetch policy. The networkStatus now properly reports as ready and loading as false after the result is returned.

• #12354 a24ef94 Thanks @phryneas! - Fix missing main.d.cts file

3.12.10

Patch Changes

• #12341 f2bb0b9 Thanks @phryneas! - useReadQuery/useQueryRefHandlers: Fix a "hook order" warning that might be emitted in React 19 dev mode.

• #12342 219b26b Thanks @phryneas! - Add graphql-ws ^6.0.3 as a valid peerDependency

3.12.9

Patch Changes

• #12321 daa4f33 Thanks @jerelmiller! - Fix type of extensions in protocolErrors for ApolloError and the onError link. According to the multipart HTTP subscription protocol, fatal tranport errors follow the GraphQL error format which require extensions to be a map as its value instead of an array.

• #12318 b17968b Thanks @jerelmiller! - Allow RetryLink to retry an operation when fatal transport-level errors are emitted from multipart subscriptions.

  const retryLink = new RetryLink({
    attempts: (count, operation, error) => {
      if (error instanceof ApolloError) {
        // errors available on the `protocolErrors` field in `ApolloError`
        console.log(error.protocolErrors);
      }
  
      return true;
    },
  });
  

3.12.8

Patch Changes

• #12292 3abd944 Thanks @phryneas! - Remove unused dependency response-iterator

• #12287 bf313a3 Thanks @phryneas! - Fixes an issue where client.watchFragment/useFragment with @includes crashes when a separate cache update writes to the conditionally included fields.