
在這一篇文章中,我們從源碼的角度再次了解下 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
的設計以及更新狀态的轉換的。
作者:
Parry出處:
http://www.cnblogs.com/parry/本文版權歸作者和部落格園共有,歡迎轉載,但未經作者同意必須保留此段聲明,且在文章頁面明顯位置給出原文連接配接,否則保留追究法律責任的權利。