從源碼的角度再看 React JS 中的 setState

在這一篇文章中，咱們從源碼的角度再次理解下 setState 的更新機制，供深刻研究學習之用。

在上一篇手記「深刻理解 React JS 中的 setState」中，咱們簡單地理解了 React 中 setState 「詭異」表現的緣由。

源碼的部分爲了保證格式顯示正常就截圖了，查看源碼點擊對應的連接直接跳轉至 GitHub 查看便可。

1. React 中的 setState 更新邏輯代碼

在更新邏輯的部分，能夠看到 React 會經過 batchingStrategy.isBatchingUpdates 判斷當前的邏輯狀態下是否須要進行批量更新。

• 若是不是，那麼就直接進行頁面的批量更新，將以前累積的全部狀態一次更新到組件上。就是相似咱們上一篇文章中舉例的快遞點一次將全部的快遞寄出。

• 若是是，那麼全部的組件狀態不進行當即更新，而是將組件狀態存放在一個叫 dirtyComponents 的數組中去，等待下次更新時機的到來再進行更新。

源碼地址

2. React 中的 Transaction 設計

爲了實現上述的更新邏輯，React 設計了 Transaction 的邏輯，看起來也像是數據庫中的事務。
源碼中如圖所示，給出了一幅圖以及大段的解釋。

React 將整個的函數執行過程包裹上了 Transaction，在函數執行前與執行後分別有 initialize 和 close 兩個方法。

這樣的話 React 就有時機在函數執行過程當中，涉及到 setState 的執行，都將緩存下來，在 close 的時候進入到 React 的 state 更新邏輯進行更新判斷操做，並最終更新到前臺的 DOM 上。

源碼地址

其實 Virtual DOM 的框架都會有這樣的設計邏輯，理解了這樣的底層設計才能很好地理解一些方法在前臺的表現行爲。

Vue.js 中也有相似的設計邏輯，後續若是有時間咱們將繼續進行相關討論。

下一篇文章，咱們繼續來看 React 底層是如何進行 batchingStrategy 的設計以及更新狀態的轉換的。