react-query vs RSC
Unanswered
Standard Chinchilla posted this in #help-forum
Standard ChinchillaOP
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?
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?
3 Replies
@Standard Chinchilla 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?
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.
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.
Standard ChinchillaOP
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.
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.
yeah i get your point. that's why i mentioned that react query is still useful (better) for some use cases. but generally, i've found more success combining both for different aspects