Vanilla Server Components

Hey everyone, I'm Krasnzony from Bulgaria, and I'm going to talk about vanilla Server Components. The motivation behind this presentation was another conference that happened early this year, React Summit. I was there, and I had this chat with a couple of folks from Verceo, from Meta, about Server Components. My main question was how to use these components outside of the world of a framework. The answer was basically, and my conclusion, was basically that it's really, really difficult. So I decided to explore this area, these ideas, and this is where this presentation is coming from.

In my head, the ecosystem in React is split in three different use cases. The first one is the old way of building single page apps, where we have the compiler, which is some sort of a building tool like Webpack or Vite or something else, Babel. We have this pipeline where we build the bundle, we throw it to a CDN and we ready up from there. If there's no server-side rendering, it's only a single page app running in the browser. Then there's this other group of apps where we own the compiler, meaning that we pick what we want to use. But we have our own HTTP server, which is delivering the main HTML, which is maybe delivering the assets and everything. In this case, we do have a server-side rendering, meaning that we could actually render React on the server and handle this on our own.

And the third option is basically relying on a framework, which immediately removes the question about picking a compiler, how everything works, it's basically hidden there. So we don't have to think about this, it's just working out of the box. The world where I live for a really long time is basically this middle group, which is we control the compiler, Vite or Webpack. We control the HTTP server, Express usually, and we do everything ourselves. So this is the area which at work, I'm using in my personal projects. And I think from a developer point of view, it's quite interesting because we have the option to explore stuff. But in the context of this presentation, this is the thing which I'm going to talk about, making several components work inside this type of setup.

So let's say that we have a really simple HTTP server without React at all. This is an ExpressJS server. We ask from the browser, hey, give me a page. We then respond just with simple HTML. We have the styles, the bundle, and that's it. Then this was the case where everything is static. We don't have to fetch anything, it's just returned HTML. But then what happens if we have to get some data? In this example, I'll rely on the typical case where we have a block. Basically, we need to fetch the blog post and the comments for each blog post. So we have to do some work, which is asynchronous. We have to go to the database, get some data, render the data, and so on.

So what happens in the handler of the HTTP server is that we wait, basically. We wait to get the posts, then the server is doing its job, going to the database, getting the posts. We wait to get the comments. We assemble some sort of response, meaning that we combine the posts and the comments. And then we return everything at once. And then the TCP connection is dropped, and that's it. The problem with this is that the user experience is bad. And this is basically the challenge that we had with React apps, that they were on the client always. So the user sees nothing until we get all the data and we render everything. So from a product point of view, we may say, okay, we don't care much about the comments, so let's render the shell, basically the basic HTML of the page, all the layout and stuff, and render the posts, the blog posts, and then fetch the comments on the client.

The better option, though, is to send the shell, show a spinner, for example, loading, then we get the posts, and then we get the comments. And this is the idea of this whole exercise. We want to provide a better experience when using React. Now the answer of this is actually HTTP steering. And when I started exploring the server components, this was basically the very first thing which I realized, is that this is not something new. It's there from HTTP protocol version 1.1. So it's really old. It's really old pattern technique to actually send data from the server to the browser.

It's really old pattern technique to actually send data from the server to the browser. But how this works. So if you go back to our HTTP server, we have the same. We just run the server. But the very first thing which happens when we ask for a page is that we return the content type, text HTML. Here's the second header, which is the most important thing in this whole story. I believe that when I was learning and basically reverse engineering how server component works, this was the key point, actually. It's opening the door for the server to notify the browser, hey, man, I am going to send you multiple things. It's not just one. So we say transfer encoding chunked, meaning that I have a lot of things to say. So when I give you a response, do not close the TCP connection. Just wait for me. I will tell you when I'm done.

And let's keep the same no react thing with fetching the blog posts, fetching the comments. The first thing that we return back is just the shell. So we basically send just the basic HTML without the blog post, maybe a spinner. And then in the meantime, we start getting the blog posts. And then the next thing that we get, that we send from the server to the browser, is actually a script tag. And the idea behind this is that the content type of our server, the very first thing that we send back to the client is HTML. So we can't just send the blog posts as JSON. We have to send some sort of HTML. And what we could do is send a script tag, which is containing a function call, which means that there are two important points here. The first one is that this function should exist on the page in order to kind of accept what's coming. And the second thing is that when we get back the blog posts, they should be serializable, meaning that we can't just send a function or a promise. We should be able to stringify whatever data we have and pass it like that.

