Intensive reading of "React Server Component"

Up to now, React Server Component is still under development and research, so it is not suitable for use in a production environment. But the concept is very interesting and worthy of learning by technical people.

At present, in addition to various domestic blogs and Zhihu interpretation, the most first-hand learning materials are as follows:

I will combine these first-hand information with the interpretations of some industry leaders, and systematically explain the concept of React Server Component and my understanding of it.

First, let's look at why we need to propose the concept of Server Component:

The concept of Server Component was proposed to solve the impossible triangle of "user experience, maintainability, and performance". The so-called impossible triangle means that at most two can be satisfied at the same time, and all three cannot be satisfied at the same time.

To briefly explain, the user experience is reflected in the faster response of the page, the maintainability is reflected in the code should be high cohesive and low coupling, and the performance is reflected in the request speed.

Ensure user experience and maintainability , pull all data with one request, and render all components at once. However, when the number of modules continues to increase, and useless module information is not deleted at will, the request will become larger and more redundant, causing the bottleneck to be stuck in the fetching block, that is, the is not good and .
To ensure the user experience and performance , consider parallel access. After the process remains unchanged, then the business logic will add or reduce a module in the future, we must modify the parallel access common logic and the corresponding business module at the same time, maintainability is not good .
Protection maintainability, performance , each module can independently access, but in the case of a parent until they have finished rendering render child elements, and his son becomes a serial access, page load is blocked, user experience is not Good .

In a word, in the decoupling mode of the front and back ends, the only bridge connected is the access request. To achieve a good user experience, the access must be initiated in parallel in advance, and the front-end module is independently maintained, so doing access aggregation at the front end will inevitably destroy the maintainability of the front-end, and this parallel is placed in In the case of the back end, the aggregate information given will lag because the back end cannot resolve the front end module, and it will become redundant over time.

To solve this problem, it is necessary to deepen the connection between the front-end and the back-end. Therefore, a front-end and back-end agreement scheme like GraphQL is feasible. However, because of its high deployment cost and the benefits only at the front-end, it is difficult to promote in the back-end.

Server Component is another solution, which assists the front end by starting a Node service, but instead of API docking, it runs the front-end isomorphic js code, directly parses the front-end rendering module, automatically extracts requests from it, and directly communicates with the server on the Node side , Because the communication cost between the servers is extremely low, the front-end code does not need to be adjusted, and the request data is also dynamically aggregated on demand, so the three problems of "user experience, maintainability, and performance" are solved at the same time.

The core improvements are shown in the figure below:

As shown in the figure above, this is the normal interaction mode between the front and back ends. You can see that Root and Child sent two requests in serial, because the network time-consuming and serial are severely blocked, so they are marked with red lines.

Server Component can be understood as the following figure, which not only reduces a network loss, but also makes the request parallel, and the result of the request has changed from pure data to a special structure that simultaneously describes UI DSL and data:

At this point, congratulations you have understood the core concepts of Server Component. If you just want to understand it in general, you can end here. If you want to learn more about its implementation details, please continue reading.

Overview

In a nutshell, Server Component is to allow components to have the ability to render on the server side, thereby solving the impossible triangle problem. It is precisely because of this feature that Server Component has several eye-catching features, which are not available in pure client components:

components running on the server side will only return DSL information, without any other dependencies , so all dependent npm packages of Server Component will not be packaged to the client side.
can access any API server side, which means that the component has the capabilities that Nodejs can have. You can theoretically do any server-side ability in the front-end component.
Server Component and Client Component are seamlessly integrated , Client Component can be called seamlessly through Server Component.
Server Component will return information on demand. Under the current logic, all references to the branch logic that cannot be reached will not be imported by the client. For example, although Server Component references a huge npm package, but the functions provided by this package are not used in a branch, the client will not download this huge npm package locally.
is not HTML, but a DSL, so even if the server component is pulled again, the generated State will be maintained . For example, A is a ServerComponent, and its child element B is a Client Component. At this time, the state of component B is modified, such as inputting some text. At this time, after triggering A to pull the DSL again, the text that has been entered by B will remain.
can be seamlessly combined with Suspense , and the loading of Suspense will not be displayed in time due to network reasons.
on the server and client at the same time.

