Easy solution for triggering re-renders with refetchQueries option after mutation

Client SDKs
,
1

Hi, today I was struggling with re-rendering a list of active participants in a transaction after a request is accepted. The query for fetching participants uses a network-only policy, so I couldn’t just update the cache. refetchQueries performed the query, but the component wouldn’t re-render. After some research, I saw in a GitHub issue that you have to pass the same variables so the component could re-render. I tried that and worked, but having to take care of passing the same variables seemed impractical, error-prone and as a code smell by itself.

After that, I saw if not passing any variable would work since the docs say that the query would use the same variables as the last time, but it would just send a request with no variables set. Then I stumbled upon an old StackOverflow question where someone talked about a function named getOperationName from apollo-link. I saw if I had that function available, and luckily it was, but from @apollo/client/utilities. This function receives the document node, in this case, the one with the query for getting participants, and returns a string with the name of the operation, which I assume is the internal name that Apollo gave to the operation, and which contains the variables used the last time. I gave it a try and worked exactly as expected. After accepting a participant, all the participant lists would be re-rendered with the new information. In practical terms, this is what I have in an onClick handler (I use codegen, and there’s where the document comes from):

`
async () => {

await updateParticipant({
variables: {}, // Here go the variables needed for updating the participant
refetchQueries: [
getOperationName(GetParticipantsDocument)!, // This does the trick
],
});

}
`

I hope this helps you!

2

I’m honestly a bit confused here - getOperationName does not add any variables to the query name or anything, it just returns the name of the operation, so for

query getParticipants { ... }

it will return the string “getParticipants”, which is what we recommend to pass in and it sounds like that also is where you started from?

Generally: network-only will initially make a network request, but after it has received the response from that, it will get updates from the cache, too. no-cache doesn’t interact with the cache at all.

3

I see the issue now. I was using

refetchQueries: [{ query: GetParticipantsQuery }]

Since that’s the example I saw. But if I use just the document node

refetchQueries: [GetParticipantsQuery]

It works the same way as with getOperationName. Speaking about the cache, I tried that first, but it would give me an error saying that the payload from the cache was undefined, that’s why I decided to use this approach instead. This is what I tried to do at first:

update: (cache, { data }) => {
  const query = cache.readQuery<GetParticipantsQuery>({
    query: GetParticipantsDocument,
  });

  const payload = query?.payload.map((participant) => {
    if (participant.uuid === data?.payload.uuid) {
      return data?.payload;
    }

    return participant;
  });

  cache.writeQuery({
    query: GetParticipantsDocument,
    data: {
      payload,
    },
  });
},

But got this error:

https://www.apollographql.com/docs/react/errors#{"version"%3A"3.12.6"%2C"message"%3A13%2C"args"%3A["payload"%2C"{\n%20%20\"payload\"%3A%20<undefined>\n}"]}

Anyways, for this case, using refetchQueries is easier than updating the cache, and it’s okay to query the API because that information is highly dynamic. But you left me thinking about the fetch policy. I’ll change network-only to no-cache since that was the one I intended to use, thanks!