时间：2020-09-24
背景
class Example extends React.Component {
constructor() {
super();
this.state = { foods: '' };
}componentDidMount() {
this.setState({foods: 'apple'});
console.log(this.state.foods); // 第 1 次 log
this.setState({foods: 'pine'});
console.log(this.state.foods); // 第 2 次 log
setTimeout(() => {
this.setState({foods: 'apple1'});
console.log(this.state.foods); // 第 3 次 log
this.setState({foods: 'pine1'});
console.log(this.state.foods); // 第 4 次 log
}, 0);
}render() {
return null;
}
};
问题汇总：
1. 运行结果，为什么？
2. render函数中, 可以setState吗?
3. componentWillMount里面setState()会不会触发重新渲染？
4. 什么是批量更新策略？
5. 什么是事务transaction?
。。。
源码分析
react源码地址： https://github.com/facebook/react/tree/35962a00084382b49d1f9e3bd36612925f360e5b/src
说明： 这里updater是通过依赖注入的方式，在组件实例化的时候注入进来的。partialState: 新的state值; callback: 回调函数。
说明：getInternalInstanceReadyForUpdate方法的目的是获取当前组件对象，将其赋值给internalInstance变量。接下来判断当前组件对象的state更新队列是否存在，如果存在则将partialState也就是新的state值加入队列；如果不存在，则创建该对象的更新队列。然后进入enqueueUpdate方法。
说明：enqueueCallback也是先获取当前组件对象，如果已经存在其他回调，就加入等待回调队列，如果当前没有回调，就创建等待回调队列。然后进入enqueueUpdate方法。
可以发现,enqueueSetState&enqueueCallback最终都是进入enqueueUpdate方法。下面我们来看看enqueueUpdate方法。
官方注解是：给组件做个标记：需要重新渲染，并且将可选的回调函数添加到函数列表中，这些函数将在重新渲染的时候执行。
说明：如果batchingStrategy.isBatchingUpdates为false,就执行batchingStrategy.batchedUpdates(enqueueUpdate,component)，否则就加入dirtyComponents。这里提到batchingStrategy，批量更新策略。
说明：批量更新策略是什么呢？看代码发现batchingStrategy批量更新策略只是一个简单的对象，定义了一个 isBatchingUpdates 的布尔值和一个 batchedUpdates 方法。默认isBatchingUpdates(下面称为更新标志)为false,然后会进入batchedUpdates方法，先把更新标志isBatchingUpdates设为true，然后执行transaction.perform(callback)，即transaction.perform(enqueueUpdate)。
React内部采用了"状态机"的概念，组件处于不同的状态时，所执行的逻辑也并不相同。以组件更新流程为例，React以事务+状态的形式对组件进行更新。
重点：transaction
小结： 通过上面的一部分代码，我们发现setState()方法主要是enqueueUpdate()进行状态更新，怎样进行状态更新呢？定义了一个批量更新策略：判断更新标志isBatchingUpdates的值，如果为false，调用batchedUpdates()-->(先把更新标志isBatchingUpdates改为true，然后调用transaction.perform(enqueueUpdate))。如果为true，就把组件加入dirtyComponents数组中。
说明：简单地说，一个所谓的 Transaction 就是将需要执行的 method 使用 wrapper 封装起来，再通过 Transaction 提供的 perform 方法执行。而在 perform 之前，先执行所有 wrapper 中的 initialize 方法；perform 完成之后（即 method 执行后）再执行所有的 close 方法。一组 initialize 及 close 方法称为一个 wrapper，从上面的示例图中可以看出 Transaction 支持多个 wrapper 叠加。
具体到实现上，React 中的 Transaction 提供了一个 Mixin 方便其它模块实现自己需要的事务。而要使用 Transaction 的模块，除了需要把 Transaction 的 Mixin 混入自己的事务实现中外，还需要额外实现一个抽象的 getTransactionWrappers 接口。这个接口是 Transaction 用来获取所有需要封装的前置方法（initialize）和收尾方法（close）的，因此它需要返回一个数组的对象，每个对象分别有 key 为 initialize 和 close 的方法。以下是源码解释图：
说明：flushBatchedUpdates 会在一个 transaction 的 close 阶段运行 runBatchedUpdates，从而执行 update。
说明：runBatchedUpdates 循环遍历 dirtyComponents 数组，主要干两件事：
1) 执行 performUpdateIfNecessary 来刷新组件的 view；
2) 然后执行之前阻塞的 callback。
下面来看 performUpdateIfNecessary。
说明：注意上面的 updateComponent，它将负责开始执行 React 组件存在期的生命周期方法。
说明：setState 传函数能获取最新 state 的原因就在这儿了，遍历队列的时候发现是个函数就每次都传最新的 nextState 进去执行一遍。
回顾
综上，
setState()为啥没有立即更新this.state值呢？
为什么在componentDidMount()中连续多次setState,无法进行state累加呢？
批量更新策略isBatchingStrategy干了什么，怎么做到更新的呢？那按照上述说的批量更新，第一次setState-->进入enqueueUpdate()-->此时isBatchingUpdates默认为false-->batchedUpdates(enqueueUpdate,...)-->设置isBatchingUpdates为true;transaction.perform(enqueueUpdates);-->(第一个wrapper:FLUSH_BATCHED_UPDATES)组件更新-->(第二个wrapper:RESET_BATCHED_UPDATES的close方法)设置isBatchingUpdates为false-->第二次setState-->isBatchingUpdates为false-->..-->组件更新-->isBatchingUpdates恢复为false。
这样和结果不对呀？按上述逻辑的话，岂不是每次setState都会更新this.state的值？
调试代码会发现，原来整个将 React 组件渲染到 DOM 中的过程就处于一个大的 Transaction 中。
说明：在进入生命周期之前，就会调用batchedUpdates()，所以此时isBatchingUpdates已经修改为true了。后面第一次进入setState()时，就会进入加入dirtyComponent中。所以这也就是为什么两次打印 this.state.foods 都是 '' 的原因，新的 state 还没有被应用到组件中。
总结
1. setState(partialState, callback)，不会立即更新state值，要合并所有的state变化后，然后重新渲染的时候，state值才会更新。
2. setState(partialState, callback)，callback会在所有状态更新之后再调用。
3. 另外在componentWillMount里面setState()不会触发重新渲染 。
4. 在render函数中不能setState()。从react生命周期可以看出：state更新会重新触发render()，所以会导致setState()-->re-render()-->setState()--re-render()-->...-->setState()-->re-render()，一直循环往复。
附：组件生命周期阶段图
关于setState同步/移步
事件中的调用setState
那么在事件中调用setState又为什么也是异步的呢,react是通过合成事件实现了对于事件的绑定，在组件创建和更新的入口方法mountComponent和updateComponent中会将绑定的事件注册到document节点上，相应的回调函数通过EventPluginHub存储。当事件触发时，document上addEventListener注册的callback会被回调，回调函数为ReactEventListener.dispatchEvent，它是事件分发的入口方法。下面我们来看下dispatchEvent：
dispatchEvent: function (topLevelType, nativeEvent) {
// disable了则直接不回调相关方法
if (!ReactEventListener._enabled) {
return;
}
var bookKeeping = TopLevelCallbackBookKeeping.getPooled(topLevelType, nativeEvent);
try {
// 放入
ReactUpdates.batchedUpdates(handleTopLevelImpl, bookKeeping);
} finally {
TopLevelCallbackBookKeeping.release(bookKeeping);
}
}
看到了熟悉的batchedUpdates方法，只是调用方换成了ReactUpdates，再进入ReactUpdates.batchedUpdates。
豁然开朗，原来在事件的处理中也是通过同样的事务完成的，当进入事件处理流程后，该事务的isBatchingUpdates为true，如果在事件中调用setState方法，也会进入dirtyComponent流程，即所谓的异步。
原生事件绑定和setTimeout中setState
在回过头来看同步的情况，原生事件绑定不会通过合成事件的方式处理，自然也不会进入更新事务的处理流程。setTimeout也一样，在setTimeout回调执行时已经完成了原更新组件流程，不会放入dirtyComponent进行异步更新，其结果自然是同步的。
顺便提一下，在更新组建时，将更新的state合并到原state是在componentWillUpdate之后，render之前，所以在componentWillUpdate之前设置的setState可以在render中拿到最新值。
参考
react SetState源码实现理解
setState 源码分析， 流程详解
React 源码剖析系列 － 解密 setState
React 源码深度解读（九）：单个元素更新
React中setState真的是异步的吗
