React Server Components

♪ Listen, I, okay, this is... Phew, man, I've never been introduced like that. Thank you, thank you, thank you, brother. That was tremendous. Look, this conference is extremely special to me because I live here. Berlin, I call it home. I've lived here for eight years and it's an absolute honor and privilege to be able to be here and talk to you today in my home city.

This year, I've spoken at somewhere upwards of 30 conferences all around the world, but in Berlin, this is number two. And it's extremely special to me to see all of you here from Belgium, from the Netherlands, all these places coming here, not just to watch me, but to celebrate React together, right? And that is a special thing. So I just want to really quick give it up for you for coming, for Git Nation. Amazing. Incredible.

I feel like I have an intro slide, but apparently I don't need it thanks to Nathaniel. My name is Tejas, pronounced like contagious. I'm not, don't worry. And over the years, I've worked in tech now for many, many years. 20 plus, I lost count. And over the years, I've had the privilege of working with and at a number of various teams that I'm really thankful for. And really, it comes out of that that I want to share these things with you today, okay? Today, I'm a consultant. I help developer-focused companies do DevRel. And if you need help with that, I'm happy to chat after. But that's not what we're here to talk about today. Today, we're here to talk about React server components. We're going to talk about it in some depth. We have 20 minutes, so we'll see how far we get. The last time I gave this talk, it was 45 minutes, even though it was in a 20-minute slot. And then the GitNation folks were like, never again. In fact, it was the last talk and it went over time, so now they're like, we'll give you the first talk, so you can't go over time. Anyway, how many of you are using React server components? Okay, that's, I'd say, 1% if that of the room, which is fine. I mean, it's new, and that's why I'm here.

What I want to talk to you about is the mechanism of React server components. So I'm not going to talk to you about how to use it. The prevalent way of how to use it is to actually just use Next.js or a framework that handles the complexity for you. I think this is relatively straightforward. You can find it, Tobias from Marcelo is here, he'll probably talk to you about it, et cetera. What I want to teach you is the mechanism, how they work. Because I have a problem accepting high-level black box abstractions as an engineer.

Anyone, am I alone in this? Anyone else? Yeah, okay, most people. And so if you tell me, just use Next.js, and it's figured out for you, I'm like, okay, that's awesome, thank you, Next.js team, but how does it work so I understand the underlying mechanism? Okay? And so that's what we're here to talk about today.

In our time together, we will not cover two things. We're not going to cover the basics of React, I assume you know this. And if you don't, we can chat separately, but I have 20 minutes here. And we will not cover server actions because at the time of giving the talk, a lot of the React-specific stuff with server actions is in Canary, meaning it's pre-release, it's not production-ready. You can use server actions in Next.js, but again, I'm not ready to talk about that in a React capacity. What we will talk about is server components from the theory side. We'll look at the problems they solve, and then we'll look at how you can implement server component rendering-ish in practice. We'll look at the boundaries between server components, client components, what they mean and how they fit together.

Okay, with that, I have 15 minutes left. Wow. With that, let's get started talking about server components. Actually, let's zoom out a little bit and talk about React. I recently had the privilege of writing a book on React, and so I'm thinking, like, first principles style. React, by its name, is a piece of software that enables web applications to what? To React, to user interact. That's the whole point. And you might think, okay, so I click a button and React does stuff. Exactly. But it's not just about reacting. It's about reacting well. It's about reacting fast. It's about when some expensive CPU work is happening, right? You're rendering a big list, and then a user enters a keystroke in an input.

That input needs to respond to them before whatever CPU work is happening. It needs to react instantly. That is the purpose of React through and through. And so typically, web applications are CPU-bound, meaning they're doing work on the CPU, or they're network-bound, meaning there's data fetching. And the data fetching can sometimes interrupt user interfaces. Can you think of a case where this happens? Spinners. In fact, X, formerly Twitter, is entirely client-side rendered, and so if you go on there, you'll see seven different spinners all at the same time. And this can interrupt your user experience. And so React aims to solve that problem, and server components is and are the answer to this.

Now, you might be thinking, okay, but server-side rendering was the answer to this, right? Server-side rendering means you render all your React components on the server-side, and then you just send HTML, or you stream text HTML to your browser. Yes, they solved the spinner problem, but the level of granularity isn't ideal. Typically, before Next.js 13, you would render an entire page on the server. You couldn't say, like, this specific card that formats Markdown, this thing alone needs to render on the server and go to the client. Server components solved that.

