Exploring React Server Component Fundamentals

Rate this content
Bookmark

I've been developing a minimalistic framework for React Server Components (RSC). This talk will share my journey to deeply understand RSC from a technical perspective. I'll demonstrate how RSC features operate at a low level and provide insights into what RSC offers at its core. By the end, you should have a stronger mental model of React Server Components fundamentals.

21 min
12 Dec, 2023

Comments

Sign in or register to post your comment.

AI Generated Video Summary

This Talk introduces React Server Components (RSC) and explores their serialization process. It compares RSC to traditional server-side rendering (SSR) and explains how RSC handles promises and integrates client components. The Talk also discusses the RSC manifest and deserialization process. The speaker then introduces the Waku framework, which supports bundling, server, routing, and SSR. The future plans for Waku include integration with client state management libraries.

1. Introduction to React Server Components

Short description:

Hello everyone! I'm very excited to give a talk this year about React Server components. I'll share what I've learned so far, explore the fundamentals of RSC, and discuss my project, Waku. RSC stands for React Server Component, and it's about using React in places different from the browser. The core of RSC is serialization, enabling React to work on separate memory spaces. Let's proceed with the demo using the canary channel of React and the package React-ServerDOM-webpack.

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.

2. Introduction to RSC and SSR

Short description:

We'll start with a simple example without RSC. It's traditional React, and it's totally unrelated to RSC. This JSX element isn't serializable. 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. 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. Running this code will display the resulting HTML. In our next example, we'll see how RSC works in comparison to this SSR example. Let's explore how the serialization aspect of RSC performs. In this demo, we use the renderToPipableString() function from react-server.webpack/.server.

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.

3. RSC Payload and Deserialization

Short description:

RSC is renderer-independent and can handle any JavaScript values. It serializes JSX elements and transfers their streams for deserialization elsewhere. The RSC payload is a string that allows data transfer step by step.

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.

4. RSC Promises and Client Components

Short description:

In this section, we explore how RSC deals with promises and how it is similar to React Suspense. We also discuss the integration of Client Components with Server Components and the serialization process for Client Components.

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.

5. RSC Manifest and Deserialization

Short description:

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. 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 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 is the end of our demo, let's move on to the next topic. We have learned how RST works, especially its serialization process. Now you might wonder if we can directly use those functions in our app development. 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.

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.

6. Features of the WACU Framework

Short description:

The framework I've been working on is called WACU. It supports four features: bundler, server, router, and SSR. A bundler is required to support directives and resolve client references. A server is necessary for dynamic data, but not for static data. A router can enhance performance by allowing the server to perform tasks before sending data to the client. SSR is a key feature in a React framework.

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.

7. SSR and Future Plans

Short description:

SSR is not necessary for an RSC framework, but it improves initial page load. Static sites may only need a bundler, while dynamic sites require a server. For complex apps, add a router and SSR. Future plans include integration with client state management libraries. Waku is an ongoing open-source project. Visit the Waku repository on GitHub for more details.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2023React Advanced Conference 2023
27 min
Simplifying Server Components
Server Components are arguably the biggest change to React since its initial release but many of us in the community have struggled to get a handle on them. In this talk we'll try to break down the different moving parts so that you have a good understanding of what's going on under the hood, and explore the line between React and the frameworks that are built upon it.
React Summit 2023React Summit 2023
26 min
Server Components: The Epic Tale of Rendering UX
Server components, introduced in React v18 end these shortcomings, enabling rendering React components fully on the server, into an intermediate abstraction format without needing to add to the JavaScript bundle. This talk aims to cover the following points:1. A fun story of how we needed CSR and how SSR started to take its place2. What are server components and what benefits did they bring like 0 javascript bundle size3. Demo of a simple app using client-side rendering, SSR, and server components and analyzing the performance gains and understanding when to use what4. My take on how rendering UI will change with this approach
React Advanced Conference 2023React Advanced Conference 2023
28 min
A Practical Guide for Migrating to Server Components
Server Components are the hot new thing, but so far much of the discourse around them has been abstract. Let's change that. This talk will focus on the practical side of things, providing a roadmap to navigate the migration journey. Starting from an app using the older Next.js pages router and React Query, we’ll break this journey down into a set of actionable, incremental steps, stopping only when we have something shippable that’s clearly superior to what we began with. We’ll also discuss next steps and strategies for gradually embracing more aspects of this transformative paradigm.
React Day Berlin 2023React Day Berlin 2023
27 min
React Server Components
React Server Components are a newer way of working with React that is widely adopted in frameworks like Next.js. In this talk, we will look under the surface of how they work and are executed on the server side, and how they fit with server rendering and traditional React apps.

Workshops on related topic

React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
WorkshopFree
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up
React Advanced Conference 2023React Advanced Conference 2023
153 min
React Server Components Unleashed: A Deep Dive into Next-Gen Web Development
Workshop
Get ready to supercharge your web development skills with React Server Components! In this immersive, 3-hour workshop, we'll unlock the full potential of this revolutionary technology and explore how it's transforming the way developers build lightning-fast, efficient web applications.
Join us as we delve into the exciting world of React Server Components, which seamlessly blend server-side rendering with client-side interactivity for unparalleled performance and user experience. You'll gain hands-on experience through practical exercises, real-world examples, and expert guidance on how to harness the power of Server Components in your own projects.
Throughout the workshop, we'll cover essential topics, including:
- Understanding the differences between Server and Client Components- Implementing Server Components to optimize data fetching and reduce JavaScript bundle size- Integrating Server and Client Components for a seamless user experience- Strategies for effectively passing data between components and managing state- Tips and best practices for maximizing the performance benefits of React Server Components
Workshop level: 
No matter your current level of React expertise, this workshop will equip you with the knowledge and tools to take your web development game to new heights. Don't miss this opportunity to stay ahead of the curve and master the cutting-edge technology that's changing the face of web development. Sign up now and unleash the full power of React Server Components!
React Advanced Conference 2021React Advanced Conference 2021
170 min
Build a Custom Storefront on Shopify with Hydrogen
Workshop
Hydrogen is an opinionated React framework and SDK for building fast, custom storefronts powered Shopify. Hydrogen embraces React Server Components and makes use of Vite and Tailwind CSS. In this workshop participants will get a first look at Hydrogen, learn how and when to use it, all while building a fully functional custom storefront with the Hydrogen team themselves.
React Advanced Conference 2022React Advanced Conference 2022
81 min
Build a Product Page with Shopify’s Hydrogen Framework
WorkshopFree
Get hands on with Hydrogen, a React-based framework for building headless storefronts. Hydrogen is built for Shopify commerce with all the features you need for a production-ready storefront. It provides a quick start, build-fast environment so you can focus on the fun stuff - building unique commerce experiences. In this workshop we’ll scaffold a new storefront and rapidly build a product page. We’ll cover how to get started, file-based routing, fetching data from the Storefront API, Hydrogen’s built-in components and how to apply styling with Tailwind.You will know:- Get started with the hello-world template on StackBlitz- File-based routing to create a /products/example route- Dynamic routing /products/:handle- Hit the Storefront API with GraphQL- Move the query into the Hydrogen app- Update the query to fetch a product by handle- Display title, price, image & description.- Tailwind styling- Variant picker and buy now button- Bonus if there’s time: Collections page
Prerequisites: - A Chromium-based browser (StackBlitz)- Ideally experience with React. A general web development background would be fine.