前言

想起自己(2021年) 8 月份面試時，被面試官們問了好幾個 setState 的問題，現(xiàn)在想想，雖然回答上問題，但是了解得不深刻。我知道 setState 被設(shè)計成“異步”是為了性能，但是涉及到源碼解讀我就歇菜了;我知道如何讓它同步，但是遇到真實的代碼情況時，卻不知道如何下手。說到底，當時是準備了面經(jīng)把這些概念記下來，而沒有真正理解它

在認識 setState 前，我們問幾個常見問題

• setState 是同步還是異步?
• 如果是異步，怎么讓它同步?
• 為什么要這樣設(shè)計?

基本概念和使用

React 的理念之一是 UI=f(data)，修改 data 即驅(qū)動 UI 變化，那么怎么修改呢?React 提供了一個 API ——setState(類組件的修改方法)

官網(wǎng)介紹：

• setState() 將對組件 state 的更新排入隊列，并通知 React 需要使用更新后的 state 重新渲染此組件及其子組件。這是用于更新用戶界面以響應(yīng)事件處理器和處理服務(wù)器數(shù)據(jù)的主要方式
• 為了更好的感知性能，React 會延遲調(diào)用它，然后通過一次傳遞更新多個組件。React 并不會保證 state 的變更會立即生效
• setState() 并不總是立即更新組件。它會批量推遲更新。這使得在調(diào)用 setState() 后立即讀取 this.state 成為了隱患。為了消除隱患，請使用 componentDidUpdate 或者 setState 的回調(diào)函數(shù)(setState(updater, callback))，這兩種方式都可以保證在應(yīng)用更新后觸發(fā)
• 除非 shouldComponentUpdate() 返回 false，否則 setState() 將始終執(zhí)行重新渲染操作。如果可變對象被使用，且無法在 shouldComponentUpdate() 中實現(xiàn)條件渲染，那么僅在新舊狀態(tài)不一致調(diào)用 setState()可以避免不必要的重新渲染

使用方法

setState(updater, [callback])

參數(shù)一為帶有形式參數(shù)的 updater 函數(shù)：

(state, props) => stateChange

// 例如
// this.setState((state, props) => {
//   return {counter: state.counter + props.step};
// });

setState 的第一個參數(shù)除了接受函數(shù)外，還可以接受對象類型：

setState(stateChange[, callback])
// 例如：this.setState({count: 2})

setState 的第二個參數(shù)為可選的回調(diào)函數(shù)，它將在 setState 完成合并重新渲染組件后執(zhí)行。通常，我們建議使用 componentDidUpdate 來代替此方法

setState(stateChange[, callback])
// 例如: this.setState({count: 2}, () => {console.log(this.state.count)}) 

與 setState 回調(diào)相比，使用 componentDidUpdate 有什么優(yōu)勢?

stackoverflow 有人問過，也有人回答過：

• 一致的邏輯
• 批量更新
• 什么時候 setState 會比較好? 當外部代碼需要等待狀態(tài)更新時，如 Promise

setState 的特性——批處理

如果在同一周期內(nèi)對多個 setState 進行處理，例如，在同一周期內(nèi)多次設(shè)置商品數(shù)據(jù)，相當于：

this.setState({count: state.count + 1});
this.setState({count: state.count + 1});
this.setState({count: state.count + 1});
// === 
Object.assign(
  count,
  {quantity: state.quantity + 1},
  {quantity: state.quantity + 1},
  ...
)

后調(diào)的 setState 將覆蓋同一周期內(nèi)先調(diào)用 setState 的值

• setState(stateChange[, callback])
• setState((state, props) => stateChange[, callback])

setState 必引發(fā)更新過程，但不一定會引發(fā) render 被執(zhí)行，因為 shouldCompomentUpdate 可以返回 false

批處理引發(fā)的問題

問題1：連續(xù)使用 setState，為什么不能實時改變

state.count = 0;
this.setState({count: state.count + 1}); 
this.setState({count: state.count + 1}); 
this.setState({count: state.count + 1}); 
// state.count === 1，不是 3

因為 this.setState 方法為會進行批處理，后調(diào)的 setState 會覆蓋統(tǒng)一周期內(nèi)先調(diào)用的 setState 的值，如下圖所示：

state.count = 0;
this.setState({count: state.count + 2}); 
this.setState({count: state.count + 3}); 
this.setState({count: state.count + 4}); 
// state.count === 4

