refetch vs invalidating query

[ytnytn1]

Hello!
In the documentation how to invalidate queries after mutations I can see that it is suggested to use query invalidation. I'm curious what if instead of invalidation use refetching ? Won't give the same effect?

Thanks in advance!

[TkDodo]

I'm curious what if instead of invalidation use refetching ? Won't give the same effect?

invalidation is a more "smart" refetching. Refetching will always refetch, even if there are no observers for the query. invalidation will just mark them as stale so that they refetch the next time an observer mounts. For queries with active observers, there is no difference as far as I'm aware.

[markivancho]

@TamirCode I believe there is a better alternative - await queryClient.prefetchQuery({ queryKey, queryFn }) for your use case

[paulosborne]

@TkDodo is there a reason why useQuery doesn't return an invalidate function alongside refetch? it feels a bit janky to have to import useQueryClient and then call invalidateQueries or refetchQueries

[TkDodo]

refetch is just returned because it's needed to bypass enabled: false for an imperative approach (that I personally don't like).

Usually, invalidation and showing the actual query doesn't happen in the same component. Invalidation often happens as a result of a mutation, which means you'll have a custom hook somewhere that wraps useMutation. That hook doesn't have access to the return values of useQuery, so it's not helping here. Cases where you have both in the same component are rare and adding 1 line of code to those isn't really a problem

[jgarplind]

I think I have found a difference that should probably be considered under certain circumstances: invalidateQueries will deduplicate in-flight requests preferring the first sent request (see #608) whereas refetch (as well as refetchQueries) will cancel in-flight requests i.e. preferring the last sent request (see bottom of https://tanstack.com/query/latest/docs/framework/react/reference/useQuery).

Typically, this is not a concern, but in rare scenarios this can matter, e.g.:

1. GET-request for key X already in-flight, with server-side logic finished before no. 2
2. mutation finishes, and requests another cache invalidation for key X (using the common pattern onSuccess: invalidate X)
3. Since the GET-request is still in-flight, no. 2 never causes a new request
4. Now the GET-request returns, but it contains stale data, since any server-side logic was run before no. 2

While this timing seems unlikely, it has happened enough to be a nuissance but too little to be reproducable on demand in our chatty CQRS-oriented architecture.

Now, I am hoping that a few strategic replacements of invaliateQueries in favour of refetch/refetchQueries will reduce the risk for stale state to practically impossible.

[TkDodo]

invalidateQueries will deduplicate in-flight requests preferring the first sent request

no it doesn't. you're referencing a discussion from 2020, and this behaviour was changed in v4:

• https://tanstack.com/query/v5/docs/framework/react/guides/migrating-to-react-query-4#consistent-behavior-for-cancelrefetch