this.setState() 方法應該是每一位使用 React 的同學最先熟悉的 API。然而，你真的了解 setState 么？先看看下面這個小問題，你能否正確回答。

引子

class Example extends React.Component {constructor() {super();this.state = {val: 0};}componentDidMount() {this.setState({val: this.state.val + 1});console.log(this.state.val); // 第 1 次 logthis.setState({val: this.state.val + 1});console.log(this.state.val); // 第 2 次 logsetTimeout(() => {this.setState({val: this.state.val + 1});console.log(this.state.val); // 第 3 次 logthis.setState({val: this.state.val + 1});console.log(this.state.val); // 第 4 次 log}, 0);}render() {return null;} };

問上述代碼中 4 次 console.log 打印出來的 val 分別是多少？

不賣關子，先揭曉答案，4 次 log 的值分別是：0、0、2、3。

若結果和你心中的答案不完全相同，那下面的內容你可能會感興趣。

同樣的 setState 調用，為何表現和結果卻大相徑庭呢？讓我們先看看 setState 到底干了什么。

setState 干了什么

上面這個流程圖是一個簡化的 setState 調用棧，注意其中核心的狀態判斷，在源碼(ReactUpdates.js)中

function enqueueUpdate(component) {// ...if (!batchingStrategy.isBatchingUpdates) {batchingStrategy.batchedUpdates(enqueueUpdate, component);return;}dirtyComponents.push(component); }

若 isBatchingUpdates 為 true，則把當前組件（即調用了 setState 的組件）放入 dirtyComponents 數組中；否則 batchUpdate 所有隊列中的更新。先不管這個 batchingStrategy，看到這里大家應該已經大概猜出來了，文章一開始的例子中 4 次 setState 調用表現之所以不同，這里邏輯判斷起了關鍵作用。

那么 batchingStrategy 究竟是何方神圣呢？其實它只是一個簡單的對象，定義了一個 isBatchingUpdates 的布爾值，和一個 batchedUpdates 方法。下面是一段簡化的定義代碼：

var batchingStrategy = {isBatchingUpdates: false,batchedUpdates: function(callback, a, b, c, d, e) {// ...batchingStrategy.isBatchingUpdates = true;transaction.perform(callback, null, a, b, c, d, e);} };

注意 batchingStrategy 中的 batchedUpdates 方法中，有一個 transaction.perform 調用。這就引出了本文要介紹的核心概念 —— Transaction（事務）。

初識 Transaction

熟悉 MySQL 的同學看到 Transaction 是否會心一笑？然而在 React 中 Transaction 的原理和行為和 MySQL 中并不完全相同，讓我們從源碼開始一步步開始了解。

在 Transaction 的源碼中有一幅特別的 ASCII 圖，形象的解釋了 Transaction 的作用。

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

簡單地說，一個所謂的 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 的方法。

下面是一個簡單使用 Transaction 的例子

var Transaction = require('./Transaction');// 我們自己定義的 Transaction var MyTransaction = function() {// do sth. };Object.assign(MyTransaction.prototype, Transaction.Mixin, {getTransactionWrappers: function() {return [{initialize: function() {console.log('before method perform');},close: function() {console.log('after method perform');}}];}; });var transaction = new MyTransaction(); var testMethod = function() {console.log('test'); } transaction.perform(testMethod);// before method perform // test // after method perform

當然在實際代碼中 React 還做了異常處理等工作，這里不詳細展開。有興趣的同學可以參考源碼中 Transaction 實現。

說了這么多 Transaction，它到底是怎么導致上文所述 setState 的各種不同表現的呢？

解密 setState

那么 Transaction 跟 setState 的不同表現有什么關系呢？首先我們把 4 次 setState 簡單歸類，前兩次屬于一類，因為他們在同一次調用棧中執行；setTimeout 中的兩次 setState 屬于另一類，原因同上。讓我們分別看看這兩類 setState 的調用棧：

componentDidMout 中 setState 的調用棧

setTimeout 中 setState 的調用棧

很明顯，在 componentDidMount 中直接調用的兩次 setState，其調用棧更加復雜；而 setTimeout 中調用的兩次 setState，調用棧則簡單很多。讓我們重點看看第一類 setState 的調用棧，有沒有發現什么熟悉的身影？沒錯，就是 batchedUpdates 方法，原來早在 setState 調用前，已經處于 batchedUpdates 執行的 transaction 中！

那這次 batchedUpdate 方法，又是誰調用的呢？讓我們往前再追溯一層，原來是 ReactMount.js 中的 _renderNewRootComponent 方法。也就是說，整個將 React 組件渲染到 DOM 中的過程就處于一個大的 Transaction 中。

接下來的解釋就順理成章了，因為在 componentDidMount 中調用 setState 時，batchingStrategy 的 isBatchingUpdates 已經被設為 true，所以兩次 setState 的結果并沒有立即生效，而是被放進了 dirtyComponents 中。這也解釋了兩次打印 this.state.val 都是 0 的原因，新的 state 還沒有被應用到組件中。

再反觀 setTimeout 中的兩次 setState，因為沒有前置的 batchedUpdate 調用，所以 batchingStrategy 的 isBatchingUpdates 標志位是 false，也就導致了新的 state 馬上生效，沒有走到 dirtyComponents 分支。也就是，setTimeout 中第一次 setState 時，this.state.val 為 1，而 setState 完成后打印時 this.state.val 變成了 2。第二次 setState 同理。

擴展閱讀

在上文介紹 Transaction 時也提到了其在 React 源碼中的多處應用，想必調試過 React 源碼的同學應該能經常見到它的身影，像 initialize、perform、close、closeAll、notifyAll 等方法出現在調用棧中，都說明當前處于一個 Transaction 中。

既然 Transaction 這么有用，我們自己的代碼中能使用 Transaction 嗎？很可惜，答案是不能。不過針對文章一開始例子中 setTimeout 里的兩次 setState 導致兩次 render 的情況，React 偷偷給我們暴露了一個 batchedUpdates 方法，方便我們調用。

import ReactDom, { unstable_batchedUpdates } from 'react-dom';unstable_batchedUpdates(() => {this.setState(val: this.state.val + 1);this.setState(val: this.state.val + 1); });

當然因為這個不是公開的 API，后續存在廢棄的風險，大家在業務系統里慎用喲！

注釋

test-react 文中測試代碼已放在 Github 上，需要自己實驗探索的同學可以 clone 下來自己斷點調試。

為了避免引入更多的概念，上文中所說到的 batchingStrategy 均指 ReactDefaultBatchingStrategy，該 strategy 在 React 初始化時由 ReactDefaultInjection 注入到 ReactUpdates 中作為默認的 strategy。在 server 渲染時，則會注入不同的 strategy，有興趣的同學請自行探索。

總結

以上是生活随笔為你收集整理的React 源码剖析系列 － 解密 setState的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。