server-components-demo VS rfcs

I, along with many ReactJS devs, have been following the development of the "new" React Server Components API with excitement. It solves some common problems in React around data fetching and efficiency in client side applications. If you're interested in learning more about the API I'd recommend you listen to the recent JS Party podcast with Dan Abramov and Joe Savona from the React Team on the future of React, and then check out the React Server Components Demo on GitHub.

I borrowed this piece of code from the React Server Components demo Notes application.

And perhaps most importantly, one of the biggest limitations of RSC at this time is their out-of-the-box support. Currently, the React team has partnered with Vercel/NextJS to develop some boilerplate functionality within the NextJS structure (still experimental). Note: This boilerplate demo app was developed in the early stages of RSC, and will be replaced by the Layouts RFC going forward.

See the README for how to install the demo. https://github.com/reactjs/server-components-demo

Let’s use this example of a server component:

For example, as I started to play around with the React team’s Server Components demo, I realized I had to fundamentally change how I approached building components. Instead of just creating a new file and typing export const MyComponent = () => {}, I now had to start thinking about how the component would be used, to help determine whether it was a better fit for the client or the server.

If you want to play around with the demo code for React Server Components, you can find this code on GitHub.

As we see in the demo app, the server component is rendered in a special format which can be read by the client. We can see the special format in the below image

I'm looking forward to trying out React server components (I plan to fork the React team's demo and play with it), but I don't see myself having a heavy use for it in my everyday life. I'm not currently working on any personal projects that require interactivity, and for the projects I'm working on, server-side rendering is probably a better way to reduce my bundle size.

You could avoid shipping down the JSX templates but only by promising to never render a comment on the client. That's basically the approach taken by this React Server Components proposal: https://github.com/josephsavona/rfcs/blob/server-components/...

Rails has experimented with this sort of thing in the past; it requires some deep integration with the HTTP server so that clients can request updates to specific chunks of the UI rather than just URLs.

a nice summary can be found here: https://github.com/josephsavona/rfcs/blob/server-components/text/0000-server-components.md

Server Components allow developers to build apps that span the server and client, combining the rich interactivity of client-side apps with the improved performance of traditional server rendering. RSC Server components have no impact on the app’s bundle’s size. RSCs can be used to fetch data from API and can’t handle state management.

With that in mind, if you’re the type of person that likes to experiment with the latest and greatest, React Server Components is well worth trying. The Server Components intro video is excellent, the React team’s RFC is a well-written guide that details how everything works. There’s also an open pull request where you can submit your own feedback on the feature.

> At a high level, React Server Components are Components that can be rendered on the server and on the client.

This is blatantly wrong. The RFC (and Dan Abramov’s video) make it clear that server components can only be run on the server, and client components can only be run on the client - only shared components run in both environments: https://github.com/josephsavona/rfcs/blob/server-components/...

There were several motivating factors behind the creation of React Server Components (the RFC lists them all), but I wanted to focus on two of the problems that I see in my work that React Server Components solves: large bundle size and waterfalls in fetching data from the server.

We could mention many other benefits, like automatic code splitting, UX improvements, etc., but I recommend you read the RFC for an in-depth explanation. For now, let’s see an example, so we can better understand how these components work.