React Server Components - Under the Hood

Hello and welcome to my session, React Server Components Under the Hood. My name is Lee Rawlins and you can find me on most places on the internet as le-rawlins. I've been doing web development now for about 20 years. I'm based out of Australia and it's a beautiful spring day here. Obviously, this is a prerecord. Most of that time I've been working with PHP, but more and more I've been working with JavaScript.

During the day, I work for a company called Previous Next and we look after some of Australia's largest websites. Some of our sites do 80 million page views a month, so we're talking about some significantly challenging projects. If you're looking for something interesting and you're based in the Australian time zone, we're hiring, so hit us up on our careers page.

Today, we're talking about React server components and I'm going to give a very brief overview to start with, but this is an advanced conference so I'm going to go down the rabbit hole and hopefully I'm picking up from the ad session just before mine. Where to start with React server components? We'll start by reading the RFC. This goes into details about what server components are, what you can use them for, what advantages they provide, and the problems that they're trying to solve. It's also a nice video walk-through from the React team. The TLDR of it is there are service side components which have direct access to the database, micro services, etc. But as a result, they have no access to state or effects. It's a cold start every time just like PHP. There are client only components and these are just what we've always called React components. They have all the different use state hooks, etc. But they can't have children that are server components, which kind of makes sense. And then we have hybrid components which can be used on the client and the server, and of course they have the shortcomings of both of them. So you can't use state or hooks or anything, but you also can't use database. And these are basically just pure components that props in and muck up out. So we're going to go down the rabbit hole here. I'm going to switch to the IDE and we're going to start having a look at this. So let's jump into my IDE and I'll just put it into presentation mode so you can read it. So we're going to start by having a look at index.client.js. So we start off here by creating a root element, and this is using the create-root from the experimental concurrent mode, which is coming in React 18. Concurrent mode allows deferring updates from appearing on the screen until they're ready. And if you're interested more in concurrent mode, have a look at Cracking the Concurrent Mode by Sadanich Yadav later this afternoon. But basically, we create this root and then we render the element to it.

So the element we're rendering this root, let's have a look at that. We've got a suspense wrapper around an error boundary around a content component. The content component itself has a context provider that's providing effectively a router with a selection ID, is editing, and search text, in fact, basically the global state. We're getting a response using useServerResponse and we're rendering the read root in the middle of that.

So let's have a little bit of a look at useServerResponse. This is using an in-memory cache from another experimental React API, which is the experimental suspense cache. It's creating a fetch by serializing the parameters or the state of the application to JSON and passing that as a query string. So let's load the page and put our debugger on and see what's happening on the server side when we hit that React endpoint. So I've got the app running here and I reload. And that drops me into a file called api.server.js, and this is basically a simple express app. It's got some endpoints that it's listing on, and the one we're interested in obviously is slash React. So that's just the thin wrapper around send response, and send response, all it's doing is passing out that location that's coming in in the query string back into a JSON object and calling react-read-in-a-tree with those props.

So let's jump into react-read-in-a-tree. The first thing react-read-in-a-tree here is wait for webpack, and what that's basically doing is making sure that bundling has finished, and once that's finished it can then read back the webpack manifest, and it passes that out to JSON and calls pipe-to-node writeable with the element created for the root of the app.

So let's pause again, leave our debugger running, and let's have a look at what this root app does. So the component itself is app.server.js. So this is effectively the shell that's coming back from the server. We've got the main element, we've got a sidebar with a logo and a title. There's a search and edit button, and there's the list of notes. And then the right hand side, the main part of the page, has got a selected note that you can edit. So the things to note here, and no pun intended, this is the Notes app, but we've got a mix of client and server components here, as well as some hybrids. So the note itself is the server component, the note list is also a server component, we've got edit button and search field, which are client components, and then we've got two hybrid components that have been used as the fallbacks for the suspense wrapper, so a skeleton of the note and a skeleton of the list.

So let's have a look at that edit button to start with. So let's go to that. This is just a thin wrapper around basically setting the context or changing the location. It's using, again, the experimental in current mode to start transitions so that you're not seeing a loading page while it's loading. Let's then have a look at the note list. So this is where the server-side component is querying from the database and then for each one is outputting a side-by-note component which is also a hybrid component. So if we backtrack back to React rendered tree, here, now let's have a look at what it's doing. I might just run the debugger through until we get to there. So again there's this wait for webpack, this pop-to-node writable and let's have a look at what that's doing. So that's coming from the React server DOM webpack module. First thing it does is, let's have pop-to-node writable, create a request from the model. So the model that's passed in here is the app element, destination is the response and webpack map is the past current manifest. It sets up a train handler, so we'll come back to that, and it calls start work. So let's unpack create request first. So it's basically a plain JavaScript object with some arrays here to keep track of module chunks, JSON chunks, and error chunks. We'll come back to this later, but the main piece of work that's happening here is it's pushing the root segment onto segments, and if we look back to what that is, it's actually a segment based around the model, which is the root of the app. So this leaves us with start work. If we jump back there, what's start work doing? Well, it's wrapped around this perform work, and the perform work basically gets the React dispatcher and attempts to render that segment. Now one thing I've found interesting here is we have a look at where this React current dispatcher comes from. It's coming from React shared internals, and if I have a look at the break point there, this is actually coming from React secret internals.

Do not use or you will be fired. I found that amusing. I don't know what that says about whether that's going to change in the future, but yeah, let's have a look at what that perform work was doing. So yeah, it's a reference to retry segment, which tries to render that element.

