@apollo/client 3.8.0

v3.8.0

on Node.js Yarn

Minor Changes

Fetching with Suspense 🎉

• #10323 64cb88a4b Thanks @jerelmiller! - Add support for React suspense with a new useSuspenseQuery hook.

  useSuspenseQuery initiates a network request and causes the component calling it to suspend while the request is in flight. It can be thought of as a drop-in replacement for useQuery that allows you to take advantage of React's concurrent features while fetching during render.

  Consider a Dog component that fetches and renders some information about a dog named Mozzarella:

  View code 🐶

  import { Suspense } from 'react';
  import { gql, TypedDocumentNode, useSuspenseQuery } from '@apollo/client';
  
  interface Data {
    dog: {
      id: string;
      name: string;
    };
  }
  
  interface Variables {
    name: string;
  }
  
  const GET_DOG_QUERY: TypedDocumentNode<Data, Variables> = gql`
    query GetDog($name: String) {
      dog(name: $name) {
        id
        name
      }
    }
  `;
  
  function App() {
    return (
      <Suspense fallback={<div>Loading...</div>}>
        <Dog name="Mozzarella" />
      </Suspense>
    );
  }
  
  function Dog({ name }: { name: string }) {
    const { data } = useSuspenseQuery(GET_DOG_QUERY, {
      variables: { name },
    });
  
    return <>Name: {data.dog.name}</>;
  }

  For a detailed explanation of useSuspenseQuery, see our fetching with Suspense reference.

• #10755 e3c676deb Thanks @alessbell! - Feature: adds useBackgroundQuery and useReadQuery hooks

  useBackgroundQuery initiates a request for data in a parent component and returns a QueryReference which is used to read the data in a child component via useReadQuery. If the child component attempts to render before the data can be found in the cache, the child component will suspend until the data is available. On cache updates to watched data, the child component calling useReadQuery will re-render with new data but the parent component will not re-render (as it would, for example, if it were using useQuery to issue the request).

  Consider an App component that fetches a list of breeds in the background while also fetching and rendering some information about an individual dog, Mozzarella:

  View code 🐶

  function App() {
    const [queryRef] = useBackgroundQuery(GET_BREEDS_QUERY);
    return (
      <Suspense fallback={<div>Loading...</div>}>
        <Dog name="Mozzarella" queryRef={queryRef} />
      </Suspense>
    );
  }
  
  function Dog({
    name,
    queryRef,
  }: {
    name: string;
    queryRef: QueryReference<BreedData>;
  }) {
    const { data } = useSuspenseQuery(GET_DOG_QUERY, {
      variables: { name },
    });
    return (
      <>
        Name: {data.dog.name}
        <Suspense fallback={<div>Loading breeds...</div>}>
          <Breeds queryRef={queryRef} />
        </Suspense>
      </>
    );
  }
  
  function Breeds({ queryRef }: { queryRef: QueryReference<BreedData> }) {
    const { data } = useReadQuery(queryRef);
    return data.breeds.map(({ characteristics }) =>
      characteristics.map((characteristic) => (
        <div key={characteristic}>{characteristic}</div>
      ))
    );
  }

  For a detailed explanation of useBackgroundQuery and useReadQuery, see our fetching with Suspense reference.

Document transforms 📑

• #10509 79df2c7ba Thanks @jerelmiller! - Add the ability to specify custom GraphQL document transforms. These transforms are run before reading data from the cache, before local state is resolved, and before the query document is sent through the link chain.

  To register a custom document transform, create a transform using the DocumentTransform class and pass it to the documentTransform option on ApolloClient.

  import { DocumentTransform } from "@apollo/client";
  
  const documentTransform = new DocumentTransform((document) => {
    // do something with `document`
    return transformedDocument;
  });
  
  const client = new ApolloClient({ documentTransform: documentTransform });

  For more information on the behavior and API of DocumentTransform, see its reference page in our documentation.

New removeTypenameFromVariables link 🔗

• #10853 300957960 Thanks @jerelmiller! - Introduce the new removeTypenameFromVariables link. This link will automatically remove __typename fields from variables for all operations. This link can be configured to exclude JSON-scalars for scalars that utilize __typename.

  This change undoes some work from #10724 where __typename was automatically stripped for all operations with no configuration. This was determined to be a breaking change and therefore moved into this link.

  For a detailed explanation of removeTypenameFromVariables, see its API reference.

New skipToken sentinel ⏭️

• #11112 b4aefcfe9 Thanks @jerelmiller! - Adds support for a skipToken sentinel that can be used as options in useSuspenseQuery and useBackgroundQuery to skip execution of a query. This works identically to the skip option but is more type-safe and as such, becomes the recommended way to skip query execution. As such, the skip option has been deprecated in favor of skipToken.

  We are considering the removal of the skip option from useSuspenseQuery and useBackgroundQuery in the next major. We are releasing with it now to make migration from useQuery easier and make skipToken more discoverable.

  useSuspenseQuery

  import { skipToken, useSuspenseQuery } from "@apollo/client";
  
  const id: number | undefined;
  
  const { data } = useSuspenseQuery(
    query,
    id ? { variables: { id } } : skipToken
  );

  useBackgroundQuery

  import { skipToken, useBackgroundQuery } from '@apollo/client';
  
  function Parent() {
    const [queryRef] = useBackgroundQuery(
      query,
      id ? { variables: { id } } : skipToken
    );
  
    return queryRef ? <Child queryRef={queryRef} /> : null;
  }
  
  function Child({ queryRef }: { queryRef: QueryReference<TData> }) {
    const { data } = useReadQuery(queryRef);
  }

  For a detailed explanation of skipToken, see its API reference.

