我读《深入浅出React技术栈》之setState源码解析
最近双11双12各种需求交杂在一起，忙得不可开交，近期好不容易空了一些下来，读完了《深入浅出React技术栈》，这本书的内容和书名如出一辙，重点在于介绍使用React过程中相关的一些技术点，例如函数式编程、Redux、React核心的diff算法的思想等相关东西，东西还是蛮多的，适合想要一窥react技术栈全貌的同学，所以这次写一下自己读完这本书的思考和部分精华内容摘记。
this.setState
this.setState相信是大家在写React时写的最多的代码，但这里面到底都发生了什么？为什么setState可以是异步的？React是如何实现异步的呢？为什么不能在componentWillUpdate和shouldComponetUpdate中调用setState。让我们来一探究竟。
在弄清楚setState之前，首先我们要知道的是React的生命周期，示意图如下：
这里我们可以注意到，为什么在componentWillUpdate和shouldComponentUpdate 中是没有见到setState的身影呢？
首先我们看下setState的源码：
这其中该方法传入两个参数partialState是新的state值，callBack后者是回调函数，updater是在构造函数中定义的一个变量，从方法名enqueueSetState中我们可以明白，传入的新的state被enqueue推入了一个栈中，并不是立即更新，随后我们继续跟踪代码。
getInternalInstanceReadyForUpdate方法获取了当前组件对象，并将其赋给internalInstance。接下来判断当前组件对象的state是否存在更新队列，若存在则把新的state值push到队列中，若不存在，则创建一个空的新队列。
这里的代码也很好理解，首先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方法
我们看到这里dirtyComponents数组会进行一个排序操作，这里因为通常情况下，父组件更新后，子组件也会随之更新，所以这里进先进行排序，使得子组件在父组件之前被更新，同时将setState中传入的回调函数存入callbackQueue队列中，且performUpdateIfNecessary方法中执行了updateComponent方法，让我们看看这个方法都做了什么。
接下来我们重点看下这个_processPendingState方法：
这个函数对state的做法就比较简明扼要了，它主要做了以下几件事：
- 如果更新队列为
null，那么返回原来的state； - 如果更新队列有一个更新值，那么返回更新值；
- 如果更新队列有多个更新，那么通过for循环将它们合并；
也就是说，在一个生命周期所有的state变化都会被合并，并统一处理。接下来我们看看performUpdate做了什么，这个函数的功能其实也简单，就是在更新组件前后分贝执行componentWillUpdate和componentDidUpdate。而在负责更新的_updateRenderedComponent函数中，我们根据传入的新旧组件信息判断是否进行更新。若返回值为true，执行旧组件的更新，否则的话执行旧组件的卸载和新组件的挂载。
整个流程图如下：
看完了这个，那么对于开头的“为什么不能在componentWillUpdate和shouldComponetUpdate中调用setState”问题我们就可以进行解释了
也就是说，组件更新时，state值还没有合并，则this._pendingStateQueue为true，使得setState会再次调用updateComponent，随后继续调用componentWillUpdate和shouldComponetUpdate方法，导致死循环，而正常情况下，已经更新过的组件不会进入再次更新的流程。
看完了这些，那么我们再看一道经典的关于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;
}
}这道题的输出是：
0 0 2 3
这里简单来说，前2个setState处于一个事务中，所以不会立即更新，而是做了合并，所以前2次log都是0，而当setTimeout被执行时，因为主线程执行完毕，已经完成了一次事务，此时是不会触发事务状态的，所以这时就是调用一次setState就更新一次状态。
这也就解释了为什么React文档中既没有说setState是同步更新或者是异步更新，它只是说setState并不保证同步更新。这里引用一下React的核心成员Dan Abramov的一个回答来继续做一点引申。
谢谢大家。：）