Server components solved the problem of data fetching. Some of you may have heard of suspense for data fetching, right? Server components is basically that. It started with solving the problem of large JavaScript bundles, right? We used to ship a lot of JavaScript. The entire application was basically just JavaScript we shipped from some server to the browser. The browsers have to download the JavaScript, parse it, execute it, and then the app becomes interactive. That's awful. Server rendering solves that by sending markup and then hydrating, so the JavaScript is loaded after. Server components solve it even more by rendering components exclusively on the server. Exclusively! So if you have a blog, it's read-only, there's no interactions. You can render that entire thing on the server and almost never on the client. And then what do you render on the client? You only ship the interactive elements. A little button, a little plus sign, the add to cart, the small stuff. And therefore you ship less code. So it's a two-way solution. It solves data fetching, because you're even fetching on the server, and it solves the large bundle size problem. So we only ship little buttons instead of entire applications. That's the solution.

So with that, I'm already bored of listening to myself speak. So let's just do a demo. How about that? What I want to show you is this little demo I have prepared. These are jokes, and they're moving. I promise you there's logic. So let's talk about this a little bit. These jokes come from a database. There's an amazing member of the React community called Shruti Kapoor.

This is Shruti, ShrutiKapoor08. And she has a GitHub repo called devjoke. And it's full of jokes, developer jokes. I needed to get this into a database. So there's a backend as a service thing called Kiel. I loaded it in here, and there's a bunch of data here, questions and answers. And I wanted to just basically give myself data to fetch.

So now I have this database, and I want to fetch it to show you server components. So this is the application fetching data from my database. And what you're seeing here is entirely client-rendered. So if I reload this, you'll look at some problems with client-side rendering. So if I reload this, exactly. Let's try that again. There we go. So it says no jokes. So there's this flash of unstyled or unintelligent content. It fetches the data, and then the data becomes available. But that no joke was not cool. It would be nice if I could fetch that data on the server and just send the jokes directly.

Then I click on what is brown and sticky. Any answers? I click on this, and I should see the answer. But it says no answer and then a stick, which a stick is brown and sticky. You're welcome. It's very safe for work. And then whenever I click on another joke, I get the answer. But you see, it has this no answer flash. Yuck. And that's because it's all client-side rendered. If I look at the Network tab here, you'll actually see network requests happening. So I click this, look at all these requests.

And if I filter on Fetch, it's doing this. Now, if I do this on the server side, we get instant stuff. Let's look at how we can add server-side rendering.

So this is a Git diff, and we're going to walk through what changed. So in step one, we add a server. This is literally an Express server that adds server-side rendering. So what we're doing is we import our dependencies. We instantiate a server, and we listen on disk. This will get our client-side JavaScript. From there, we have a route parameter slash page. And whatever that parameter is, we just require that. We expect it to be a default export of something in a pages folder. This is how Next.js works. You get a route parameter. OK, this is probably a JavaScript file under pages. Require it. Show it. That's what we're doing here. And then we take that, and we use render to string to turn the component into an HTML string, send it over the network. That's it. This is server-side rendering in a nutshell. It's oversimplified, because we have 20 minutes. There's a bunch of educations that I'm not handling. Use a framework. But this is about the mechanism. So let's run this now. So I'm going to go here, and we'll git checkout one. npm run build. So we're building the server, and we're starting the server. That's all we're doing.

And now we'll go back to my browser. This is Arc, by the way. Best browser in the world. Chicken need Hydra. I don't even know. But we're now on port 3000, not 5.1.7.3 slash question. And it says no jokes, and it just actually has no jokes at all. Can someone tell me why? We have no jokes, because what we're doing is we're fetching on the client side. But this is server-side rendered, and we're not hydrating. We're not adding the JavaScript after the fact. In fact, if you look here at the React DevTools, this page doesn't appear to be using React. So a very easy solution to this would be what? Would be to come here to our server, excuse me, server.tsx. And when we render to string, we send the HTML, but we also do script src slash client.js like this. And then we load the client-side JavaScript. In theory this should work, but I don't trust the demo effect, so let's see. Reload. Are you using React? Yeah, you are. And so now we picked up React on the client side. We hydrate, and it works. But the problem still sucks, because we're still client-side fetching. You see this? And we have this because the initial load is without data, and then we still fetch on the client side. It would be cool if we can fetch on the server-side.