New error extraction mechanism, smaller bundles 📉

• #10887 f8c0b965d Thanks @phryneas! - Add a new mechanism for Error Extraction to reduce bundle size by including error message texts on an opt-in basis.

  By default, errors will link to an error page with the entire error message.
  This replaces "development" and "production" errors and works without
  additional bundler configuration.

  Bundling the text of error messages and development warnings can be enabled as follows:

  import { loadErrorMessages, loadDevMessages } from "@apollo/client/dev";
  if (process.env.NODE_ENV !== "production") {
    loadErrorMessages();
    loadDevMessages();
  }

  For a detailed explanation, see our reference on reducing bundle size.

New @nonreactive directive 🎬

• #10722 c7e60f83d Thanks @benjamn! - Implement a @nonreactive directive for selectively skipping reactive comparisons of query result subtrees.

  The @nonreactive directive can be used to mark query fields or fragment spreads and is used to indicate that changes to the data contained within the subtrees marked @nonreactive should not trigger re-rendering. This allows parent components to fetch data to be rendered by their children without re-rendering themselves when the data corresponding with fields marked as @nonreactive change.

  Consider an App component that fetches and renders a list of ski trails:

  View code 🎿

  const TrailFragment = gql`
    fragment TrailFragment on Trail {
      name
      status
    }
  `;
  
  const ALL_TRAILS = gql`
    query allTrails {
      allTrails {
        id
        ...TrailFragment @nonreactive
      }
    }
    ${TrailFragment}
  `;
  
  function App() {
    const { data, loading } = useQuery(ALL_TRAILS);
    return (
      <main>
        <h2>Ski Trails</h2>
        <ul>
          {data?.trails.map((trail) => (
            <Trail key={trail.id} id={trail.id} />
          ))}
        </ul>
      </main>
    );
  }

  The Trail component renders a trail's name and status and allows the user to execute a mutation to toggle the status of the trail between "OPEN" and "CLOSED":

  View code 🎿

  const Trail = ({ id }) => {
    const [updateTrail] = useMutation(UPDATE_TRAIL);
    const { data } = useFragment({
      fragment: TrailFragment,
      from: {
        __typename: "Trail",
        id,
      },
    });
    return (
      <li key={id}>
        {data.name} - {data.status}
        <input
          checked={data.status === "OPEN" ? true : false}
          type="checkbox"
          onChange={(e) => {
            updateTrail({
              variables: {
                trailId: id,
                status: e.target.checked ? "OPEN" : "CLOSED",
              },
            });
          }}
        />
      </li>
    );
  };

  Notice that the Trail component isn't receiving the entire trail object via props, only the id which is used along with the fragment document to create a live binding for each trail item in the cache. This allows each Trail component to react to the cache updates for a single trail independently. Updates to a trail's status will not cause the parent App component to rerender since the @nonreactive directive is applied to the TrailFragment spread, a fragment that includes the status field.

  For a detailed explanation, see our @nonreactive reference and @alessbell's post on the Apollo blog about using @nonreactive with useFragment.

Abort the AbortController signal more granularly 🛑

• #11040 125ef5b2a Thanks @phryneas! - HttpLink/BatchHttpLink: Abort the AbortController signal more granularly.

  Before this change, when HttpLink/BatchHttpLink created an AbortController internally, the signal would always be .aborted after the request was completed. This could cause issues with Sentry Session Replay and Next.js App Router Cache invalidations, which just replayed the fetch with the same options - including the cancelled AbortSignal.

  With this change, the AbortController will only be .abort()ed by outside events, not as a consequence of the request completing.

useFragment drops its experimental label 🎓

• #10916 ea75e18de Thanks @alessbell! - Remove experimental labels.

  useFragment, introduced in 3.7.0 as useFragment_experimental, is no longer an experimental API 🎉 We've removed the _experimental suffix from its named export and have made a number of improvements.

  For a detailed explanation, see our useFragment reference and @alessbell's post on the Apollo blog about using useFragment with @nonreactive for improved performance when rendering lists.

  useFragment improvements

  • #10765 35f36c5aa Thanks @phryneas! - More robust types for the data property on UseFragmentResult. When a partial result is given, the type is now correctly set to Partial<TData>.

  • #11083 f766e8305 Thanks @phryneas! - Adjust the rerender timing of useQuery to more closely align with useFragment. This means that cache updates delivered to both hooks should trigger renders at relatively the same time. Previously, the useFragment might rerender much faster leading to some confusion.

  • #10836 6794893c2 Thanks @phryneas! - Remove the deprecated returnPartialData option from useFragment hook.