Exploring React Server Component Fundamentals

Hello everyone! I'm very excited to give a talk this year, especially because it's about my new project. It's about React Server components, which I've been learning and experimenting for several months.

Today, I'm going to share what I've learned so far. My name is Daishi Kato. I'm an open source developer, and some of my popular projects are Jotai and Zustand. You may know, but they are both for state management. They are like competitors, but it's actually good because they bring more feedback to us. Currently, Zustand is pulling ahead and Jotai is chasing. At React Day Berlin 2022, I spoke about Jotai. It's an honor to be here speaking again this year.

In the first part of this talk, we'll explore the fundamentals of RSC. I have a demo using just Node.js without any frameworks. It's not live coding, but I hope you'll find it enjoyable. If you're interested, you can try it on your own later. This demo is primarily for library authors or those who want to understand RSC's internal behaviors.

The second part we'll discuss my project, Waku. It's a React framework focusing on RSC. Let me start with an answer of mine. What is RSC? RSC stands for React Server Component. However, the server part in the name might be misleading. It's more about using React in places different from, say, the browser. And just a quick note, you can technically use RSC in browsers, too. Going deeper, what are the core of RSC? I believe the essence is serialization. Before RSC, React worked within a single memory space. But with RSC, React can now work on separate memory spaces. This could be between a server and a client, two servers or even within the browser's worker threads. Now, let's proceed with the demo. Let's begin by setting up a test project. For now, we'll use the canary channel of React until a stable version is out. The package React-ServerDOM-webpack is here to give us the RSC features.

It's designed specifically for webpack because some of its features have a close relationship with bundlers. However, we don't use webpack in our demo anyway.

Now let's move on. We'll start with a simple example without RSC. Here's our first example. It's traditional React, and it's totally unrelated to RSC. Looking at the code, you'll find we are simply defining an AppComponent and displaying the result with console.log. When you run the code, it will display a JSON object. This is often referred to as a React element or a JSX element. What's key to note here is that this JSX element isn't serializable. For example, it contains a symbol for its special typo property. In this example, the type property is a function which is not serializable. We'll explore how RSC addresses this shortly, but before that, let's look at the traditional server-side rendering with our next example.

Server-side rendering or SSR is a process to generate HTML content on the server. It's important to note that SSR is different from RSC. While RSC may run on the server, it doesn't produce HTML. By the way, SSR can technically run on browsers too. Now, let's examine the code. We utilize the RenderToPipeableStream function from react-dom-server. This function is available in the stable version of the react-dom package. Since RenderToPipeableStream returns a stream, we can't simply use console.log. Instead, we direct it to Process.standard.out. Running this code will display the resulting HTML. SSR is commonly used during the initial page load to enhance user experience and search engine optimization. In our next example, we'll see how RSC works in comparison to this SSR example.

Now, let's explore how the serialization aspect of RSC performs. In this demo, we use the renderToPipableString() function from react-server.webpack/.server. Do note, this is available only in the Canary version. Except for importing the function from a different package, the rest remains the same as the previous example. Running this code gives us a JSON-like output.

It's commonly referred to as the RSC payload. This payload is an internal representation and is often considered as implementation detail. RSC is renderer-independent, which means, while it might be frequently used with react-dom, RSC isn't strictly tied to the DOM.

Also, as you see in this example, we supply an option to nulljs, react-server-condition. It's essential because without this, the code doesn't run. This specification is to determine if the code runs under an RSC environment.

Next, we'll look at how the deserialization process takes place. In this demo, we're focusing on deserialization. Let's look at the code. The react-server.webpack slash client refers to the client side of the library. Typically it's used in browsers, but for the sake of this demo, we are using the node.js version. The function createFromNodeStream is to deserialize the RSC payload. To make the demo work in a single Node.js instance, we are using the paththrough stream. In real-world scenarios, the data from this stream might be sent over a network.

The outcome on the console might look familiar. It's the same as the JSX element we discussed in our first example. In fact, executing the console.log statement which is commented at the end of the code will show the identical result twice. This is the core functionality of RSC. Serializing a JSX element, transferring its stream by any method and then deserializing it to reproduce the same result elsewhere. We'll dive a little deeper in the upcoming examples.

RSC's ability to serialize data isn't just for React. It can actually handle any JavaScript values. I would think of it this way. RSC supports JSX elements on top of standard JavaScript values. Now, taking a look at the code and its output, this basic example demonstrates that RSC can handle objects, arrays, strings, and numbers. While we are highlighting the serialization in this example, deserialization would just work similarly. At first glance, this might seem very basic. Something we can do with JSON string file and JSON parts. So, what would be the unique aspect of RSC? You might notice an extra prefix before the JSON string, which in this case is zero column. Remember, the RSC payload is designed as a string meaning data is transferred step by step.

Each line represents a chunk of JSON with the prefix acting as an ID so that it can be linked to another chunk of JSON. In the next example, we'll see how data is transferred over time. This example shows how RSC deals with promises. Usually, promises can be serialized. But RSC makes it possible by sending the resolved value in a stream as time passes. On the other end, when deserializing, you get back what seemed like the original promise. Looking at the code, the function just returns an array containing a new promise. If you run this code, it will first show an array with a placeholder inside. Wait for a second, and the resolved value appears. And you don't have to worry about how it was sent. It just works behind the scene.

