Combining Zustand with React Query
Vložit
- čas přidán 8. 09. 2024
- 🚀 Project React → cosden.solutio...
📥 Import React (Newsletter) → cosden.solutio...
Source Code → github.com/cos...
Join The Discord! → discord.cosden...
VSCode Theme | Font → Material Theme Darker | Menlo, Monaco "monospace"
In this video I will show you the correct way to combine Zustand with React Query, two very popular libraries that don't even need to be combined together because of how good they are! But they definitely can if you need them to. Just be careful because there is a right way to do it, and a wrong way to do it. I will show you both.
Destcruturing elements from zustand store will lead to rerenders if something in the store is changed, even if you don't destructure it. Better to do it like: const filters = useUserStore((state) => state.filters)
Didn’t even know. Going to push some fixes to my repo at work tomorrow.
yes that is true I learnt it the hard way
you could use useShallow to prevent such behavior if you want to destructure the states
Much appreciated. I started implementing React Query on top of Zustand and started to think, why this sounds like duplicating data. Great and simple explanation.
as an entry level developer, with no work experience, i got that part at the very begining when i tryed tanstack query. i guess now i can be proud! :D great channel btw
Can't wait for the next video: Combining Redux with Zustand and React Query
смешно смешно 😂
Man im just building this now. Are you stalking me? :D Great content!
on the website the example they have is they make 2 types, one describing state and the other type describing actions then create the store saying create. It might be overkill but I thought it helped make the code a little easier to read. Especially if their are more than one actions assigned to a state.
Great explanation, thank you for the clarification between the client and server state management!
This is what I've been looking 😊 thank you
Use Zustand for anything related to UI like theme, colors, settings, etc.
Use TSQuery for all your server state, I.e. data that comes from fetch calls to a backend, like a posts api that returns all posts in a social media app
Hey I have a question.
Actually I felt in a situation where I make a post request to an APIs end points and I want to used the data from without passing in a zustant state. With a get request is very simple but I could not figure it out when making a post request
@@stanzy237 you can store those inputs in state and then define your mechanism for removing it. Also, you could return the input data / database output in your post response from the api and use it as well.
But if you need to persist the posted data between renders or various interactions, then you will need to store it intermittently in Zustand
@@TannerBarcelos ok great advice thank you.
I have to say this is true for normal cases like you described. For some other cases, you must put the users to zustand by useEffect and make changes for client. For example, in the user list, you need display an active column with checkbox, and you can check/uncheck the checkbox then submit the changes. Imagine that you have more other fields need do the same. In these cases, you have to put the users to zustand firstly by useEffect, there is no good way to implement this with react query only.
You could just store the IDs of the selected users in Zustand and then check against that for the UI. No need to duplicate the users
@@cosdensolutions well you can have a try, like i said, if you have multiple fields need to be updated by clients and the list also have sorting and filtering functionalities. you will see the issue. To save it in the store, you can keep the list as single source of truth. Make your life much easier.
@@geforcesong tanstackw query is for state management , you don't need to make a duplicate state. just store selectionId, filter state in zustand
I like these types of video, that way I can send it instead of having to spend the time to actually explain best practices, before explaining key concepts. If you haven't done, can you also create a similar video but using query params instead of local state? Maybe also RSC patterns combined with client side code.
I just so happen to find out about zustand
Began using reacy query a while back
And boom i find this video 5h after posting lets go
Same bro😂. Zustand then react query and got recommendations for supabase
Isn't it a much better practice to do the "filter state management" via the URL? That way it stays persistent when refreshing, and sharing the URL
Hahah ! That video came out on point ! Thank you so much ! :)
thank you
I am actually building a react native application and need help with managing state with firebase and the client app (native app) I wanna know if I can use this pattern?
Can we have a video on react query, tanstack table and zustand to make a datatable?
actually there is Mantine React table and Material UI table that implement tanstack table very nicely and work well with react query. Also there is great documentation and examples.
You would not need Zustand in the first step. Regarding the table if you want to preserve the filters, sorting and so on while the user navigates pages, that's when you need to think about how to preserve the state of the table, which may be desired or not.
make a custom hook that use react query to fetch data and pass it to tantack table and using zustand for holding state that hook return the table and loading state
Just look into Shadcn data table it uses tanstack table
and what if we need state mutations in the data , dont we need to keep the client state for that ??
I liked the explanation, really crisp! However, my only concern is this that in case let's say this is supposed to be a shared global state within a big app. Let's say you're planning to store user's profile data or auth for a simpler example. Having a zustand store, from which you can retrieve the state value in any other component feels like a much more better approach, rather than adding react-query everywhere. Would love to know other opinions and thoughts?
React Query is meant to call the same query in many components, they highly recommend it! That's why the cache is there and it works great
You can wrap the react query call in a helper hook that you use around your app. Then you don’t need to repeat the cache key etc
Isn't it a better practice to do the "filter state management" via the URL? That way it remains persistent when refreshing the page, and when sharing the URL
yes it is, making a video on that soon
i don't think your example is good for client state. for filtering, sorting, product variant options search param (in url) better choice then saving it in client state. Let me know if i am wrong
How are you're going to save your filtering state to pass it to the url? you need client state to save these filters.
If you use the URL then you don't need Zustand. But not everything needs to always go in the URL
@@latinrev3822 pagination? Rewrite url maybe? You can use useState for that. There is no point to use global state if your state gonna be used in just 1 component
You might probably want the search params as a default/initial value, not as a state value, since waiting for the url/search params to change might hinder your UI Component, for example controling a Switch Input active state.
You still need client states for a better UI transition/active state.
I think you are right but maybe he merely wanted to show the point that we should not use client globle state management like zustand to store data from server when we already use react-query or swr to handle the server data management, although the case is not that proper.
I do exatly this proposal to my team past week rsrsrs
thanks for these videos for frontend development.
I guess I am the first watching this video 😅
practical knowledge thank you
What if I want to implement filtering on the client.
Why check data in useEffect? Why do you check data into onSuccess function of ReactQuery?
How have you done this beautiful cursor animation?
A lot of yapping IMO. I feel zustand has specific cases but to be used for filtering is not so good. Just stick it in the url.
Have one question, tanStack query will store data in cache. But what if I want to get data from server instead of cache since the data may change at any time?
good question , in next js we have revalidate but i dont know about this
and also i got one doubt related to this video : what if we need state mutations in the data , dont we need to keep the client state for that ??
check docs, staleTime and gcTime are your friends
thanks!!! ❤
Darius ! I know you are completely fluente in French 😄🇫🇷
Zustand is "global" state management
What to do incase, The server data I need requires in multiple components, Should I call the query in each of those components, or get it initially in some main component and store it in zustand?
Call the query in each component! That's what RQ is built for. It will fetch it once then return from the cache every time
@@cosdensolutionsWhat if I need to fetch the initial data with react query and then make some complex updates and use those data on multiple components? How to deal with this?
are there any disadvantages if i use useQuery and axios together?
Not at all! I do it all the time
Can we update the state with mutation
How about a derived state from server state ? Let's say I got users from the backend, but I want to keyBy it and use it in multiple components. What's the best way here please ?
You could use useMemo to create a derived array/object as you want, that way you save an extra render than if you use useEffect. Or you add the logic in the fetch fn
Where to use useMemo, I couldn't get it ?
guys if I use mobx do I even need react query or would it be better if I just make my queries in mobx methods
no, I would then stick to that
But does it make sense to use the store to save user data if i need the user data to be persistent through mmkv?
Yes, and then you'd pass it as initial data to RQ
@@cosdensolutions oh yess that’s actually great…never thought of it that way.
does anyone know why react-query removed the onSuccess property in usequery?
Its useMutation that has onSuccess
since it would causes many problems, cons are bigger than pros
There is an explanation on tkdodo's blog as to why they removed the onSuccess from useQuery
Noiccceee
Is this the same for SWR?
probably yes
Jotai is better and less complex
What's the point of setting data from an API into another store? You lose the main purpose of RQ... RQ provides a 'global store' for your data under the guise of a cache. Such videos numb people
Nice video, but it could easily have been 5 mins shorter