How to update response cache when using useMutation

[yokoyama-takuya]

Thanks for awesome library!
I want to update mutation's cache without refetching, is that possible? like queryClient.setQueryData.
https://tanstack.com/query/latest/docs/react/reference/QueryClient#queryclientsetquerydata

I know can use any HTTP request method by useQuery's queryFn and useMutation's mutationFn .
Even if POST method's API, I should use useQuery?
The API is only search, but using POST method becase have many request parametes.

[TkDodo]

I think you want this: https://tanstack.com/query/v4/docs/react/guides/updates-from-mutation-responses

[yokoyama-takuya]

@TkDodo Thank you for your reply. I want to update mutation's cache.

  const mutation = useMutation<{ list: { data: string }[] }>({})
  if (mutation.data?.list) {
    // I want to change this `mutation.data.list`
  }

[TkDodo]

transform the response inside the mutationFn, before returning it

[PinkaminaDianePie]

also have this problem. it looks like mutations don't expose any setData method :(

[TkDodo]

Believe it or not, this context helps.

I need to update response cache not from the mutation response, but from the different place

The bigger underlying issue is that mutations aren't really a global state manager like queries. With a query, you can call useQuery in multiple components and it will read the same data from the same cache entry.

If you call useMutation twice in different components, you will not get the same data. If you call .mutate() in both, they will each have their own cache instance. You can see that in the devtools.

Mutations aren't "meant" for distributing data throughout your application, so really, setting data on a mutation shouldn't be something that you want.

Ideally, a mutation updates a resource on the server, and then either updates the corresponding query or invalidates it. Then, you'll use the result of the query to access data - but not the data returned from the mutation.

[PinkaminaDianePie]

Ideally

That's the key word here :) I follow this pattern in the new code, but I have some legacy stuff, like where the screen shows the result of the mutation, and this result can be changed later on by websocket-based subscription. I've thought I could mimic this behavior by updating the mutations from the caching logic to avoid any refactorings. But with those limitations in place, it's probably just easier to rewrite such places to redirect right after mutation to a page with a query.

[TkDodo]

yeah I just checked there is no API that does it. You can't even try to find the mutation in the mutationCache and then call setData because it doesn't exist.

You can call setOptions and set a new mutationFn that synchronously writes, and then call .execute() to execute it but please don't do that 😂

[PinkaminaDianePie]

You can call setOptions and set a new mutationFn that synchronously writes, and then call .execute() to execute it but please don't do that 😂

That feels too hacky, i'd rather rewrite my code to stop relying on mutation results that much :D

[TkDodo]

good call :)