New features in Act18

1. Automatic batching

In React multiple setstates are merged into one render.

In other words, setState does not modify State in real time, but only starts rendering once by combining multiple setState calls, which can reduce the instability caused by the existence of intermediate values of data states and improve rendering performance, which can be understood as the following code:

Const handleClick = () => {setName(" handsome ") setAge(22) // Only trigger render once}Copy the code

However, prior to act18, setState in asynchronous functions did not perform a merge. Due to the loss of context, the merge could not be done, so every setState call immediately starts a re-render. In addition to repeating setState, The optimization brought by React18 is that rendering can be optimized in any case (asynchronous callback,promise, timer) and setState that is called multiple times in callback functions are also merged.

If you want to rerender immediately after the setState call, just use the flushSync wrapper:

Import {flushSync} from "react-dom" const handleClick = () => {flushSync (() => {setName()}) setAge(22)}Copy the code

To turn this feature on, replace ReactDom. Render with ReactDom. CreateRoot call method

2. New ReactDom Render API

The way to upgrade is simple

import ReactDOM from 'react-dom/client'; const container = document.getElementById("app"); // Old render API reactdom. render(<App TAB ="home" />, container); // New createRoot API const root = reactdom.createroot (container); root.render(<App tab="home" />);Copy the code

Concurrent APIS

Concurrent Mode is an interruptible rendering design architecture. When do you interrupt rendering? When a higher-priority render arrives, perform the higher-priority render immediately by abandoning the current render in exchange for visually faster response times.

Some people say, no, after the render is interrupted, the previous render CPU execution will be wasted. In other words, the overall execution time increased. This is true, but there are actually two kinds of user perception of the timeliness of the page interaction. The first kind is the immediate input feedback. The second is the side effects of this input, such as updating the list. Even if the input feedback is satisfied first, the immediate side effect feedback is slower, which makes for a better experience, not to mention that the side effect feedback is mostly nulled by changes in the input feedback.

React changes the render DOM tree mechanism to two bidirectional lists, and the render tree pointer has only one pointer to one of the lists. Therefore, the pointer pointer can be switched after the update is complete, and changes to the other tree can be abandoned at any time before the pointer is switched.

startTransition

Let’s start with the basic usage

import { startTransition } from "react"; Const handleClick = () => {startTransition(() => {setName(" smarty ")}) setAge(22)}Copy the code

In simple terms, renderings triggered by setState wrapped in the startTransition callback are marked as non-urgent renderings that may be preempted by other urgent renderings.

For example, when the setName list is updated so much that the rendering is 100% CPU used, the user makes an input and triggers the rendering caused by setAge. The rendering caused by quitting seName will stop immediately and setAge will be supported. This allows the user’s input to be reflected quickly in the UI, at the expense of the slower response of the UI setting name. A broken transition can be accessed by isPending:

import { useTransition } from "react";
const [isPending, startTransition] = useTransition();
Copy the code

SSR for Suspense

The full name is: Streaming SSR with Selective chocolate

Rather than a one-off rendering mechanism like renderToString, he sees selective hydration, which refers to the binding of js events after the backend content is hit to the front-end. Before React18, this operation must be holistic. However, the hydration process may be slow and cause local lag, so selective hydration can be prioritized in order

So this feature is actually in preparation for SSR, and Supense is the carrier for enabling it (so don’t think of Suspense as just a loading function anymore). Suspense was originally designed to solve server side rendering problems, but it started with the ability for clients to load on demand, and you’ll see how much more powerful React makes Suspense root work.

SSR for Suspense solves three main problems:

  • SSR mode, if different modules access efficiency is different, because the slowest crimp overall throughput time of HTML module, which may lead to experience is not as good as the SSR to, to take an extreme case, a hypothesis statement components depend on the slow query, data take five minutes to come out, then the consequences of the SR is bad time to five minutes long.
  • Even though THE SSR content is hit on the page, there is no interaction in the whole page because JS is not implemented.
  • Even after js is loaded, due to the fact that only one encounter with chocolate is complete before React18, the first interaction response may lag

The biggest difference is that the server render has a simple res.send instead of res.socket. This rendering changes from a single action to a continuous action.

So summarize, the new VERSION of SSR performance to improve the secret: on demand

conclusion

Taken together, act18 focuses on faster performance and responsive user interactions, with interrupt and preemption concepts everywhere

In the future, when it comes to front-end performance optimization, we might actually think about it in terms of interrupts and preemption

  • Interrupt the design of the framework at any time, the first priority rendering strategy, and the UI interaction module that the user cares most about
  • A “smooth” pipeline SSR from the back to the front, and changes the hydration process on demand, with support punctuated by higher-priority user interactions, the part of the first-priority hydration user that is interacting with