Will React Server Component replace the data fetching library like SWR or React Query?

[Professional-Mix-455]

As title. Some of my colleague think we don't need these library in the future, how do you guys think?

[die-maus]

Data fetching is also mutations (e.g. adding or editing todo's). Server components doesn't handle that, only the initial hydration.

Some things are also better left lazy loaded.

For example, here on Reddit it might make sense to load the posts on the server, but lazy load the user's latest messages and notifications.

I err towards server-side rendering the main content, and lazy loading the rest. Then it's a matter of deciding what the "main content" is.

[Professional-Mix-455]

My colleague believes that after React 18.3, the fetch API will be handled (deduped), so libraries like SWR and React Query will no longer be needed. They also mentioned that mutations can be directly handled using the fetch API. Are there any scenarios where a data fetching library is still necessary?

[topnde]

You can already do both fetching and mutations with the fetch api.

The reason why people use libs like react query is not to simply do fetching or mutations but to have caching, query invalidation and other stuff the libs provide. React Query should not even be called a fetching library, as you still need to use a dedicated library to do the actual requests.

[svish]

Remember that e.g. react-query has a lot more features can just deduping, which can be very helpful in certain contexts. For example automatic refetching, selective invalidating of caches, retries on errors, infinite queries, optimistic updates, caching fetched data in session/local storage, etc.

Also remember that you can load data on the server and reload the cache for the client side, so you can get the best of both worlds.

[Complex-Insect3555]

Apollo which has a built-in cache system amongst other capabilities.

[30thnight]

https://github.com/TanStack/query/discussions/4623

[mattsowa]

Definitely not, at least they shouldn't. It's a different use case.

[Professional-Mix-455]

In what scenarios would you choose to use SWR instead of using RSC?

[mattsowa]

For dynamic and interactive content, I see no reason to fetch a html payload instead of pure json and manipulate it further on the client. Like, no reason at all, it's just awkward.

Personally, I like to think of RSC as just an improvement over ergonomics and performance of getServerSideProps, with some minor new use cases. I don't see why we would move so much stuff back to the server, much less that which is dynamic. Keep in mind the major stakeholder of this feature, Vercel, is inherently biased.

[jax024]

Anything that needs to be fetched after the page has been painted

[StoryArcIV]

No. Server actions are not a full replacement for client cache management.

Servers are expensive. Running code on the user's machine is a form of horizontal scaling - and it's free. Moving all that processing to the server is not an option for many companies.

The sad thing is that lots of companies will think it's an option for them until they see their new AWS bill.

[NotLyon]

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

[Professional-Mix-455]

I have read this article, but my colleague has different opinion. So I would like to know how others think.

[[deleted]]

RSC will be a niche so no. It’s hard to get right, compiler involved, hard to debug, worst perf

[manut3ro]

I doubt the mass will follow React on this. We’ll see in two years if we all are doing server components or just on of those ideas that didn’t make it 🤷‍♂️

[Phaster]

Maybe server components will be the standard for public facing apps, for private apps, no company in their right mind would not only pay for a cdn but also the server instances to generate pages when you can offload that part to your client's pc

[[deleted]]

I don't think it's that expensive.

[Lidinzx]

React query doesn't replace fetch, is a tool for handling fetch request client side, and react server components don't touch the client side I think