react query now Tanstack Query is just so much useful for the state management like loading state, error state, successful data fetching , mutation and many more
I like the basic description of what a React component is: a function of state that returns a view. That is brilliant and I wish I'd heard that some years ago. Took me a while to grasp how React will call your components multiple times to render things! Which gets me to how hooks are a mediocre solution that always like they were pushing what React is capable of perhaps a bit too hard.
Was using SWR as it's a much simpler and approachable library, but the design is inconsistent which makes mutations painful. The mutator in SWR only modifies cache data; it doesn't include your network call. This mean your errors in mutation network requests are segregated from SWR. This is in contrast to fetching in SWR where SWR _does_ bundle the fetcher in the SWR call, so SWR could process this error. The amount of error handling doubles as the design decision of including/excluding the network request is inconsistent. It becomes quite difficult in SWR because you may make other network requests independent of SWR that are not mutations or SWR fetches, so you need to figure out if these are related to SWR or not _and_ if SWR would handle them or not. For example, if you have an SWR handler for fetcher errors but you also have a handler for all network request failures, the error may be reported to the end user twice. But you can't simply remove your network request error handling as then you'd lose handling of mutation errors which SWR won't catch or network errors unrelated to SWR. Unless you write some convoluted state machine for processing errors, you'd need to handle each mutation network call and SWR-unrelated network call explicitly while ignoring errors on fetcher network calls if you want SWR to handle those. In TQ, an error in either a mutation network step or a query's network step triggers TQ's `onError` so I can process the error there and it immediately removes all of this thinking.
I was on the same boat! Now converting the codebase to use RQ with a query key factory after too many headaches with mutations and worst of all, mutations of dependant data.
I love React Query. It's like a developer-friendly RxJS for the most common use case. Next time RxJS gets more popular, devs will say, "this kinda reminds me of React Query"
Excellent video. I subscribed straight away. Out of curiosity what tool(s) are you using for the code presentation - the zooming in/out, emphasis on lines/blocks, transitions all look awesome. I am still using PowerPoint/keynote to present code at work and it’s tedious to say the least.
Great video describing ReactQuery! From the title I was expecting to learn about the actual founding of React Query (instead of what it's solving) but I guess those are virtually the same/intertwined. Idk why I thought it'd be more of a documentary style on Tanner and team but that's where my brain went Also was very excited to dive into coding with React Query at the end but the vid wrapped up well enough for me.
Thank you for using the analogy with math, the origin of everything (why we need to learn a concept from scratch when there is transfer learning (bijection)).
Love it!. This pretty much summed up my journey to react-query too. I started building my own, it got complicated. Then I switched to axios-hooks, which was pretty nice. But then I needed the same functionality for non-http calls. (fetching data from a c++ wrapper). React query doesn't care what's in your async function, so it was perfect. Plus it has a ton more features that often come in handy.
as a person who tries different approaches in pet-projects, I find React Query and Reatom best in how the handle data, although Reatom is a bit strange at first glance and RQ is a bit easier. Reatom makes you actually write code for your need, really clean approach, RQ in that sense may be a bit clumsy you need to know your settings Thanks for the video
Amazing content! Keep it up, I learned so much and want to watch more great informative videos! Editing and code high lighting and speed/pacing is PERFECT
I wonder how many hours went into video editing... The process... Animation of code, graphics, syncing everything with a voice over. I would like to see how you do it. Thumbs up 🎉
Was getting into so much spaghetti code with use effect+ use state , useState causing rerenders of the component and retrigerring the useEffect until someone reviewed my code and just told me to stop using useEffect for simple data fetching (which i was using it for). So after a bit of searchit i ended up running into react Query which is not only better ,but simplified my entire code
This is a great video, but I think that if you really want it to keep up to date, you should have called both this video and your online course "Tanstack Query" (they've made it adjustable to more frameworks). Beside, Tanstack products are worth considering further videos such as this one by being a whole eco system which includes Tanstack Router, Tanstack Table, Tanstack Form, and more.. Thank you!
It's been around longer, but as long as you'll insist on holding it, you'll drift this topic away from being relevant.. The best evidence for that is that once the new version was released with its new "Tanstack" label, any "react query" code ia now a legacy code.
We called the course React Query because the syntax of the course is in React, which is also where 95% of our usages comes from (comparing @tanstack/query-core downloads with @tanstack/react-query). I still call the react adapter "react-query" and the vue adapter "vue-query" etc, so I think the naming is fine.
3:30 that's wrong, in normal case browser should send cancellationToken to backend.. u should have AbortController implemented, so backend will no longer process data
You can implement AbortController and pass the signal, yes, but the shown useEffect code didn't do that (so it suffers from the bug). With React Query you can either cancel or let the request continue to have it cached for further access under the correct key.
Thats totally true and accurate we can achieve the same behavior (kinda) using AbortControllers on the cleanup function and the hook function itself, no need for the clumsy ignore thingy
6:49 some variations of the quote: There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors. -- Leon Bambrick There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery -- Mathias Verraes there's two hard problems in computer science: we only have one joke and it's not funny. -- Phillip Scott Bowden There are so many variations on the “there are only two hard problems in computer programming...” joke that I’m starting to suspect that programming isn’t actually very easy. -- Nat Pryce
I always thought of it as a data-fetching library. 1) Since it is an async state manager, React Query can be an alternative to state managers like Redux toolkit and Zustand? 2) Is there a way to use both the Redux toolkit and React Query? 3) Will it be relevant to do that?
Axios is a data-fetching lib, Zustand is a sync state manager, Redux has own alternative to RQ named RTQ Query, and yes it's relevant to use different tools for different tasks
it's not an alternative but an addition; as the video says, treating synchronous and asynchronous state equal is what got us into this situation in the first place. Redux has its own integration with RTK-Query, so if you're already using redux, i'd use that. If not, I'd use React Query + whatever state manager you prefer for synchronous state.
Those are all wonderful tools! Also RSCs do not get rid of this issue. They can get your data into your markup on the server but you’ll still have issues of caching somewhere. You also have to go to the server any time you want to update your markup (or your data). Different problem, great solution, but not mutually exclusive at all.
It seems to me that the main problem in this hypothetical scenario is that you are needlessly requested to make an abstraction for 7 lines of extremely simple code :P Maybe this is why I am not a project manager or lead dev, but it seems like those 7 lines of extremely simple code solve all 4 of the issues you laid out that were created by the abstraction in the first place.
If you don't need to cache data, re-validate, update cache, sharing the data across applications. The initial 7 lines is fine. That's how we all start. The problem is once you need to start to build something serious fast, handle different state during data-fetching, avoid same api is being called multiple times, sharing those remote fetch result across applications, safe api throttling by design, react-query automatically makes sense for you. You usually can build something faster than average SPA. Caching is very powerful. I had seen enough times devs try to come up their own solutions from that 7 lines, all end up in an extremely terrible version of react-query 95% of the times and waste lots of engineering hours. They were all confident they can come out something better than react-query.
I know it'll the dependency array for useMemo and useCallback, but I'm not sure if it's planning on solving useEffect's. If it does, then yeah that'll definitely help.
The compiler wouldn't, but the new use() hook will remove the need of using the useEffect() hook for data fetching. This being said and as the video stated, React query/ Tan stack query is not much about the data fetching itself, but more about how to manipulate this data, I don't think it will change much with react 19
@@uidotdev I think they grabbed the store layer idea from the Apollo Client for GraphQL; I actually found Tanstack as a suitable replacement for Apollo a couple of years ago, I was used to using Apollo, and I suddenly had to start a nongraphql project. With Tanstack, I could abstract the store layer and interface it with any other data access in the same way than with Apollo and with a few more goodies.
The solution is probably to just inject your data rather than fetch your data in the component. Just like how pure function are supreme, so too are views that hold no state. Same input in, same output out. I’m glad you made the reference to views and functions being equivalent, otherwise devs may not have been able to see the link between pure functions and pure views.
@@uidotdev Thanks, Yeah I always use redux for client state therefore I see as long as redux can handle both server and client side state it would be good to use it alone.
React query is just a weak alternative for the tooling GraphQL developers have already. for REST APIs react query makes a lot of sense over manual processes.
Love this library. It's truly a shame that because most developers know only about mainstream libraries they use stupid redux and never even heard about Tanstack. This should be a standard period
Amazing video, great explanation, instantly subscribed.
Thank you Martin!
And i subscribed after reading this
RQ being used in 1 out of every 6 React apps is a wild stat
🤯
Its wild that its not higher!
@@lascivio exactly
@@lascivio Latest download numbers say 19%, so almost 1 in 5 🤯
@@TkDodoCourse got outdated before it's release 🤯
react query now Tanstack Query is just so much useful for the state management like loading state, error state, successful data fetching , mutation and many more
I like the basic description of what a React component is: a function of state that returns a view. That is brilliant and I wish I'd heard that some years ago. Took me a while to grasp how React will call your components multiple times to render things! Which gets me to how hooks are a mediocre solution that always like they were pushing what React is capable of perhaps a bit too hard.
Was using SWR as it's a much simpler and approachable library, but the design is inconsistent which makes mutations painful. The mutator in SWR only modifies cache data; it doesn't include your network call. This mean your errors in mutation network requests are segregated from SWR. This is in contrast to fetching in SWR where SWR _does_ bundle the fetcher in the SWR call, so SWR could process this error. The amount of error handling doubles as the design decision of including/excluding the network request is inconsistent. It becomes quite difficult in SWR because you may make other network requests independent of SWR that are not mutations or SWR fetches, so you need to figure out if these are related to SWR or not _and_ if SWR would handle them or not. For example, if you have an SWR handler for fetcher errors but you also have a handler for all network request failures, the error may be reported to the end user twice. But you can't simply remove your network request error handling as then you'd lose handling of mutation errors which SWR won't catch or network errors unrelated to SWR. Unless you write some convoluted state machine for processing errors, you'd need to handle each mutation network call and SWR-unrelated network call explicitly while ignoring errors on fetcher network calls if you want SWR to handle those. In TQ, an error in either a mutation network step or a query's network step triggers TQ's `onError` so I can process the error there and it immediately removes all of this thinking.
I was on the same boat! Now converting the codebase to use RQ with a query key factory after too many headaches with mutations and worst of all, mutations of dependant data.
Best react query explanation video I have seen. Bravo!
So happy to hear that. Thank you for the kind words!
Using it for two years, love it. Tanner is a proper G ❤
The realest G.
The usp of this video is its content and the how you r presenting it nice ui, color full test, animation
TanStack Query 🙌🏼
I love React Query. It's like a developer-friendly RxJS for the most common use case. Next time RxJS gets more popular, devs will say, "this kinda reminds me of React Query"
(I'm referring to the way it lets you structure your code - declaratively - not the specific API obviously)
Great explanation, fetching always looks easy until it doesn't
100%. Thanks for watching!
If you watched the video, you would have known that it's not about fetching 😜😜
@@codewkarim You are right, he never mentioned fetching data from a server in a useEffect.
My bad.
Excellent video. I subscribed straight away. Out of curiosity what tool(s) are you using for the code presentation - the zooming in/out, emphasis on lines/blocks, transitions all look awesome. I am still using PowerPoint/keynote to present code at work and it’s tedious to say the least.
The emphasis on code blocks and the transitions makes presentation so engaging. I love it.
Would really like to know how that's done as well.
Great video! It took me a bit of time to convince my colleagues to use RQ. Now, they're having fun!
Great tech. It gets even better the bigger your team/codebase gets.
I don't really comment on videos, but this one was really well made. Thank you! More of this! And I will definitely check out the React Query course.
That is very nice of you to say. Thank you!
Great video describing ReactQuery!
From the title I was expecting to learn about the actual founding of React Query (instead of what it's solving) but I guess those are virtually the same/intertwined. Idk why I thought it'd be more of a documentary style on Tanner and team but that's where my brain went
Also was very excited to dive into coding with React Query at the end but the vid wrapped up well enough for me.
Yeah that's fair. Appreciate the feedback!
I would be interested to know *how* it solves all those problems
You have outdone yourselves. This is absolutely superb content
That means so much. Thank you!
Thank you for using the analogy with math, the origin of everything (why we need to learn a concept from scratch when there is transfer learning (bijection)).
Love it!. This pretty much summed up my journey to react-query too. I started building my own, it got complicated. Then I switched to axios-hooks, which was pretty nice. But then I needed the same functionality for non-http calls. (fetching data from a c++ wrapper). React query doesn't care what's in your async function, so it was perfect. Plus it has a ton more features that often come in handy.
as a guy who works with education, art and tech I must say: THIS IS SO WELL DONE! Congrats 🚀👌🏻👌🏻
Thank you!
I’ve been in go world for a moment still doing next js daily but man I love go and coming to this I’m reminded how crazy our js world is.
Why did you remove the older videos from the channel? Please bring them back.
I was randomly looking at react query only 6 hours before this was uploaded
Hopefully it was helpful!
great video
Not sure what else is on your content backlog, but would be interested in watching the stories of certain coding design patterns (Big Four, etc.)
Great explanation, great stickers and visuals, by far the best learning experience I ever had
Thank you Carlos!
I hope this course also teaches me how to use fetch properly to handle success state, and 400 different types of error states
This makes me appreciate React Query even more
Every people in company watch this video. It's very perfect information
Thank you so much! Using Query in my new project :D
You're welcome!
as a person who tries different approaches in pet-projects, I find React Query and Reatom best in how the handle data, although Reatom is a bit strange at first glance and RQ is a bit easier. Reatom makes you actually write code for your need, really clean approach, RQ in that sense may be a bit clumsy you need to know your settings
Thanks for the video
Whatttt. I've seen this video's thumbnail and ive been putting it off to watch it, now im glad i watched it 😁
Amazing content! Keep it up, I learned so much and want to watch more great informative videos!
Editing and code high lighting and speed/pacing is PERFECT
Thank you! That's actually really helpful feedback. Pacing is always a tricky balance with code.
best and deeep explanation we need more from you sir and fullstack project tutorial will be a breeze to the fire
I wonder how many hours went into video editing... The process... Animation of code, graphics, syncing everything with a voice over. I would like to see how you do it. Thumbs up 🎉
This one was about 2-3 weeks of work for a team of 3 working on it full time.
Perfectly explained. 👏
Thank you!
Shoutout Relay gang 🤘
have some data duplicated and some extra re-renders isn't a big issue, which is why context is fine.
This is such amazing content,you should be proud of what you do. My respects to you sir ❤
That means a lot. Thank you!
Awesome video ❤❤❤🎉🎉🎉
Thank you!
Was getting into so much spaghetti code with use effect+ use state , useState causing rerenders of the component and retrigerring the useEffect until someone reviewed my code and just told me to stop using useEffect for simple data fetching (which i was using it for).
So after a bit of searchit i ended up running into react Query which is not only better ,but simplified my entire code
the explanation was great
ive been working on nextjs and react since nextjs was released (same with react) and yet none of my jobs ever used RQ. SO it cant have won.
Well said, Tyler, quality-content-king. 💚Bueno! 💯
Great video, RC is one of my 'go-to' tools on every project i've
Great explanation!
Thank you!
This is a great video, but I think that if you really want it to keep up to date, you should have called both this video and your online course "Tanstack Query" (they've made it adjustable to more frameworks).
Beside, Tanstack products are worth considering further videos such as this one by being a whole eco system which includes Tanstack Router, Tanstack Table, Tanstack Form, and more..
Thank you!
react query is a more popular term
It's been around longer, but as long as you'll insist on holding it, you'll drift this topic away from being relevant..
The best evidence for that is that once the new version was released with its new "Tanstack" label, any "react query" code ia now a legacy code.
We called the course React Query because the syntax of the course is in React, which is also where 95% of our usages comes from (comparing @tanstack/query-core downloads with @tanstack/react-query). I still call the react adapter "react-query" and the vue adapter "vue-query" etc, so I think the naming is fine.
Too expensive, especially for anyone not earning in dollars.
This is bang on 💯
Thanks for watching!
3:30 that's wrong, in normal case browser should send cancellationToken to backend.. u should have AbortController implemented, so backend will no longer process data
You can implement AbortController and pass the signal, yes, but the shown useEffect code didn't do that (so it suffers from the bug). With React Query you can either cancel or let the request continue to have it cached for further access under the correct key.
Thats totally true and accurate we can achieve the same behavior (kinda) using AbortControllers on the cleanup function and the hook function itself, no need for the clumsy ignore thingy
Thanks! Helped me with a problem I thought I couldn't fix
Glad it was helpful!
6:49 some variations of the quote:
There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors.
-- Leon Bambrick
There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery
-- Mathias Verraes
there's two hard problems in computer science: we only have one joke and it's not funny.
-- Phillip Scott Bowden
There are so many variations on the “there are only two hard problems in computer programming...” joke that I’m starting to suspect that programming isn’t actually very easy.
-- Nat Pryce
🙌
nice one
btw which font are you using for text in the video? like at 2:09
Fira Code for the hooks and Outfit for the descriptions.
How about other react-query alternatives?
Great explanation! What's your comparative thoughts of RQ and swr
Thank you! I prefer RQ, but both are fine. I feel like now days most people are choosing RQ.
I should probably give this a good, I've always abstracted API calls to a API client directory - then I call them in a Zustand action.
Really nice video. Can please tell us which tool used for animation ?
I always thought of it as a data-fetching library. 1) Since it is an async state manager, React Query can be an alternative to state managers like Redux toolkit and Zustand? 2) Is there a way to use both the Redux toolkit and React Query? 3) Will it be relevant to do that?
Axios is a data-fetching lib, Zustand is a sync state manager, Redux has own alternative to RQ named RTQ Query, and yes it's relevant to use different tools for different tasks
it's not an alternative but an addition; as the video says, treating synchronous and asynchronous state equal is what got us into this situation in the first place. Redux has its own integration with RTK-Query, so if you're already using redux, i'd use that. If not, I'd use React Query + whatever state manager you prefer for synchronous state.
Animations are smoooth
❤
Where can i read more about the 5 O'Clock rule mentioned in the video, it sounds interesting
I made it up! I just really think the average developer doesn't care much for the craft of coding and just wants to get home ASAP (which is fine).
How does ReactQuery compares to other such libraries, for example swr?
Great video!
Glad you enjoyed it
The are a number of existing libraries like React Query such as RTK, SWR. Also RSC makes a lot of these no more necessary.
Those are all wonderful tools! Also RSCs do not get rid of this issue. They can get your data into your markup on the server but you’ll still have issues of caching somewhere. You also have to go to the server any time you want to update your markup (or your data). Different problem, great solution, but not mutually exclusive at all.
damn cool Explanation☸☸
It seems to me that the main problem in this hypothetical scenario is that you are needlessly requested to make an abstraction for 7 lines of extremely simple code :P Maybe this is why I am not a project manager or lead dev, but it seems like those 7 lines of extremely simple code solve all 4 of the issues you laid out that were created by the abstraction in the first place.
If you don't need to cache data, re-validate, update cache, sharing the data across applications. The initial 7 lines is fine. That's how we all start.
The problem is once you need to start to build something serious fast, handle different state during data-fetching, avoid same api is being called multiple times, sharing those remote fetch result across applications, safe api throttling by design, react-query automatically makes sense for you. You usually can build something faster than average SPA. Caching is very powerful.
I had seen enough times devs try to come up their own solutions from that 7 lines, all end up in an extremely terrible version of react-query 95% of the times and waste lots of engineering hours. They were all confident they can come out something better than react-query.
I already bought old react query course, Do i get free updated the course? or must buy a new one?
With RSC react-query is not needed anymore tho.
A bit of a dumb question: if I’ve got Next.js app with MobX - is React Queey going to improve my life?
Yes if you’re doing tons of asynchronous calls that determine the state of your application
he’s back!!!!
We're so back.
Nice 🔥🔥
This was amazing, would react compiler solve some of the issues were facing here?
I know it'll the dependency array for useMemo and useCallback, but I'm not sure if it's planning on solving useEffect's. If it does, then yeah that'll definitely help.
At this point, React should be re-written with Svelte.
The compiler wouldn't, but the new use() hook will remove the need of using the useEffect() hook for data fetching. This being said and as the video stated, React query/ Tan stack query is not much about the data fetching itself, but more about how to manipulate this data, I don't think it will change much with react 19
@@MrMaxave I meant about having to constantly re-render
and react compiler is here
💚
shouldn't you use the full library name? tanstack react query?
Didn't feel necessary (and this vid/course was created with Tanner and Dominik who agreed).
@@uidotdev great! good video though
This approach is very much like Tanstack
Ah. It is a rebranded Tanstack
👯
@@uidotdev I think they grabbed the store layer idea from the Apollo Client for GraphQL; I actually found Tanstack as a suitable replacement for Apollo a couple of years ago, I was used to using Apollo, and I suddenly had to start a nongraphql project. With Tanstack, I could abstract the store layer and interface it with any other data access in the same way than with Apollo and with a few more goodies.
RQ is good, though I prefer SWR.
The solution is probably to just inject your data rather than fetch your data in the component. Just like how pure function are supreme, so too are views that hold no state. Same input in, same output out. I’m glad you made the reference to views and functions being equivalent, otherwise devs may not have been able to see the link between pure functions and pure views.
Never heard about it!
Sometimes it is just easier to use HTMX. And this is one of those times.
Good video. but misleading title .
Stark Path
what about Redux toolkit query?
If you're already using Redux, then RTK Query is great too.
@@uidotdev
Thanks, Yeah I always use redux for client state therefore I see as long as redux can handle both server and client side state it would be good to use it alone.
React query is just a weak alternative for the tooling GraphQL developers have already. for REST APIs react query makes a lot of sense over manual processes.
Godfrey Cliffs
Myrna Divide
Colton Mission
Love this library. It's truly a shame that because most developers know only about mainstream libraries they use stupid redux and never even heard about Tanstack. This should be a standard period
Rowe Plains
D'Amore Ville
Eliseo Crossing
Haylee Light
2:06 rick ross lol
Vs rtk?
Hettinger Mission
Brown River
Georgiana Estates
Fidel Lodge
Kareem Roads
Savion Falls