When might I want to use removeQueries instead of invalidateQueries and vice-versa

[Aaronius]

The removeQueries documentation is a bit limited. It isn't really clear what effect calling removeQueries might have on active or inactive queries (maybe none?) or why I might want to use invalidateQueries instead. Could someone give me a brief primer please?

[TkDodo]

removeQueries has no effect on active queries. If a component re-renders for some reason that then tries to use the removed query, it will go into hard loading state again. Not sure why you'd ever want to remove an active query...

invalidateQueries is something completely different. It:

• marks all matching queries as stale, so that they will be refetched the next time they are used
• active queries will be immediately refetched per default (unless you change the options)

invalidation never removes something from the cache, it just refetches.

[Aaronius]

Thanks @TkDodo. I think I'm not really understanding how a query in cache marked as stale affects components using a useQuery hook. I see you mentioned so that they will be refetched the next time they are used but I'm maybe I'm not understanding what the next time they are used means. I don't think I exactly understand what "active query" means either.

To illustrate, we have an app with two routes (using react-router). Assuming the user goes to Route A, we render a component that uses useQuery with a query key of todos. The data loads and it's rendered. The user then goes to Route B and clicks a button. If, in the button's onClick handler, we call removeQueries, and the user navigates back to Route A, they don't see any stale data. The query is immediately in the loading state. However, if we instead call invalidateQueries from the button's onClick handler and the user navigates back to Route A, they see stale data for a brief moment before fresh content is fetched. We'd prefer the user never sees stale data in this case, so we're leaning toward calling removeQueries, but I think we might just be misunderstanding invalidateQueries. Is this behavior we're seeing expected? Perhaps something else in our app code is playing into this; I haven't tried creating a super simple reproduction.

[TkDodo]

I see you mentioned so that they will be refetched the next time they are used but I'm maybe I'm not understanding what the next time they are used means.

the points when stale queries will be refetched are described here: https://react-query.tanstack.com/guides/important-defaults
there is also a good example in the docs: https://react-query.tanstack.com/guides/caching

lastly, I've blogged a lot about this topic already, I can suggest starting here: https://tkdodo.eu/blog/practical-react-query

[Aaronius]

Thanks @TkDodo!

[nathanhannig]

If you edit some data related to a record, and return the user back to the record's page, removeQueries() works well so you don't show them the previous version of data they just edited while the query is refetching.

[TkDodo]

What if you do a mutation that modifies a record on the server, and you want to make RQ freshly refetch that record the next time it is accessed

you're describing exactly what invalidateQueries does.

isn't "remove" what clears that entry from the RQ cache?

yes, it removes it, which means the next time you use it, you get a "hard loading state". With invalidation, you'll still see the stale data, but because it is marked as stale, it will be refetched in the background and you'll see new data.

There's a reason why the docs and all examples focus on this pattern rather than doing things like remove / reset / refetch: It has the best UX and is the easiest to get right for developers.

"Refetch" to me means making another network request to get a new/fresh response and data, but here you're saying it refetches but doesn't clear the cache

yes, refetch does make another network request. But why do you need to clear the cache before you make that network request? Maybe that's where the confusion comes from?

So to me it sounds like you're saying, RQ makes a new network request, but then ignores it and still uses a cached response anyway, which doesn't make sense.

No, that's not what I'm saying. What it does is it:

• gives you the old, cached data
• makes a network request
• then gives you the new data

As opposed to:

• gives you nothing so you have to render a loading spinner
• makes a network request
• then gives you the new data

This is literally what happens when you click the refetch button in the devtools. We don't delete data. We just replace it with new data once it comes in.

[graup]

With invalidation, you'll still see the stale data, but because it is marked as stale, it will be refetched in the background and you'll see new data.

This means that until it's refetched, you see stale data. Sometimes that's fine but sometimes you want to make sure users don't see any stale data. Then you have to remove, right? Since a query object only has remove and refetch (and nothing like reset), does it make sense to call both of them? If my mutation is in the same component as the query, is it ok to remove() and refetch() in the mutation's onSuccess?

[TkDodo]

use queryClient.resetQueries() if you want that

[jrnxf]

@TkDodo would love your take on this:

I think the new hydration changes to react query v5 expose a valid use case for remove queries IMO. Since hydration changes now occur in an effect, if I redirect a user to a route thats entry point is an RSC that prefetches data, and I know that query might be cached and I want to avoid a flicker of stale data (bc of hydration in a useEffect) removing the potentially cached query before navigating knowing the RSC will prefetch and supply seems like an elegant solution.

Do you disagree?

[jrnxf]

you're describing exactly what invalidateQueries does.

Not exactly - invalidateQueries will clear cache and immediately refetch, but you might not need to refetch right then and there, at which point removeQueries would be preferable. Niche use case maybe, but worth mentioning

[madrasaty-tech]

I used removeQuery when the user in my app logged out and than logged again with different account, the initial value of the profile was the old account, I didn't want that to happen, so instead of using invalidateQuery ( which didn't solve the problem ) , I used removeQuery to remove any cached data about the user who logged out , that is one reasonable case I encountered and I believe there is a lot more cases out there to use removeQuery.

[ZeCarlosCoutinho]

Same issue here.
From what @TkDodo was saying on the comments above, when you use invalidateQueries, the queries become stale. So, next time a component asks for the data, the query will:

1. Give the old, stale values in the cache.
2. Fetch fresh values on the background and re-render when done.

This does not work in the case when a user logs in with a different account, because in 1), the query would provide the values of the previous account that were stored in cache (which could potentially be a data privacy issue!)

Instead, if you use removeQueries, all the cached queries are removed, so when the user logs in another account, the queries can only provide new, correct values.

So, to reply to @TkDodo in this:

Not sure why you'd ever want to remove an active query...

Probably, when a user logs out 😉 But I guess he already knows this since he is one of the contributors to this repo xD

[TkDodo]

Probably, when a user logs out

At which point you probably redirect to the login page where the query isn't "active"

[KGSands]

What if you use user for the RouterContext (e.g. for permissions) - it would still be active on login?