Manually update Apollo cache after GraphQL mutation

Ensuring that GraphQL mutations properly update your Apollo client's cache can be a bit tricky - here's how to manually control that.

Unless a mutation mutates a single existing entity, you'll need to use a specific update function to ensure data updates returned by the mutation are propagated.

Your call to the useMutation hook can take an update callback function, which takes two arguments: a DataProxy object allowing you to interact with Apollo's cache store, and a FetchResult object containing data returned by the mutation.

The DataProxy object can be interacted with using readQuery and writeData methods to read existing cache data and update entries, respectively.

// This mutation is something that does not represent an existing entity,
// note that no ID is returned.
const SOME_MUTATION = gql`
  mutation ($something: String!) {
    foo (something: $something) {
      result
      info
      bar {
        id
        one
        two
      }
    }
  }
`;

const BAR_QUERY = gql`
  query ($id: ID!) {
    bar (id: $id) {
      id
      one
      two
    }
  }
`;

function Foobar() {
  const [mutate, { data }] = useMutation(SOME_MUTATION);

  // Run the mutation at component mount
  useEffect(
    () => {
      mutate({
        variables: { something: 'something' },
        update: (store, { data: { foo: { bar } } }) {
          store.writeQuery({
            query: BAR_QUERY,
            data: { bar },
            variables: { id: bar.id }
          })
        }
      })
    }
  )

  return <div>{data && JSON.stringify(data)}</div>;
}

When you then execute BAR_QUERY with any of the fetchPolicy options that involve reading from cache, you'll find that the cache will work.

Note that it could often be a better idea to think about how to remodel the resource so that it can have an id field returned by the API, or configuring the cache with a dataIdFromObject function to infer an ID from the type so that it can be treated as something cacheable. Nonetheless, it's good to keep the writeQuery solution in mind, as you don't always have control over the API you need to consume.