匆匆过客：React17
React17 新增个性：对使用者来说，无新个性, 官网原话：
The React 17 release is unusual because it doesn’t add any new developer-facing features. Instead, this release is primarily focused on making it easier to upgrade React itself.
事件零碎重构
作为一个 React 库深度使用者，我集体是特地喜爱这种 All In Js 的开发方式，整个页面逻辑都能够用 js 写，而不必 html 与 js 之间一直切换、互相设计；
但另一个重要的点就是开发过程不必思考事件的跨浏览器兼容问题，因为 React 曾经通过合成事件（SyntheticEvent）做了支流浏览器的兼容。
虽说应用形式大部分统一，但和原生事件并不完全相同, 差别在于：
- 事件节点的挂载机制，React 是采纳所有节点事件都挂载在 document 节点上，采纳事件委托与注册散发的机制实现；
- 事件触发机会不统一, 虽都听从向下捕捉向上冒泡，但合成事件会
晚一拍；具体表现就是，原生事件捕捉 -> 原生事件冒泡 -> react 事件捕捉 -> react 事件冒泡； - 回调事件的入参不一样，原生的就是事件对象，React 的则为合成事件对象，并且他本身有一个事件池专门来治理这些对象；
React 17 对事件零碎做了重构，其扭转点：
- 事件节点的挂载机制扭转，从 document 变为 root 节点，且这个变动不会造成 root 节点之外的 Portals 监听生效;
import React from 'react';
import ReactDOM from 'react-dom';
class Foo extends React.Component {enter(e){console.log('click foo');
e.stopPropagation();}
render() {return <div style={{ height: 30, background: 'blue'}} onClick={this.enter}>Foo</div>;
}
}
export default class Bar extends React.Component {enter(e){console.log('click bar'); }
componentDidMount() {ReactDOM.render(<Foo />, this.refs.c);
}
render() {return <div style={{ height: 50, background: 'red', color: 'white'}} onClick={this.enter}>Bar <div ref="c"/></div>;
}
}看下面的示例，页面 UI 如下图，如果是 17 以前，当咱们点击 Foo 区域时，冀望 Bar 区域不要响应，纵使加了 stopPropagation, 也不能阻止；但随着 17 的到来，这个 bug 就能够防止，这也是为 渐进式降级 做铺垫
- 事件回调机会和原生事件各自为政(这真的是个大晋升);
- SyntheticEvent 不再存入事件池，所以 e.persit()就不再失效;
承前启后
v17 开启了 React 渐进式降级的新篇章（稍微有点虚张声势）
17 当前，容许同一个页面上应用不同的 React 版本。依据官网的 demo 示例，是基于懒加载的个性实现，用法有点相似于 SPA 微利用的玩法。集体感觉这并没有黑魔法，如果不必二次加载，而冀望某个组件用独自的 react 版本，这该报错还是报错，就像上面这样：
所以通过理解后面两个个性，的确是印证官网那句话：17 只是为了给 18 及当前的版本铺路，为了让用户更简略的去降级版本
React18 新个性
主动批处理(Auto Bacthing)
批处理是 React 将多个状态更新分组到一个从新渲染中，以取得更好的性能（缩小 render 次数）。
在 React 18 以前，批处理更新只会产生在 React 事件回调中，而在 Promise、setTimeOut、原生事件回调或或任何其余事件外部的更新都没有采纳批处理，举个🌰：
// 18 以前: .
setTimeout(() => {setCount(c => c + 1);
setFlag(f => !f);
// render 2 次
}, 1000);
// 18 及当前:
setTimeout(() => {setCount(c => c + 1);
setFlag(f => !f);
// render1 次
}, 1000);绕过黑魔法：flushSync
自定义渲染优先级
在 react16 退出异步渲染时，提出了渲染优先级的概念，like: 用户输出 > 动画 > 列表展现。在多个渲染工作到来时，它会优先渲染高优先级的工作。
但因为这是一个现实的构想，程序本人是很难判断什么肯定是高优先级，因为用户应用场景太简单了；所以在 18 中，这个底层能力进一步凋谢，推出了几个 hooks：startTransition、useTransition、useDeferredValue 等，这些 hooks 能够让用户自定义渲染优先级
举个例子，输出搜寻框，直观点：
上面是伪代码，间接看 demo 演示间接一点：
import {startTransition} from 'react';
// 高优先级: 输出数据回显
setInputValue(input);
// 应用 Transition 对低优先级的渲染进行标记
startTransition(() => {setQuery(input);
});
官网的列子，我感觉对图形化的用户会更易感触，有趣味的能够理解一下：< 官网示例 >
所以最新版的 React 将 state 的更新分成了两类：
- 紧急更新（Urgent updates）将间接作用于用户交互，比方输出、点击等等
- 过渡更新（Transition updates）将 UI 从一个视图过渡到另一个视图
通过这些 hooks 咱们能够自定义渲染优先级。
新的入口挂载 API：createRoot
// 18 以前：import {render} from 'react-dom';
const container = document.getElementById('app');
render(<App tab="home" />, container);
// 18 当前：import {createRoot} from 'react-dom/client';
const container = document.getElementById('app');
const root = createRoot(container); //
root.render(<App tab="home" />);值得一提的是，18 对老的挂载形式也是兼容的，只是这种用法没法应用新个性(开发环境会提醒), 这也是渐进式降级的一部分
渐进式降级
官网原话：从技术上讲，并发渲染是一个突破性的降级。因为并发渲染是可中断的，所以启用它时组件的行为会略有不同，这个比例大略 0.2%.
所以官网为了大家更加顺滑的降级到 18，提出了 渐进式降级, 提供一个 StrictMode API，应用这个模块包裹的节点，将听从严格模式，这有助于：
- 辨认不平安的生命周期
- 应用过期字符串 ref API 的正告
- 应用废除的 findDOMNode 办法的正告
- 检测意外的副作用
- 检测过期的 context API
- 确保可复用的状态
上面的 demo, Header 和 Footer 将以失常模式渲染，而被 StrictMode 包裹的 Component 节点，将以严格模式渲染
import React from 'react';
function ExampleApplication() {
return (
<div>
<Header />
<React.StrictMode>
<div>
<ComponentOne />
<ComponentTwo />
</div>
</React.StrictMode>
<Footer />
</div>
);
}严格模式不能自动检测到你利用版本升级带来的副作用，仅能够帮忙发现它们，使它们更具确定性，通过 成心反复调用 一些申明函数来实现（具体请查看官网文档）
// 失常模式
* React mounts the component.
* Layout effects are created.
* Effects are created.
// 严格模式
* React mounts the component.
* Layout effects are created.
* Effect effects are created.
* React simulates effects being destroyed on a mounted component.
* Layout effects are destroyed.
* Effects are destroyed.
* React simulates effects being re-created on a mounted component.
* Layout effects are created
* Effect setup code runs虽说这个模块只在开发环境无效，但仔细的人会发现，反复的销毁和挂载他还是会带来新的问题，例如：
const [value, setValue] = useState(0);
useEffect(() => {setValue(val => val + 1);
})
// 失常模式打印的是 1，但严格模式这会打印 2;对于这个问题国内曾经有文章开始探讨，react 仓库也有一个 issue 是对于这个问题的探讨，感兴趣的能够戳这里。
浅析并发渲染
首先在说 react 渲染之前，温习一个知识点：浏览器中的 js 执行和 UI 渲染是在一个线程中程序产生(蕴含 js 执行，事件响应，定时器，UI 渲染)，且 js 的执行是单线程（基于 eventloop）。
这个单线程就决定了，解决 A 就解决不了 B。
有了这个共识，咱们来理一理 react 渲染史
同步渲染
最早的 react（16 之前）是同步的，就是指当用户通过 setState 触发一个更新，到更新渲染到页面，会经验两个过程：
- diff 阶段：会根节点开始 diff，找出更新前后 dom 树的差别；
- commit 阶段：依据 diff 的后果，更新 UI 到页面；
因为整个过程是同步的，会始终占据 js 线程；所以在一个更新的过程中，页面产生的点击、输出等交互事件都会期待，直到这次更新实现，显然这个体验是蹩脚的。
异步渲染
为了解决同步渲染阻塞主线程的问题，那就让渲染变的更加灵便 – 造成这些最大的问题不是性能，而是调度（React Conf 2018）。
基于此一个轰动前端圈的名词诞生 -Fiber，新的渲染架构最大的特点就是将以往一条路走到黑的玩法分成了两个阶段：
- render 阶段: 一个链表构造的工作链，是可打断的；
- commit 阶段: 就是把 UI 更新到界面的过程，这是同步的，不可打断的；
通过链表示意 render 阶段节点之间的关系，并加持工夫切片的形式，链表上节点是否持续向后比对，取决于以后线程是否闲暇; 并且 react 会将每个更新工作标注优先级，如果新的更新优先级高于正在解决的工作，那么前一次工作就会被打断废除，从而解决更高优先级的工作；
这里须要明确的是: 一旦一个更新工作被打断废除，高优先级工作执行完后，这个工作是须要从头再来一遍的计算的。
另一个要记住的点是，是先有 Fiber 再有 hooks，而不是 hooks 带来了 Fiber。
并发渲染
只有你读过 React18 的一些文章，你可能会听过 Concurrent Mode、Concurrent React 或者 Concurrent features, 这些名词都不重要，重要的是明确他的目标。
首先，先纠正一下大家听到异步渲染可能产生的一个谬误臆断：异步渲染不是指一个树的两个或多个分支同时被渲染。
动下脚指头想一想，这怎么可能，这自身就是与浏览器渲染原理就是相悖的。
官网原话：
Concurrency is not a feature, per se. It’s a new behind-the-scenes mechanism that enables React to prepare multiple versions of your UI at the same time.
multiple versions of your UI 圈起来，考试要考。
并发渲染胜利解决了异步渲染中中断废除的问题，他是中断可复原持续的；不过在一些场景，也会存在中断废除的问题。
这个能力，在当前也能解锁另一个应用场景：状态复用。比方一个 tab 切换，当从 a 切到 b，再从 b 切回 a 时，这时候通过某些实现，咱们就能够状态复用，疾速的在屏幕上展现出 a；
并发渲染带来的意义远不止这些（还包含对 server，native 端），我只捡了点我能看懂的分享给大家。反正官网写的十分美妙，我集体还是比拟期待。
举荐浏览：
- What is Concurrent React?
- React 的 Concurrent Mode 是否有适度设计的成分？
- React 并发渲染的前世今生
总结
通过对 react18 新个性的相熟及渲染模式的解说，让咱们能够感触到，这个版本将对咱们利用的体验将带来肉眼可见的晋升，前提是你不滥用，并且会用。
并且随着基于底层的一直裸露和并发模式一直的建设，当前可能咱们用的就不是 react，而是 Remix，Next 这种基于 react 库建设起来的生态框架，这也是 React 工作组成立起来的意义之一，更好的打造 React 生态。
很难设想，这竟然是是我 2022 年第一篇文章。往年全中国最迷茫的是中国经济，第二可能就是我了，但愿这是个转折！！！