DEV Community: Eric Endo

Avoiding refetch to update Apollo Client cached data (React)

Eric Endo — Sat, 27 Feb 2021 14:19:20 +0000

TLDR

Include updated fields in mutation response: Apollo will do their magic 🪄 and update the cached data. No need to refetch().

If you use Apollo Client (with hooks please!) in your React project, chances are that you have already done something like this to update the data after a mutation:

const GET_POST = gql`
  query GetPost($id: ID!) {
    post(id: $id) {
      id
      title
      description
    }
  }
`

const UPDATE_POST = gql`
  mutation UpdatePost(
    $id: ID!,
    $title: "String,"
    $description: "String"
  ) {
    updatePost(
      id: $id,
      title: "$title,"
      description: "$description"
    ) {
      id
    }
  }
`

function PostDetails({ id }) {
  const { data, refetch } = useQuery(
    LIST_POSTS,
    { variables: { id } }
  )
  const [updatePost] = useMutation(UPDATE_POST)

  async function editPost(formValues) {
    await updatePost({ variables: formValues })
    refetch() // <-- do we really need it?
  }

  // ...render and other component parts
}

Can we avoid the refetch() after updatePost() (thus avoiding one unnecessary request)? Yes, by simply adding some fields to the mutation return:

const UPDATE_POST = gql`
  mutation UpdatePost(
    $id: ID!,
    $title: "String,"
    $description: "String"
  ) {
    updatePost(
      id: $id,
      title: "$title,"
      description: "$description"
    ) {
      id
+     title
+     description
    }
  }
`

Why does this work? To answer this, we need to understand two Apollo concepts first: data caching and cache updating.

For the caching part:

Apollo Client stores the results of its GraphQL queries in a normalized, in-memory cache. This enables your client to respond to future queries for the same data without sending unnecessary network requests.

For the updating part:

In order for Apollo Client to update the cache automatically, we have to remember to always return the new data in operation responses.

For query responses, that’s the point. The entire purpose of a query is to return data and cache it.

But for mutations, like editTodo that change a single entity, we should be able to update the item automatically if we return the value in the mutation response.

So, for mutations like this one from the example (a single entity with id), just include updated fields in the mutation response: Apollo will do their magic 🪄 and update the cached data. No need to refetch().

But... what about other cases, when entities have no id field or mutations that change data related to the updated entity, for example?

This Apollo Blog post (already linked in the updating part) talks about some strategies for those cases - but we can talk more about those cases in one (or more) post(s) in the future.

PS 1: English is not my native language. Feel free to suggest any corrections, point grammatical errors, and etc.

PS 2: check the original post here (in Brazilian Portuguese)

Cover background image by SpaceX

Como evitar refetch para atualizar os dados do cache do Apollo Client (React)?

Eric Endo — Tue, 23 Feb 2021 19:51:55 +0000

TLDR

Inclua os valores atualizados no retorno da mutation. O Apollo vai fazer sua mágica 🪄 e atualizar os dados do cache, sem precisarmos utilizar o refetch().

Se você usa Apollo Client (com hooks, por favor!) na sua aplicação React, chances de você já ter feito algo desse tipo para atualizar os dados após uma mutation:

const GET_POST = gql`
  query GetPost($id: ID!) {
    post(id: $id) {
      id
      title
      description
    }
  }
`

const UPDATE_POST = gql`
  mutation UpdatePost(
    $id: ID!,
    $title: "String,"
    $description: "String"
  ) {
    updatePost(
      id: $id,
      title: "$title,"
      description: "$description"
    ) {
      id
    }
  }
`

function PostDetails({ id }) {
  const { data, refetch } = useQuery(
    LIST_POSTS,
    { variables: { id } }
  )
  const [updatePost] = useMutation(UPDATE_POST)

  async function editPost(formValues) {
    await updatePost({ variables: formValues })
    refetch() // <- precisamos mesmo disso?
  }

  // ...render e demais partes do component
}

O ponto é: esse refetch() após o updatePost() pode ser evitado (consequentemente evitando uma requisição desnecessária), simplesmente adicionando alguns campos no retorno da mutation:

const UPDATE_POST = gql`
  mutation UpdatePost(
    $id: ID!,
    $title: "String,"
    $description: "String"
  ) {
    updatePost(
      id: $id,
      title: "$title,"
      description: "$description"
    ) {
      id
+     title
+     description
    }
  }
`

Por que isso funciona? Pra entender melhor, precisamos entender dois conceitos do Apollo: como ele cacheia os dados, e como ele atualiza os dados cacheados.

Para a parte do cacheamento (tradução livre):

o Apollo Client armazena os resultados de suas queries GraphQL em um cache normalizado, na memória. Isso possibilita que seu cliente responda a queries futuras envolvendo os mesmos dados sem enviar requisições de rede desnecessariamente.

Para a parte da atualização (tradução livre):

Para o Apollo Client conseguir atualizar o cache automaticamente, temos que lembrar de sempre retornar os novos dados nas respostas das operações.

Para respostas de queries, esse é o ponto. Todo o propósito de uma query é retornar dados e cacheá-los.

Mas para mutations, como o editTodo que alterar uma única entidade, nós devemos ser capazes de atualizar o item automaticamente se retornarmos o valor na resposta da mutation.

Então para mutations como essa do exemplo, de uma única entidade e que possua id, basta incluírmos os valores atualizados no retorno da mutation que o Apollo faz sua mágica 🪄 e atualiza os dados do cache, sem precisarmos utilizar o refetch().

Mas... e quando estamos falando de outros casos, quando as entidades não possuem um campo id, ou de mutations que impactam dados derivados da entidade atualizada, por exemplo?

Este post do Apollo Blog (que eu já linkei na parte da atualização) fala de algumas estratégias - mas isso pode ser algo para discutirmos mais em um (ou alguns) post(s) futuro(s).

Imagem de fundo da capa por SpaceX