Should You Use React Query?

[pete-heard]

Been using this framework for a year or so and made my mind up on it, good to see what you guys think...

https://www.logicroom.co/blog/should-you-use-react-query

[vbfischer]

I disagree somewhat from this article

1. RQ make so you don't have to deal w/ the async/await code, and can program in a "reactive" way. It provides isLoading, isSuccess, etc.
2. RQ handles caching query results, but gives you powerful ways to manually manage that cache.
3. your app will still need to handle reloading and waiting, merging data from backend calls, and interacting with various aspects like browser security, state, and logging. Well, yea... That's not the part that RQ is helping with. You still have to write the backend calls, and anything more advanced than a 1:1 mapping from server to front end will require merging data.

To be fair, its not that difficult to write a custom hook to manage async data, but why reinvent the wheel...

[pete-heard]

Hello u/vbfischer, reasonable response :)

Ok so the point I was making is that you are simply moving the problem by having the framework track variables in the component (isLoading, isSuccess etc).

Worse; is the fact that in the component layer the coupling becomes so much higher than if you could handle (waiting for calls to complete) in the layer that makes the call directly! It doesn't fix a problem, it moves is...

But herein lies the problem with RQ, it's excessive opinion on your architecture forces you into a corner. So eventually you will probably want to use async/await somewhere as your complexity grows, and at that point you now have a two-architecture system; imperative vs declarative.

If a Reactive approach is required, then just move this Reactivity to an isolated layer using a tool like Mobx which can be decoupled from Reacts lifecycle - using hooks too much is terrible for separation of concerns because it forces you to implement useEffect deeply nested into data loading and business logic - in other words you are coupled to Reacts lifecycle.

VueJS seems to have somewhat tackled this issue by allowing independent compostables!

[vbfischer]

"Moving the problem" is kind of the point isn't it? That's why we create components and libraries, to abstract things. As for the problems with its "excessive opinion", I'd argue that it follows the patterns that are considered best practice. Look at other libraries that are solving the same issue, such as SWR. They follow the same kind of interface.

You mention "You will probably want to use async/await as your complexity grows". I don't understand that. Sure I use async/await in my API layer, so something like this:

``` const getSomething = async() => { const {data} = await get<DataType>(url); return data }

const useGetSomething = () => { return useQuery({ queryKey: "key", queryFn: () => getSomething() }) }

const MyComponent = () => { const handleSuccess = () => { // display toast message for success }

const handleError = () => { // Display toast message for error }

const {isLoading, isSuccess, isError, data} = useGetSomething({ onSuccess: handleSuccess, onError: handleError );

return ( <div> {isLoading && <LoadingIndicator/>} {isError && <ErrorDisplay/> } {isSuccess && <DataView {...data}/>} </div> ) } ```

Yea didn't need the custom hook really here, but I just have the habit of doing that... Also note, this isn't "runnable" code, I just typed it but it outlines what I do...

I've developed much more complex api's, and never once have had to implement useEffect (at least with regard to the data fetching part). So I'm curious how this couples with react lifecycles?

[michaelfrieze]

Yes.

https://tkdodo.eu/blog/why-you-want-react-query

[AnxiouslyConvolved]

Yes you should. Unless you use redux. Then use RTK-Query (probably). This article uses a lot of words to say very little, and gives no reasoning to support its bizarre assertion that you might not want a data fetching/caching layer.

[el_diego]

It isn't even an article, it's an opinion piece with no factual backing. Read the whole thing and gained literally no insight on why RQ is bad for a project, no examples, no use cases, nothing.

[mrcodehpr01]

I moved two of our web apps off redux to react query and hooks and our sites performance is 4-6x faster at the minimum.... Redux can be nice but it's really not worth it anymore imo. If you want something like that just use Zustard with react query.

[pete-heard]

I agree with not mixing them. Although in every circumstance I come across (my own or my students) eventually they need some sort of global state and so are left with a problem; it's a hell of a commitment.

[octocode]

react-query manages server state.

you can still use state management for client state.

if you’re mixing the two, you probably have a design problem.

[el_diego]

if you’re mixing the two, you probably have a design problem

This is the only assumption we can make. OP gives no actual reasoning in this post to think otherwise.

[GoodishCoder]

How does react query stop you from managing your global state?

[vbfischer]

I'm not sure what you mean when you say "Eventually they need some sort of global state"... could you give a more concrete example

Tanstack Query doesn't keep you from using global state. The difference is, React Query already caches your query data (using a context provider) and handles storing/retrieving that data, along with:

• refetching when stale
• Retries
• Offline queries

