Understanding Tanstack Query as state
Hey there!
I am hoping someone can help me understand the concept of using Tanstack Query (React Query) as a state manager? I have been reading articles and even playing around with some code myself on how lots of people love using TQ as a state management tool. The idea that your state lives on server-side and you app simply reads from query/cache. This of course seems really cool especially for say data tables etc.
But I am struggling to understand the concept of possibly using that for something that is maybe more traditionally aa client-side state but moving it to server side? Let's say you have user's preferences stored in the database. You could store things like, what colour theme they're using and maybe some other things. You use TQ to fetch this data from the server so on load we know what theme the user has chosen, but now we want them to be able to change their theme choice! Traditionally we'd just use a useState or a Zustand store and our Theme Provider can base what it is showing off that state. Is the idea with TQ that we would trigger a mutation (edit the user's preferences) and then invalidate the TQ query on the user's theme provider so that the theme then updates? So the state is sort of doing a round-trip?:
User changes theme -> mutation to the database -> invalidate database theme query -> UI updates theme
Is this the recommended pattern? In my head this works perfectly fine but just feels a bit clunky or slow? Other options being:
User loads page -> TQ pulls state from database -> state is loaded into something like Zustand -> User changes theme (through zustand) -> UI updates immedietly -> mutation goes to the database
Perhaps there's some guides/teachings on this issue? I'm struggling to find much and usually articles only focus on using localStorage which is not what I want!
5 Replies
rare-sapphire•2mo ago
your assumption that the UX could be "clunky or slow" is fair. your logic of "user changes theme -> ..." is correct. there's some things you can do to improve the UX
instead of "User changes theme -> mutation to the database -> invalidate database theme query -> UI updates theme", you can instead return all of the necessary data you need in the
useMutation call and then update the query cache appropriately. so inside your useMutation usage you would put queryClient.setQueryData(...) in the onSuccess callback
another thing you can do is use optimistic updates which is talked about here and herevicious-gold•2mo ago
To add to what @DaK said, additionally
Is this the recommended pattern?Yes, it is the recommended pattern, even though it is heavier on the network (as you will refetch the data after the mutation), it is the easiest to implement. You can anytime go in and optimize parts of your UI to use optimistic updates or/and setting data in the cache manually from the response of the mutation. Another thing to take into consideration is, what a mutation updates. As a single mutation can modify multiple resources on the backend, so you will want to invalidate all of the related resources.
solid-orange•2mo ago
You can have mutation do an optimistic update as well.
ambitious-aqua•2mo ago
Since this state is going to be saved to external store TQ is the right choice. And just like @zorro said, to avoid waiting for data to come back from db you can do optimistic update.
fascinating-indigoOP•4w ago
Okay great this is all very reassuring thank you everyone! 😃