So let's advance a little bit in git history. Let's go to the next commit. So we added a server, but notice we changed no application code. What is application code? Let's look at application code here. So if we go to our pages slash question, questions, what we're doing in questions, we're fetching this yuck. We're fetching a use effect, and we're setting juke. You should never do this, by the way. This is the less ideal way to fetch data in React. You want to fetch on the server-side as early as possible, that is, even in module scope, never in use effect. We can talk more about that around if you have questions.

So this is suboptimal, and that's why we have this ugly yuck, no answer, and then the answer comes, and then the jokes will probably load in the background. Lame, lame. So we now fetch on the server-side. When we fetch on the server-side, we can do it in multiple ways. Server components is the premier 2023-plus way of fetching on the server-side. So let's look at how we do this now with server components. If we do it with server components, we can basically just turn this component into an async component. Oof. Actually, maybe not all of it. So we'll jokes equals, oh wait, oh my goodness. Look, wow. Beautiful. And instead of set jokes here, we just return the results, whatever it is we're doing. And this is it. But the problem now is it's like, this is async. This isn't a React component, because React components are not async. You can't do this. Except with server components, you can. Let's look at how. So I'm going to undo all of this. Actually, you know what? I'm going to save it. And then I'll come here and just reset my changes. Let's look at how we add server components to the mix here. So here's what we're doing. We updated our questions component. And we turned this component into an async component. That's what we did. Literally, what I just wrote, we're doing that here. And we're also doing that in the answers file. We literally take a component and add async to it and fetch here instead of in use effect.

On our server, what changes are we doing? Well, before we render to string, we have another function called unwrap JSX. Unwrap JSX is an async function that requires being awaited. And keep in mind, here we're on the server. And on the server, we can await things, because servers are async. So we await unwrap JSX.

Another question, what does unwrap JSX do? It literally goes component by component by component by component. And if a component is a function component, and if that function component is async, because it has an await with a data dependency, it will await it, turn it into a regular component that's not async, and then return it. And the code for that is here.

So unwrap JSX, if it's a string or a number or Boolean, then it's not going to be an async function. We just return it. If it's an array, we await all elements in the array. This is a React fragment. We just await it. If it's an object, then if it's a React element, and if it's a built-in component, div, span, p, we call unwrap JSX on its children, a.k.a. props. If it's a function component, we call unwrap JSX on its props, because props have children that may be async. And then we await the component itself, the function component. We call it with its props, await it. And finally, we recursively just unwrap everything. So we just await everything in the React tree. And at the end, what we get is a big tree of JSX, but all data dependencies have been resolved. And then we take that return and pass it to render to string and just get a React string. That's your basic server components render. You just await a bunch of stuff on the server, send it. Of course, you don't necessarily need to synchronously send a string. You can also stream a response. This is just simplified for mechanism. That's the gist of how it works. And because now you're rendering initial markup on the server, you can do some really cool things. For example, you can take all that initial JSX that you created on the server and store it in window.

Then what you can do is listen for navigation in the client side. So this is the server bundle. And we're storing the initial render on the server. If we go to the index, what we can do is create soft navigation. So we come here. We listen for all clicks on anchor elements. And instead of navigating in the browser, we stop that, and we call navigate. And navigate fetches another JSX tree from the server and just re-renders it. So it's soft navigation.

And I'd love to show you the full server components flow now by generating the HTML on the server for the next page and sending it and saying, hey, React on the client side, just re-render this tree. So if we get checkout, checkout, excuse me, checkout for PM run build. So this is a full server components flow based on what we just covered. So if we come here and we reload, we'll go to slash question queue. There we go. No, no. Oh, wow. It redirected.

So now we've got a full server components flow where we are, if we click on the joke, right? First of all, there's no style of, there's no flash of unloaded content. But also, when I click here, it navigates. And the sliding position is not interrupted. We persist the state. Because we're not fundamentally navigating in the browser. We're just re-rendering new JSX. We fetch. Let's look at what happens on the server side. Or rather, from the network tab. So once again, the jokes are going to come from here. And what I'll do is, I've got the network inspector open. And I'll fetch. Let's actually put this on the side.