So if we have a look at this, this retry segment is responsible for resolving elements that are from the past segment, and a lot of the work happens in attempt resolve element. And this basically is attempting to translate the element into an array that we can serialize and send back as JSON. It can deal with HTML, it can deal with fragments, it can deal with server components, client components, react demos, but the net result here is it turns this React element into some sort of tuple with like the symbol, the element, its key and its props. And once it has been reduced to this format, it can be processed as a model chunk by process model chunk.

So let's jump to that. So basically we're given here the model and it's turned into a string and serialized. So if I just let the debugger run through, we might have a look at the format of the content here. So let's open this up. So as we can see here, it starts with the type of the element here. We've got the element name itself and then we've got the element's props and then one of those props is children, and then it repeats itself. So this is effectively the serialized representation of the element tree. And we've got some special nomenclature in here that the client can understand to work out what sort of element we're dealing with here. Let's have a little bit of a look at how this resolve model to JSON works, which is what generates this JSON. Basically, anything that's already been converted into that tuple format we talked about seems to be sent as is, but everything else is converted into a similar format. It seems that it has guards around things that can't serialize the JSON, so it can't serialize classes, it can serialize just plain old JavaScript objects, it can't serialize functions, event handlers, all the things that don't make sense represented as a string. If we run this through again until we get to where it's rendering the sidebar list, where we've got multiple components, we can see here the UL. This is rendering the sidebar note list, so we might just open up that note list component and have a look at what it's made up of.

As we saw before, it's got a sidebar note inside it, but if we have a look in the sidebar note itself, it in turn renders a client sidebar note. So if we have a look at the client sidebar note, we can see it has properties like ID, title, et cetera. If we look back at this JSON that's being output, we can see in here that there's a lot of these at five references. So previously, we were looking at a JSON, we could see in there, there was like div, et cetera, things that we could rationalize down to HTML elements. But now we're seeing this at five and we can see the ID and the title properties that match up with these properties over here, as well as the expanded children. And so these at fives placeholders in the JSON that's sent back, and the client will then replace these slots with the client side elements. So wrapping things up on the server side, the only thing left is that start flowing, which we had before for the drain handler. If I jump back to that. So this createDrainHandler here, it's a wrap around start flowing, and what start flowing does is flush the completed chunks.

So the drain handler is an event that occurs in the compression middleware, which is wrapped around the outside of the Express Server. And so when it's ready to send, it just flushes all the chunks, and that just goes through and emits the module chunks first. So that's each of the client side components, and so any new components from Webpack that need to be loaded, the JSON chunks which we looked at, and also any error chunks if something went wrong.

So let's just take a pause and restart the server without debug on. And while that's restarting, let's have a look at client-side components again. So we'll jump all the way back to that client cache, and jump into this new server response. So that's running, I'll just minimize that away, and let's have a look at this create-from-fetch. So we're back in the client-side JavaScript now. create-from-fetch has got two functions here. It creates a response, and it starts reading from the stream. Let's have a look at create-response first. And not surprisingly it's creating something to pass that JSON back out, and the guts of it looks to be here with this pass model string and pass model tuple.

So let's move to the browser, and let's put our debugger on those methods. So I'm going to open this up in my debugger, and I click load. I've got some preset breakpoints here, and I'm going to reload the app. So we can see that we've got JSON pass coming in here, and so the first things that are coming back from those chunks are the components, the client components. So this has got the chunk names here from Webpack as well, so that we can load in those imports. Let's run through. So that was the client search button, now we've got the client edit button. I've got the SOAD BAR NOTE client component. And then we get to our actual JSON that we sent back across the wire. We can see in here again, we've got these references to the AT5, and basically what will happen is we'll end up in the ones that are prefixed with the AT. React takes care to lazy load those chunks and inject them back in. And then for the tuples, if we have a look at this one here, we've got the symbol was React element, the element itself is p, and then we've got the element properties. So for each one of those items in the JSON, React create element is being called, and creating elements and putting them where they need to be. So let's stop that and jump back to my slides.

So I guess the question after looking at this is, what's next? And, well, when is this production ready? And the best place to answer that is to see the open areas of research in the RFC. And it's not a short list. You know, one of the things you probably noticed before that the Express app was passing a hardcoded location param. So there's some work to do to make that generic, and that's identified on their list, they've got that listed there as a routing.

So that hardcoded endpoint is something that they're hoping to solve by coming up with solutions for frameworks first, and then lessons learned in those frameworks can be things that are applied more generally. They also want to do some work to improve developer tooling. You know, React in the browser has got an excellent extension for helping you debug what's happening. But when you've got some components being rendered on the front end and some components being rendered on the back end, you know, being able to identify that in the tree is going to be critical.

Bundling. The wait for Webpack bit feels a bit eek. You know, what it's basically doing is waiting until, you know, it can see index.js written to disk, and then it knows that Webpack's finished, and then it knows it can read that JSON. So it feels like there's a bit of work to do there. And then pagination and partials. One thing you've probably noticed from the fact that we're sending back the global context to the app is that we're re-rendering the whole app every time a request goes back to the server. So this obviously less than ideal. So I think that's one of the things that will be resolved.

So yeah, I hope you enjoyed that. Thanks for sticking out to the end. It was really interesting topic to learn about, and I enjoyed getting my hands dirty with the debugger there. If you've got any questions, feel free to reach out to me. As I said, the username's L.A. Rowland. I'll be on the GitNation Discord. I'm also on Jamstack, Slack, and you can reach me on Twitter if needs to.