React18 official version released

React18 official version released

I was still looking at the source code a few days ago. I wanted to say that I would try to see the features of React18. I didn’t expect the official version to come out today:

react18-release

Now take a look at the new features of React18 based on the blog post released by the React team: React v18.0 .

Concurrent

In fact, when I ran the source code before, I realized visually that React18 has really entered the era of concurrency. Here is the rendering of the v17 version:

reactv17

Compare the rendering of Reactv18:

Reactv18

It can be seen that compared to v18, in the part of React code running (ie the pink code segment), v18 runs 2 tasks, while v17 mobilizes 1 task. What exactly happened? After that, I really need to dig into the source code and see what kind of sassy the gods are doing.

Rendering will be interrupted

While the documentation makes it clear that developers don't need to know what they're doing under the hood (behind the scene), one caveat is that rendering can be interrupted. The following is from the original text:

With synchronous rendering, once an update starts rendering, nothing can interrupt it until the user can see the result on screen.

In a concurrent render, this is not always the case. React may start rendering an update, pause in the middle, then continue later. It may even abandon an in-progress render altogether.

That is, when rendering synchronously, once an update (of state or props) triggers the rendering, it cannot be interrupted until the user sees the re-rendered UI. But in concurrent mode, React might trigger an update, stop, resume later, or it might render the whole deprecation job halfway through.

Of course, React will guarantee the consistency of rendering and state internally, so ... it will be good to dig later.

State can be reused

The status petting mentioned here refers to:

Another example is reusable state. Concurrent React can remove sections of the UI from the screen, then add them back later while reusing the previous state. For example, when a user tabs away from a screen and back, React should be able to restore the previous screen in the same state it was in before.

That is, when part of the UI is removed and added back, React can reuse the previous state. The example here is that when the user clicks away from the page and then jumps back, React should be able to restore the page in the same state.

My personal understanding is that when you leave the current page and jump back to the previous page, the state of React can be restored, instead of being completely lost as before, and the page is rendered from the initial state.

If my understanding is correct, without persisting state, you can write a lot less Redux code.

Available in DataFrame Suspense

Suspense is a new feature in testing, and it does the following:

React.Suspense

React.SuspenseA loading indicator can be specified in case some of its child components in the component tree are not yet ready to render. Currently, lazy loading components is the only use case <React.Suspense>supported :

// 该组件是动态加载的
const OtherComponent = React.lazy(() => import("./OtherComponent"));

function MyComponent() {
     
     
  return (
    // 显示 <Spinner> 组件直至 OtherComponent 加载完成
    <React.Suspense fallback={
     
     <Spinner />}>
      <div>
        <OtherComponent />
      </div>
    </React.Suspense>
  );
}

According to the content of the blog post:

In React 18, you can start using Suspense for data fetching in opinionated frameworks like Relay, Next.js, Hydrogen, or Remix. Ad hoc data fetching with Suspense is technically possible, but still not recommended as a general strategy.

It probably means that you can finally use React's built-in API to wait for the data to be fetched before rendering the page.

In other words, can write a lot less Redux-Saga code?

The server component is still in development

Server Components is also a new component currently under development.

After that, it should be possible to directly use React's built-in API for Server Side Rendering without Next.js?

What's new in React18

Automatic status update

Before v18, batch updating was performed in React event listeners, and Promise, setTimeout, JavaScript original event listeners did not package updates, but v18 will automatically listen to these events and automatically package updates to improve performance.

Transitions

This is a new feature, the main purpose is to distinguish between urgent updates (urgent updates) and non -urgent updates (non-urgent updates) .

The difference between the two is that urgent updates are when the user triggers an event, and they expect to receive immediate feedback, such as a click, input, etc. Non-urgent updates (AKA transition updates) are like UI transitions, etc.

So here are new hooks, developers can tell React which update is an urgent update (urgent updates) , so that once the state changes, the urgent update (urgent updates) can reset the content of the urgent update (urgent updates).

Suspense

It was briefly mentioned before, here is a code example:

<Suspense fallback={
    
    <Spinner />}>
  <Comments />
</Suspense>

While it is Commentstill loading, it Spinnerwill be rendered... You still have to hand on an example to understand how to use it.

New Client-to-Server Rendering API

The client has two new APIs, both react-dom/clientexported from to react-domreplace the API from :

  • createRootwill replace ReactDOM.render.
  • hydrateRootwill replaceReactDOM.hydrate

The server also has a new API, most likely to warm up the SSR later:

  • renderToPipeableStream, which can be streamed from a Node environment
  • renderToReadableStream, works in Deno and Cloudflare workers

New Strict Mode behavior

still in planning

new hooks

There are five:

Most of the new hooks are still in a stage of vague understanding, and it is better to take the time to type an example for a more in-depth understanding.

Guess you like

Origin blog.csdn.net/weixin_42938619/article/details/123840259