Meet React Flight and Become a RSC Expert

My name is Mauro and I work for a company that is called Doubleloop in Italy. And I mentioned this company because it's been very important for me being here today. First of all because they are my main sponsor for being here doing this talk, but also because this company has some traditions. For example, we have special Fridays. On Friday we don't work for our customers, we don't do any usual work. I would say that we try to not work at all usually, but we do something different. For example, we explore some new topics.

And it was during one of those Fridays that I decided to explore RSC, React Server Components, because everybody was talking about them, but I didn't know anything, so I was very curious to learn something. How I did it? Well, I started by studying a little bit, so reading articles, blogs, I could find on the internet, and I finally found the workshop by Kent Seagal that I can suggest to you, that is about creating a framework based on React Server Components from scratch. I tried to follow it, it was very good, but it was not enough for me because to learn and understand really something I need to go deep, to write some code with my own hands. So I decided to do an additional step to create some puzzles that I had to solve one by one. And from those puzzles basically also the idea for the talk was born.

So today what I'm going to do is to share with you my learning journey through these puzzles or challenges, as I will call it during the talk. So this was the original title that I sent with the proposal, but during the preparation I thought of a different point of view, so I decided to associate the acronym RSC to many different meanings, each one for each different challenge that we are going to see, just to make it a little bit more fun. So this is the new final title. I remember also the enjoy flight, because we are going to talk about flight a little bit.

The first challenge is a simple hello world, we start easily. So we try to use the React Server Components technology but without using a server. So the challenge is called React Serverless Components, this is our first meaning for the acronym. So we want to create a very simple hello world, you can see it on the right, this is the final result. And on the left you can find some very simple code that you can run on a client, you don't need a server for this. And this code what it's basically doing is something that you can do with the RSC technology, that is loading some content that is pre-generated somewhere else, maybe on a server, I don't know, but for now we don't care about the server.

We can fetch this content from somewhere, then we can use a new function that is available in React 19, in the React Server Components package, obviously, that is called createFromFetch, that takes the content fetched and decodes in some way so that it can become something that we can render from React. There is also another thing that is new in React 19, a new feature in React 19, a new hook called use, maybe they finished the names for the hooks, so they went for the most simple one, it's called simply use. You may think you can use everything with use, but it's not the case, you can basically use any kind of resource, let's call them, in particular for now, it's used for using promises and context, so a simple way to get some remote resources, promises, and use it with a synchronous syntax instead of using async await and the usual stuff.

Now that we have the decoded stuff, we can render it using the usual render method from React DOM, there is nothing new in it, but maybe you are curious to understand what's this pre-generated content we are talking about. It's basically something like this. This is a new protocol that the React team introduced with RSE, it's called ReactFlight, this is the reason I told you remember the flight word, because it's important. It's a protocol that is used to serialize stuff so that you can send it from one place to another, for example from a server to a client, so you can generate the content in some place, send it somewhere else, and use it for example to share the rendering job between a server and a client. It's similar to JSON but it's not really JSON, we'll see a little bit more how it looks later. So with this we can imagine a workflow made like this one, for now we know how to deserialize this kind of content, using the createFromPatch function, we don't know yet how to serialize something on the server side, we'll see it later.

Okay, I can say that the first challenge is completed, so let's go quickly to the second one. It's not really that different, so I call it the first challenge and a half, because it's not really very different from the first one, so it was not good to call it second. The acronym in this case is translated as replaceable static content, because we want to add an additional step, what if we want to load more different content using RSC, not just a single page, we want to switch between different kind of contents. That's absolutely possible, the example it's the one you see on the right. Don't worry about the code, because there is a GitHub repository with all the snippets of code that I'm showing, I will give you the link later.

So with this example we don't use anything new from React 19, because the only thing we need to do is use the useState hook, for example, to store our content somewhere, like we are used to do. For example, we can store the result of the createFromPatch function that we have seen we have seen from the previous example, and just pass it down as a property to a non-sting or a root component, like in this case, and use it there. So our root component is in reality a very dynamic one, because it doesn't render anything from its own, it's just getting the content from somewhere else.

