queryClient.setQueryData dirty state

[hoetmaaiers]

I am looking for a clean way to know when my queryClient data is dirty. Maybe the 'dirty' terminology is not immediately clear, so I try to clarify this:

Whe useQuery I fetch data from the server, e.g. I fetch a Point on a geographical map. In my application I visualise this Point data on it's edit page. All edit changes are local and persisted in the QueryClient via setQueryData. I persist these local changes in queryClient because other components also visualise this temporary data.
In this scenario the data in queryClient is 'dirty' because it doesn't resemble the data on the server.

When I move away from the form I want to warn the user about unsaved changes. To define 'unsaved' changes I am looking for some kind of dirty state.

Am I just using wrong terminology or am I looking for something that is not possible with react-query?

[TkDodo]

I don't think that you should be using the queryClient as a "local" state manager. if you are using background updates or other forms of re-fetches, your data will be overwritten by the server state.

the idea is that you and the queryClient don't own the state - it's just a view of what is on the server, which is as up-to-date as you like it / make it. The only way I am ever writing to the query cache is:

• for optimistic updates
• to write data back to the cache after a mutation instead of invalidating

I would suggest that you keep the "edits" that the user makes separate from the queryClient. Can be in local react state, or another state manager like zustand or even redux.

Your local data is then dirty if it's not undefined, which is a very easy check :)

I have written about this concept here: https://tkdodo.eu/blog/practical-react-query

[hoetmaaiers]

Thank you for sharing your thoughts. I also experimented with mutating the queryClient cache, but works more against then with react-queries defaults.

For completeness: I now manage 'dirty' state in both parent (component) state and In Zustand.

[manjunath-satyamurthy]

@TkDodo I don't understand why should we limit ourselves to not use the queryClient cache as local state manager. I think for many scenarios it works perfectly well. Especially when react-query does provide ways to enable or disable background updates,

doesn't it make sense to stop background updates and refetches when user is editing and continue after its pushed to the server.

As an end user, I also would expect the same, not to be magically have new entries or be removed while I am editing !

[TkDodo]

doesn't it make sense to stop background updates and refetches when user is editing and continue after its pushed to the server.

you can definitely do it, I just think it's not really worth it. You'd have to turn off all automatic refetches, and potentially disable the query, but you still cannot stop everything: If refetch is called manually or the query is invalidated manually, it might still refetch. This is a minor point and you can just "not do it" in your code, so it will likely work.

I just think it's better to keep things separated, as the whole idea of server state and client state was to separate the two, because they have different needs. We've had them managed together in redux for a long time and moved away from this, and I'd personally rather not have them together again, even if everything is in react-query.

Another thing: Suppose you open an edit form that edits some entity (maybe a todo), and you write that directly to the queryCache: All observers in your app will be informed about that change, even though your state is considered ephemeral. Most of the time, I don't want that - I'd rather keep that state in the edit form only (local state), and only make it globally available once the user hits Apply - in which case the mutation happens and we're back to the two points I mentioned above.

YMMV and it might be a good idea in some scenarios. But in those cases, I think you're also better off just adding a dirty?: boolean flag to your state and set that to true when you write to the cache.