React Query Is (Still) Essential - My Favorite React Library 

Are you talking or the toxoplasmosis in your brain?

@@bobobo1673did you even watch the video till the end?

@@bobobo1673 what's a toxopalsmosis

i cant believe he didnt pet the cat on cam

@@renejotas exactly 😔 poor cat

if i decide to use reactQuery , do i need another state manager ? , like redux or zustand for the client side, or just using React Query is fine ?

@@freezzefx2670 No, you don't have to use any other state management library along with React Query. React Query handles its own states, and you can access different state values by destructuring them like this: const { data, isLoading, isError } = useQuery('myQueryKey', fetchDataFunction); It is like this: Initially, when your component mounts, isLoading becomes true. So, while fetching data, you can show a loading indicator. If something goes wrong, isError will become true, allowing you to show a different UI for errors. Once data comes in, it will be available in data, and you can use that data to show your actual UI. All these are states, so as they change, your component will rerender automatically. I have destructured only three properties (data, isLoading, isError), but there are many other properties that you can use; refer to the docs.

@@freezzefx2670 No, you don't have to use any other state management library along with React Query. React Query handles its own states, and you can access different state values by destructuring them like this: const { data, isLoading, isError } = useQuery('myQueryKey', fetchDataFunction); It is like this: Initially, when your component mounts, isLoading becomes true. So, while fetching data, you can show a loading indicator. If something goes wrong, isError will become true, allowing you to show a different UI for errors. Once data comes in, it will be available in data, and you can use that data to show your actual UI. All these are states, so as they change, your component will rerender automatically. I have destructured only three properties (data, isLoading, isError), but there are many other properties that you can use. refer to the docs.

@@freezzefx2670 No, you don't have to use any other state management library along with React Query. React Query handles its own states, and you can access different state values by destructuring them like this: "const { data, isLoading, isError } = useQuery('myQueryKey', fetchDataFunction)" It is like this: Initially, when your component mounts, isLoading becomes true. So, while fetching data, you can show a loading indicator. If something goes wrong, isError will become true, allowing you to show a different UI for errors. Once data comes in, it will be available in data, and you can use that data to show your actual UI. All these are states, so as they change, your component will rerender automatically. I have destructured only three properties (data, isLoading, isError), but there are many other properties that you can use; refer to the docs.

​@@freezzefx2670 No, you don't have to use any other state management library along with React Query. React Query handles its own states, and you can access different state values by destructuring them. Unfortunately, I can't provide a code example here because RU-vid removes my comment if I do so. It is like this: Initially, when your component mounts, isLoading becomes true. So, while fetching data, you can show a loading indicator. If something goes wrong, isError will become true, allowing you to show a different UI for errors. Once data comes in, it will be available in data, and you can use that data to show your actual UI. All these are states, so as they change, your component will rerender automatically. I have destructured only three properties (data, isLoading, isError), but there are many other properties that you can use; refer to the docs.

lmao

I did this via simple events and a hook and packaged it as react-state-events. indeed moving components around is now really easy and the code redesign was also very very simple in an existing project.

I mean, you probably already read it, but LIFT principles from Angular are really useful for this.

how do you mange state in you react-query then? with context only ?

@@liftwithamey all the api responses are cached in react query based on the query key. So if you set refetch on mount to false, it will use the cached data which is basically useSelector in case of redux.

wouldn't rtk-query have fit since you were already using redux?

@@ssk7690I just took out logic out of UI code and everything became very obvious. Now a regular JS class tells React what to do through events and React updates accordingly. I can get as async and complex as I want and the UI code stays very simple and readable. Caching? I'll just stash it in the controller. Need a sequence of requests? just regular async/await does it, then publish success or failure accordingly. Cancels? push/pull a list of them in the controller. React doesn't need to know about that.

@@MadsterV by cancelling pending queries I meant something else. Let’s see this with an example. Say you’re firing 10 api calls on a page. Now if the user clicks on a different tab within the page, by default the api calls in second page wouldn’t start until the previous 10 are completed. Hence the need to cancel the pending queries based on user activity. This can be achieved very easily using react query, all you’ll need is the query key.

Query-Key factory is a godsend.

​@@smithrockford-dv1nb you're thinking of SWC (speedy web compiler). SWR is a cache invalidation strategy (stale while revalidate). I believe it's also a useQuery-like library from vercel.

@@smithrockford-dv1nb that's SWC

@@smithrockford-dv1nbSWR means Stale-While-Revalidate. What you’re referring to is SWC.

@@smithrockford-dv1nb You're confusing it with SWC. SWR is a library by Vercel to do the same thing, though more opinionated focused on data fetching than general async, hence its name (Stale While Revalidate).

How did you handle type safety wheb suspense option enabled? It seems tanstackquery provides useSuspensequery but swr not.

Yeah. If you use optimistic updates so much that your data is basically just state, with an extra database synchronization step, you should embrace a state manager for it, not a query manager.

I used to feel this way more, but then I had to do long-term maintenance on some Angular apps? I started to much prefer a more modular approach. I think the reality is that the "official" version would work half as well and would reduce the support given to alternatives. At the very least, there's tradeoffs.

