Differentiating useQuery data changes - Mutation vs Refresh from server

[nitzansan]

Hi everybody.
Been trying to look for a related discussion but couldn't find anything.

I was wondering if there's a built-in ability to differentiate between changes coming from Mutate operations to changes coming from Server "refresh" (meaning a new data was returned while revalidating).

This seems to me something quite trivial that should've been part of the API and common usage patterns.
Basically my usage is:
I have a page with several editable components, that can potentially be edited by multiple users at the same time.
Because the changes and multi-editing for this page are not that frequent, I want to load it immediately from the cached data and ignore the entire isFetching mechanism, since I don't need to introduce loading mechanism there.

When I first load it and fetch the entity with useQuery I parse the data into a relevant object.
When I update a component, I use mutate and update the data locally, triggering a new process of parsing the data and resulting in a new object and new reference (which is a good thing).
When useQuery revalidates the data and a new data arrives, this is a fresh data from the server and I want to display a fake 1 second loader with the message "syncing from server" or something similar, only in the components that changed.

This way, I get to have a seamless experience and only interfere the user's experience when needed and in a minimal way.
The problem is that I cannot differentiate the data changes between the two potential sources easily.
The only solution I see right now is to set some boolean state "hasMutated" on mutate success and then when useQuery data changes check this bool and act accordingly (and obviously turn it off afterwards).
Does this sound like a good workaround solution?
My expectations from the library would've been to have some boolean on useQuery, similar to isFetching which helps you to identify this (e.g isRefreshedData boolean)

Thank you kindly and hope this entire thing makes sense. 😅

[nitzansan]

@tannerlinsley - Would love to hear your thoughts, specially about this being part of the API. 👨‍🏫

[tannerlinsley]

Hmm, I could go either way. It's true that with a bit of tagging on your data, you could easily signify to your app which is which. And I think that's for sure a valid workaround. If we were to make it a part of the api, we would really need to think about the ergonomics of it and what we're really trying to achieve. If the real usage is to know where an update came from, we would need to be wholistic about that and do it everywhere, since updates can come from many official sources like refreshings, rehydration, etc and also arbitrary sources (custom mutations).

I'll talk about it with the team and see what happens.

[nitzansan]

Makes a lot of sense that the actual tagging will be "wholistic", and I'm pretty sure that this kind of tagging would prove to be useful for consumers.
I was pretty shocked to see that no one talked about this before, since communicating with the user after a change has been detected should be a common UX pattern and for that you need this kind of change-source identification.

I have to say that in general I think it would be extremely helpful and educative to have some UX patterns examples for modern web-applications using react-query. Seems like right now it's mostly used by static-content sites and web-app developers still trying to figure out how to best utilize and workaround some missing functionalities for web-apps.

And getting back to the actual topic - the work around that I'm going to do will have it's limitations, specifically when trying to manage multi-tab sessions (as discussed here - #336).
Would love having both functionalities available by the library itself.

Thank you very much for taking the time to read and think about this things. I really do love the library and the work you're doing! 💪