問題2：為什么要 setState，而不是直接 this.state.xx = oo?

因為 setState 做的事情不僅僅只是修改了 this.state 的值，另外最重要的是它會觸發(fā) React 的更新機制，會進行diff，然后將 patch 部分更新到真實 dom 里

如果你直接 this.state.xx = oo 的話，state 的值確實會改，但是它不會驅(qū)動 React 重渲染。setState 能幫助我們更新視圖，引發(fā) shouldComponentUpdate、render 等一系列函數(shù)的調(diào)用。至于批處理，React 會將 setState 的效果放入隊列中，在事件結(jié)束之后產(chǎn)生一次重新渲染，為的就是把 Virtual DOM 和 DOM 樹操作降到最小，用于提高性能

當調(diào)用 setState 后，React 的 生命周期函數(shù) 會依次順序執(zhí)行

• static getDerivedStateFromProps
• shouldComponentUpdate
• render
• getSnapshotBeforeUpdate
• componentDidUpdate

問題3：那為什么會出現(xiàn)異步的情況呢?(為什么這么設(shè)計?)

因為性能優(yōu)化。假如每次 setState 都要更新數(shù)據(jù)，更新過程就要走五個生命周期，走完一輪生命周期再拿 render 函數(shù)的結(jié)果去做 diff 對比和更新真實 DOM，會很耗時間。所以將每次調(diào)用都放一起做一次性處理，能降低對 DOM 的操作，提高應(yīng)用性能

問題4：那如何在表現(xiàn)出異步的函數(shù)里可以準確拿到更新后的 state 呢?

通過第二個參數(shù) setState(partialState, callback) 中的 callback 拿到更新后的結(jié)果

onHandleClick() {
    this.setState(
        {
            count: this.state.count + 1,
        },
        () => {
            console.log("點擊之后的回調(diào)", this.state.count); // 最新值
        }
    );
}

或者可以直接給 state 傳遞函數(shù)來表現(xiàn)出同步的情況

this.setState(state => {
 console.log("函數(shù)模式", state.count);
 return { count: state.count + 1 };
});

執(zhí)行原理

首先先了解三種渲染模式

• legacy 模式：ReactDOM.render(, rootNode) 。這是當前 React app 使用的方式。當前沒有計劃刪除本模式，但是這個模式可能不支持新功能
• blocking 模式：
• ReactDOM.createBlockingRoot(rootNode).render() 。目前正在實驗中，作為遷移到 concurrent 模式的第一個步驟
• concurrent 模式 ：ReactDOM.createRoot(rootNode).render()。目前在實驗中，未來穩(wěn)定之后，打算作為 React 的模式開發(fā)模式。這個模式開啟了所有的新功能 擁有不同的優(yōu)先級，更新的過程可以被打斷

在 legacy 模式下，在 React 的 setState 函數(shù)實現(xiàn)中，會根據(jù)一個變量 isBatchingUpdates 判斷是直接更新 this.state 還是放到隊列中回頭再說，而 isBatchingUpdates 默認是 false，也就表示 setState 會同步更新 this.state，但是，有一個函數(shù) batchedUpdates，這個函數(shù)會把 isBatchingUpdates 修改為 true，而當 React 在調(diào)用事件處理函數(shù)之前就會調(diào)用這個 batchedUpdates，造成的后果，就是由 React 控制的事件處理過程 setState 不會同步更新 this.state

像 addEventListener 綁定的原生事件、setTimeout/setInterval 會走同步，除此之外，也就是 React 控制的事件處理 setState 會異步

而 concurrent 模式都是異步，這也是未來 React 18 的默認模式

總結(jié)

首先，我們總結(jié)下關(guān)鍵知識點

• setState 不會立即改變 React 組件中 state 的值
• setState 通過引發(fā)一次組件的更新過程來引發(fā)重新繪制
• 多次 setState 函數(shù)調(diào)用產(chǎn)生的效果會合并(批處理)

其次，回答一下文章開頭的問題(第二第三問題在文中已經(jīng)回答)

setState 是同步還是異步?

• 代碼同步，渲染看模式 legacy模式，非原生事件、setTimeout/setInterval 的情況下為異步;addEventListener 。 綁定原生事件、setTimeout/setInterval 時會同步concurrent 模式：異步