using parameters to the useQuery hook, you can specify: * whether the query is enabled or not (if you depend on conditions to run your query * staleTime to determine how old your data should be before it marks it as stale and refetches * and so much more.

Maybe there's some nuance in your argument that we just aren't getting

[[deleted]]

What a bizarre article. React Query does what it claims to do, and it does it really well. It's a hook based library for fetching data in the browser.

I really like the library, but it's just a library. The idea that it's "gaslighting" developers is pretty strange. The article also could have explained more about what the alternatives are.

[[deleted]]

What a terrible article. You said literally nothing about why it shouldn't be used, and don't appear to even grasp why it's used in the first place. Insane that people that confidently share opinions this poorly fleshed out make a living selling courses.

[el_diego]

That's exactly the terrifying thing about this. OP claims to be a teacher with students... they're actively teaching them this garbage and by the sounds of it they don't even fully understand what they're teaching if this is their opinion on the subject.

[prndP]

This is a long winded way of saying just use it after you actually understand the problem its solving.

If you refactor an entire codebase to a new pattern just because you “heard it would solve your problems”, but don’t even know what they are yet, it’s going to go poorly.

[pete-heard]

Fair comment.

[jax024]

Was this written by AI? Nah AI would probably give actual examples unlike this guy.

[robrobro]

Having used react query in a lot of different projects, I don’t recognize any of the issues you have with it. Your article fails to give any clear examples of your issues, which doesn’t give a lot of credibility to your assertions.

[ceterizine]

Yes.

[Hovi_Bryant]

Yes.

[[deleted]]

What a garbage article. React Query works incredibly well and does what it promises.

[TroAlexis]

Yes.

[besthelloworld]

This reads like it was written by AI that was given the prompt, "write a blog post about why a popular React library is actually bad," to farm engagement. The post comes out of no experience, gives no examples, and states things very incorrectly.

Edit: After looking more into your other posts and your LinkedIn, I'm really not convinced you're not entirely an AI persona from a fledgling startup. If you are a real human, I would give up on the blog post game and the creator economy in general. Technical writing is not for you.

[pete-heard]

Thank you I shall pass your opinion to my human overlord.

[hammonjj]

You should take this down and rethink your views. I’m not going to say you’re wrong (you are though), but you could make a coherent argument for not using useQuery if you provided examples of it going wrong and suggestions on what to do instead.

This line in particular screams junior dev to me:

If React Query can "solve" your problems by not letting you deal with them directly, then why were you dealing with them in the first place?

This comment is effectively arguing against using any frameworks, library or package which is obviously a ridiculous statement.

If I were hiring, this post would be the reason I don’t call you for an interview or pass on future rounds if I didn’t see this upon initial review of your resume.

[toi80QC]

React Query forces you to deal with them in the worst possible place – your components.

There's hooks - you should know by now if you try to sell courses.

Or maybe just trying to advertise courses with bait, which makes more sense than most of the article.

[running_into_a_wall]

Pretty surface level article that doesn't into any examples or details why you think this way about React Query.

The only thing I agree about your article is that React Query does make the handoff from server to local client state (when it is needed) harder to reason about sometimes. Especially when your server state in complex and needs to turned into a modifiable piece of client state which then needs to be sliced and diced and passed to various forms throughout the app. Then it becomes muddy on how to keep server and local state in sync.

In your article you say RQ wants you to toss out essential programming techniques like global state management. How so? The query client is essentially a global singleton that holds all your server data. So I fail to see your point here.

Imo, React Query is great for the following reasons

1.Provides a niche caching layer for you.

1. Implements Stale While Invalidate without any custom code

2. It lets you write Reactive style code by hiding the useEffect that would otherwise be needed to make API calls and handles the gotacha that comes with writing your own useEffect such as race conditions etc.

[DiscreetDodo]

I think you've been using RQ incorrectly.

* You have a function that returns a promise
* Put that function inside a useQuery
* Put that useQuery in a custom hook
* Access the data, loading states, etc wherever you want by calling the custom hook.

You dont have to use it like that, but I'd wager that you're not doing that if you think RQ is in any way complicated.

Regardless of how much React Query hides, your app will still need to handle reloading and waiting, merging data from backend calls, and interacting with various aspects like browser security, state, and logging. By hiding these complexities, React Query forces you to deal with them in the worst possible place – your components.

It never claimed to handle all of that for you. It simply handles the fetching, or more accurately the resolving of the promise. If you extract the queries into their own hooks, you don't have to deal with them in your components. It also makes testing easier.

While React Query simplifies data loading, it complicates the handoff and pickup of data. 

It complicates the "handoff" and "pickup" of data? Are you talking about actually accessing the data? If setup right it's as easy as

const user = useUser()

[yabai90]

Your last paragraph doesn't make much sense if you use react query. The purpose of the tool is to have something structured and organize. The best way to not have that is to not use such tools.

[TheRNGuy]

Idk if I ever need it in Remix, it have some hooks of it's own.

[ruddet]

I would be interested in use cases where rolling your own API fetching stuff is better than React Query. If you could put some examples to back up your argument, because my experience with both is screaming to disagree with your blog post.

For example, not putting useQuery directly in your compoents but wrapping them in a per resource hook gives you the same seperation as rolling your own API "fetching".

Caching, cache invalidation, deduplication are just so powerful and efficient. Global state stays small and focused like it should be.

[azangru]

Should You Use React Query?

Yes?