React要更新，就像渣男会变心

港控/mmm° 2022-10-10 14:56 112阅读 0赞

今天和同事聊天，我说他是个铁憨憨，不会和女生聊天。

他啪的一下跳起来，“我可懂情调了”

“哦？那你来句土味情话。”

他清清嗓子，压低了腔调，望向远方，缓缓道：

> 如果我是`component`，我对你的情愫在`didMount`时燃起，直到我生命`unmount`时熄灭

正当他沉浸在YY的世界无法自拔时，我说：

> 你知道在`React18`，`componentDidMount`和`componentWillUnmount`可能调用多次么？

![dbc40083fdf149742086cf63862c7df9.png][]

呵，渣男！

## 从Strict Mode谈起 ##

`React`有个特性 —— `Strict Mode`，被`StrictMode`包裹的组件在`DEV`环境会对不推荐写法有更严格的提示与辅助检测行为。

**「辅助检测行为」**是指部分方法会被`React`重复调用，帮助开发者更容易发现不规范使用这些方法时的潜在`bug`。

> 所有会被重复调用的API见StrictMode文档\[1\]

举个例子：

function App() {
      const [num, update] = useState(0);
    
      function onClick() {
        update(num + 1);
      }
    
      console.log('render');
    
      return (
        <p onClick={onClick}>{num}</p>
      );
    }

当`App`被`StrictMode`包裹，点击`p`触发更新后，`App`组件会`render`两次。

> 在`v17`之前，例子中`console.log`会执行两次。但在`v17`之后，`React`覆写了`console`方法，所以`console.log`只会执行一次，但组件实际会`render`两次

这么做的目的是：作为函数组件，`App`的**「副作用」**应该在`useEffect`回调中执行。

如果不规范书写副作用（比如在组件函数体内写副作用），那么重复`render`更容易暴露可能产生的`bug`。

铺垫完背景。接下来，让我们揭露`React`善变的渣男行径。

![5fae8bee63156c24156b7d86ee5b26e6.png][]

最近刷`v18`讨论组时突然发现：`StrictMode`中会增加一条`Strict Effect`规则。

![99c7b32a3fe55948644dcc0a4bcb6590.png][] ![57b876d6903507e187511ae7a6455268.png][]

## Strict Effect ##

简单的说，类似上文讲到的部分`API`在`StrictMode`下会重复执行。

`Strict Effect`规则会让`useEffect`、`useLayoutEffect`在`StrictMode`下也会重复执行。

比如：

function App() {
      // 或useLayoutEffect
      useEffect(() => {
        // 逻辑1
        return () => // 逻辑2;
      }, [])
      
      // ...
    }

在当前`React`中，组件`mount`时，执行逻辑1。

而在`Strict Effect`规则下，`mount`时的逻辑如下：

*  组件`mount`时，执行逻辑1
 *  `React`模拟组件`unmount`，执行逻辑2
 *  `React`模拟组件`mount`，执行逻辑1

注意，这里`useEffect`的依赖项是`[]`，在以往的认知里，依赖项为**「空数组」**意味着该`useEffect`逻辑只会在`mount`时执行一次。

而在`v18`的`Strict Mode`，由于包含了`Strict Effect`规则，`mount`时的`useEffect`逻辑会被重复执行。

![a996fce454fd553d95f04640f3d6742f.png][]

某种程度上讲，这种打破开发者既有认知的`Breaking Change`，比`Concurrent Mode`更让人难以接受。

那么`React`团队为什么要设计这条规则呢？

## 一切为了Offscreen ##

`Offscreen`是一个开发中的`API`，预计会在某个`v18`的小版本发布。

他的功能类似`Vue`中的`keep-alive`，用来在组件**「失活」**时在后台保存组件状态。

举个`Tab`切换的例子，在`Posts`和`Archive`之间切换`Tab`：

![5896ea764eff99acb2b6d206f90ab2e3.png][]

当切换到`Posts`时，`Archive`属于**「失活」**状态。

如果不需要保存状态，则销毁`Archive`组件。当切换到`Archive Tab`时，再重新`mount Archive`。

当需要保存状态时，只能将`Posts`与`Archive`的状态保存在他们的父组件或状态管理（比如`Redux`）中。

而有了`Offscreen API`，在`Fiber`树（可以理解为虚拟`DOM`树）层面，可以保存失活的组件结构与状态。

这个`API`的应用场景主要包括：

*  切换路由时保存之前路由的状态
 *  预加载将要切换的路由

现在问题来了：当`Offscreen`组件从**「失活」**变为**「活动」**，会触发什么生命周期函数呢？

答案是：`componentDidMount`以及：

useEffect(() => {
       // 触发这个逻辑...
    }, [])

当`Offscreen`组件从**「活动」**变为**「失活」**时，会触发`componentWillUnmount`与：

useEffect(() => {
       // ...
       return () => {
         // 触发这个逻辑...
       }
    }, [])

所以，这些曾经被认为在组件生命周期中只会触发一次的方法，由于`Offscreen`，在未来可能会多次触发。

这也是`React`提前在`StrictMode`中加上`Strict Effect`规则的原因。

就像渣男变心前都会有些反常的举动。

![836408671dbf07beb4256a1770eeadcb.png][]

## React18是真的挑战 ##

不管是`Offscreen`还是`Concurrent Mode`，可以预见随着`v18`的到来，`React`会更强大，相应的学习曲线会更陡峭。

这既是机遇，也是挑战。

千万别等变化一股脑到眼前时再埋怨：

你个渣男，当初说好一心一意只会触发一次，现在为了妖艳新特性，背叛我们的诺言。

![65dfd8cac8c17c81afbdd1e76ff29415.png][]

到那时`React`只会拍拍屁股转身，留下不羁的背影：

![b18c4a0c4ede73322a079471ebf96891.png][]

### 参考资料 ###

\[1\]

StrictMode文档: https://zh-hans.reactjs.org/docs/strict-mode.html\#detecting-unexpected-side-effects

[dbc40083fdf149742086cf63862c7df9.png]: /images/20221005/de5697c2d4734c13af96a52210259faf.png
[5fae8bee63156c24156b7d86ee5b26e6.png]: /images/20221005/238758c2a49c449193c642bf49ffc354.png
[99c7b32a3fe55948644dcc0a4bcb6590.png]: https://img-blog.csdnimg.cn/img_convert/99c7b32a3fe55948644dcc0a4bcb6590.png
[57b876d6903507e187511ae7a6455268.png]: /images/20221005/9bd64266a3a64b928a617803ee6526e8.png
[a996fce454fd553d95f04640f3d6742f.png]: /images/20221005/63ac079f22f442e98ca4a0362677f034.png
[5896ea764eff99acb2b6d206f90ab2e3.png]: /images/20221005/2c47ca077bf14689a786646e93a7c8d4.png
[836408671dbf07beb4256a1770eeadcb.png]: /images/20221005/0dac87ad18c74479ad1cbf2b5ac49a92.png
[65dfd8cac8c17c81afbdd1e76ff29415.png]: /images/20221005/9e0a20926bca40b9a2459c56c2a7e7ff.png
[b18c4a0c4ede73322a079471ebf96891.png]: /images/20221005/1acd8be2302a4bbdbcc62056c054795d.png