#react-query vs RSC

4 messages · Page 1 of 1 (latest)

patent flower
#

Hi, can someone help me with an existential question about fetching data using React Server Components (RSC) versus using react-query?

I'm trying to figure out the benefits of using RSC for data fetching over react-query. Initially, I thought with react-query you can handle all states: pending, data, and error, in a single component...

With RSC, you need to manage the fetching in one component, create another component ('use client') to pass the fetched data to, have another for the pending state, and another for the error state. Additionally, you need to add two more components: Suspense and ErrorBoundary. These last two can't be used in the same component where the fetch is done. So, to ensure standard handling of an HTTP request with RSC, you have to use/create more components than with react-query.

Then there's the part about sharing fetched data between components. It seems the answer is the same for both cases: "use the cache". However, I feel I have more control over the cache with react-query than with the cache in Next.js...

Am I missing something? What benefits do I get with RSC over react-query?

compact ironBOT
#

🔎 This post has been indexed in our web forum and will be seen by search engines so other users can find it outside Discord

🕵️ Your user profile is private by default and won't be visible to users outside Discord, if you want to be visible in the web forum you can add the "Public Profile" role in id:customize

✅ You can mark a message as the answer for your post with Right click -> Apps -> Mark Solution
(if you don't see the option, try refreshing Discord with Ctrl + R)

sonic badge
# patent flower Hi, can someone help me with an existential question about fetching data using R...

major benefit is with rsc, the data is being fetched on the server not on the client, which potentially increases page load.

i'm not sure fetching with RSCs are as complicated as you say though. fetch requests are pretty straightforward, fetch in a server component and pass data to a client component (if the data is indeed needed in the client, say for some user interaction)

for mutations, server actions are pretty good. coupled with some new React hooks, handling the loading, error states shouldn't be much of a hassle. i'll recommend watching Leerob's talk at React Conference a few days ago - https://www.youtube.com/watch?v=0ckOUBiuxVY (from around 3:32hr).

final point. i think react query is still beneficial in some cases and I occasionally use it for when I need some fetch data invalidated at intervals, query invalidation after mutations, or some other react-query specific functionality RSCs won't just give me atm.

patent flower
#

Thanks for sharing this, it's very insightful.

What I was trying to say about fetching data in RSC is that when you need to share fetched data across different parts of your component tree, you have to rely on the cache. This can be problematic if we use Next.js's cache.

With react-query's cache, you can access, modify, and manage it as you wish.

Another point I mentioned is the need to use Suspense and ErrorBoundary to handle the pending and error states of the HTTP request. Without the Suspense component, you'd block the user's page until the fetch completes, and to handle potential errors, you need to use ErrorBoundary or an error.tsx file. You don't need all this with react-query since you can handle all these states within a single component.