React Server Components The React Server Components team released a solution to the React page’s performance issues with multiple interface requests. Of course, the proposal is still in the draft stage, and the official only released a video and a sample demo to illustrate the draft.

Server Components

The main reason for this solution, as explained in the video and RFC, is that the React component relies on data requests for rendering. If each component requests data by itself, the sub-component will start to request data of the sub-component only after the parent component finishes rendering the sub-component’s data request, which is the official so-called WaterFall data request queue. Putting data requests together is very difficult to maintain.

Since components require data to render, why doesn’t the interface just return the rendered component? So they came up with the Server Components solution. Regardless of whether the logic makes sense, let’s take a look at the general flow of the solution.

The React component is divided into two types: Server component (.server.tsx) and Client component (.client.tsx). The Server component is rendered directly on the Server side and returned. The difference from SSR is that Server Components return serialized component data rather than the final HTML.

Possible problems

The way that components and their data are returned together via the interface brings the benefit of package size, but can it really smell as good as React Hooks? I don’t think so.

Interface to return

In general, the front-end JS loads the component and the interface returns the data the component needs. React Server Components combines the two Components. Although the package volume is optimized, it is obviously escaped into the interface return. This disadvantage is especially pronounced in paginated requests such as lists. Components only need to be loaded initially, but because they are merged into the interface, each time the interface returns a redundant component structure, it is not known whether it is good or bad. Maybe you need to optimize the interface later to return only data twice.

Server cost

There are many server costs here, starting with the cost of the machine itself. Moving the client rendering behavior to the server inevitably increases the pressure on the server side, and the cost of this area increases by an order of magnitude as the number of users increases. The official response to this question is that as the cost of servers decreases, the advantages of Server Components will offset this disadvantage.

Question: This might become more expensive for applications. In the search demo, finding those search results plus rendering them on the server is a more expensive operation than just an API call sent from the client.

Reply: We are moving some of the rendering to the server — so it’s true that your server will be doing more work than before. But server costs are constantly going down, and far more powerful than most consumer devices. I think React Server Components will give you the ability to make that tradeoff and choose where you best want the work to be done, On a per component basis. And that’s not something that’s easily possible today. Via: RFC: React Server Components

However, in my current business, the cost of the server is still very expensive. In order to reduce the cost, people are sending logic to edge computing or even client side processing. On the one hand, it is to save cost, and on the other hand, it is to reduce pressure and speed up processing.

In addition to the cost of the machine itself, the cost of the request increases. After all, you have to deal with component rendering in addition to the data request, and this is not easily decoupled as a component coupling. Compared with the conventional scheme, JS files are used to load components to the client and the interface simply returns data, which increases the time cost very much. In particular, in conventional schemes, JS files are cached in the browser after loading, and the subsequent cost is very small.

The volume issue may be fine, but increasing the request time can be deadly.

Mental burden

This is also illustrated in the RFC. As useState, useReduce, useEffect, DOM API and other methods cannot be used in Server Components, it is bound to bring a lot of mental burden to users. Although the official said that we will use tools to make developers do not feel, and will provide runtime error, but I believe that just thinking about when to write Server Componet and when to write Client Component is already a headache. Not to mention a Shared Component.

In addition, the cost of debugging can become very high when cross-end processes are added. Let alone many people do not have experience in the server, even students with relevant experience may not be able to quickly locate in the server. The official line on this issue is to rely on internal error monitoring and logging services.

Get back to the essence of the problem

Getting back to the essence of the problem, the React Server Component is designed to solve the problem of a data request queue in which the child Component has to wait for the parent Component to finish rendering the child Component. Isn’t there another solution besides the Server Component? It’s not.

import React, {useState, useEffect} from 'react';
import ReactDOM from 'react-dom';

function App() {
  const [data, setData] = useState([]);
  useEffect(() = >{ fetchData.then(setData); } []);return (
    <div>{! data.length ? 'loading' : null}<Child data={data} />
    </div>
  );
}

function Child({data}) {
  const [childData, setData] = useState([]);
  useEffect(() = >{ fetchChildData.then(setData); } []);if(! data.length) {return null;
  }
  
  return (
    <div>{data.length + childData.length}</div>
  );
}

ReactDOM.render(<App />.document.querySelector('#root'));
Copy the code

As the sample code shows, simply loading the component but not returning the DOM in the case of no data can also make the child component’s data requested first without waiting. Of course this needs to be optimized in the way it’s written, but I still think it’s better than going through the hassle of making a Server Component.

I think the comments in the RFC make a good point about optimizing the packaging volume of the Server Component.” I think using an 83KB library for formatting dates in a project is a bigger problem than the 83KB package size (about 20KB after Gzip). “

Removing a 83KB (20KB gzip) library isn’t a big deal, I would say the bigger problem here is that you’re using an 83KB library to format dates. Via: RFC: The React Server Component”

In fact, the official list of two libraries for date processing and Markdown format processing can be seen as both for data processing needs. In this case, if the volume of this piece is very “expensive”, it is completely possible to let the server to return the formatted data, which is less cost to solve the problem.

Afterword.

After reading all the talk in RFC: React Server Component, most people still take a negative view of the Server Component, saying that it probably doesn’t address actual pain points in the business the way React Hooks do. In terms of the proposals exposed so far, I personally feel that the Server Component does more harm than good. The React users who do not use the Server Component are expected to be decoupled if implemented.

While the proposal is not without its benefits, I personally think the biggest benefit is that it brings an official standard for serialization of the React component. React component provides a foundation for multi-terminal, multi-machine, multi-language communication. Based on this serialization scheme, we can realize component cache storage, multi-machine concurrent rendering components and so on. Multilingual implementation is also a concern in RFC discussions. It is possible to implement the React component in other languages using this serialization standard.