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"
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
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.
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.
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)).
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.
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
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
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 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.
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
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.
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 🎉
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.
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.
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
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.
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
@@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.
And this is why whenever devs talk bad about Ember, I roll my eyes. React is a libray, not a framework. With Ember, all of this and more has already been considered and built in. With React every team that uses it has to build an actually functioning framework from various 3rd party libraries
@@uidotdev Yeah, and that's also why every single React team I have ever worked on has suffered from the same issues. Most React developers simply know what they know and don't know how inefficient the development process actually is in the library. To me, it is just silly to think that 'I can organize my project ANY way I want to' is so useful. Because in the end, it just creates an ecosystem of apps with almost no cohesion and a million different ways to do the same thing. Going from one React team to the next, you have no idea what you are walking into because every team literally does it differently. Random routers, random spread operator prop drilling where you get 6 or 7 layers deep and have no idea what data is even in the current scope, not to mention the challenges honestly mentioned in this video. I say this as someone who has worked on numerous React teams and is quite proficient in the library. But I have also extensively used many other frameworks and for my money, I enjoy convention over configuration and a cohesive framework which encourages not rebuilding the wheel. Just my two cents.
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.
0:14 Good video overall, but I have no idea what you're talking about when you're making a "five o'clock rule" metaphore nonsense. Perhaps I'm not familiar with some trivia, but the description you give makes little sense, either. "The level of abstraction bubbles up".... wtf does that mean? Is it good or bad for an abstraction to "bubble up"? Does it mean more of it or less of it? And what does "bubbling up" have to do with "five o'clock"? As for the main "story" of react query, in my opinion you don't stress enough how caching is the main idea behind the popularity of react-query (and how react-query probably wasn't even the first to do it, but that doesn't matter, it's still the best). At the time, everyone was writing hooks for async requests and everyone was putting data in some client store using redux, flux stores and home-made alternatives. And none of them succeeded because the notion of "caching" (vs "storing") was the missing ingredient. The difference between "storing" and "caching" is subtle, but in short, with "caching" you're writing each component without ever thinking to check if the data exists or not. You just fetch it as if you don't care about duplicate requests. And the cache resolves that for you. That's the brilliant part. With the "storing" paradigm you had to check whether the data was available, and if it was, then you didn't initiate a fetch. Such orchestration was a great pain. And this is how the notion of "caching" basically killed (solved) all the "state management" problems and experiments of the time.
Problem with react-query is that it assumes everyone needs caching. IMO caching by default in most projects endup being costly mistake. I just want loading and race condition problem solved. Other problem examples were just biased - context should live outside, caching was never aked for…
React query sucks for dynamic queries and reading the status of a query in another component to show loading and failure states. I ended up ditching rq and instead rolling my own, keeping the historically best parts like onSuccess and onMutate handlers. I think they are too opinionated on those callbacks and on rq replacing other global state solutions and i got tied of it. The fact that is not obvious how the API should be used and they tell us we are using it "wrong" means there is something wrong with the api, not the users
@@uidotdev no... it's not. That's why there were gh issues open about the onsuccess handler and they just removed the callbacks in the latest version because there was so much confusion. Just because something is used widely doesn't mean it's used correctly. It's a mistake to conflate the two It's also most commonly used as just something to make api calls with. Haven't seen not one developer use it to replace some other state management solution. It's a mess in my view, and pretends to be something it apparently is not to I guess gain downloads? I don't know But after rolling my own and just focusing on the "how to make api calls better in react" problem, I realized rq is missing allot in terms of working with apis. So many ways to make then easier to work with
@@SogMosee "Just because something is used widely doesn't mean it's used correctly" is exactly the reason why we removed the callbacks. I understand that it was an opinionated move and you're free to disagree with it. There was also never the claim that you can or should use RQ "to replace some other state management solution", quite the contrary: It's a "state manager for your async state", and if that comes from data fetching only (like it will for most apps), that's fine. Synchronous state that you want globally available should still be managed by other state managers. They go very well with React Query :)
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
Best react query explanation video I have seen. Bravo!
So happy to hear that. Thank you for the kind words!
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.
Using it for two years, love it. Tanner is a proper G ❤
The realest G.
TanStack Query 🙌🏼
The usp of this video is its content and the how you r presenting it nice ui, color full test, animation
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 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, great stickers and visuals, by far the best learning experience I ever had
Thank you Carlos!
I was randomly looking at react query only 6 hours before this was uploaded
Hopefully it was helpful!
You have outdone yourselves. This is absolutely superb content
That means so much. Thank you!
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!
Why did you remove the older videos from the channel? Please bring them back.
Awesome video ❤❤❤🎉🎉🎉
Thank you!
great video
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.
I hope this course also teaches me how to use fetch properly to handle success state, and 400 different types of error states
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
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.
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.
This makes me appreciate React Query even more
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.
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)).
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
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.
have some data duplicated and some extra re-renders isn't a big issue, which is why context is fine.
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.
he’s back!!!!
We're so back.
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
Perfectly explained. 👏
Thank you!
Whatttt. I've seen this video's thumbnail and ive been putting it off to watch it, now im glad i watched it 😁
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.)
best and deeep explanation we need more from you sir and fullstack project tutorial will be a breeze to the fire
Thank you so much! Using Query in my new project :D
You're welcome!
the explanation was great
Shoutout Relay gang 🤘
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
Every people in company watch this video. It's very perfect information
This is bang on 💯
Thanks for watching!
as a guy who works with education, art and tech I must say: THIS IS SO WELL DONE! Congrats 🚀👌🏻👌🏻
Thank you!
How about other react-query alternatives?
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 explanation!
Thank you!
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
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.
Great video, RC is one of my 'go-to' tools on every project i've
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.
This is such amazing content,you should be proud of what you do. My respects to you sir ❤
That means a lot. Thank you!
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
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.
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 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.
Well said, Tyler, quality-content-king. 💚Bueno! 💯
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.
nice one
Can you please make content on micro frontend as well.
Really nice video. Can please tell us which tool used for animation ?
Too expensive, especially for anyone not earning in dollars.
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.
I already bought old react query course, Do i get free updated the course? or must buy a new one?
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.
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
Thanks! Helped me with a problem I thought I couldn't fix
Glad it was helpful!
Animations are smoooth
❤
damn cool Explanation☸☸
Great video!
Glad you enjoyed it
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.
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
Nice 🔥🔥
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.
With RSC react-query is not needed anymore tho.
🙌
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
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.
Vs rtk?
RQ is good, though I prefer SWR.
and react compiler is here
Sometimes it is just easier to use HTMX. And this is one of those times.
Never heard about it!
💚
And this is why whenever devs talk bad about Ember, I roll my eyes. React is a libray, not a framework. With Ember, all of this and more has already been considered and built in. With React every team that uses it has to build an actually functioning framework from various 3rd party libraries
I think people liked React for exactly the reasons you described.
@@uidotdev Yeah, and that's also why every single React team I have ever worked on has suffered from the same issues. Most React developers simply know what they know and don't know how inefficient the development process actually is in the library. To me, it is just silly to think that 'I can organize my project ANY way I want to' is so useful. Because in the end, it just creates an ecosystem of apps with almost no cohesion and a million different ways to do the same thing. Going from one React team to the next, you have no idea what you are walking into because every team literally does it differently. Random routers, random spread operator prop drilling where you get 6 or 7 layers deep and have no idea what data is even in the current scope, not to mention the challenges honestly mentioned in this video. I say this as someone who has worked on numerous React teams and is quite proficient in the library. But I have also extensively used many other frameworks and for my money, I enjoy convention over configuration and a cohesive framework which encourages not rebuilding the wheel. Just my two cents.
Good video. but misleading title .
Who designed the page? I need address. That man is wanted.
It was actually a Woman and she works full time with us.
Im yet to use it and this video did not convince me 😕
Ok 👍
Second 😄
❤
2:06 rick ross lol
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.
first
Thanks for watching!
@@uidotdev top quality content, have to be the first there captain 🫡
Wait, are we going back to jquery? lol
theo at the end 🙁
0:14 Good video overall, but I have no idea what you're talking about when you're making a "five o'clock rule" metaphore nonsense. Perhaps I'm not familiar with some trivia, but the description you give makes little sense, either. "The level of abstraction bubbles up".... wtf does that mean? Is it good or bad for an abstraction to "bubble up"? Does it mean more of it or less of it? And what does "bubbling up" have to do with "five o'clock"?
As for the main "story" of react query, in my opinion you don't stress enough how caching is the main idea behind the popularity of react-query (and how react-query probably wasn't even the first to do it, but that doesn't matter, it's still the best).
At the time, everyone was writing hooks for async requests and everyone was putting data in some client store using redux, flux stores and home-made alternatives. And none of them succeeded because the notion of "caching" (vs "storing") was the missing ingredient. The difference between "storing" and "caching" is subtle, but in short, with "caching" you're writing each component without ever thinking to check if the data exists or not. You just fetch it as if you don't care about duplicate requests. And the cache resolves that for you. That's the brilliant part. With the "storing" paradigm you had to check whether the data was available, and if it was, then you didn't initiate a fetch. Such orchestration was a great pain.
And this is how the notion of "caching" basically killed (solved) all the "state management" problems and experiments of the time.
Problem with react-query is that it assumes everyone needs caching. IMO caching by default in most projects endup being costly mistake.
I just want loading and race condition problem solved. Other problem examples were just biased - context should live outside, caching was never aked for…
You can't write tutorial code at work ❤
I didn’t get it, what does it mean?
@@theprovego2934 it's a quote he said in the video.
I prefer rtk query
Even outside of a Redux project?
Tomasa Junctions
React query sucks for dynamic queries and reading the status of a query in another component to show loading and failure states. I ended up ditching rq and instead rolling my own, keeping the historically best parts like onSuccess and onMutate handlers. I think they are too opinionated on those callbacks and on rq replacing other global state solutions and i got tied of it. The fact that is not obvious how the API should be used and they tell us we are using it "wrong" means there is something wrong with the api, not the users
It's used in 1/6 React apps, I think it's fairly obvious how the API should be used.
@@uidotdev no... it's not. That's why there were gh issues open about the onsuccess handler and they just removed the callbacks in the latest version because there was so much confusion. Just because something is used widely doesn't mean it's used correctly. It's a mistake to conflate the two
It's also most commonly used as just something to make api calls with. Haven't seen not one developer use it to replace some other state management solution. It's a mess in my view, and pretends to be something it apparently is not to I guess gain downloads? I don't know
But after rolling my own and just focusing on the "how to make api calls better in react" problem, I realized rq is missing allot in terms of working with apis. So many ways to make then easier to work with
@@SogMosee "Just because something is used widely doesn't mean it's used correctly" is exactly the reason why we removed the callbacks. I understand that it was an opinionated move and you're free to disagree with it. There was also never the claim that you can or should use RQ "to replace some other state management solution", quite the contrary: It's a "state manager for your async state", and if that comes from data fetching only (like it will for most apps), that's fine. Synchronous state that you want globally available should still be managed by other state managers. They go very well with React Query :)