Of course, there are ways to send a live promise from a server to the client, and it's a really interesting concept how it's done. But in general, this is what we have to do. We keep the TCP connection open. We stream back some HTML in the form of a script tag and a function call, and this renders the blog posts. And we do the same for the comments.

We basically send absolutely the same thing, a script tag with the comments. And then in the end, we basically close the TCP connection.

Let's get React in the whole story. So let's say that I want to render an app now. It's not just HTML, like a static HTML. I want to use React now. So if I start with this, I'm basically getting the blog posts, getting the comments the same way, and then I'm using render to string. This is the API provided by React for a really long time.

The thing is that this is a synchronous API, which means that I need to have the data before that, before I reach this point. So I do that, and then I just assemble some HTML, I'll send it back to the browser. So this is cool, but of course, it is the same bad user experience basically. What if I bring in all the asynchronous work? Basically say, okay, I now know that my React components could be async functions, meaning that the React component on the server could be an async function. So I do this. I basically bring the getting of the posts and getting of the comments inside my component.

So this is nice, but it's not actually working because render to string doesn't really work with asynchronous data. So the way to solve this is to use another API called render to pipeable string. And the way of how this looks like is like that. So the really key point here is actually this one, stream.pipe, and we pass the response of the Express.JS handwork. So of course, there are some details here about how everything works in terms of API. We provide the status code together. We provide the entry point, this bundle is imported into the HTML. But the key point here is that we basically say with these lines, we're saying, hey, React, start to render this tree, and every time when we get something back, just pipe it to the browser. And this whole thing, this API, is using content type chunked and sending back different chunks to the browser by using this API.

How this looks like from a component point of view, it's a really natural API. We just drop async await function, and we do everything as nothing really happens. Behind the scenes, though, it's not exactly like that. We have to use this render pipe of a stream function to make this work. Otherwise, async functions are not really working fine. So if we get back to the user experience, though, if we just do this, like an async and then we do await of stuff inside, we have the same bad UX. Which we want to kind of improve that by, again, doing the same experience where we send the shell, we get the blog post, and then get the comment. And the way of how this works is that we should use the suspense component and use a function that's not really a hook, it's a function. It's, I think, a really exciting API that is coming with React. It's used for different things, but in the context of this presentation, use will accept a promise. So what will happen now is that as soon as I ask about a page, and there is a suspense boundary, if there is a component inside this tree, this sub-tree, which is under the suspense boundary, and if there is a use function that accepts a promise, React is basically waiting. It's waiting this promise to be resolved and then reveals whatever is inside the suspense. So inside the post component, I have this getPost function, which is basically returning a promise. This five is just a delay, so I simulate properly. But what's important here is that we don't have await here. We just pass the promise as it is. And suspense knows that there is a component inside which is using use and there is a promise. So it basically waits. So if you go back to the whole thing and we ask about our page, then what happens is that we send a shell first and we show a spinner. This is the fallback of the suspense, basically. And then in the meantime, the blog posts are getting fetched by this function getPost.

And then when this is done, we send the blog post. The suspense boundary is basically open now. And then we load the comments, and we have a fallback of the suspense here in the posts. We load the comments. We do the same thing. And yeah, we basically have the same experience using React. We have to use though the suspense boundary and use callback. And this is basically done now.

Before moving forward, I want to show you really quick here how everything actually is done. And you can see it really easily. If I refresh the page now and I go back to the response, like a raw response of the page, you will see that in the very beginning, I have just this. So this is basically the shell that's coming from the rendering of the React. And you see that after some time, I get a bunch of other stuff, which are basically a diff which is hidden containing all my data. So if I collapse everything now, you will see that this diff with the data has some ID. Then there is some JavaScript sent from the server to the client. This is not JavaScript that I wrote. This is JavaScript which is sent by React. And what this is doing is basically replacing a placeholder, the template with the content of another diff which is hidden. And you see that it's not that magical, really. It's just a combination of HTTP streaming, a bit of smart replacement because here we have a command and it's not really just deleting this and placing another diff or something.