I will fetch. So I'll click on a joke. Why was Six afraid of Seven? Fetch. And it's going to load. And there. Because notice, we didn't lose state. Soft navigation through server components.

The question is, what did we fetch? And if we go to answer, this is what we fetched. Let me make this nice and big for you so you can see. OK? Type of is re. Props. Children. So we have head. We have HTML head body. And then, in children, we have a div. It's basically the next page expressed as React components from the server to the client.

React on the client side says, oh, I know what this is. And then we just call re-render. We say, let's render. Do your virtual DOM diffing. And then do the next page without any hard navigation. This is the gist of server components. You render a bunch of components on the server. You await them. Then you pass them to a server renderer. And then you ship them. And this enables soft navigation. If we look at the code, everything now is async. So we just literally async await. This is a server component here.

It's ts-ignore because the TypeScript definitions don't know how to deal with promises returned from this. But that's the gist of it.

So on the server side, we have the unwrap JSX function that does this. We've talked about this. And then you take the return value of the unwrap JSX function, pass it to render to string, or even render to stream, it doesn't matter. And that's the interplay between server components and server-side rendering. You can also just send that straight to a client. You don't need that. But this is typically how it's done.

One final remark as we close, I can't believe it's been 20 minutes, as we close, is that server components sort of mess up the semantics of things. Because the React server components are rendered in a server components server, and then pass to the server-side renderer, which is a client of the server component renderer. So the server, in this case, is the client. Is that clear? If it's not clear, it's not even clear to anyone. But no, there's one server. And the server-side renderer is a client of that server. But the browser is a client of the server-side renderer. This is why server components fundamentally is a bad name. So are client components, which, by the way, we didn't talk about client components. And we didn't have that in the demo. But a client component starts with the directive, use client. And this is a cue to the bundler, the build system, TurboPack, Tobias. When the bundler sees use client, as it's compiling the dependencies, it says, OK, this thing, I'm going to split that up into a separate bundle, send that bundle to the browser, and then load it on the client-side only. So the server renderer will render a little hole that the browser will fill in for the interactive client elements. That's how it works.

20 minutes, not enough to go as deep as we want to, but I'm around all day. I'm happy to talk about this with you and really solidify your understanding of React server components. Because I do believe, in summary, I have to wrap up, unfortunately. But I do believe that there's a lot of imposter syndrome in this space. There's a lot of esoteric language where people may not have the most solid understanding of this. And I'd love to demystify some of that.

I'd love to give you the confidence to have high-quality conversations. So get on Slido, get on x, formerly Twitter, let me know. And I'm happy to answer your questions. To wrap up, there's lots of content about this on YouTube. And I also recently wrote a book on React that goes deep into this type of stuff. It's going on sale March next year. Don't buy it if you don't want. I'm not here to make a pitch. Honestly, it's just if you find this stuff interesting. With that, React Deberlin, thank you so much for having me. Woohoo! Woohoo!

We've got a question coming in. And I'm pretty sure they're rolling in. People are so transfixed with the talk. One thing I am curious about, because I love this philosophy of diving into the black box. Because I think, and I've definitely been guilty of this, sometimes it's easy to just be like, ah, someone else has thought about it. I do not need to worry. I know that this is not necessarily just limited to server side, to server components. But just in general, what are some approaches that someone can go about, if they want to discover what's underneath the black box? How can they go and find that information? It's a great question.

This talk was inspired by the work of the community, as most things are in React. And Dan Abramov, anyone know Dan Abramov? Two people. Take that, Dan. No, but he would actually like that, probably. No, but Dan wrote a long article on how you create React components from scratch. And that was what taught me. And then also, I was at React Advanced London. Shout out, Git Nation, where Dan lives in London, was there. And I did have some holds, but I just asked him. I was like, explain this to me. And did not stop. I mean, he's a very smart person, but I'm not. And so when a not-so-smart person talks to a very smart person, you're like, are you speaking Greek? And so I feel this tendency to like, OK, maybe I'll just pretend I understand him so I at least look cool. But I didn't do that. And I think this is something that I can give to people to learn the underlying things is find an expert. There's plenty at this conference, at other conferences. You're one. And ask them questions, and then don't like, I think I have this tendency to pretend that I get it when I don't. Do not stop until you get it. And I think we would appreciate that. If you come ask me questions personally, and you almost borderline harass me, like I have to get it, I don't get it. Awesome.

