React Query is Secretly an Amazing State Manager
HTML-код
- Опубликовано: 24 авг 2024
- It just works, no other state management library needed at all. That is pretty dope.
-- my links
My SaaS (closed beta, not public yet): www.splitter.gg/
My Discord: / discord
My GitHub: github.com/jos...
well, zustand is more of a client state library where react query is more of a server state library. I think they have different main purposes.
true
They literally address this in the tanstack query docs
Spot on…different tools for managing client and server state
You can use react query for client state management, all you have to do is wrap your logic in promises.
@@hichemfantar1965yes, but there’s absolutely no reason to resort to that type of hacking when there are several libraries specifically made for handling client state
I find react query also REALLY shines when it comes to optimistic updating.
When combined with tRPC so you don’t have to even worry about type casting or passing around query keys and such, it’s crazy how simple all this is made.
you actually don't need to return the refetch function, you could also invalidate the query cache key "cart", because that is in use it would get refetched directly
Something to point out is that this approach is more suited toward server-state.
Zustand, Redux, XState and other state-machine like solutions do still hold a strong place. Especially is you have client-side data that you need to manage/cannot store on a server. Think more along the lines of a predictable stream of storing state for a client app, stuff like an app local-shopping cart, theme, routing specific contextual info, etc.
That being said, not many web apps truly need a full fledged solution like Zustand or other, and can get by with React Context alone for most things. These state-machine like solutions start mattering more as your app grows and stuff like Redux slices or Zustand stores come into play where ownership of the store doesn't leak or cause side effects into others, WITHOUT having to have a 15 layer tree of context providers.
Why mention that you have to explicitly type the Zustand solution and not mention that you do the same with React Query with `return cart as Cart`? That's quite unfair.
To be frank, that's a fetch issue. you have to type the fetch call somewhere unless you're using GaphQL or some other typed api call (which would work with React Query out of the box, but not with zustand). But in zustand you also have to type the entire store, which is fine for the example 2 items but if you get more (loading state, errors, initial load etc) it does get out of hand. React Query you only need to type the output. If you make the fetch call in a different function, you can type the return of that function and RQ will infer the result from that.
it's about the fetch result, not the cart and refreshCart. Those are 2 completely different things
I think you could have presented React Query without "diminishing" Zustand which presents itself as "bear necessities state-management". Including the constraint "from API", it is expected that a server state management library like React Query overweights a light weight and bear-bone client state management library like Zustand.
Don't get me wrong, I love your content and both libraries, I just think it's an unfair comparison.
Great content man, you are also the only person on the internet who pronounces zustand properly. I know the reason, I see your windows task bar.
hehe
He is german xD
genau
We still gotta get him pronouncing Lucia correctly! “Loo-shuh” (Along with everyone else)
It's worth mentioning that this only works if you don't need to mutate the state on the client side. React Query is not a full on state manager, it just caches requests.
I think everyone would love content on hydration and using react query and server components with nextjs. And all the great abstractions that would make it scalable.
For client side state management I'll take zustand any day of the week. I would only use react-query if I am dealing with server side state and not using trpc for some reason.
So is it okay to use zustand for client state stuffs like theme, toggle bars, etc and React query for sever state async data both at the same place?
Legend State with Tanstack Query seems like the way to go right now when it comes to state management in React imo.
I would just use trpc, it wrap react query and provide typesafety between your frontend and backend.
trpc is dope, just not sure how compatible it is with the recent next versions
Still, tRPC doesn't give you caching ablities react-query does. Different tools but both awesome!
what is the thing you didn't know React query can do?
data fetching 😂
@@gradientO😂 lol
The usecase for the two library is quite different and it's very glaring that tenstack is more powerful when it comes to asynchronous.
When I hear "state managers", I expect traditional state/settings/logic management.
This is "server cache management", which is a subset. State managers can become cache managers, but cache managers isn't suited to be come state managers since it's a specialized thing.
i had no idea oranges are the better apples
Hey that was almost amazing.Really happy
josh, your videos were very help full to me. thank you so much
Why don’t people use RTK? It auto generates hooks for you that you can use anywhere. No need to write multiple fetch logic. I don’t get why people love react query so much over RTK.
I'm using RTK for some of my projects, and I can see one use case for this. State in redux has to serializable, but there can be cases where we need a non-serializable instance of a class to be in state. IF you are using other client state management tools like zustand for this, react query is a great choice for server side state without adding all of rtk to your project.
Might be wrong - this is just my observation so far :))
React Query is such a dream to work with. tRPC really makes you forget how painful the old days were.
React Query is great in this situation for synchronising server state (cart contents) to the client.
You could also set staleTime to regularly refresh the client-side cart data, to keep the cart in sync even if the customer is switching between multiple browser tabs or are logged in to an account across multiple devices.
Zustand or other client-side state managers are best for state that stays on the client, or if state needs to sync from client to server instead of the other way around.
You just showed basics of React Query? Dunno how you could not know about this
Exactly, this make no sense 🤔
Just because you know it, it doesn't mean that everyone does.
@@oscardasilva971but Josh has done many videos on it already
Yeah I'm super confused lol
@@oscardasilva971 I mean it's just how you use react query, I was expecting some not that obvious feature
OMG I am learning and you are posting your videos just in time! It's as if I am your private student!!! Thansk Gosh 😆😆😁😁😁😁
Is bro getting dumber or am I gaining some skills ?
Zustand and RQ are solutions for totally different problems. I use RQ to persist server side data and a global state manager like zustand to only keep client side state.
At the beginning of the video I thought he's gonna talk about great features of RQ like caching, smart fetching, mutations and all, but nope, bro violated us
True, this comparison was so unfair
Yeah, wasted 5 minutes thinking RQ has a special general-purpose mode.
Hey @Josh or others in the comment section , which one do you guys prefer React Query or SWR?
Zustand + react-query can be a good combination
In one project, definitelly! But each solves different problems - react-query server-side state as a cache. Zustand client state
@@CistiC0987 Yep, I agree with you. It will always depend on the use case and project requirements.
what if you need to change the data locally to then make a mutation? Will it be necessary Zustand/Redux/useState, or react query provides a solution for this?
Could you make a video of combining server actions with React Query? Where you would do mutations on server and use React Query to manage state, cache, handle errors, etc... I'm just starting to use both of these, so maybe i'm wrong and maybe this is not a good combination. Would like to hear others opinion.
Keep it up!
Thanks, Josh for great tutorial.
Is there any solution with localstorage for state management?!
yes, i know that with both redux and react query you can persist your data. I'd guess the other libraries have that option too
react query solved every problem for me except for optimistic updates, optimistic updates for multiple related and unrelated queries every time i change something sucks
please make a crush course on react/tanstack query or suggest a beginner friendly playlist
But I use Server Component
Can someone please explain why making an API route and doing this in next is better than updating a db with a server action then revalidating the page?
its really amazing i am not using anything like redux now days only for some some theme and client stuff i use redux or zustand otherwise react query is my choice for all stuffs
You showed a typescript problem, not a Zustand problem
If you use graphql, relayjs appears to do all of this and more. Let me know if this is an incorrect understanding
As I understand, relay seems to be similar to apollo client, so yes, they are among others a cache providers for your react app. So yes, you're right. But also vice versa, you can use react-query for graphql as well, at least, I did in my projects. Is much more lightweight than apollo cache, where Cache Normalization seemed a little intimidating to me (don't know about relay)
i dont think its good approach always , sometimes its gets to be slower on refetch opposite of client state what show the update at the time
We can not lean on it like redux its server state management very good with the server cache that's it
React query is amazing!!!
Can you pls provide the github link to this project
what if we do not fetch the data but lets say want to store the mouse position or a theme color?
Then you need to go with client state management like zustand or redux, something like that
i prefer RTKQ, a little more boilerplate but have better DX
You don't really explain anything in this video...
Great video 🔥
Can you bring more videos like reddit clone, Learned a lots of things from that.
Thank you
This is pretty normal with RQ though
i like SWR more
🔥🔥🔥
Sorry Josh, didn't enjoy the video. The example you said was 'cleaner' didn't look cleaner to me. I'm really struggling to understand why and in what circumstances React Query is a good idea and this didn't help.
Why not using Server Components and revalidatePath ?
True, but you can't use server components on older versions of react, and can't upgrade react if a lot of un-upgradeable dependencies (ex MUI 5) are dependent on older versions of react
Rtk wins
Yo man I'm fastest to comment 😎
Looks like you give up tRPC... react-query is cool
LoL, I figured this out 😂😂
Please josh I have a query building an crm dashboard I have multiple user role and user can create multiple products and can create a many campaign for a single product and for a specific campaign i want to show leads or send via api how can I make database system please help me I am your very old subscriber.
Touch grass man