关于react.js:React-18-带来了什么

41次阅读

共计 4300 个字符，预计需要花费 11 分钟才能阅读完成。

（因为当初 React18 还没正式公布太多的文档，很多概念和内容是我从多个起源拼凑而来，外面蕴含了很多我集体的了解，可能到 React18 正式公布的时候，会有些许谬误，写这个文章仅仅是满足一下好奇心理。所以如果你是在将来的某个工夫内看到这篇文章，你记得去浏览官网的内容，并以官网的内容为主。）

其实 React18@alpha 曾经公布有一段时间了，因为我最近分到一个调研 –
“UMI 如何反对 react@18 alpha”。（要不然，我应该会持续蹲。）

所以就开始看了看相干的文档和新闻。

比拟好的音讯是，你能够十分平滑的降级到 React18。

比方在 umi 中，抛开测试和兼容之类的代码，仅仅只须要批改一行代码就能够反对。

- import {hydrate, render} from 'react-dom';
+ import ReactDOM, {hydrate, render} from 'react-dom';
- if (window.g_useSSR) {- hydrate(rootContainer, rootElement, callback);
- } else {- render(rootContainer, rootElement, callback);
- }

+ reactRoot = (ReactDOM as any).createRoot(rootElement, {
+   hydrate: window.g_useSSR,
+ });

+ reactRoot.render(rootContainer);

并且改完从业务侧，页面代码中都无需做任何批改我的项目就能够失常的运行。
接着你就能够通过选择性的增加 React18 的新个性到你的某些新页面或者优化某些场景。

（看到这里不得不吐槽一下 React Native，发一个小版本都前后不兼容啊！）

开箱即用

当你简略的更改了相似下面的代码，你将间接享受到 React18 开箱即用的一些性能。

  • 主动批处理以缩小渲染
  • Suspense 的 SSR 反对（全新的 SSR 架构）

主动批处理以缩小渲染

批处理使 React 将多个状态更新分组到单个从新渲染中以取得更好的性能。这个个性在当初的 React17 中就曾经有了，然而在不同的上下文中交互的时候，将不反对批处理。当初 React18 中，减少了对网络申请，promise、setTimeout 等事件的主动批处理反对。

React17 – Updates inside of promises, setTimeout, native event handlers, or any other event were not batched in React by default.

function App() {const [count, setCount] = useState(0);
  const [flag, setFlag] = useState(false);

  function handleClick() {fetchSomething().then(() => {
      // React 18 and later DOES batch these:
      setCount(c => c + 1);
      setFlag(f => !f);
      // React will only re-render once at the end (that's batching!)
    });
  }

  return (
    <div>
      <button onClick={handleClick}>Next</button>
      <h1 style={{color: flag ? "blue" : "black"}}>{count}</h1>
    </div>
  );
}

Suspense 的 SSR 反对

之前在服务端渲染上对 Suspense 的反对不是很好，当初你能够通过应用新的 API pipeToNodeWritable 来应用全新的 SSR 架构。

比方咱们冀望最终关上的页面如下：（绿色代表用户可交互）


（图片来自 React18 工作组 discussions 37）

当你没有应用 SSR 性能时，咱们的页面都会在页面启动的时候，经验短暂的白屏阶段，这是因为此时浏览器发动了对 js 的申请和加载，页面之后期待这些 js 文件被下载实现之后，才会被执行，渲染出页面。

当应用 SSR 时，React 会在服务端将组件渲染成 Html 并发送给用户，此时用户将会看到页面的根本框架，只能进行一些内置 Web 交互（如链接和表单输出）。


（此处，灰色阐明屏幕的这些局部尚未齐全交互）

之后浏览器照常加载 js 文件，当 js 文件加载实现之后，通过水合过程，将以后的 html 渲染成可交互的。

这个过程的专业名词是“Hydrate”，在 vue 中被翻译成“激活”，React 社区更冀望称之为“水合”或者“注水”来形容这个过程，就相当于将“水”注入到“干”的 Html 中。

这里也存在一个和不应用 SSR 一样的问题，当 js 被全副加载，页面组件被全副“水合”之前，页面钻研是不可交互的。React18 就反对，让局部的页面优先加载完数据，优先执行水合。你的页面看起来大略是这样子的。

并发渲染（concurrent rendering）