Three components

Server Component divides components into three types: Server Component, Client Component, and Shared Component, which end with the suffixes .server.js , .client.js , and .js

Among them, .client.js is the same as ordinary components, but both .server.js and .js may run on the server side, where:

.server.js must be executed on the server side.
.js executed depends on who calls it. If it is .server.js , it will be executed on the server side. If it is .client.js , it will be executed on the client side. Therefore, it essentially needs to receive the constraints of the server-side component.

The following is an example of Server Component shown in the RFC:

// Note.server.js - Server Component
import db from 'db.server'; 
// (A1) We import from NoteEditor.client.js - a Client Component.
import NoteEditor from 'NoteEditor.client';

function Note(props) {
  const {id, isEditing} = props;
  // (B) Can directly access server data sources during render, e.g. databases
  const note = db.posts.get(id);
  
  return (
    <div>
      <h1>{note.title}</h1>
      <section>{note.body}</section>
      {/* (A2) Dynamically render the editor only if necessary */}
      {isEditing 
        ? <NoteEditor note={note} />
        : null
      }
    </div>
  );
}

As you can see, is the mixed syntax of Node and React . Server components have harsh restrictions: cannot have a state, and props must be serialized .

It's easy to understand, because the server component must go through the process of serialization and deserialization to be transmitted to the client. JSX can be serialized, and props must also follow this rule. In addition, the server cannot store the state for the client, so the server component cannot use any state-related APIs such as useState

But these two problems can be circumvented, that is, the state is converted to the props parameter of the component, which is .client.js , as shown in the figure below:

Or take advantage of the seamless integration of Server Component and Client Component, put the status and props parameters in the Client Component, which is called by the Server Component.

advantage

Zero client volume

This sentence sounds a bit exaggerated, but in fact it is really true under the limit of Server Component. Look at the following code:

// NoteWithMarkdown.js
import marked from 'marked'; // 35.9K (11.2K gzipped)
import sanitizeHtml from 'sanitize-html'; // 206K (63.3K gzipped)

function NoteWithMarkdown({text}) {
  const html = sanitizeHtml(marked(text));
  return (/* render */);
}

marked sanitize-html will be downloaded locally, so if only this file is transferred, the theoretical increase in the client's volume is the render function, which may be less than 1KB.

Of course, this is also a limitation. First of all, this component has no state and cannot be executed in real time on the client side, and running on the server side may also consume additional computing resources, if some npm packages have high computational complexity.

This benefit can be understood as that the marked package can only be read to the memory once on the server. Later, as long as the client wants to use it, it only needs to execute the marked API on the server and return the output result to the client, without the client downloading marked this package.

Have complete server capabilities

Since Server Component is executed on the server side, any code of Nodejs can be executed.

// Note.server.js - Server Component
import fs from 'react-fs';

function Note({id}) {
  const note = JSON.parse(fs.readFile(`${id}.json`));
  return <NoteWithMarkdown note={note} />;
}

We can take the understanding of the request to a higher level, that is, request is just an Http request initiated by the client. Its essence is to access a resource, which is an IO behavior on the server. For IO, we can also write and delete resources file db directly access the database through sql syntax, or request directly issue a request locally on the server.

Code Split at runtime

We all know that webpack can move unused imports out of packaging through static analysis, while Server Component can dynamically analyze at runtime to move imports that are not used under the current branch logic out of packaging:

// PhotoRenderer.js
import React from 'react';

// one of these will start loading *once rendered and streamed to the client*:
import OldPhotoRenderer from './OldPhotoRenderer.client.js';
import NewPhotoRenderer from './NewPhotoRenderer.client.js';

function Photo(props) {
  // Switch on feature flags, logged in/out, type of content, etc:
  if (props.useNewPhotoRenderer) {
    return <NewPhotoRenderer {...props} />;
  } else {
    return <OldPhotoRenderer {...props} />;
  }
}

