React 17 要来了,非常特别的一版

React 17 要来了,非常特别的一版

关注「前端向后」微信公众号,你将收获一系列「用原创」的高质量技术文章,主题包括但不限于前端、Node.js以及服务端技术

写在前面

React 最近发布了v17.0.0-rc.0,距上一个大版本v16.0(发布于 2017/9/27)已经过去近 3 年了

与新特性云集的 React 16及先前的大版本相比,React 17 显得格外特殊——没有新特性

React v17.0 Release Candidate: No New Features

不仅如此,还带上来了 7 个 breaking change……

一.真没有新特性?

React 官方对 v17 的定位是一版技术改造,主要目标是降低后续版本的升级成本

This release is primarily focused on making it easier to upgrade React itself.

因此 v17 只是一个铺垫,并不想发布重大的新特性,而是为了 v18、v19……等后续版本能够更平滑、更快速地升上来:

When React 18 and the next future versions come out, you will now have more options.

但其中有些改造不得不打破向后兼容,于是提出了 v17 这个大版本变更,顺便搭车卸掉两年多积攒的一些历史包袱

二.渐进式升级成为了可能

在 v17 之前,不同版本的 React 无法混用(事件系统会出问题),所以,开发者要么沿用旧版本,要么花大力气整个升级到新版本,甚至一些常年没有需求的长尾模块也要整体适配、回归测试。考虑到开发者的升级适配成本,React
维护团队同样束手束脚,废弃 API 不敢轻易下掉,要么长时间、甚至无休止地维护下去,要么选择放弃那些老旧的应用

而 React 17 提供了一个新的选项——渐进式升级,允许 React 多版本并存,对大型前端应用十分友好,比如弹窗组件、部分路由下的长尾页面可以先不升级,一块一块地平滑过渡到新版本(参考官方 Demo)

P.S.注意,(按需)加载多个版本的 React 存在着不小的性能开销,同样应该慎重考虑

多版本并存与微前端架构

多版本并存、新旧混用的支持让微前端架构所期望的渐进式重构成为了可能:

渐进地升级、更新甚至重写部分前端功能成为了可能

与 React 支持多版本并存、渐进地完成版本升级相比,微前端更在意的是允许不同技术栈并存,平滑地过渡到升级后的架构,解决的是一个更宽的问题

另一方面,当 React 技术栈下多版本混用难题不复存在时,也有必要对微前端进行反思:

  • 一些问题是不是由技术栈自身来解决更为合适?

  • 多技术栈并存是常态还是短期过渡?

  • 对于短期过渡,是否存在更轻量的解决方案?

关于微前端在解决什么问题的更多思考,见Why micro-frontends?

三.7 个 Breaking change

事件委托不再挂到 document 上

之前多版本并存的主要问题在于React 事件系统默认的委托机制,出于性能考虑,React 只会给document挂上事件监听,DOM 事件触发后冒泡到document,React 找到对应的组件,造一个 React 事件(SyntheticEvent)出来,并按组件树模拟一遍事件冒泡(此时原生 DOM 事件早已冒出document了):

React 17 要来了,非常特别的一版

react 16 delegation

因此,不同版本的 React 组件嵌套使用时,e.stopPropagation()无法正常工作(两个不同版本的事件系统是独立的,都到document已经太晚了):

If a nested tree has stopped propagation of an event, the outer tree would still receive it.

P.S.实际上,Atom 在早些年就遇到了这个问题

为了解决这个问题,React 17 不再往document上挂事件委托,而是挂到 DOM 容器上

React 17 要来了,非常特别的一版

react 17 delegation

例如:

const rootNode = document.getElementById('root');
// 以为 render 为例
ReactDOM.render(<App />, rootNode);
// Portals 也一样
// ReactDOM.createPortal(<App />, rootNode)
// React 16 事件委托(挂到 document 上)
document.addEventListener()
// React 17 事件委托(挂到 DOM container 上)
rootNode.addEventListener()

另一方面,将事件系统从document缩回来,也让 React 更容易与其它技术栈共存(至少在事件机制上少了一些差异)

向浏览器原生事件靠拢

此外,React 事件系统还做了一些小的改动,使之更加贴近浏览器原生事件:

  • onScroll不再冒泡

  • onFocus/onBlur直接采用原生focusin/focusout事件

  • 捕获阶段的事件监听直接采用原生 DOM 事件监听机制

注意,onFocus/onBlur的下层实现方案切换并不影响冒泡,也就是说,React 里的onFocus仍然会冒泡(并且不打算改,认为这个特性很有用)

DOM 事件复用池被废弃

之前出于性能考虑,为了复用 SyntheticEvent,维护了一个事件池,导致 React 事件只在传播过程中可用,之后会立即被回收释放,例如:

