Should queryCache/queryClient clear trigger a refetch?

[aaronjensen]

It appears that when calling clear() on queryCache (v2) or queryClient (v3) if a query is active, it will not be refetched until the component that has the useQuery is rerendered. This was very surprising--I would have expected it to clear all data and then immediately refetch (complete with isLoading = true). As far as I can tell, there's no way easy to do that right now. Is there supposed to be a way to do this?

My use case is that I have a top level query for the user session, which is effectively null (or an error) when the user is not signed in. Once the user is signed in, I want to clear the query cache and let that refetch in order to get the current user's session (I also want to clear all other queries so that they can be refetched anew for the newly current user).

Thanks!

[tannerlinsley]

Calling refetchQueries after should do the trick

[aaronjensen]

Thanks for the quick response. Unfortunately, it doesn't appear to because once they're cleared, they're gone from the cache/client so there's nothing to refetch. You can try it out here: https://codesandbox.io/s/react-query-2-refetch-on-error-5v4pk?file=/src/App.js

[aaronjensen]

V3 has the same issue: https://codesandbox.io/s/react-query-3-refetch-on-error-ux360?file=/src/App.js

[TkDodo]

@aaronjensen I think clear does nothing more than remove everything from the cache. I don't think this is a good idea to do while you have active subscribers, as you do in the example.

Regarding your use case: When the user clicks logout, I would probably call clear(), and then redirect to the login route. There, you would certainly be able to refetch the session key, because you mount the login view (refetchOnMount). Or, if you are not mounting for some reason, you could add the userId to the queryKey, which would also trigger a re-fetch if the userId then becomes null or so.

At least that is how I would do it: clear the cache when the user logs out, rather than after they have logged in ...

[aaronjensen]

Yep, you got it. And yeah, I considered option 1, but was hoping to get away without that (it couples the login request to the session request as the login request must now return the same data the session request has).

Re: 2, I believe refetch only works if I fetch it explicitly (i.e. with fetchQuery)

And yeah, w/ 3 the extra state is undesirable.

Is there a reason that there isn't a way to actually clear a query's cache without also unsubscribing the active queries? I'm sure no one wants yet another way to reset queries, but even @tannerlinsley was under the impression that clear works differently than it actually appears to.

[TkDodo]

Is there a reason that there isn't a way to actually clear a query's cache without also unsubscribing the active queries?

I think if you clear the cache, you have no subscribers anymore. A subscriber is defined by their presence in the cache. Now maybe we could clear the cache and then re-render all previous subscribers, but that would immediately add them to the cache again. What you want would maybe be something like reset thats available for mutations, which re-sets them to the "initial state" as if they were just created...

setQueryData(key, undefined)

There are three important states:

Not yet loaded
Loaded but undefined
Loaded and defined
There's no easy way to reset to state 1, and that's where I'm trying to get.

I see, but I don't think it's a very common case. Setting the query data to undefined, and then showing the loading spinner depending on that (isLoading || data === 'undefined') might do it. "Loaded but not defined" could use null for that.

Another approach would be that react-query re-sets to the initial state with hard loading if you setQueryData to undefined, but that sounds very breaking. If we really want a way to reset to state 1, I think we would need a new reset method. But given that there are so many good solutions to your problem, I personally don't think it's needed.

[aaronjensen]

Now maybe we could clear the cache and then re-render all previous subscribers, but that would immediately add them to the cache again.

Yes, this is what I want. It's maximally surprising to me that clearing the cache removes subscribers. It feels like it's counter to the way React and effects should work because it puts everything into a nonsensical state where a re-render will return it to a sensible state. Now, it's possible that there are scenarios where clear's behavior as it is is necessary, perhaps when clearing while changing some other state that would also cause any active useQuery's to unmount, so you really don't want them to resubscribe.

The suggestions about introducing a new state can work, but they won't work for suspense. For that, I'd need to actually change the query and/or force a rerender in some way.

A reset method that would behave as I expected clear to would be great, though I would be hesitant to suggest adding a new method. Since 3.0 is right around the corner, a breaking change could be introduced, but it may be late in the game for that. I would not suggest the breaking change of changing the behavior setQueryData, that would be surprising. Instead, clear could be a bit less nuclear and not clear subscriptions (only data). This could potentially be behind a flag.

I do realize this is a bit of an edge case, but I can't I'm the first to want to clear data so it is no longer visible (loading) and refetch it.

[TkDodo]

I think clear is mostly used to remove all entries in the cache when someone logs out. At that point, you have no active subscribers anymore. Again, what you want is a clear cache data, not a clear cache, which is what clear does. That's fundamentally different imo. I would prefer the extra method, because that's already what we have for mutations as well (reset).

[tannerlinsley]

I would be interested in a PR for reset functionality and what it might look like.

[tannerlinsley]

I still think the best way is to clear on logout before the new auth components are mounted. This emulates a new entry into the app.

The other way would be to loop over all the queries in the cache and remove the ones that have no active observers, then refetch all queries that are active.

[aaronjensen]

@tannerlinsley thanks, but see my previous response to @TkDodo. Clearing on logout is a separate thing that won't help because I actually have a query even in the signed out scenario (to see if the user is signed in).

What I want is to be able to clear a query's data while still having its observers maintained and have it refetch essentially as if it was a brand new query.

[tannerlinsley]

Ah. So why not just setQueryData(key, undefined) and refetch? Tanner Linsley

…

On Dec 7, 2020, 8:48 PM -0700, Aaron Jensen ***@***.***>, wrote: @tannerlinsley thanks, but see my previous response to @TkDodo. Clearing on logout is a separate thing that won't help because I actually have a query even in the signed out scenario (to see if the user is signed in). What I want is to be able to clear a query's data while still having its observers maintained and have it refetch essentially as if it was a brand new query. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[aaronjensen]

Unfortunately, that never sets isLoading to true again, so there's no difference between that and the state it was previously in where the data was undefined because the original query resulted in undefined.

There are three important states:

1. Not yet loaded
2. Loaded but undefined
3. Loaded and defined

There's no easy way to reset to state 1, and that's where I'm trying to get.

[tannerlinsley]

I've opened a PR with rough support for query.reset(), queryClient.reset(query), queryClient.resetAll(), and queryClient.resetQueries(filters)

It still needs tests and documentation, but I don't have enough time right now to do those. Hopefully this is enough to get people started and finish the job. If ya'll can get it done relatively quickly, it can come out in the main v3 release.

[barrymichaeldoyle]

Is this dead? :(