This is because the Server Component will be pre-packaged when it is built. At runtime, it is a dynamic package distributor. It is completely possible to distinguish which branch logic is currently running, and which branch logic is not running, and only tell props.xxx The client pulls the missing package of the branch logic that is currently running.

The pure front-end mode is similar to the wording:

const OldPhotoRenderer = React.lazy(() => import('./OldPhotoRenderer.js'));
const NewPhotoRenderer = React.lazy(() => import('./NewPhotoRenderer.js'));

It's just that this way of writing is not native enough, and the actual scenario is often only the front-end framework automatically wraps the route with a layer of Lazy Load, and this way of writing is rarely seen in ordinary code.

No client-side round-trip data access

Generally considering the network consumption of fetching data, we tend to process it as asynchronous, and then display Loading before the data is returned:

// Note.js

function Note(props) {
  const [note, setNote] = useState(null);
  useEffect(() => {
    // NOTE: loads *after* rendering, triggering waterfalls in children
    fetchNote(props.id).then(noteData => {
      setNote(noteData);
    });
  }, [props.id]);
  if (note == null) {
    return "Loading";
  } else {
    return (/* render note here... */);
  }
}

This is because in single-page mode, we can quickly get this DOM structure from the CDN, but if we wait for the number to be fetched, the overall rendering will slow down. The Server Component itself is executed on the server side, so it can take the DOM structure and fetch at the same time:

// Note.server.js - Server Component

function Note(props) {
  // NOTE: loads *during* render, w low-latency data access on the server
  const note = db.notes.get(props.id);
  if (note == null) {
    // handle missing note
  }
  return (/* render note here... */);
}

Of course, this premise is sensitive to network consumption. If it is a slow SQL query that takes a few seconds, this is counterproductive.

Reduce the component level

Look at the following example:

// Note.server.js
// ...imports...

function Note({id}) {
  const note = db.notes.get(id);
  return <NoteWithMarkdown note={note} />;
}

// NoteWithMarkdown.server.js
// ...imports...

function NoteWithMarkdown({note}) {
  const html = sanitizeHtml(marked(note.text));
  return <div ... />;
}

// client sees:
<div>
  <!-- markdown output here -->
</div>

Note and NoteWithMarkdown are abstracted at the component level, since the real DOM content entity has only a simple div , in the Server Component mode, the returned content will be simplified to this div without including those two abstract components. .

limit

There are three components in Server Component mode, namely Server Component, Client Component, Shared Component, each of which has some usage restrictions, as follows:

Server Component：

❌ can not useState , useReducer other state storage API.
❌ not use useEffect API and other life cycle.
❌ not use window browser supports only the API and so on.
❌ Custom Hooks that include the above conditions cannot be used.
✅ Can seamlessly access server data and API.
✅ Can render other Server/Client Component

Client Component：

❌ Server Component cannot be referenced.
- ✅ However, it is possible for Client Component to call Server Component in Server Component, such as <ClientTabBar><ServerTabContent /></ClientTabBar> .
❌ Cannot call server-side API to get data.
✅ You can use all the full capabilities of React and browsers.

Shared Component：

❌ can not useState , useReducer other state storage API.
❌ not use useEffect API and other life cycle.
❌ not use window browser supports only the API and so on.
❌ Custom Hooks that include the above conditions cannot be used.
❌ Server Component cannot be referenced.
❌ Cannot call server-side API to get data.
✅ It can be used on the server and the client at the same time.

In fact, it is not difficult to understand, because Shared Component is used on both the server and the client, so it has their disadvantages, and the benefit is stronger reusability.

intensive reading

To quickly understand Server Component, I think the best and fastest way is to find the difference between it and PHP + HTML ten years ago. Look at the following code:

$link = mysqli_connect('localhost', 'root', 'root');
mysql_select_db('test', $link);
$result = mysql_query('select * from table');

while($row=mysql_fetch_assoc($result)){
  echo "<span>".$row["id"]."</span>";
}

