What to Expect From Zero-Bundle-Size React Server Components

Initially, React was mainly a frontend framework that focused on the client-side. And now it is interesting to watch how the Facebook team is developing React server-side.

In December 2020, the React team announced a new feature called React Server Components, which is still in development but you can try the demo. Since then, the React community has been actively discussing this new way of building React applications. Most of the feedback is positive, so I decided to try it myself. 

What We Have Now

For server-side rendering, you need to either set up your own server and write a custom bundler or employ server-side React frameworks like NextJs, AfterJs, Gatsby.

And it is OK when you just started. However as the codebase grows, so does the bundle size and the cost of maintenance. 

Sometimes the logic for building the markup is based on databases. So you have to run it on several levels of abstraction and then pack. It’s even worse when you need to output exactly HTML from a server. You can fix it with dangerouslySetInnerHTML, but it is considered an anti-pattern.

What React Offers

Zero-bundle-size react server components are not a replacement for traditional Server-side rendering (SSR). The components complement SSR. Paired with, let’s say, Next.js, they create an intermediate format and enable rendering by sending no bundles to the client-side. This allows merging the server-tree with the client-side tree without a loss of state and enables scaling up to more components.

SSR has the principle of sending the pre-built HTML markup and then hydrating it with JS, so a user can not interact with your website until the JS is loaded. Server components behave in a different way, they can be called multiple times and not on the first load and have their own format of transferring data over the network.

Benefits

1. Integration with NodeJS ecosystem, so you are able to use familiar developer tools.

2. React teams worked a lot to prepare the React wrapper packages for Fetch and Postgres, which are now quite common in most apps. They are currently in the experimental phase.

3. Data optimization over the network is visible. If you look at network calls, you will see just JSX transferred from the frontend.

4. You will have no problems with using the feature thanks to the uniform interface of the components. So, I think it won’t be a hard task to implement zero-bundle-size react server components into your current projects. 

Limitations 

1. Since it is upgraded but still server-side rendering, we face problems with libraries that are programmed to have access to the window. In practice, we have access to the global, but not the window in the backend. 

For my test project, I used the Leaflet app for maps. But maps don’t load if rendered in the backend. So you have to transfer the maps to the frontend (through .client.js).

2. If you initially have a create-react-app (CRA), you can’t use the new components so you will need to eject from its ecosystem and tweak webpack configuration the way you need it. Taking into account that a lot of projects are developed with CRA, it is a considerable problem because they don’t have an easy opportunity to upgrade. 

3. Since the feature is not finished yet, there is no documentation, and you have to read code, download the demo-app, and use the debugger to discover the requests between the frontend and backend. 

4. Also without documentation it is not clear how to work with pipeToNodeWritable, and how it interacts with unstable_useTransition.

Wrapping Up

Probably, with the server components, we will get a good user experience, cheap maintenance, and fast performance at the same time. 

For now, developers do need to think about the optimal compositing of the network requests and working with the backend resources. This includes proper planning of architecture, isolation of logic for the server-side and client-side part. With React server-side components, these two concerns are merged, but in more intuitive way. And what’s more important, it’s up to you if you want to use them. You can combine it with existing architecture and use familiar technologies and techniques with this new approach because React is not an opinionated framework, it’s a library which can be used in many different ways. 

There are still interesting and not covered cases such as sharing the react context and redux-like libraries as well as the ways they will behave with this new ecosystem. Also, the documentation does not mention how you can use this feature with typed languages, like TypeScript. But the React team states that they value developers’ feedback, so you can mention them on social media to let them know which cases are crucial for you.