blog/you-might-not-need-react-query

[giscus[bot]]

blog/you-might-not-need-react-query

React Query is a great library, but like any tool, you should choose it for the right problem

https://tkdodo.eu/blog/you-might-not-need-react-query#inject-comments

[bryanltobing]

🚀🚀

[mkarajohn]

In a sea of strong opinions which seems to be the trend right now, this was a refreshing read. Everything has its tradeoffs indeed.

[sairajchouhan]

may be not a right place to ask but, is server actions a react feature or a next.js one?

[TkDodo]

it's a nextJs feature built on top of React primitives afaik

[its-monotype]

Good article! I personally prefer NestJS as backend framework

[redhair]

Great read and I couldn't agree more. react-query and RSC are not at odds, especially for apps with a variety of data fetching requirements.

[eBitzu]

Not everyone is doing SSR, so react query is still a valid choice

[TkDodo]

Definitely. There are some big IF statements in the core take-away:

If you're starting a new application, and you're using a mature framework like Next.js or Remix that has a good story around data fetching and mutations, you probably don't need React Query.

[papadavis47]

Very helpful article. Thank you 💯 🙏

[debater-coder]

I think there are some good reasons not to use SSR. For example, with service workers, we can build web apps that are closer to native apps, as they only get source code from the server for updates. In this case, it would be silly to use SSR, as 99% of the time the app is loaded from cache. In this case, if we were to run code both on the client and the server, it would increase complexity. Personally, I think we should either do data fetching only on the server (with React Server Components), or on the client (with React Query). For websites, it makes sense to do things on the server, and for web apps things should be done on the client. I feel like true web apps (things you would expect from native, like 3D modelling, photo editing, etc.) should not be done with server-side libraries such as Next.js or Remix, but with client-side SPAs. We shouldn't neglect these types of apps.

Great article though!

[nninnnin]

Great foresight! It would be different what kind of application we build.

[Moshyfawn]

I'm not here to tell you to use React Query in every possible situation, just because I happen to maintain it. If you decide to use it, it should be because it helps you solve a problem.

I'm stealing this quote to use as an answer to many React Hook Form question Lmao

[vezaynk]

From a high-level point of view, React-Query offers a generic wrapper around asynchronous operations. Data querying naturally just happens to be the most common one.

I haven't used it for this, but I imagine it's generally useful in any cases where you have a long-running operation which needs any of the following:

• rate-limit retrieval with caching
• observe status of operation (inactive, pending, done, error, etc)
• handle errors procedurally during the component lifecycle
• probably others I'm missing

I recently wrote about breaking up expensive blocking synchronous work into non-blocking asynchronous work, and I imagine that combining those cases with React-Query could be convenient in the React world.

[SimHoZebs]

Seeing this article show up confused me because React Query was never ONLY a data fetching tool for me. If data fetching was all I cared for, I would've stuck with fetch/axios. It seems that those who think React Query is dead doesn't realize data fetching itself was never a problem. RSC doesn't replace query caching, conditional cache invalidation, error handling, etc. If you think React Query is dead, you aren't using the library to its full potential.

[nninnnin]

But if do data fetching on the serverside, is it needed to cache data on the client side? or to invalidate cache? I think not..

[SimHoZebs]

As far as I understand, it would depend on the kind of data being fetched. RSC is great when the data is designed to be static for its usage, but any data based on client-side interaction still benefit significantly from React-Query.

Imagine, as a simple example, a page of a user's transaction history on a financial management app like Mint. Let's say a Walmart transaction was automatically assigned as 'Groceries', but the user wants to assign it as 'Home Supplies'. The change request requires client-side, conditional cache invalidation for client-side data to sync with the changes that were just made on the server. If this page was designed with data fetching on RSC, the user would need to reload the website to see the update. But of course, this may change with Next.js Server Actions.

[nninnnin]

Sure it is. I just thought that if really dynamic contents rendered on server side, It would be waste of networking resources because it has enough resources (and even faster) to be rendered on clientside. Problem is when and how to be synched with the server state, and React Query does work on it. So yeah, like you said, "how many times this component(UI) is updated by user?" will be the mostly considering questions for us FE engineers. Thank you for giving me nice illustrations :)

[gnunesdev]

really great read, it gave me some good ideas on how to implement react query while trying out RSC 🚀

[tholder]

We've used server components with react query on a big app, it's working great. We just pass the data over to react query in a cache loading component and everything just works. Being able to then do everything on the client that tanstack query does is great. Optimistic loading particularly is something I think we would miss without it.

[goktugerce]

I can’t say I’m experienced in either React Query or Server Components. I only started migrating a personal project to React Query after reading your awesome posts, but I feel like you still need React Query in a lot of different situations. Maybe it’s due to my lack of understanding of Server Components.

I was designing a page that displays a table with a lot of filtering (I can’t load all data and filter it on the client because it is a lot of data), I struggle to come up with a solution for Server Components. First, you can’t use state variables or hooks. I don’t really like to push every filtering change to URL (if that is the solution). I would rather have a custom useQuery hook with my filter variables (sorting, filtering, paginating) so React Query takes care of it instead. That way I don’t have to worry about which components will be server components and which components will be client components.

Again I am not very experienced in either technology, so maybe I am thinking it incorrectly. But that’s my take so far after a week of experimenting with both.

[TkDodo]

I think the interactive part (filters) would still be a client component so that you can use state. You could then run a server action to fetch new data, or indeed update the url and revalidate the route.

It's a different paradigm, and as long as you're happy with React Query, there's no need to change anything really :)

[omerman]

Great article.
I keep using it alongside server components mainly for fetching data that should not be SEOed like specific user's data, and then I would still want to do it in the background and display a loading state and all that :)

[Karim-capatlas]

Absolutely! Stability is key in complex projects, and that's why many developers still rely on PHP (even with all the new frameworks emerging). The good news is, React Query's core functionality should remain relevant. The question is how it integrates with these exciting new features!