In fact, PHP has long been a "Server Component" solution, which directly accesses the DB on the server side and returns the DOM fragments to the client side.

After tossing with React Server Component for so long, it can be found that the biggest difference is that the returned HTML fragment is changed to a DSL structure. This is actually the result of a powerful React framework behind the browser. In addition to allowing us to continue to write React grammar on the server without degrading to "PHP grammar", the benefits of this are more importantly that the component state is maintained.

Another important difference is that PHP cannot parse any npm package in the current front-end ecosystem, so there is no way to parse the modular front-end code, so although the efficiency of PHP is intuitively the same as that of Server Component, the cost behind it is to write another set It does not rely on any npm package or JSX syntax to return HTML fragments, most of the features of Server Component cannot be enjoyed, and the code cannot be reused.

Therefore, in essence, HTML is too simple to adapt to the complexity of today's front-end. Although the common back-end framework has powerful back-end capabilities, the front-end capabilities are still 20 years ago (direct return to DOM), and only Node is in the middle As a bridge, the layer scheme can better connect the modern back-end code with the modern front-end code.

PHP VS Server Component

In fact, in the PHP era, both front and back ends can be modularized. The back-end modularity is obvious, because the back-end code can be developed modularly and finally packaged to the server to run. The front-end can also be developed modularly on the server-side, as long as we strip off the front-end and back-end code, the cyan is the back-end part, and the red is the front-end part:

But there is a problem, because the back-end service is stateless to the browser, so the back-end modularity itself is in line with its functional characteristics, but the front-end page is displayed in the user's browser, and each time it is routed to the new Pages, obviously cannot maximize the advantages of the client's continuous operation. We hope that on the basis of maintaining the front-end modularity, there is a continuous running framework on the browser side to optimize the user experience, so Server Component actually does the following things:

This has two major advantages:

Taking into account the advantages of PHP mode, that is, the seamless mixing of front-end and back-end code, it brings a series of experience and capability enhancement.
The front and back ends are still modularized. The red part in the figure is packaged as a whole with the front-end project, so the development still retains the modularity, and the modern React framework is maintained on the browser, whether it is single-page or data-driven, etc. Features can continue to be used.

to sum up

Server Component is not mature yet, but its concept is still very reliable.

If you want to achieve "user experience, maintainability, and performance" at the same time, it is not feasible to focus on the back-end or the front-end. It can only be achieved if a balance is achieved between the front and the back. Server Component expresses a kind of professional development concept, that is, the front and back ends will go to the full stack in the future. This kind of full stack is to deepen the front and back ends at the same time, so that the program development can reach a height that can not be achieved by pure front end or pure back end.

In 2021, the domestic development environment is still relatively backward. The so-called full-stack often refers to "understanding a little bit about the front and back ends", and it is difficult to incubate the concept of Server Component. Of course, this is also our motivation to continue to learn from the world.

Maybe the difference between PHP and Server Component is the touchstone to test whether a person is a real full stack or a pseudo full stack. Just ask your colleagues!

The discussion address is: "React Server Component" · Issue #311 · dt-fe/weekly

If you want to participate in the discussion, please click here , a new theme every week, weekend or Monday. Front-end intensive reading-to help you filter reliable content.

Follow front-end intensive reading WeChat public

Copyright statement: Freely reproduced-non-commercial-non-derivative-keep the signature ( Creative Commons 3.0 License )

Intensive reading of "React Server Component"

Overview

Three components

advantage

Zero client volume

Have complete server capabilities

Code Split at runtime

No client-side round-trip data access

Reduce the component level

limit

intensive reading

PHP VS Server Component

to sum up

黄子毅

引用和评论

精读《算法题 - 二叉树中的最大路径和》

Vue.js-Vue实例

2025年最新反编译微信小程序的教程及工具

Flex 布局学习总结（对齐方式）

Koa+Typescript起手式(空环境) 不用每次玩node都要搭环境了！

你可能不知道的图片加载相关知识

巧用 CSS 实现高频出现的复杂怪状按钮 - 镂空的内凹圆角边框