Something more about react-flight, because we are probably curious, we have already seen that in react-flight we can include some representation of our DOM in a sort of JSON-like syntax. It's not really JSON but it resembles it. But the other important thing is that content is not limited to just one row of stuff. We can have many pieces that are called chunks, each one has a prefix that is a key associated to this chunk, because an important property of react-flight is the ability to compose different chunks together, and the way you compose them is to reference other chunks with this $key syntax. So also react-flight is composable, like all the react libraries aim to be. So what can we think to do with all of these things that we have seen so far? Maybe static site generation, we can generate our react-flight payload somewhere and use it from a client without having a real server available. But the same is possible with the old HTML, so why do we need RLC to do that? Probably this is not a very strong selling point for RLC, but what I can tell you for now is that the react-flight protocol is a rich protocol, it can share between server and clients a lot of things more than simple HTML, so we will see probably later if this is something that we can use properly.

Okay, let's go quickly to the second challenge, because it's time to introduce a server in the mix. This is the reason why this challenge is called react-server and client. We want to understand if we can use effectively a server because the technology is called a react-server component, so probably there is something we can do on the server.

The first thing I have to advise you is that to use RLC on a server you need to start your Node.js with a particular flag that enables the RLC mode, if not you will use React in the old legacy mode, that is a bit different, so you won't be able to do this kind of stuff if you don't start Node.js with this flag.

Then this is an example of a backend, very simple, I use Fastify as a backend technology, you can use whatever you like, like Express.js, Sono.js, everything is good, it's not important. Then you need some endpoint, a dedicated one maybe, where you can use a function that is made available by the React 19 that does this serialization part. This function is called renderToPipeableStream, remember the word stream because we will see it later and it's becoming very important.

Something more about the React flight, you see another example here on the right. The React flight can only contain the final DOM for the code that has been generated on the server, but also a higher level representation of your application that describes the components themselves. So you have a dual view, I would say, the final virtual DOM and also the tree of components that have been used to generate that DOM. It can be useful for debugging and other sorts of things.

Obviously the React DOM generated also references the components that have generated them with the same syntax $key that we have seen before. $something is always a reference to something. And we have completed the workflow that we have seen before, now we also know how to serialize stuff. But with this kind of thing, we have moved basically all the job on the server. Now, the client is very stupid, it just takes some pre-generated page and renders. Not a very important job, but we want to share a little bit the task of rendering a page between a server and the client, not just doing something only on one side. Also, server components have some limitations with respect to the client component that we have always used in React because by design they are stateless, there is no state by default on the server, if you don't implement it yourself.

So for example you can't use any hooks that manage a state, you can't use the context either on the server. Moreover, server components are not interactive because they are not executed by a browser, they are not JavaScript, let's say. So for example, I cannot do a button that does something like doing an alert on a server component. If we want to do that RSC gives us client-only components, so components that can be executed effectively on the client, and they are prefixed by this directive. If you use client, if you put the use client directive on the top of your client component, they are recognized by RSC and handled properly as client components. Obviously, a client component can be included in a full page that is generated by a server, but not the other way around. So if you have React on the client you cannot have server components there, so client components like this one cannot directly reference other server components. And what about React Lite in this case? Client components are special, they are included in payloads in two different pieces. The first one tells the client how to load the client component code itself, so it's a simple reference to some JavaScript. And then you have another kind of reference, it is $L, it means lazy, the L is for lazy. So client components are just lazy references, something that will be lazy loaded when needed.

So client components are just lazy references, something that will be lazy loaded when needed. This is the only difference with the references that we have seen so far. An additional note, usually this kind of stuff is not a simple inclusion of a JavaScript for your clients. Usually there's a bundler in the middle that just takes all the client only components, creates a bundle, sends it to the browser. It's a little bit more complex, but since we are trying to simplify the stuff in this case I didn't use a bundler. There is an alternative that is using a Node.js loader that is available through RSC to handle these client components. And this is the way you can register this loader and use it from your code.

Okay, so with this challenge we learned a little bit how to do server-side rendering in an alternative way, because we were able to do it also before RSC, but it's a little bit different. Before RSC you needed to use the renderToString function that is generating HTML. Now we have a new function, renderToPipelineString, that instead generates React flight payloads instead of direct HTML. But in my opinion this is still not a killer feature for selling RSC. If I had to sell it to you, probably not.

