Zero Bundle Size Server Components

React Server Components. React Server Components is a recent feature introduced with the React team and launched with Next.js 12. Today, I will be talking about the rendering strategies, which is mainly client-side rendering and server-side rendering. Then I'll talk about the React Server Components, what are React Server Components, how it is different than server-side rendering, and how we can use them in our application. We will also see the performance benefits of using React Server Components.

Then we'll do everything coding, a live coding, and see everything up and running. Finally, we'll also talk about some challenges that you might come across when you try to use React Server Components in your existing application.

A bit about myself, my name is Asima. I'm a Senior Front-End Engineer working in Amsterdam. In my free time, I like to create some Front-End videos. You can reach me out on LinkedIn, Twitter.

So finally talking about the rendering strategies, so we have client-side rendering and server-side rendering. In client-side rendering, when a user requests a website, server sends a blank HTML with a script tag with source bundle.js. Browser then downloads the JS file, React gets loaded, and a request is sent to fetch the data from server. After the data is received from the server, the content becomes visible. This approach works great for building high user-interactive websites, as you can reload the components which have been changed instead of reloading the entire page. However, the problem comes as you ship more and more code to our JS bundle. The bundle size increases and browser takes time to download the bundle, because of which we get delayed FCP. Also with client-side rendering, there are SEO problems and you're not able to run them on non-JavaScript devices.

We have another strategy, which is server-side rendering. In server-side rendering, when user requests a website, this time server sends a fully rendered HTML, but this HTML is static. So what browser does is that parallelly it also downloads the JS file, then the comparison is done between the page, which is generated by the browser, and the one which is sent from the server. This is what we call hydration. After hydration, react takes control and content becomes interactive. One of the huge benefit we get from SSR is improved FCP because browser does not have to wait for client to generate an HTML and show content to the user. Also, the issue problem is solved, but one of the problem with SSR is that you can only use server-side rendering on first upload. After that, after hydration the app behaves like a normal client-side rendered application. Now some of you might say that in Next.js, you can create multiple routes and on each route you can use server-side rendering. But what happens is that as you switch between those routes, the state of components is not maintained. This is one of the major difference between server-side rendering and React Server components.

So talking about React Server components, as the name suggests, React Server components are rendered on the server. Now the end goal for browser is to generate a DOM tree. So if you're using client-side rendering, all the components in a React DOM tree are rendered on the server. If you use client-side rendering, all the components are rendered on the client. If you use server-side rendering, all the components are rendered on the server. However, with React Server components, some of the components are rendered on the server, and some of the components are rendered on the client. And when I say the components rendered on the server, it does not mean server-side rendering. Because in server-side rendering, what happens is that all the components, whether it's a server component or a client component, everything gets converted into a raw HTML and sent to the client. In fact, React Server components can be used along with server-side rendering.

So what you can do is that when user requests a page, for the first time you can use server-side rendering. And this time server will send a HTML. And the next time, as you switch between the route, the client can request server component, and this time server will send a JSX-like object, which looks something like this.

So now if you look at this clearly, so the response we are getting is some of the client files and some of the server files. So now if you pay attention to the client file, what is sent from the server is only the file reference and the chunks are empty. However, with the server file, it's already sent, rendered from the server.

Now why would you want to render components on the server? So one of the benefit is that if the component is already on the server, it can access the DB and file system directly, which means that it can access the server resources very quickly, which means that data fetching becomes really fast than using a fetch call from the client. Also server is good in making computations. So you can get faster computations and also for the security purposes, you can choose to keep the sensitive data on the server instead of sending on the client. So the main idea behind RSC is to let server do what it can do the best before handing over things to the browser.

So what server is good at is data fetching fast performance. So you can choose to do all the performance related stuff, heavy rendering on the server and leave client for the interactivity part. All the code that we do inside the server component is not sent to the client bundle, which is a huge performance benefit because it adds zero KB to the bundle size. And also we get direct access to DB and the file system with server components.

Now what is sent from the server is rendered server component and the client place holders. So when tree shaking happens, only the server components are refetched, which means that the state of client components is maintained. Now all of you must be feeling like what is happening, but we will see everything in the coding. Right now the server components are still in experimental state and it's only supported in Next.js. So if you want to try them out, you need to use Next.js. There is a framework created by Hydrogen, by Shopify, which is Hydrogen. It uses the React server components and feel free to check out the documentation, it's really interesting how they have used server components.

Now there are a couple of rules we need to follow when we need to use React server components. I will just read them out. So firstly, you need to save the files with extension.server.js and client.js because this tells React that which components are to be rendered on the server and which components are to be rendered on the client. So our components can only pass serialized props to the client components, which means you cannot pass functions. Client components cannot import server components and server components cannot use hooks like uState or any event handlers. You also need to have some configurations to get them started. So you need to install nextcanary react-rc and react-dom-rc. Also in your next.config.js, you need to turn on the flags server components too.

Now let's create a server component. So what we are going to create today is an email application. It has a list of emails, and as you click on any of the email card, it should open the email body. So in our application there are two main components. One is the email list and another one is the email body. So first let's write the email list component. So first I will do is fetch the emails. Now I will go through the emails and for each email, I will display name, subject, description, and date. Now here, instead of passing the raw date, I will import a function and pass the formatted date. Now the email list component look something like this. What I'm going to do now is that break this component into two components.

So one is the container component, which will be used for fetching data, and the another one is view component, which will have everything related to the view. So now I've broken this component into two components. Now I will rename the files with.server and.client.js, because I want the server file to be rendered on the server and client file to be rendered on the client. Now I'm going to import email list, view component into my server component. Now, one thing to note here is that in the props, you can only add those props, which can be serialized over the network, which means that you cannot pass any functions to the client component. So this is how what my server file looks like, and since it's rendered on the server, so instead of fetch, we can also read it from the DB or read it from the file system directly.

For more resources, you can check out the blog by Dan Abramov introducing zero bundle-sized server components. You can also refer to the Next.js documentation and explore the live app created by Next.js. Now let's see what we have built so far. Our application consists of email cards, and when you click on a card, it opens the email body. The response sent to the client includes the client files and a fully-rendered server file in a JSX-like object format. One important thing to note is that the state is maintained when switching routes, which is not possible without React server components. Now, let's discuss some challenges that may arise when using server components. First, client components cannot import server components directly. Instead, composition can be used to include server components as children. Second, hooks cannot be used inside server components, so it's important to divide components into client and server components to handle states properly. Lastly, making third-party API calls inside server components requires rendering the data on the server and passing it to the component using getStaticProps in Next.js. Next.js is a suitable framework for React server components as it provides configurations for rendering, routing, and bundling.