Awesome. Let's do it. By the way, harassment against the code of conduct. I use the term lightly, but hopefully you get it. Well, first of all, Lies, you are a very smart person, general. So thank you very much for turning. So some of the audience questions have slid in. And as well, make sure you upvote questions that you really want to be answered, because we do not have time to go through all of them.

But next one's really about TypeScript. So what is the TypeScript solution for asynchronous components? Great question. So I just didn't like NPM install at type slash react at latest. But the new type definition's good. So easy. Yeah, I didn't even need to TS Igbore. Nice, nice.

And let's talk about managing state as well in server-side rendering. So like, can you just talk about it? Give us some tips. Yeah, so server-side state is way different than client-side state, right? Because one server services multiple clients, whereas client's usually bespoke state. This is a huge problem. And a lot of it is solved by using intelligent caching strategies on the server-side. So ideally, you have some type of cache where the key is your unique user ID, and you can keep their state there. Yes. I don't know how much in depth you want to go, but that's where you'd start, is thinking about caching and then invalidating per user, per path, something like this. Again, Next.js has helpers for this, to revalidate path, and so on, that help you with that. But that's the direction. I think there's one thing where there's always, maybe, there's some set paths that you can start for those, especially in Next.js, which is quite opinionated, and then you can go and do so many more things as well.

Yeah, and if you namespace your routes by user ID, for example, then you've already got a cache key. Absolutely. All right, the next one, this one is from Ricardo. Thank you, Ricardo. Hey, Tejas, what do you think the biggest obstacle to get RSE to production right now is? Nothing, as far as I know. OK, well, I take that back. I think it's difficult to, and this is just because of lack of education, I think it's, one of the biggest hurdles is, you need to re-arch, if you have an existing React application, you need to re-architect a lot of things, especially if you started with create React app, or if you're with Vite, you're just, good luck. I think that's a hurdle, some of you are laughing, but it's true. And then the other side of it is, it's quite hard to deploy, especially with server actions. How do you reason about, inside my React component, onClick equals useServer inside the closure, how do you then factor out that function and deploy it as a serverless function? This is where, Vercel has a tremendous edge, pun intended, and, yeah, so I think the biggest obstacle to get it to production is reasoning about server actions and their extraction plus incrementally migrating to RSE are some of the biggest obstacles there. So what you're saying is, there are a few obstacles, do you think they're gonna be worked out in the near term, or do you think it's gonna be a while? I think there's definitely an impetus there, but of course, the least friction is just use Vercel. And I would love to see that not be the case, not because I have ill will against Vercel, but I do want to democratize RSE. Yeah, so I hope it's solved in the near term, but I don't know.

All right, cool, we have time for one more question, but remember, even if we don't get to your question now, you're gonna be able to find Tejas over in the Q&A discussion spot over by the, by the... Use memo track. Not misinformation, I don't know. Not the use memo track, over by the reception. That's where I wanted to say, my brain just went blank. All right, last one from Mr. O, how do you debug them? Do you build and run the server again and again? Well, no, I mean, so this was just because it's a lazy demo. I prepared this like yesterday. You debug, how do you debug React server components? If it's this thing, how do you debug it? Yes, but you could use v-node, which gives you like automatic reload on saves, for example. But to debug RSCs, if you're using a framework, the framework will help you. Like Next.js will just give you warnings, intelligent warnings in the console, in the air, et cetera. I know Remix is thinking about RSCs, React server components as well, but at this time, Next.js is the only framework and it'll help you. So again, if I wasn't clear in the beginning, do not roll your own React server components yet. This was just for teaching you mechanism, use a framework. No, I love that. And I think it's important as well, sometimes to just step outside of the tools, to understand what the tools are doing for you, then going back into the tools to actually get the work done as well. And to think, you know, okay, I get it. I get it, I can teach it. And if for some reason, someone has a nervous breakdown and deletes the open source code, I could probably come close in my own implementation. That's high estimation of my abilities, but not a high estimation of yours. Thank you very much, Tejas. Let's give him a round of applause as well.