useQuery callbacks don't run after unmount, useMutation callbacks do

[vincerubinetti]

It seems that the onSuccess/onError/onSettled callbacks will run if the component is quickly unmounted while the fetch/fn is still in progress, but only in useMutations, not useQuerys. Here's a minimal reproduction of the difference:

https://codesandbox.io/s/react-query-unmount-req3pu

I can see use cases for either behavior. Perhaps there should be some kind of option, and make both of them work the same way by default for consistency?

Regardless, what's a good work around for doing an "unmount" cleanup action on a useQuery. My (simplified) use case, where
I have an app-global notification "toast".

  const { data } = useQuery({
    queryKey: ["analyze"],
    queryFn: () => {
      notification("Analyzing");
      return analyze(...blahblahblah);
    },
    onSuccess: () => clearNotification(),
    onError: () => notification("Error analyzing"),
  });

I want to clear the notification (associated with this query) when the current component, which it is logically associated with, unmounts, because it will no longer be relevant to the user. But the callbacks don't fire if the user navigates away or otherwise unmounts the component while queryFn is still running.

My solution right now is to just use React's useEffect cleanup:

  useEffect(() => {
    return () => {
      clearNotification();
    };
  }, []);

But with React 18's double mounting-unmounting, I guess this isn't ideal.

Is a more RQ idiomatic way to do this? Could useQuery support some kind of onUnmount callback, or maybe that would be subject to the same React 18 weirdness? Could useQuery callbacks actually run after unmount to be made consistent with useMutation, and leave it to the developer to check if the component is still mounted (breaking change)?

[TkDodo]

useQuery callbacks are observer level callbacks, so they are the same as callbacks on .mutate. They are thus bound to the lifecycle of components they are mounted in.

useMutation callbacks are the "exception" here, because they always run.

For global callbacks, you'd want the global cache level callbacks, because, again, the callbacks on useQuery are observer level callbacks, which means if you call useQuery twice (e.g. via a custom hook), onSuccess will also be called twice, showing two notification.

• https://tanstack.com/query/v4/docs/react/reference/QueryCache#global-callbacks
• https://tkdodo.eu/blog/react-query-error-handling#the-global-callbacks

[vincerubinetti]

Thanks, I think this is what I was looking for.

Since I only need this to apply to one particular query, I'm checking against the query.queryKey like so:

const queryClient = new QueryClient({
  ...otherStuff,
  queryCache: new QueryCache({
    onSuccess: (_, query) => {
      if (query.queryKey[0] === "analyze") clearNotification();
    },
    onError: (_, query) => {
      if (query.queryKey[0] === "analyze")
        notification("error", "Error analyzing");
    },
  }),
});

[lehnerchristian]

Hi!

We had a similar problem where we pass callbacks to the mutate and whenever the a mutation starts running and the component triggering this mutation is being unmounted immediately the onSuccess and onError callbacks are not being executed. Our use-case is that we have a dropdown menu component to copy documents for example. If the user clicks this menu item it should be closed but the user should be notified when the copy process is done.
The easiest workaround that we found was to use mutateAsync instead of the normal mutate and we chain directly onto the promise to call the callbacks ourselves because this way the promise chain is not bound to any React lifecycle.

And to be honest I think it's a bit of a weird behavior that when the component that triggers the mutation is unmounted the rest of the logic after the mutation is done, i.e. the callbacks, is swallowed and magically disappears 🤔

What do you think?

[TkDodo]

I think you're using the wrong callbacks and that the accepted answer in this discussion points to all the resources that you need to make this right.

[TkDodo]

okay sorry, I misread the accepted answer. The correct resources to read are:

• https://tkdodo.eu/blog/mastering-mutations-in-react-query#mutate-or-mutateasync
• https://tanstack.com/query/latest/docs/react/guides/mutations#mutation-side-effects

[lehnerchristian]

Thx for your quick reply, @TkDodo 🚀

Yeah, I do understand that it happens as it's also mentioned in the docs, but I don't quite get why not running the callbacks in the case of a quickly unmounted component is a desired behavior? Mentioning the why this happens or why that's desired in the docs might also shed some light on that for future people discovering that "problem" 🙂

[TkDodo]

yeah, it's in my blog: callbacks on .mutate are bound to the component lifecycle to do component related side-effects, like setting local state, or redirecting to a different page, which you wouldn't want unconditionally.

As an extreme example, suppose you're on a detail page and your mutation to update the entry takes some time. In the meantime, the user navigates away. Now in onSuccess, you'd want to redirect the user back to the list page for that resource. But this likely doesn't make sense to happen if the user has already navigated away for themselves ...