我读《深入浅出React技术栈》之setState源码解析

最新推荐文章于 2024-08-07 09:56:43 发布

王和阳

最新推荐文章于 2024-08-07 09:56:43 发布

阅读量1.5k

点赞数 2

分类专栏：前端开发文章标签： React 源码 setState

本文链接：https://blog.csdn.net/as645788/article/details/84871930

版权

前端开发专栏收录该内容

11 篇文章 0 订阅

订阅专栏

本文深入探讨React技术栈，包括函数式编程、Redux、React的diff算法等关键知识点。解析setState的工作原理，阐述其异步特性及在React生命周期中的作用。通过源码分析，揭示React如何避免不必要的组件更新，以及事务在组件更新过程中的应用。

摘要由CSDN通过智能技术生成

最近双11双12各种需求交杂在一起，忙得不可开交，近期好不容易空了一些下来，读完了《深入浅出React技术栈》，这本书的内容和书名如出一辙，重点在于介绍使用React过程中相关的一些技术点，例如函数式编程、Redux、React核心的diff算法的思想等相关东西，东西还是蛮多的，适合想要一窥react技术栈全貌的同学，所以这次写一下自己读完这本书的思考和部分精华内容摘记。

this.setState

this.setState相信是大家在写React时写的最多的代码，但这里面到底都发生了什么？为什么setState可以是异步的？React是如何实现异步的呢？为什么不能在componentWillUpdate和shouldComponetUpdate中调用setState。让我们来一探究竟。

在弄清楚setState之前，首先我们要知道的是React的生命周期，示意图如下：

这里我们可以注意到，为什么在componentWillUpdate和shouldComponentUpdate 中是没有见到setState的身影呢？

首先我们看下setState的源码：
setState源码

这其中该方法传入两个参数partialState是新的state值，callBack后者是回调函数，updater是在构造函数中定义的一个变量，从方法名enqueueSetState中我们可以明白，传入的新的state被enqueue推入了一个栈中，并不是立即更新，随后我们继续跟踪代码。

getInternalInstanceReadyForUpdate方法获取了当前组件对象，并将其赋给internalInstance。接下来判断当前组件对象的state是否存在更新队列，若存在则把新的state值push到队列中，若不存在，则创建一个空的新队列。
enquueUpdate
这里的代码也很好理解，首先ensureInjected方法检查当前运行的代码是否处在一个事务（reconcile transaction）中，若不是则会抛出错误。且若batchingStrategy.isBatchingUpdates为false（可以简单理解为当前不是在一个批处理流程中），则进行batchedUpdates（批量更新），若为true，则推入dirtyComponents中，接下来我们跟踪并看下batchingStrategy的源码。

至于为什么要做batchUpdates（批量更新），用React自己的话来说，是“为了避免组件被不必要地更新”，而且在这里我们可以看到，React更新组件是有一套自己的规则，通过组件的状态来执行，查阅资料后得知，React内部存在着"状态机"这个概念，也就是说当组件处于不同的状态时，所执行的逻辑是不同的。具体来说，React以事务+状态的方法来对组件进行更新，那么，到底什么是事务呢？

事务

下面这张图来源于React官方源码对事务的解释：

从图上我们看到，其实Transaction事务说白了就是在不改变原有方法的基础上，在执行方法的前后进行额外的操作。具体来说，就是一个方法会被wrapper包裹，且方法需要通过perform来调用，且在被包裹方法的前后分别执行initialize和close。下面我们看代码，举例说明普通函数和被wrapper包裹的函数执行时有什么不同：

function test(){
    console.log('test')
};
transaction.perform(test);
//执行initialize方法
//输出'test'
//执行close方法

这里可能有的人会有疑问，为什么React要引入Transaction事务这个概念呢？其实Transaction事务这个概念来源于面向切面编程，举个简单例子，有时候我们在做真正的业务之前，经常需要进行验证，授权，或者输出日志的操作，也就是在主要的逻辑代码之前或者之后插入一些代码，但我们又不希望对原有的代码做侵入，这时候就是Transaction发挥作用的时刻了。
对于React来说，主要有以下几个应用场景（文字翻译自React源码）：

在Reconciliation调和之前/之后保留输入选择范围。即使出现意外错误也可以恢复这个选择。
在重新排列DOM时停用事件，同时确保事后事件能被重新激活。

说了这么多关于事务的事儿，接下来让我们看下ReactDefaultBatchingStrategy中的transaction是如何实现的

我们可以看到这里定义了2个wrapper，其中RESET_BATCHED_UPDATES负责在close阶段重置ReactDefaultBatchingStrategy的isBatchingUpdates为false。而FLUSH_BATCHED_UPDATES负责在close执行flushBatchedUpdates，在这个方法里包含了Virtual DOM到真实DOM的映射等其他操作，且此方法会清空dirtyComponents数组并执行runBatchedUpdate方法
runBatchedUpdates

我们看到这里dirtyComponents数组会进行一个排序操作，这里因为通常情况下，父组件更新后，子组件也会随之更新，所以这里进先进行排序，使得子组件在父组件之前被更新，同时将setState中传入的回调函数存入callbackQueue队列中，且performUpdateIfNecessary方法中执行了updateComponent方法，让我们看看这个方法都做了什么。
updateComponents

接下来我们重点看下这个_processPendingState方法：

这个函数对state的做法就比较简明扼要了，它主要做了以下几件事：

如果更新队列为null，那么返回原来的state；
如果更新队列有一个更新值，那么返回更新值；
如果更新队列有多个更新，那么通过for循环将它们合并；

也就是说，在一个生命周期所有的state变化都会被合并，并统一处理。接下来我们看看performUpdate做了什么，这个函数的功能其实也简单，就是在更新组件前后分别执行componentWillUpdate和componentDidUpdate。而在负责更新的_updateRenderedComponent函数中，我们根据传入的新旧组件信息判断是否进行更新。若返回值为true，执行旧组件的更新，否则的话执行旧组件的卸载和新组件的挂载。

整个流程图如下：
整体流程

看完了这个，那么对于开头的“为什么不能在componentWillUpdate和shouldComponetUpdate中调用setState”问题我们就可以进行解释了

也就是说，组件更新时，state值还没有合并，则this._pendingStateQueue为true，使得setState会再次调用updateComponent，随后继续调用componentWillUpdate和shouldComponetUpdate方法，导致死循环，而正常情况下，已经更新过的组件不会进入再次更新的流程。
performUpdateIfNecessary

看完了这些，那么我们再看一道经典的关于setState的题目：

class Test extends Component {
  state = { val: 0 }

componentDidMount() {
    this.setState({ val: this.state.val + 1 }); 
    console.log(this.state.val); 
    
    this.setState({ val: this.state.val + 1 }); 
    console.log(this.state.val); 
    
    setTimeout(() => {
      this.setState({ val: this.state.val + 1 }); 
      console.log(this.state.val); 
      
      this.setState({ val: this.state.val + 1 }); 
      console.log(this.state.val); 
    }, 0);
  }

  render() {
    return null;
 }
}