Jumping off the React Server Component hype-train

Nicholas Ortenzio
2 min readJun 14, 2023

--

Photo by National Cancer Institute on Unsplash

One of the exciting things about NextJS was writing isomorphic code. Specifically when it came to React components (since obviously not every aspect of the project is meant to run on both client and server.) But the React components themselves, that was pretty huge.

You kind of lose that with RSCs. Like, yes, its still React, but its two different paradigms, and theres a lot of careful planning that needs to go into the structure of your application before you start to code, because, right now at least, theres a lot of “you cant do that anymore” when using the NextJS /app directory to take advantage of server components.

Let’s take a look at what those are:

A table that compares appropriate use cases for React Server Components vs React Client Components
From nextjs.org

What it basically comes down to is this: code within a server components cannot make any references to state, DOM events, or hooks. While that make sense on the surface (as it simply doesn’t exist on the server), I think it’s a step backwards to introduce limitations where there were none before.

Context providers pose another hurdle, since they are essentially state-management, and that is forbidden in a RSC. It’s fairly common to have a provider near root of the application, to share global state and events. [also, why doesn’t React have an event bus?] So if you need that, the solution is to ensure that every child of the context provider is a client-side component.

So what do you do if you have multiple Server components that need to share fetched data? The recommendation is to simply request the data multiple times and let NextJS take care of de-duping the requests. But what if those requests aren’t (or shouldn’t be) cached?

There’s an answer to that too, but the key point is that you’ll be dedicating time to finding solutions to new issues and edge cases… that may require you to opt out of effectively using RSCs.

I’m not saying that React Server Components are “wrong” or “bad” or “haunted” (although I reserve those opinions), just that RSC requires a lot of upfront architectural decisions that initially seem antithetical to the appeal of using NextJS in the first place.

In conclusion, I refuse to change and everyone else is wrong.

Nicholas Ortenzio invented dipping pretzels into Nutella, among other things.

--

--