Why useMutation is designed as not able to share status and data between multiple component?

[Brandon-Ln]

I am new to React Query and trying to use it to server state management.

I have a login business process that can be simplified like below:

1. An unrecognized user types some info and clicks the button to trigger a POST request api/check.
2. Render the next page route(ps: another component) if the api/check receives data successfully.
3. The user may fire a different POST request like api/send-code-a depending on the api/check received data when they do the next action.

Personal thoughts

It is obvious that both api/check and api/send-code-a will cause side effects on the server(for instance api/check may cause graphical captcha verification in some situations) and both need to be invoked manually. So I chose useMutation to encapsulate my custom data fetching hook.

Confusion

The trouble here is becaz api/check and api/send-code-a is fired in a different component(or route), and as the docs said:

Another difference is that mutations don't share state like useQuery does.

So the custom useCheckMutation hook in the next page route can not access the cached data in the previous route which makes it hard to extract request handled process abstraction.

1. After reading the docs I think this could be done by mixing using useQuery and useMutation for useQuery can access cache data by using the same query key, however, it seems like a hacky implementation in this common use case(maybe?)
2. I know in the React world, we have some methods like State hoisted or useContext to share state, but these look verbose and unsuitable (maskedAccount is OK but what about captchaTicket or processToken? The UI does completely not care about latter.)
3. I have already used React Query as a server state store, It seems a bit strange to separate some pieces of server-side data into other modules if I use global variables to store the shared responses.

Questions

1. Why useMutation is designed not like a global store via mutation key? It seems like a intended decision
   What are the considerations behind it?
2. What is the recommended practice in this common situation? Did I understand some concepts incorrectly?

It is grateful in advance for reading this long text. It would be much appreciated if anyone could try to answer it. :)

[TkDodo]

Why useMutation is designed not like a global store via mutation key?

Because every time you invoke a mutation by calling mutate or mutateAsync, you create a new mutation. So if you mutate twice, there will be two mutations for the same key. That's a fundamental difference to queries, where there can only ever be one entry for a key, and multiple calls to the queryFn will be deduplicated. There is no deduplication for mutations. If you do mutate('foo') and mutate('bar'), it will be two requests, and two mutations in the MutationCache.

What is the recommended practice in this common situation?

Usually, you use a mutation to make a change on the server, then you have a query to request the resource that was changed by the mutation to share data for that resource. So whatever your api/check and api/send-code-a did change, I would have a query api/get-the-thing and return that.

if that's not possible, we have a new hook useMutationState in v5 that can give you access to all mutations for a mutationKey, for example:

// Get all data of all "post" mutations
const data = useMutationState({
  filters: { mutationKey: ['posts'] },
  select: (mutation) => mutation.state.data,
})

note that useMutationState will always return an array, even there is only one invocation, and you cannot trigger further mutations from it. But it will always show state like it is in the MutationCache, so it's a way to "subscribe" to those changes.

[Brandon-Ln]

Thanks for your detailed reply!

You have mentioned that the key difference between useMutation and useQuery is that each mutation operation is processed independently(even if the mutation key or arg is the same), but why? Is this because the returned data of the backend mutate API is unstable, making it unsafe to share across multiple components compared to query API? I know that there seems to be a concept of idempotence in backend interfaces.

In my current use case, simplified code like the below:

  // component A
  const { data, mutateApi } = useCheckAccountMutation(args);
  if (data.maskedAccount) {// '[email protected]'
    navigate("to component B");
  }

  // component B
  const { data } = useCheckAccountMutation(args); // The args is consistent with those passed in component A
  console.log(data.maskedAccount, data.accountId); // undefined undefined
  const { mutateApi } = useSendCodeMutation(data.accountId)

So the problem here seems to be that the resource is returned through a mutation API response, rather than through an extra resource query API. The mutation API response should be some transient status rather than resources. Ideally, maybe I should discuss a more reasonable API design with the backend developers.

In a nutshell, React Query seems to need to work with the interfaces that follow CRUD semantic convention to get full value. If my understanding is incorrect, please feel free to correct me.

[TkDodo]

but why?

it's because requests shouldn't be deduped. If I call addTodo twice at the same time, I'd want to have two todos added, not just the first one. That's the difference to queries where "give me all todos" can be deduplicated into the same promise, even if multiple components request the same data at the same time.

--

in your example, component B can read the state of the mutation done by component A via useMutationState