This example is about a basic promise. As far as I understand, this should be similar to how React Suspense works. If you use suspense on the server, the server first sends a fallback and a placeholder, which will be resolved afterwards. In the next slide, we'll adjust our focus slightly and see how Client Components works with RSC. One of the biggest features with RSC is Client Components. RSC allows us to interleave Client Components with Server Components. Now, let's reveal how Serialization works for Client Components. Taking a look at the code, there's a Counter Component, which is a Client Component. Next, inspect the Counter.js file. At the top, you'll notice the useClientDirective. This is crucial, as it indicates that the file acts as an entry point for Client Components. We only need the directive for the entry point. We don't need to put useClientDirectives for all files. The remaining part of the file simply defines a regular React Component. Back in our main file, there's a mention of ReactServer.webpack.node.register. This statement registers a handler for the useClientDirective. Although React offers multiple methods, we've chosen this particular method for simplicity in our demo. To get our demo running, there's a small tweak required. You'll find a manifest object in our code.

Typically, this would be automatically produced by a bundle. But for our demonstration, we've defined it manually. This manifest object is passed to the renderToPipelineString function. Running the code shows a cryptic result. While you don't need to understand every detail, it's worth noting the line that displays ID chunks and more. They are something that we detailed in the manifest object. This information becomes key when deserializing the RST payload on the client, and it allows to dynamically load the client component code. Such information is called a client reference.

Next, let's take a brief look at how the deserialization aspect works. In this demo, we are expanding on the previous example by adding the deserialization process. The areas marked with red rectangles indicate the differences from the previous example. As with one of the previous demos, we utilize CreateFromNodeStream and Passthrough. The id within the manifest object is the file name in this case, so that the client can import it from the server later. Additionally, we've created a config object, which we'll be passing to the CreateFromNodeStream function. Consider this approach a temporary workaround. It's not representing the real implementation. Now let's look at the outcome. The result shows a div element with two children. The first one is an h1 element, and the second is a lazy element, representing our client component. This demonstrates the React tree where server and client components are interleaved. Theoretically, if we render this tree, it will display the content. We won't do that in this talk but it will be an interesting challenge.

This is the end of our demo, let's move on to the next topic. We have learned how RST works, especially its serialization process. In our demo, we simply used functions exported by the React libraries. Now you might wonder if we can directly use those functions in our app development. It would be pretty hard and could require a lot of effort. It becomes clear that something like a framework would be helpful. My motivation was to understand RST better and to integrate some of my libraries. And that drove me to create a minimal framework that primarily supports RST.

The framework I've been working on is called WACU. We can't go too deep in details, but let me briefly tell what features are being developed. So what is missing from the core aspect of RST? In other words, what is required beyond serialization? We'll discuss four features as those are currently supported by my framework.

The first feature is a bundler. Recall one of our demos with the use client directive. While we use the function from one of React libraries, it's basically a bundler's job. We could technically create a client reference using a runtime solution, but such an approach might not be ideal and could negatively affect the developer experience. Therefore, a bundler is essential to support those directives. Along with a bundler, React libraries help support handling them. A bundler is also crucial for resolving a client reference to get the client module. I believe it's fair to conclude that a bundler is required for RSC.

The second feature is a server. RSC serialization results in a stream. To transmit this stream over a network, we require an RSC-capable server, usually an HTTP server. This server must be equipped to handle specific requests and respond with RSC payloads. A server is essential for producing dynamic data. However, when it comes to static data, the RSC-capable server isn't strictly necessary. This is because we can construct RSC payloads at build time and then deploy them with a standard HTTP server. So RSC doesn't always need a server. To differentiate the two scenarios, we might refer to them as dynamic RSC, which involves a server, and static RSC, which doesn't.

The third feature is a router. While the necessity of a bundler and a server is straightforward, understanding the importance of the router for RSC might be less obvious. Please don't get it wrong, but a router isn't strictly necessary, in my opinion. However, if your app uses a router, it could be of help. This is because a router lets the server know more details before the client starts. This means the server can do tasks before sending data to the client, and it can lead to better performance. We view a router as an additional feature for an RSC framework. However, with a router, we can further optimise the use of RSC.

The last feature is SSR. SSR is typically a key feature in a React framework.

In our context, SSR refers to generating HTML on servers. So SSR itself is not related to RSC, which implies SSR is not necessary for an RSC framework. However, there is a benefit of SSR, and that is improving the initial page load. Remember that it doesn't contribute to the performance for subsequent updates. So if the initial page load performance is a priority for your app, then SSR is essential. If the initial page is purely static content, you can generate the HTML during the build time, also known as SSG. We distinguish them as Dynamic SSR and Static SSR.

I have been developing Waku since last May. It includes the four features I just presented. Notably, these four features are stacked, allowing you to use them selectively. For static sites, you might only need a bundler. For dynamic sites, introducing a server would be appropriate. For more complex apps, consider adding a router and SSR.

Looking ahead, one of my goals is to develop a solution integrated with client state management libraries, such as Jotai and Zastand. I anticipate the need for a dedicated router for these integrations. We'll keep exploring this direction. Waku is an ongoing project and if it catches your interest, it's open-source, your contribution would be invaluable. Feel free to visit the Waku repository on GitHub to see the implementation of these features. Your feedback is always welcome. And with that I've reached the end of my talk. Thank you for your attention.