当然你也能够选择性的应用 React18 的一些新性能，React18 退出了一个次要的可选机制，“并发渲染（concurrent rendering）”，这个是很多新性能的根底。
值得注意的是这里的“并发”应用的仍旧是单线程。然而这个单线程能够被中断的。因而渲染能够在多个渲染工作之间交织进行，如用户交互，网络申请，计时器，动画和浏览器布局 / 绘制等等。
它的次要工作调配大抵如下：

当渲染工作遭逢到更高级的渲染工作时将会被中断，而后优先执行优先级更高的工作，再工作实现之后，再回到原来的渲染工作上。

你能够通过一下一些新的 API 来通知 React 哪些是优先级较高的工作。

  • startTransition
  • useDeferredValue
  • SuspenseList

startTransition 过渡更新

这是一个比拟好了解的 API，通过应用 startTransition 来包裹一些 setState，申明他们是比拟不重要的渲染行为。比方官网的例子外面提到的搜寻场景。

当用户在搜寻框中输出时，搜寻框须要实时的显示用户的输出字符，而后通过网络申请（或者本地过滤数据），获取到新的列表数据，再更新列表。这外面会有两个 setState，一个是 input 的 value 绑定。一个是搜寻之后的页面数据绑定。

import {startTransition} from 'react';


// 紧急：显示输出的内容
setInputValue(input);

// 将外部的任何状态更新标记为转换
startTransition(() => {
  // Transition: 显示后果
  setSearchQuery(input);
});

如果你须要在期待过渡渲染的时候执行一些体现，如 loading 操作之类的。
你能够应用 useTransition

import {useTransition} from 'react';


const [isPending , startTransition] = useTransition();
startTransition(() => {
  // Transition: 显示后果
  setSearchQuery(input);
});

{isPending  &&  < Spinner />}

useDeferredValue

推延更新屏幕上不太重要的局部（这个还没有放进去文档）。

SuspenseList

协调加载指示器呈现的程序（这个还没有放进去文档）。

然而从 Suspense 的用法来看，预计与懒加载的优先级无关，可能是指定哪些加载优先执行。（我猜的，毕竟新的文档简直都是这个概念。）

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

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

其余

除了下面提到的这些和合作多任务、基于优先级的渲染、调度和中断等无关的性能之外，还有值得关注的个性。

StrictMode 严格模式

你的组件将会被屡次调用加载 - 卸载，以确保他们的状态正确。

React intentionally double-invokes effects (mount -> unmount -> mount) for newly mounted components.

值得关注的是，这个个性是被默认开启的，其实当初的 React 中就曾经有应用这个性能了。— 疾速刷新（Fast Refresh），开发时能够放弃组件状态，同时编辑提供即时反馈。

Offscreen

新的 Offscreen API 容许 React 通过暗藏组件而不是卸载组件来放弃这样的状态。为此，React 将调用与卸载时雷同的生命周期钩子——但它也会保留 React 组件和 DOM 元素的状态。这就是 React 中的 keepalive 性能啊。

这是我所期待的一个能力，当初是应用 <div hidden={true} /> 实现。

当然它还能够用作预渲染页面，提前渲染用户行将达到的页面，有点相似 Next 中用 Link 链接的页面，会被提前渲染。

在优先级方面，Offscreen 是最低的，实践上它会被任何其余的渲染工作中断。

it will not be in the initial 18.0 release, but may come in an 18.x minor.

感激浏览，有任何疑难能够通过评论一起探讨。喜爱这个文章的敌人，请给一个赞，喜爱我的敌人，能够关注一下我。感激三连。

参考链接

https://zh-hans.reactjs.org/blog/2021/06/08/the-plan-for-react-18.html
https://github.com/reactwg/react-18/discussions/4
https://github.com/reactwg/react-18/discussions/21
https://github.com/reactwg/react-18/discussions/22
https://github.com/reactwg/react-18/discussions/27
https://github.com/reactwg/react-18/discussions/37
https://www.youtube.com/watch?v=bpVRWrrfM1M

正文完
react.js
发表至： react.js
2021-06-25
 0
关于react.js:React-组件的生命周期
关于react.js:React性能优化之memouseMemouseCallback的使用与区别
关于react.js:react高频知识点梳理
图片轮播预览