So let's go quickly because we have a lot of work to do. The third one, do you remember Stream? Nice to meet you. So the third one is focused on the streaming concept and it's called React Streaming Components. This is where the things become interesting in my opinion, because this is something new. Let's say that we wanted to create an application that updates continuously, maybe infinitely, indefinitely, in theory, but in practice. Very simple. A counter that increments and periodically updates the page.

The interesting thing here is that on the server, server components can be asynchronous. So through the use of async await functionality can load data and delay rendering. The way they simulated loading some data is just a set timeout, but imagine that here you are loading some data from a database or somewhere else. Then you can immediately render what is available. So the current value for the counter for example.

Through the use of suspense you can delay the rendering of what comes next. In this case the value of the next value of counter. And to make it infinite I use recursion. So we are using the same component again and again, just increasing the counter. Don't do it this at home, because at some time it will stack overflow. This is just a demo, not a production code.

React flight also in this case. Third thing, internal components from React are rendered through this $S notation that is for symbols. Then the most important thing here is that in one chunk, the first that we send to the client, we have a list reference, like the one for the client components. It's the same thing because we are waiting for something that has yet to come. We reference something that is not there, it will come someday, and when it will come the page will be updated. Okay so now we are able to stream content and we are able to differentiate fast content that comes immediately, to slow content that will appear later. This is something that probably we didn't have before. So I think this is a real game changer of RSE.

This is a point where RSE gives you something new. Let's go quick to the fourth challenge. I call this one React Strange Constraints, because there is something that I couldn't understand. If someone knows it, please explain it to me.

In this challenge I was trying to optimize the rendering, so I wanted to send to the browser the initial page as HTML, not just the RSE and then doing the rendering of the RSE on the browser itself, on the client, because I know that Next.js, for example, can do it. If you look at Next.js generated pages, they are HTML with something in it, but they are HTML. How can I do this?

First of all I have to prepare two different backends. This is one possible way, and I will explain you later why I need to do that. The first one will be dedicated to RSE generation, so I need to start with the flag that I've shown you before. In this one I have the same endpoint that we have already seen. I listed on a different port because I have two different backends. There is an alternative way, I don't have the time to show it, but you will find it on the GitHub repo. Instead of having two different backends, you can use workers to start two different processes on the same backend, and that's another way of doing the same thing.

On the main backend what I have is a sort of a proxy that just calls the RSE endpoint and gets back the RSE, and then does what we did before, RSE, render to string something. It also does another thing, that is add to the final HTML, inject into it also the RSE payload for the same content. This will be used by the client for hydration, so we need both, because for example if we have client components intermixed with server components, we need to do hydration on the client, we are not enough with the generated HTML, so we also inject the RSE. We also inject the RSE in the HTML itself and then on the client we can read it with this snippet of code. We get the payload from the page directly. We can use a readable stream. This is standard javascript, nothing from React, so you can read the stream and pass it to another function. Create from readable stream is the same as create from fetch, but uses a stream instead of the result of a fetch, but does exactly the same. So in this way we are optimizing our initial page load. We did a step more in SSR, but why I call it the React strange constraints? Because React is strange, because in my opinion, because it doesn't allow you to do render to string and render to pipeable stream on the same process. If I could do it, I wouldn't have the need for two different backends or workers. I don't know why in React you can't do that, so if someone knows the reason, please tell me. I will sleep better tonight.

Okay, we are almost there. The final challenge. What if I want to use a language that is not javascript on the backend? Does RSC allow me to do that? I call this one Rust server components. It was in the video, maybe someone came here because they heard the word Rust. It was a quick bait, I admit it.

So I created such a challenge, but I had no way if I could do it. This is the only one I had no idea if I could come to an end. I finally do it, sort of, because I found a library that is called rscx from another Italian guy like me, Antonio Pitasi. It's called Rust server components, the library, and allows basically to do a couple of things. First of all, you can tag functions with the component attribute and they become sort of server components. They are functions like the one we write in javascript using React, but they are in Rust.

