React18新特性
React 团队在 2022 年 3 月 29 日正式发布了 React 的第 18 个版本。 在这篇文章里简单介绍 React 18 的新特性，React Concurrent Mode（并发模式）的实现，以及简要的升级指南。
New Features
Automatic Batching
早在 React 18 之前，React 就已经可以对 state 更新进行批处理了：
function App() {
const [count, setCount] = useState(0);
const [flag, setFlag] = useState(false);
function handleClick() {
setCount((c) => c + 1); // Does not re-render yet
setFlag((f) => !f); // Does not re-render yet
// React will only re-render once at the end (that's batching!)
}
return (
{count}
);
}上面这个例子中，用户点击按钮时会产生两次 state 的更新，按理来说每次 state 更新都会导致一次 re-render。但是，这两次更新完全可以合成一次，从而减少无谓的 re-render 带来的性能损失。
这种批处理只限于 React 原生事件内部的更新。
在 React 18 中，批处理支持处理的操作范围扩大了：Promise，setTimeout，native event handlers 等这些非 React 原生的事件内部的更新也会得到合并：
// Before: only React events were batched.
setTimeout(() => {
setCount((c) => c + 1);
setFlag((f) => !f);
// React will render twice, once for each state update (no batching)
}, 1000);
// After: updates inside of timeouts, promises,
// native event handlers or any other event are batched.
setTimeout(() => {
setCount((c) => c + 1);
setFlag((f) => !f);
// React will only re-render once at the end (that's batching!)
}, 1000);Transitions
Transitions 是 React 中一个用于区分高优更新和非高优更新的新概念。
-
高优的更新/渲染：包括鼠标点击、打字等对实时交互性要求很高的更新场景，卡顿时会影响用户的交互行为，使用户明显感到整个页面卡顿。
-
非高优的更新/渲染：普通的 UI 更新，不与用户的交互相关，一些对更新实时性要求没那么高的场景。
这里有一个 demo，上方是一个滑动条用于控制下方树的倾角，最顶上的扇区展示了当前的掉帧情况，当用户拉动滚动条时，下方的树的每一个节点都会重新渲染，这会带来明显的卡顿，不仅是下方树的渲染卡顿，上方的滚动条也会无法实时跟着用户的交互移动，这会给用户带来明显的卡顿感。
类似场景下常见的做法应该是 debounce 或 throttle ，React 18 为我们提供了原生的方式来解决这个问题：使用 starTransition 和 useTransition。
starTransition：用于标记非紧急的更新，用starTransition包裹起来就是告诉 React，这部分代码渲染的优先级不高，可以优先处理其它更重要的渲染。用法如下：
import { startTransition } from "react";
// Urgent
setSliderValue(input);
// Mark any state updates inside as transitions
startTransition(() => {
// Transition: Show the results, non-urgent
setGraphValue(input);
});- useTransition：除了能提供 starTransition 以外，还能提供一个变量来跟踪当前渲染的执行状态：
import { useTransition } from "react";
const [isPending, startTransition] = useTransition();
return isPending && 在勾选了 Use startTransition 后 ，滑动条的更新渲染不会再被树的渲染阻塞了，尽管树叶的渲染仍然需要较多的时间，但是用户使用起来不再有之前那么卡顿了。
Suspense
Suspense 是 React 提供的用于声明 UI 加载状态的 API：
上面这串代码里，组件 ComponentThatSuspends 在请求处理数据过程中，React 会在它的位置上展示 Loading 组件。
React 16 和 17 中也已经有 Suspense 了，但是它不是完全体，有许多功能仍未就绪。在 React 团队的计划中，Suspense 的完全体是基于 Concurrent React 的，所以在 React 18，Suspense 相较之前有了一些变化。
ComponentThatSuspends 的兄弟组件会被中断
还是上面那个例子：
-
Legacy Suspense 中，同级兄弟组件会立即挂载（mounted）到 DOM，相关的 effects 和生命周期会被触发，最后会隐藏这个组件。具体可以查看 代码示例。
-
Concurrent Suspense 中，同级兄弟组件并不会从 DOM 上卸载，相关的 effects 和生命周期会在 ComponentThatSuspends 处理完成时触发。具体可以查看 代码示例。
Suspense 边界之外的 ref
另一个差异是父级 ref 传入的时间：
-
在 Legacy Suspense 中，在渲染之初
refPassedFromParent.current立即指向 DOM 节点，此时ComponentThatSuspends还未处理完成。 -
在 Concurrent Suspense 中，在
ComponentThatSuspends完成处理、Suspense 边界解除锁定之前refPassedFromParent.current一直为 null。
也就是说，在父级代码中访问此类 ref 都需要关注当前 ref 是否已经指向相应的节点。
Suspense for SSR
React 18 之前的 SSR， 客户端必须一次性的等待 HTML 数据加载到服务器上并且等待所有 JavaScript 加载完毕之后再开始 hydration， 等待所有组件 hydration 后，才能进行交互。即整个过程需要完成从获取数据（服务器）→ 渲染到 HTML（服务器）→ 加载代码（客户端）→ 水合物（客户端）这一套流程。这样的 SSR 并不能使我们的完全可交互变快，只是提高了用户的感知静态页面内容的速度。
React 18 的 Suspense：
-
服务器不需要等待被 Suspense 包裹组件是否加载到完毕，即可发送 HTML，而代替 Suspense 包裹的组件是 fallback 中的内容，一般是一个占位符（spinner），以最小内联