从源码的角度再看 React JS 中的 setState

Posted 2021-04-30 DevOpenClub

在上一篇手记「深入理解 React JS 中的 setState」中，我们简单地理解了 React 中 setState “诡异”表现的原因。

在这一篇文章中，我们从源码的角度再次理解下 setState 的更新机制，供深入研究学习之用。

源码的部分为了保证格式显示正常就截图了，查看源码点击对应的链接直接跳转至 GitHub 查看即可。

1. React 中的 setState 更新逻辑代码

在更新逻辑的部分，可以看到 React 会通过 batchingStrategy.isBatchingUpdates 判断当前的逻辑状态下是否需要进行批量更新。

如果不是，那么就直接进行页面的批量更新，将之前累积的所有状态一次更新到组件上。就是类似我们上一篇文章中举例的快递点一次将所有的快递寄出。

如果是，那么所有的组件状态不进行立即更新，而是将组件状态存放在一个叫 dirtyComponents 的数组中去，等待下次更新时机的到来再进行更新。

https://github.com/facebook/react/blob/35962a00084382b49d1f9e3bd36612925f360e5b/src/renderers/shared/reconciler/ReactUpdates.js#L199

2. React 中的 Transaction 设计

为了实现上述的更新逻辑，React 设计了 Transaction 的逻辑，看起来也像是数据库中的事务。
源码中如图所示，给出了一幅图以及大段的解释。

React 将整个的函数执行过程包裹上了 Transaction，在函数执行前与执行后分别有 initialize 和 close 两个方法。

这样的话 React 就有时机在函数执行过程中，涉及到 setState 的执行，都将缓存下来，在 close 的时候进入到 React 的 state 更新逻辑进行更新判断操作，并最终更新到前台的 DOM 上。

https://github.com/facebook/react/blob/6d5fe44c8602f666a043a4117ccc3bdb29b86e78/src/shared/utils/Transaction.js#L28

其实 Virtual DOM 的框架都会有这样的设计逻辑，理解了这样的底层设计才能很好地理解一些方法在前台的表现行为。

Vue.js 中也有类似的设计逻辑，后续如果有时间我们将继续进行相关讨论。

下一篇文章，我们继续来看 React 底层是如何进行 batchingStrategy 的设计以及更新状态的转换的。

---

加入 DevOpenClub Pro 知识星球

高质量、有价值的交流社区永远都不会是你所在的 QQ 群或者微信群；

获取每年所有原创开发视频教程的第一手更新；

每日分享高质量的国外技术开发头条信息与资源；

获取 [学软件开发 & 学英语] 相关国外超清视频的第一手百度云更新；

获取百度云中分享的超清视频课程以及源码等相关资料；

获取其他高质量软件开发行业新闻、技术文章、教学视频分享；

第一时间获取视频更新提醒及观看密码；

遇到相关技术问题可以进行快速提问以及讨论交流；

群中认识更多的朋友以及合作开发项目的机会；

认识更多的行业朋友，或者交流自己的创业小项目。

---