React setState源码实现理解

时间 2019-12-06

标签 react setstate 源码实现理解栏目 React 繁體版

原文原文链接

html

Q1--setState改变状态以后，不会当即更新state值
A1react
- [1. react生命周期]()
- 2. react更新state具体作了什么
- 3. transaction 事务
- 4. 回顾上述问题
- 5. 总结
Q2--在render函数里，没法setState
A2

segmentfault

Q1

setState改变状态以后，不会当即更新state值。因此，若是改变state值，react是何时进行组件的更新呢？setState()到底作了一些什么呢？数组

A1

1. react生命周期

2. react更新state具体作了什么

引入一段源码app

react中定义的setState方法，定义了两个参数(partialState,callback)。函数

partialState: 新的state值;
callback: 回调函数。post

getInternalInstanceReadyForUpdate方法的目的是获取当前组件对象，将其赋值给internalInstance变量。接下来判断当前组件对象的state更新队列是否存在，若是存在则将partialState也就是新的state值加入队列；若是不存在，则建立该对象的更新队列。而后进入enqueueUpdate方法。this

enqueueCallback也是先获取当前组件对象，若是已经存在其余回调，就加入等待回调队列，若是当前没有回调，就建立等待回调队列。而后进入enqueueUpdate方法。spa

能够发现,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以事务+状态的形式对组件进行更新。

经过上面的一部分代码，咱们发现setState()方法主要是enqueueUpdate()进行状态更新，怎样进行状态更新呢？定义了一个批量更新策略：判断更新标志isBatchingUpdates的值，若是为false，调用batchedUpdates()-->(先把更新标志isBatchingUpdates改成true，而后调用transaction.perform(enqueueUpdate))。若是为true，就把组件加入dirtyComponents数组中。

React内部采用了"状态机"的概念，组件处于不一样的状态时，所执行的逻辑也并不相同。以组件更新流程为例，React以事务+状态的形式对组件进行更新，所以接下来咱们看看事务的机制。

3. transaction 事务

wrappers (injected at creation time)
                                   +        +
                                   |        |
                 +-----------------|--------|--------------+
                 |                 v        |              |
                 |      +---------------+   |              |
                 |   +--|    wrapper1   |---|----+         |
                 |   |  +---------------+   v    |         |
                 |   |          +-------------+  |         |
                 |   |     +----|   wrapper2  |--------+   |
                 |   |     |    +-------------+  |     |   |
                 |   |     |                     |     |   |
                 |   v     v                     v     v   | wrapper
                 | +---+ +---+   +---------+   +---+ +---+ | invariants
perform(anyMethod) | |   | |   |   |         |   |   | |   | | maintained
+----------------->|-|---|-|---|-->|anyMethod|---|---|-|---|-|-------->
                 | |   | |   |   |         |   |   | |   | |
                 | |   | |   |   |         |   |   | |   | |
                 | |   | |   |   |         |   |   | |   | |
                 | +---+ +---+   +---------+   +---+ +---+ |
                 |  initialize                    close    |
                 +-----------------------------------------+

这是官方代码的解析图。

能够看出调用函数是perform(anyMethod),而后方法anyMethod被wrapper包裹了，wrapper依次执行了initialize->anyMethod->close

function anyMethod(){
    console.log('xx')
};
transaction.perform(anyMethod);

代码的执行顺序是

initialize()
输出xx
close()

因此这里wrapper是怎样定义的呢？

第二个wrapper比较简单，先来看一下第二个wrapper。

第二个wrapper(RESET_BATCHED_UPDATES)的做用是将更新标志isBatchingUpdates重置为false;个人理解这里是收集完全部要更新的state值，都加入_pendingStateQueue待更新状态队列了，而后组件更新完了以后，将更新标志重置为false，等待下次更新。而后下面来看一下第一个wrapper。

5&f=png&s=54081)

第一个wrapper主要的做用是更新组件，执行了ReactUpdates.flushBatchedUpdates.bind(ReactUpdates)。

能够看到flushBatchedUpdates方法循环遍历全部的dirtyComponents，又经过事务的形式调用runBatchedUpdates方法。

一共作了两件事：

一是经过执行updateComponent方法来更新组件
二是若setState方法传入了回调函数则将回调函数存入callbackQueue队列。

而后看一下updateComponent方法,官方注释是：更新组件，会调用shouldComponentUpdate,而后调用剩余的生命周期函数，更新DOM结构。

这里终于更新了组件。看代码会发如今shouldComponentUpdate以前，执行了_processPendingState方法,该方法主要对state进行处理：

1.若是更新队列为null，那么返回原来的state；
2.若是更新队列有一个更新，那么返回更新值；
3.若是更新队列有多个更新，那么经过for循环将它们合并；

综上说明了，在一个生命周期内，在componentShouldUpdate执行以前，全部的state变化都会被合并，最后统一处理。

4. 回顾上述问题

综上，

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 尚未被应用到组件中。

5. 总结

setState(partialState, callback)，不会当即更新state值，要合并全部的state变化后，而后从新渲染的时候，state值才会更新。
setState(partialState, callback): callback会在全部状态更新以后再调用(demo中state的foods&drinks所有更新以后才会调用)
事务这么有用，那咱们能够调用事务吗？答案是不能够。
另外在componentWillMount里面setState()不会触发从新渲染

Q2

在render函数里，没法setState

A2

在render函数中不能setState()。

从react生命周期能够看出：state更新会从新触发render()，因此会致使setState()-->re-render()-->setState()--re-render()-->...-->setState()-->re-render()，一直循环往复。

因此，同理在state更新的生命周期的函数中(componentWillUpdate/componentDidUpdate)，都不能setState()

参考资料

https://juejin.im/post/59cc4c...

https://zh-hans.reactjs.org/d...

https://www.imooc.com/article...

https://segmentfault.com/a/11...