Also there is a macro, this HTML bang macro, that allows to write something that is very similar to JSX, which looks like it, and in this way I create sort of server components using Rust. The HTML macro, like the name probably suggests, is generating directly HTML. What I did to complete the challenge is to write an additional function that I called flight that simply is used in combination with HTML to generate flight payloads instead of the HTML itself. So in this way I created a back end that is compatible with my RSC client on the browser. It is a proof of concept. It doesn't really work for a complex example. It only works for very simple stuff for now, but it was an idea. I wanted to demonstrate if ReactFlight could become someday a language agnostic protocol. In theory it could be. Not easy, obviously, because the most important thing that we need is that the protocol needs to be documented and stable. That is not so far. I have an hope since recently React 19 got a final release, maybe they will decide at least to document the protocol that is now documented only through examples of reverse engineering of code from other people. This is the way I understood. I understood a little bit of it but maybe someone will consider this option, probably not me, because I'm not a Rust developer, I have to confess, but maybe I can make a Java version or something like that.

Okay, this was the last challenge. Just some final conclusions. So what are the positive parts of RSC in my learning journey? I put streaming on the first place because for me it's something very new and very interesting. The other thing is the ability to balance the server and client work because it's very flexible. You may decide where to do your rendering work, most on the server, most on the client, the better of both, you decide.

Also you can extend the meaning of client server, because in the optimization example we have seen that we have three entities, three different entities. We have two backends, one dedicated to RSC, one for generating the final HTML and there are solutions taking advantage of these kind of things. So I would say that there are no real client and server, there are different roles that you may decide where to achieve. And also the fact that the RSC is basically a set of primitives that are really basic like the React flight protocol and this allows for many different implementations.

For example we have Next.js from some time, we also have another implementation that is Waku and also Remix or the new version, the React router v7 is supported by RSC. I think also this TAN-stack start framework is going or is already supporting it, so it's something that is getting adoption. The main thing that I see against it, but probably it's my point of view, that is the protocol itself, or so React flight is not really well documented so far. I don't know if the React developers are willing to document and make this protocol stable.

It will eventually open the occasion to extend it to other ecosystems and languages. And if you have a question that is is this a better approach than other approaches for doing server-side rendering or other kind of stuff? I'm not sure yet because I think it's too early. As I said the React team final has been released I think one week ago or something like that. So I think it's a little bit early but during the next year probably we'll understand a little bit more. Here are a lot of links, I think they will be shared with you in the following days. So finally I'm not alone because there are other people that are joking with the RSC acronym. I found this one React showloading air component. It was really fun so I included it. Thank you everyone for listening.

So Mauro, great talk. Thank you so much for the conclusion, I love it. I have a conclusion so I take a screenshot. So the first questions we have here. When creating the React flight file, does the developer have to ensure things are lazy loaded or is there an optimization step in the compiler? Well something that I didn't have time to tell during the presentation but I think it's very important so I take the occasion. You don't generate those files by hand. I did it because I'm crazy and I wanted to understand how they were made so I went inside but the goal was not to write them by hand. They are written by that serialized to pipeable stream, render to pipeable stream function. You don't have it to do it by hand and but the RSC framework, the basic primitives that are in React 19 are doing all the work for you so you only need to care about the framework you choose. But I think I created this talk because I think it's, at least for me, to understand if something is useful I need to go inside it so I need to understand the why behind the scenes. Thank you.

Next questions, how does the streaming work with the various infrastructure options? Well streaming is in this case doesn't really need a special infrastructure because it works fine with the simple HTTP. I think you can use it via server sockets or other ways.

To have, for example, the infinite stream that I said it's not for production. Obviously if you have a server socket you can continue pushing content in that case. The advice was for the standard communication via HTTP. You obviously can't do infinite streaming there because the HTTP channel needs to be released if not you are wasting resources. But for server sockets, for example, why not?

Thank you. We have time for one more question. So have you seen whether RSC hydration is faster than regular hydration? And it's supposed to be but I'm curious if the difference is significant. I didn't do any specific test of performance but I guess it is because the most important thing about ReactFlight, in my opinion, is that it does part of the work on the server while with the standard SSR solutions you get something that needs to be elaborated more. In this case most of the work because ReactFlight when this is realized is basically the internal structure of the virtual DOM. So the first part of generating the virtual DOM is already done on the server. Only the final part of reconciliation is done on the client so I believe it's faster than regular hydration.

Thank you very much for your answer and I think if you have more questions you would be at the Q&A spot.