banner
innei

innei

写代码是因为爱,写到世界充满爱!
github
telegram
twitter

Why RSC (Part 1)

React 19 will officially introduce the concept of React Server Component (RSC), and Client Component and Server Component will be officially separated from now on. Next.js has supported Server Component since version 13. So why RSC? What are the advantages? In this chapter, we will discuss this issue.

Avoiding Hydration Errors#

The introduction of RSC reduces the occurrence of hydration errors. If you only use Server Component to describe all components, hydration errors will not occur.

First, let's review why hydration errors occur.

We know that in traditional SSR architecture, the code is isomorphic, which means that the server needs to render the page and return HTML to the browser for static rendering before the page is rendered. After the JS is loaded, the browser executes the JS code again to re-run this code and bind the state and event interactions to the UI. If the state at this step is inconsistent with the state during server rendering, hydration errors will occur.

Let's take a simple example - displaying the current server time. Suppose we need the UI to show the current time. We quickly write the following code:

Due to hydration, the time on the browser is different from the time during server rendering, resulting in inconsistent data. This leads to a hydration error.

In Next.js versions 14.2.x and above, you can have a clearer understanding of why this problem occurs.

image

In traditional SSR, data hydration needs to be handled manually. For example, in the above example, we need to display the server time. We need to use getServerSideProps to ensure the consistency of the data.

This separation-based approach becomes very difficult to manage in the case of a large number of states, and the retrieval of server data must be centralized in the current page instead of in individual components, which makes the development experience more complex.

For example, when you need to retrieve more server data and the component depends on server data, you need to pass the server data from the top-level of the page to each component. If the component hierarchy is deep, you have to use Context or state management libraries to pass the data, even if the component logic is not strongly associated with the page. This approach limits the reusability of components because such components always need to retrieve server data from the top-level of the page instead of having independent logic to obtain the state:

So, in the RSC mode, we can easily combine the required data with the components. For example, in the above example, we can quickly encapsulate it into a component.

```tsx filename="app/page.tsx" import { Servertime } from './components/server-time'

export default function Home() {
return
}

```tsx filename="app/components/server-time.client.tsx" 'use client'

import { useEffect, useState } from 'react'

export function ServertimeClient(props: { time: number }) {
const [currentTime, setCurrentTime] = useState(props.time)
useEffect(() => {
// Simple time handling, not reliable.
const id = setInterval(() => {
setCurrentTime(time => time + 1000)
}, 1000)
return () => {
clearInterval(id)
}
}, [])
return

{currentTime}

}

Smaller Bundle Size#

Since Server Components only run on the server, the external libraries used in Server Components will not be loaded on the browser. This is more convenient for many tasks that require third-party libraries to process data or charts. Generally, these libraries have large file sizes, and these data can be processed only on the server side. By reducing the JS loaded on the browser, it reduces network load and improves the performance of the initial rendering.

Here is a simple example. For example, code highlighting is usually implemented using third-party libraries such as Prism or Shiki. These libraries generally have large file sizes, and if all languages need to be imported, the bundle size after packaging may increase by several megabytes.

Normally, we would use lazy or dynamic to split the code of components that use these libraries to prevent loading large JS files on the initial page and reduce the LCP metric.

However, since the HTML returned by the server already contains the highlighted DOM, it is unnecessary for the browser to download Shiki and perform highlighting again.

image

image

With Server Components, the logic of this component is completed on the server side, so there is no logic for rendering this component on the frontend, and naturally, Shiki will not be downloaded. Therefore, Shiki will not be included in the client's JS bundle.

The effect is significant.

image

This article is synchronized updated to xLog by Mix Space.
The original link is https://innei.in/posts/tech/why-react-server-component-1


Loading...
Ownership of this post data is guaranteed by blockchain and smart contracts to the creator alone.