Status of useMutation not shared across usages/components with custom hook (like useQuery does)

[bennettdams]

Describe the bug

Imagine creating a custom hook (let's name it useTodos) which is used in multiple components and uses useQuery and useMutation inside.
When using useQuery, its status (and the helpers isLoading, isError, ...) are shared across multiple usages of useTodos.
For useMutation, this is not true. Every usage of useTodos will have its own mutation status.

To Reproduce

Here's a CodeSandbox that shows the behavior.

It shows two components that both use useTodos.
For GET requests (via useQuery), the status is shared across the components.
For POST requests (via useMutation), the status is different for both components. Only the component who executes the mutation will have the status "error".

Expected behavior

I understand that useQuery has one precise query key to identify "the same hook". Mutations are not like that.
In my case, I had a list that showed items (like "Todos") and a child component that was supposed to create a new item (like "Todo"). Naturally, I used useTodos in both components and wanted to show an error in the List component. The problem is isError was never true, only the child component's one was.

function TodoList() {
  // this "isError" here will never be true, only the <Todo> component's "isError" will
  const { todos, isError } = useTodos();

  return (
    <div>
      <p>Todos:</p>
      {isError && <p>Error!</p>}
      <div>
        {todos.map((todo) => (
          <Todo todo={todo} />
        ))}
      </div>
    </div>
  );
}

function Todo({ todo }: { todo: Todo | null }) {
  const { createTodo } = useTodos();

  return (
    <div>
      {todo ? (
        <p>{todo.title}</p>
      ) : (
        <div>
          <button onClick={() => createTodo(...)}>Create</button>
          <input ... />
           ...
        </div>
      )}
    </div>
  );
}

I'm using React Query for a while now and being used to useQuery having a shared status, I wasted time checking my mutation implementation ("Why is the error not thrown?" etc.), but in reality useQuery and useMutation just behave differently and differently than expected.

I would really like to let useMutations share their status across all components.
There's already a mutationKey, which could maybe used for this exact use case.

[TkDodo]

Yes, I was also surprised by this, but mutationKey is not required, unlike the queryKey, so we can't really create a subscription like for useQuery. Mutations are also imperative so it just doesn't happen very often I guess. What we do have is the useIsMutating hook, similar to the useIsFetching hook, so that you know when a mutation is in-flight, and you can filter these by mutationKey. With that, you can e.g. disable all buttons that would trigger the same mutation. Not sure how that would fix the error situation though - but you can take a look how to create a subscription to the mutationCache by looking at the impl of useIsMutating:

https://github.com/tannerlinsley/react-query/blob/master/src/react/useIsMutating.ts

[bennettdams]

@TkDodo Thanks for the feedback and possible workaround.
I could also create my own React context and save isError or isLoading there, so all components have the same status - I just thought it'd be nice to let React Query provide this out of the box.
Feel free to move this issue to the discussions, so we keep it there as a "feature request".

[VolodymyrBaydalka]

I have similar "Idea" under the discussions section - #2294

[TkDodo]

Feel free to move this issue to the discussions, so we keep it there as a "feature request".

let's keep here, I'd like to analyze how hard it would be to actually use the mutationKey to achieve that functionality, or if that would be a breaking change.

[Noitidart]

I always attach mutationKey and then got to the part where i needed to share if it ever succeeded or failed count and same thing. Thanks for bringing up this topic, it was first hit on search engine. I should have searched first rather then assume.

[stefan-toubia]

I was very surprised to find this out today when my mutation hook wasn't working as expected. I've also run into issues like the one described here as well as #2294. Losing transient mutation state like isLoading or error when your component changes contexts is unfortunate.

It made me start to wonder why there's such a strong conceptual distinction between queries and mutations, when at the end of the day they're both just abstractions around some promise that returns data, generally an HTTP request.

You could almost use useQuery in place of useMutation today if it exposed the imperative functions like mutate and mutateAsync and if it had a callback like onMutate. The key difference between the two hooks seems to come down to configuration, e.g. queries execute on lifecycle events by default, mutations do not retry by default, etc. I could imagine both of these hooks being thin wrappers around some other hook that provides all the common functionality, such as useRequest. This could even simplify some of the internals for RQ - one cache instead of separate query and mutation cache.

I could easily be overlooking some important details or underestimating the complexity, but I do agree that the state behavior of useMutation is not intuitive and inconsistent with useQuery.

[TkDodo]

@stefan-toubia it is something that is on my mind for quite some time. What if mutations were conceptually "just" disabled queries, where mutate or mutateAsync just calls refetch() 🤔 .

Not only would that get rid of a ton of internal code (MutationCache, Mutation, MutationObserver, ...), it would also, at the same time, add a lot of features for mutations, like sharing data, select and other options.

Of course, we could still turn off some of the options and / or set different default values for useMutation.

However, when I went down that road, there is one thing that works inherently different from queries:

useQuery instantly creates an observer, but useMutation only does it after .mutate is called. Further, if you call .mutate multiple times, the previous observer is unsubscribed automatically. That is necessary so that callbacks of .mutate are only called once. However, callbacks on useMutation itself are actually cache level callbacks, which will execute any time the mutation succeeds / fails, even if the observer has already unmounted. That is important, and something that doesn't exist on the query cache itself.

Feel free to take a look at the implementation (best on v4 directly, alpha branch), the road would need to be a merging of the two slightly different functionalities. Would love to have it but I don't have enough time to look into it right now :)

[nextrapi]

Just thought to provide code for another workaround for this issue, which doesn't require manually keeping state but still allows different components to share the same mutation object. As mentioned, just wrap a react context around the custom hook and the desired functionality will be achieved.
https://codesandbox.io/s/silent-frost-mjxlrf?file=/src/App.js

const CustomMutationProvider = ({ children }) => {
  const mutation = useMutation({
    mutationKey: "UpdateData",
    mutationFn: async () => {
      // Fake api call
      await new Promise((resolve, reject) => setTimeout(reject, 2000));
    }
  });
  return (
    <CustomMutationContext.Provider value={mutation}>
      {children}
    </CustomMutationContext.Provider>
  );
};
const CustomMutationContext = React.createContext();
const useCustomMutation = () => React.useContext(CustomMutationContext);

And use like so:

const queryClient = new QueryClient();
export default function App() {
  return (
    <div className="App">
      <QueryClientProvider client={queryClient}>
        <CustomMutationProvider>
          <ComponentA />
          <ComponentB />
        </CustomMutationProvider>
      </QueryClientProvider>
    </div>
  );
}
const ComponentA = () => {
  const { mutate, status } = useCustomMutation();
  return (
    <div>
      <h1>Component A </h1>
      Status: {status}
      <br />
      <button onClick={mutate}>Update</button>
    </div>
  );
};
const ComponentB = () => {
  const { mutate, status } = useCustomMutation();
  return (
    <div>
      <h1>Component B </h1>
      Status: {status}
      <br />
      <button onClick={mutate}>Update</button>
    </div>
  );
};

[welcomemax]

If I understood the reason correctly, the following worked for me:

// workaround for https://github.com/TanStack/query/issues/2304
// instead of useIsMutating
const [isMutating, setIsMutating] = useState(false);
useEffect(() => {
  return queryClient.getMutationCache().subscribe(({ type, mutation }) => {
    if (
      type === 'updated' &&
      mutation.options.mutationKey?.[0] === 'KEY' // your predicate here
    ) {
      setIsMutating(mutation.state.status === 'loading');
    }
  });
}, []);

[cdpark0530]

I got into this today. My current workaround is

function useShippingZone() {
  const address = useAppSelector(selectAddress);
  const queryKey = ["getShippingZone", address.zipCode];
  const result = useQuery(queryKey, getShippingZone, {
    meta: address as IndexSignature<typeof address>,
  });
}

async function getShippingZone({ meta }: QueryFunctionContext<...>) {
  const address = meta as unknown as Address;
  ...
}

type IndexSignature<O extends object> = {
  [P in keyof O]: O[P] extends object ? IndexSignature<O[P]> : O[P];
};

where you need to pass variables through meta option. (which is very vulnerable in typing, and not really recommended as other developers wouldn't think that's what meta should be used for). But for this case where I anyway save address in a global state, I think it's worth to do.

[antoniel]

Based on @TkDodo answers #2304 (comment), I've implemented my useCustomMutation that uses useQuery to share data between components.

My first use-case that requires that useMutation share data across components was a multi-step form in react-native (ps: in react-native, the stack navigation doesn't unmount the previous screen) where at the first page, we need to get an AuthToken, we do it onPress of a button by the user, so it makes sense to be a mutation at this point, but I faced that if I need to get the token on subsequent screens, it will not be there, so that's why of the implementation.

The useCustomMutation follows the exactly same API of useMutation

export const useCustomMutation = <TData = unknown, TError = unknown, TVariables = unknown, TContext = unknown>(
  mutationKey: MutationKey,
  mutationFn: MutationFunction<TData, TVariables>,
  options?: Omit<UseMutationOptions<TData, TError, TVariables, TContext>, 'mutationKey' | 'mutationFn'>
): UseMutationResult<TData, TError, TVariables, TContext> => {
  const query = useQuery<TData, TError>(
    ['CustomMutation', mutationKey],
    async () => await Promise.resolve(false as unknown as TData),
    { retry: false, cacheTime: Infinity, staleTime: Infinity }
  )
  const queryError = useQuery<TError, TData>(
    ['CustomMutationError', mutationKey],
    async () => await Promise.resolve(false as unknown as TError),
    { retry: false, cacheTime: Infinity, staleTime: Infinity }
  )
  const mutation = useMutation<TData, TError, TVariables, TContext>(
    mutationKey,
    async (...params) => {
      queryClient.setQueryData(['CustomMutationError', mutationKey], false)
      return await mutationFn(...params)
    },
    {
      ...options,
      onSuccess: (data, variables, context) => {
        queryClient.setQueryData(['CustomMutation', mutationKey], data)
        if (options?.onSuccess) options.onSuccess(data, variables, context)
      },
      onError: (err, variables, context) => {
        queryClient.setQueryData(['CustomMutationError', mutationKey], err)
        if (options?.onError) options.onError(err, variables, context)
      },
    }
  )
  const isLoading = useIsMutating(mutationKey)

  // We need typecasting here due the ADT about the mutation result, and as we're using a data not related to the mutation result
  // The typescript can't infer the type correctly.
  // eslint-disable-next-line @typescript-eslint/consistent-type-assertions
  return {
    ...mutation,
    data: query.data,
    isLoading: !!isLoading,
    error: queryError.data,
    isError: !!queryError.data,
  } as UseMutationResult<TData, TError, TVariables, TContext>
}

You can find it also on a gist: https://gist.github.com/antoniel/1f8d59f7e3f73487e5ba02a293fb39ec