@@Nassifeh This is actually a pretty good point I can see where you’re coming from. I’ll probably feel less salty once I get better at using these 3rd party react packages

@@MerkieAE It's definitely an adjustment period, even if I'm in favor of it. 😩 I miss when every guide or tutorial was doing stuff the same way I am. But I won't miss having to update basically the whole app all at once twice a year.

But React isn't a Framework. It's a JavaScript library. It wasn't meant to handle data fetching built-in.

Critically, React Query is not using useEffect under the hood (for the fetching bit).

@@stoogel what's using? There's no alternative to useEffect for connecting to external APIs in React as far as I know.

You probally use sagas "wrong" way. React-Query is 90% same things compared to Redux Toolkit Query - which is solve the 'fetch data' use-case of sagas. If your daily sagas purpose is :fetch data, update loading, set success, set error, invalidate incomming fetching action, wait another action's data , your work is just overlapping RTKQ - as I said "wrong". I personally though sagas make no sense to my project since RtkQ released. Back from start, sagas CAN handles all React-Query usages - but in a dirty way

@@lamhung4899 Thanks for the answer! How would you suggest to use saga in a proper way?

Not too long ago I learned this

absolutely. react-query expects a rather specific use case and once you step out of it, you're on your own. I moved logic out of React code into a regular JS controller class and just use a simple pub/sub to communicate events from the controller to the UI through a subscription hook (react-state-events). Then everything clicked without the need for awkward hooks and rendering weirdness (I did use a very simple state machine!). Controller offers methods which are hooked to UI controls and UI updates as needed when the controller decides to do so. I can even call the controllers from other components if I wish to do so. I can unmount and keep the controller alive to remount UI later, in a different place or even mount many different components at the same time that render the same data in different ways. Very flexible with minimal boilerplate! No useEffect, no double calls, no undesired renders. Just a plain class sending UI events and a plain React component rendering whatever the events say.

React Query Doesn't work really well with server components. Nextjs fetching api comes with caching, revalidation already so react query is not really necessary

loh

wondering as well

It's slightly easier to handle (no need to do QueryClientProvider/useQueryClient) thing, it's 3 times lighter according to bundlephobia APIs for cases Theo mentions are the same, the code from this video would work with useSWR exactly the same Because of worse docs, i had problems making useSWR and Tanstack Table to cooperate (i guess Tanstack tried to vendor lock-in to sway me to use Tanstack/React Query) but i overcame it

React Query is data agnostic, meaning it doesn't care how you provide it the data, via fetch, via XMLHTTTRequest, via axios or pull it from localStorage. All it cares about is that you give it a function that returns some data or throws an error. If the function returns the data it is considers a success, if it throws it is considered an error.

I agree with you there, it's a great tool to master, but it's not THE solution to every problem.

Just blabla. Give some actual examples for us to learn from.

@@filipjnc IKR dude just wrote 5 sentences of nothing. "Some cases", yeah lol

Firing off tracking events, subscribing to server sent events or socket events , for example

red is red, blue is blue

@@raijinhasarrived what if someone is color-blind

SWR is a decent way to cache fetch calls. React Query is a groundbreaking way to manage async functions and state in React. IMO, they’re about as comparable as a toy car and a semi truck

@@t3dotgg Got it, thanks.

Was wondering how complex these simple things get in other frameworks

Angular can use signals too now ig

other frameworks like Svelte, Solid or Vue face the same async state management issues too, and they do have adapters to work with Tanstack Query (aka, React Query), because Tanstack Query's implementation is framework-agnostic. The only framework that came built-in with a truly fully-feature HttpClient would be Angular, which is based on Observable and can do async state management out of the box, e.g. set/unset Loading, catch error, debounce, cancellable. The problem is it is too specific to Angular and cannot be easily re-used by other frameworks, like Tanstack Query.

@@vutruong4164 RxJS is not framework specific, Angular's HttpClient is almost just a wrap around fetch converting it to a cancellable observable, I did a quick google here and theres RxJS for React, but I have to say it looks kinda ugly

@@figloalds RxJS is not "framework-specific" in the same way Redux isn't. As in the authors want to believe they wrote a cool general abstraction which can be used everywhere, but it is so boilerplate-ridden and error-prone that you have to use another library to work with the framework of choice. And it becomes the de facto way of using the state management. That's why when you hear "Redux" you instantly associate it with React codebase, even though ACKSHUALLY it's React Redux which associates Redux with React. On top of that Redux has another abstraction called Redux Toolkit which brings a lot of things, a set of rules to deal with async state management and its error handling among the most important ones, which were suspiciously absent from base Redux. I didn't use RxJS but, looking at its basic concept, looks like it can easily become a hell of callbacks with quadrillion layers of indirection, with guidelines on error handling completely absent. I bet it's a lot nicer to use within Angular and you yourself think of angular code snippets when saying "RxJS".

If you use axios and typescript, then you can pass generic AxiosError to useQuery etc

You can type the React query error

We default to the type 'Error' in v5 and provide a way to let you override it with module augmentation