There is some complexity around how this is actually replaced. But this is how the server components work. The server is streaming these hidden diffs with all the markup and we have this function which is really small and it's replacing some HTML, which you saw already on the DOM. Of course, there needs to be, after that, some rendering on the client. So, so far, we saw completely static server-side rendering, meaning no React. We just send HTML. We see dynamic server-side rendering, where we have a rendering async component and then we wait in the beginning for the posts and the comments. And then we have a good user experience using suspense and use. But all this is just on the server. We don't have anything on the client, meaning that if I want something slightly different on the client, like some interactivity, like a button that needs to be clicked or something, this is not done yet.

We have only server-side rendered stuff now. So, what about the client? And here's where the server component magic comes from. Let's say that I have this comments component, which we already saw, but then inside I have this use state, which is showing the comments only when the user wants to see them. So, it's important to say here that even though this is supposed to be a client component, it's completely renderable on the server, meaning that the server is not going to export or anything if it's this use state. This function is fired only once on the server, and it will be always false, meaning the state visible, and there will be always just the button.

Even though the data is there, what will reach the client, the browser, is actually only this button. So, if we move forward and if we have to ship this to the client, we have to say that I can't really call this function get comments by post ID every time, because when this state changes here, this function will be fired multiple times, meaning that creating the same promise multiple times. So, there needs to be a cache of the promise, and it's getting really complicated. Let's say that it's good practice that we send the promise as a prop to the comments, meaning that we want to send the same promise every time to the comments component. Of course, we have to use client. This is to instruct the bundler, basically to know that this is going to the client. It needs to be incorporated into the bundle, because if we're so, so far, we don't have a bundle at all.

Everything is just on the server, and there is no bundling. So, when I was going through this whole journey, I realized that the tool chain, in my case, is that I have the source folder. I have a compiler that basically translates my TypeScript to valid JavaScript, and based on that, it's creating a bundle as well. Out of this folder, I'm running my Node server, and now when I have the bundle, I'm shipping this bundle to the browser. This is basically how my tool chain looks like. If I use a framework, it's nothing like that. Everything is really short because I just have my TypeScript files, and then I run the server. But what happens with me now? Well, I'm thinking how to implement that, how to make everything this works.

I know about HTTP streaming, I know how suspense works, so probably I have to implement the same thing in order to start supporting the server components in my case. So for a while, I was thinking, maybe a month and something, I was trying to build a VIT plugin to do it. I know that there is one, but I wanted to do it myself, and it was really difficult. And I had to know so much details about VIT, about how everything works, which I started thinking, maybe that's a wrong approach.

So I came with the idea of basically importing this magic before even I reached the compilers. And I decided to write a small tool, which is getting my raw TypeScript files and preparing them for the client, meaning that it's basically stripping out everything which is on the server, and it's just getting only the stuff that are going to be shipped to the browser in one folder, and then doing the same for the server. And while I'm doing this, I have the opportunity to modify the files, to basically implement the logic about running server components on the client, the client boundaries and everything. So it was much easier and much more fun, I would say.

And then I used the compiler. And this library is called ForkIt if you want to try it. This is the URL, I'm not going to talk about it. But this is how it works. It's kind of supporting maybe 80% of everything which is out there about server components. There are some edge cases which are really difficult to implement, so I didn't do them. So I'll finish with two things. The first one is that the mindset when we're working with server components is slightly different.

So far, we were thinking about React as something that runs on the client, mostly, kind of. And we have this dev which is just filled with all of our components. Well, now it's really server oriented, meaning that everything is on the server and everything is a server component. And occasionally, just a couple of things are the so-called Iowans client components. And we hit rate on a really specific portion of the pages. So this is something really important when we start working with server components, the mindset is changed.

And the last thing which I want to say now today is that there are problems with server components. They're not ideal. The mental model is different, so you have to be ready about that. You have to think about the developer experience in your team, in your company. Do you want this? Do you need it? There is some build complexity, of course. There needs to be a toolchain. You have to probably change your toolset about how everything works. And there are things which are not so well designed, I would say.

The custom validation, what happens if you need cookies or authorization and headers. And you have these client components that are communicating with server components, using server actions. And what happens if I need to pass a header, additional header there? Like where? How? Is it secure? Type safety, serialization constraints, of course, you can serialize everything. Even though in Next, for example, this works out of the box for promise function. Well, function, it depends. But yeah. And of course, it's hard to test. If you think about it, how? I'm going to test the client boundary. It's complicated.