<button onClick={(e) => {
console.log(e.target.nodeName);
// 输出 BUTTON
// e.persist();
setTimeout(() => {
// 报错 Uncaught TypeError: Cannot read property 'nodeName' of null
console.log(e.target.nodeName);
});
}}>
Click Me!
</button>

传播过程之外的事件对象上的所有状态会被置为null,除非手动e.persist()(或者直接做值缓存)

React 17 去掉了事件复用机制,因为在现代浏览器下这种性能优化没有意义,反而给开发者带来了困扰

Effect Hook 清理操作改为异步执行

useEffect本身是异步执行的,但其清理工作却是同步执行的(就像 Class 组件的componentWillUnmount同步执行一样),可能会拖慢切 Tab 之类的场景,因此 React 17 改为异步执行清理工作:

useEffect(() => {
// This is the effect itself.
return () => {
// 以前同步执行,React 17之后改为异步执行
// This is its cleanup.
};
});

同时还纠正了清理函数的执行顺序,按组件树上的顺序来执行(之前并不严格保证顺序)

P.S.对于某些需要同步清理的特殊场景,可换用LayoutEffect Hook

render 返回 undefined 报错

React 里 render 返回undefined会报错:

function Button() {
return; // Error: Nothing was returned from render
}

初衷是为了把忘写return的常见错误提示出来

function Button() {
// We forgot to write return, so this component returns undefined.
// React surfaces this as an error instead of ignoring it.
<button />;
}

在后来的迭代中却没对forwardRefmemo加以检查,在 React 17 补上了。之后无论类组件、函数式组件,还是forwardRefmemo等期望返回 React 组件的地方都会检查undefined

P.S.空组件可返回null,不会引发报错

报错信息透出组件“调用栈”

React 16 起,遇到 Error 能够透出组件的“调用栈”,辅助定位问题,但比起 JavaScript 的错误栈还有不小的差距,体现在:

  • 缺少源码位置(文件名、行列号等),Console 里无法点击跳转到到出错的地方

  • 无法在生产环境中使用(displayName被压坏了)

React 17 采用了一种新的组件栈生成机制,能够达到媲美 JavaScript 原生错误栈的效果(跳转到源码),并且同样适用于生产环境,大致思路是在 Error 发生时重建组件栈,在每个组件内部引发一个临时错误(对每个组件类型做一次),再从error.stack提取出关键信息构造组件栈:

var prefix;
// 构造div等内置组件的“调用栈”
function describeBuiltInComponentFrame(name, source, ownerFn) {
if (prefix === undefined) {
// Extract the VM specific prefix used by each line.
try {
throw Error();
} catch (x) {
var match = x.stack.trim().match(/n( *(at )?)/);
prefix = match && match[1] || '';
}
} // We use the prefix to ensure our stacks line up with native stack frames.

return 'n' + prefix + name;
}
// 以及 describeNativeComponentFrame 用来构造 Class、函数式组件的“调用栈”
// ...太长,不贴了,有兴趣看源码

因为组件栈是直接从 JavaScript 原生错误栈生成的,所以能够点击跳回源码、在生产环境也能按 sourcemap 还原回来

P.S.重建组件栈的过程中会重新执行 render,以及 Class 组件的构造函数,这部分属于 Breaking change

P.S.关于重建组件栈的更多信息,见Build Component Stacks from Native Stack Frames、以及react/packages/shared/ReactComponentStackFrame.js

部分暴露出来的私有 API 被删除

React 17 删除了一些私有 API,大多是当初暴露给React Native for Web使用的,目前 React Native for Web 新版本已经不再依赖这些 API

另外,修改事件系统时还顺手删除了ReactTestUtils.SimulateNative工具方法,因为其行为与语义不符,建议换用React Testing Library

四.总结

总之,React 17 是一个铺垫,这个版本的核心目标是让 React 能够渐进地升级,因此最大的变化是允许多版本混用,为将来新特性的平稳落地做好准备

We’ve postponed other changes until after React 17. The goal of this release is to enable gradual upgrades.

参考资料

  • React v17.0 Release Candidate: No New Features

联系我
     

如果心中仍有疑问,请查看原文并留下评论噢。(特别要紧的问题,可以直接微信联系 ayqywx

在比特币日报读懂区块链和数字货币,加入Telegram获得第一手区块链、加密货币新闻报道。

Click to rate this post!
[Total: 0 Average: 0]

人已赞赏
Dapp开发小白百科

Flutter 1.22 发布 | 支持 iOS 14 和 Android 11,以及更多新功能

2020-10-10 11:59:57

Dapp开发

React17 之Fiber中的Slot

2020-10-21 13:42:10

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
有新消息 消息中心
搜索