Zero Bundle Size Server Components


Server components is an exciting new feature introduced in React 18. It lets us leverage the fast performance of the server by offloading work behind a component to the server. Why would we want to do that? because server has direct access to data source .so fetching data, making aPI calls would be really fast on the server. The most amazing thing about RSC is that they add 0 kb to the client bundle. So not only RSC reduces the bundle-size but will also improve page load times, eventually providing better user experience. In this talk I will be talking about what react server components are, why do we need them . RSC is often confused with SSR but we will see how they are fundamentally different. We will create a small react application using server components and see the performance benefits. We will also see the challenges we might face when we use RSC in our normal react application. Finally we deep dive into React’s brain and see how things are happening under the hood.



React Server Components. React Server Components is a recent feature introduced with the Reactor team and launched with Next.js 12. Today I will be talking about the rendering strategies, which are the most important features for React. I will be talking about the rendering strategies, which are the most important features for React. 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, live coding, and the 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 Ashima. 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. Finally, talking about the rendering strategies. We have client-side rendering and server-side rendering. In client-side rendering, when a user requests a website, the server sends a blank HTML with a script tag with source bundle.js. The browser then downloads the JS file, React gets loaded, and a request is sent to fetch the data from the 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 a user requests a website, this time, the server sends a fully rendered HTML, but this HTML is static. So, what the 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 high duration. After high duration, React takes control, and content becomes interactive. One of the huge benefits we get from SSR is improved FCP, because browser does not have to wait for client to generate an HTML and show the content to the user. Also, the SEO problem is solved. But one of the problems with SSR is that you can only use server-side rendering on first upload. After that, after high duration, 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. And this is one of the major differences 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 server-side rendering, all the components are rendered on the server. Sorry, if you use client-side rendering, all the components are rendered on the client. And 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 benefits 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 0kb 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 placeholders. 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 Shopify, which is Hydrogen. It uses 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. Server 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 useState or any event handlers. You also need to have some configurations to get them started. So, you need to install Next Canary, ReactRC, and ReactDOM RC. Also, in your Next.config.js, you need to turn on the flag server components to. Now, let's create React 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 looks 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.clientjs, 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 the more resources, you can check out the blog by Dan Abramov, introducing zero bundle size server components. And then you can check out the Next.js documentation, and also there is a live Next.js has created an app, which you can reference for creating your own application. Now, let's see what we have built so far. So, this is our application, which is like email cards, and as I click on the card, so it opens the email body. Now, let's see what is being sent to the client. So, as I click on the second card, so this is what the response looks like. And this is what we saw in the screenshot as well. So, it sends the client files, the reference of the file name, and this will be used by the browser to generate the client file later on. And then this is a fully rendered server file. So, the server is sending something like a JSX-like object. Second thing I want to point out here is that as you open the webpack, and here we have components, and in components we have email body and email card and email list. So, if you notice here that all the files which are sent is the client files, and there is no server file, so which is like none of the server code is sent to the client bundle. Another thing to notice here is that like as I mark it important, so now I will switch between another route. So, I'm going to mark important the second route. So, now my route changes, right? So, it has open email slash two, but the state has maintained. So, the previous important has been maintained. But if you were using only the next JS without React server components, what would happen is that the entire page would refresh, so we would have lost the state. So, now it's no matter how many routes we change, all the state is maintained. So, now let's talk about some of the challenges we can come across when using server components. So, first challenge is that client components cannot import server components. And what I mean is that let's suppose we have a client component, my client component, and let's try to import a server component, but this does not work. So, instead of using it like this, what we can do is use composition. So, we can pass the server component as children. And this is how we will use it. We can compose the server component inside the client component. The next challenge you can face is using hooks inside server components because it's rendered on the server, so you cannot use state, use effect, anything. So, make sure whenever you want to use states, you divide your components into client component and server component. So, you can drop all the state-related code into client component. And another biggest challenge is making a third-party API call inside server components because as we are making the third-party call, the data also needs to be rendered on the server. And then you can pass the rendered data into your component using get static props if you're using Next.js. Now, let's see why do we need a framework, why we want to use Next.js for using React server components. And that is because for React server components, we need configurations at all the levels, which is rendering, routing, and also the bundling. And Next.js provides all those configurations in-house at the moment, and that's why React team has decided to launch React server components with the frameworks. So, this is what our code looks like, our folder structure. It has every component has a client file and a server file. So, we'll have two server files and the two client files, which are rendered on the client. So, now we can pretty much say that every front-end dev is a full-stack developer. Thank you for attending my talk. You can reach me out on Twitter or LinkedIn. And here is the link to the slides. The email application is also on the GitHub, so please feel free to check them out.
17 min
24 Oct, 2022

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Workshops on related topic