It's all about the frameworks

We've built PHP!

This week Kent hosted a live stream with Dan and Joe from the React core team to hash out what RSC's are all about. There's quite a lot of buzz and confusion around this new feature.

Dan has been super active on Twitter trying to answer questions and explain RSC's.

Briefly, RSC's allow React components to be rendered on the server, including data fetching. To be a server component though, they cannot hold state or produce side effects (e.g. useState and useEffect).

This means less code gets sent to the client, so faster load times, and potentially faster data fetching if your server is located with your DB.

Confusing components

At a high level, this makes sense. The devil's in the details! The tricky part is these RSC's are tightly bound to the frameworks right now, and so you really need Next.JS to play with this new tech¹.

Many folks in stream chat were expecting more. Docs? Examples? Repos? But it seems we're still too early for that just yet, and even Next.JS classes this as beta. That does signal things could change but these calls for comments are a good way to put the feelers out and see what's what.

The confusion comes over how exactly they work. Like kids in a toy store, we want things, and we want them now! RSC's bring a new mental model² to the table, and we're going to need to get on board with that before we decide if they're cutting the mustard.

The best place for this right now is Dan's Twitter feed.

Serverside concerns

So what's the problem?

The waterfall

Due to RSC's being nested among Client Components, it's going to be easier to end up with a server-side waterfall. As the tree gets parsed, one RSC can trigger a request, then as the tree progresses, more requests get triggered. Unlike Remix where server data is gathered at the route loader.

The solution is to de-dupe requests via a new fetch(). Next.js is doing this already, and means a query key can avoid waterfalls where possible.

Patching fetch

There was some buzz a while ago about React patching fetch. Muscling in on browser API's for React wasn't taken too kindly.

They're not patching fetch, though it will be a custom fetch that the frameworks will need to provide if they want, but it's ultimately a decision for the implementor.

Cache headers and accessing req object

Can we access the full request object with this custom fetch, and can we set custom headers?

This had a bit of back and forth but ultimately it sounds like, maybe. Depends on the framework 😄 The discussion was around the benefit of being able to do that in the first place and why it's needed.

'use client'

In Next.JS components are RSC by default, and you need to add the use client directive to function as they do today. This "opt out", rather than in, is seen as annoying and not overly clear what type of component you're dealing with from a DX perspective.

Dan did acknowledge this and mentioned it was a bit of a trade off. For the given benefits, this seemed like the best option, though they did try others and liked those worse. Perhaps it will improve as more and more people start to use them.

More than a feeling

Overall, there was a sense of excitement. Still some trepidations from chat, and Kent didn't seem 100% won over, but he did seem more appeased.

Many of these conversations seem to start with comparisons of frameworks though. "Remix does it like this", "Astro does it like this" which I think is wrong sort of questions. The real question is "how does this improve my life as a React developer", "what are the possibilites"? And does it improve UX as well as DX? For me?

Yes, I think it will. But it won't come overnight and not without a bit of work on your mental model.

Shopify did attempt this with Hydrogen but abandoned it in favour of Remix. ↩
For most React developers certainly. Though if you use Astro or Remix, there are some comparisons here. ↩

Blog