資訊專欄INFORMATION COLUMN
摘要：接上文，流程圖臟組件從流程圖里能看出，會遍歷數組，并在事務中調用。該事務有兩個包裝器，和。對于這種情況，我們只能通過檢查批量更新的計數器來跳過這次更新。這個設計避免了同一個組件的重復更新。
接上文，
React流程圖：
https://bogdan-lyashenko.gith...
從流程圖里能看出，React會遍歷dirtyComponents數組，并在事務中調用ReactUpdates.runBatchedUpdates。這個事務是個新事務。那么為什么要這么設計呢？
此事務的類型為ReactUpdatesFlushTransaction，在此之前我們已經提到過，我們去看下其相應的包裝器以方便我們理解這個事務具體完成什么任務。代碼里有如下注釋：
ReactUpdatesFlushTransaction包裝器會清空dirtyComponents數組，并且執行所有已經壓入隊列里的更新操作，這些操作一般都是由過程后的處理方法壓入的（比如，commponentDidUpdate方法）（ReactUpdatesFlushTransaction’s wrappers will clear the dirtyComponents array and perform any updates enqueued by mount-ready handlers (i.e., componentDidUpdate)）
我們也驗證下是否代碼真的這樣運轉。該事務有兩個包裝器，NEST_UPDATES和UPDATE_QUEUEING。在事務的初始化階段，我們會先把dirtyComponentsLength存儲起來，然后在關閉階段，React進行組件比較。在更新過程中，很可能dirtyComponents組件都發生里改變，所以，需要不止一次的運行flushBatchedUpdates方法。代碼比較直白，沒有什么黑魔法。
但是，這里其實有個地方需要注意下，ReactUpdatesFlushTransaction覆蓋了Transaction.perform方法，之所以這么做，是因為，執行更新時需要調用ReactReconcileTransacation里的行為（這個事務在掛載過程中也使用到了，目的是為了確保應用狀態安全）。所以，在ReactUpdatesFlushTransaction.perform方法的執行過程中，ReactReconcileTransaction方法會被調用到，所以，就是把事務方法在包了一次。
整個技術流程大概如此：
[NESTED_UPDATES, UPDATE_QUEUEING].initialize() [SELECTION_RESTORATION, EVENT_SUPPRESSION, ON_DOM_READY_QUEUEING].initialize() method -> ReactUpdates.runBatchedUpdates [SELECTION_RESTORATION, EVENT_SUPPRESSION, ON_DOM_READY_QUEUEING].close() [NESTED_UPDATES, UPDATE_QUEUEING].close()
在此文的最后，我們會回到事務方法，在確認下事務是如何幫助方法完成的,但在此之前，我們先確認下ReactUpdates.runBatchedUpdates的實現。(srcrendererssharedstackreconcilerReactUpdates.js#125)
在執行之前的第一步，就是把dirtyComponets進行排序，如何排序呢？基于mount order這個字段進行排序（一個整數值，在組件實例化時被設置進組件），這個字段代表父組件（它們也最先掛載）先更新，子組件接下去更新，以此類推。下一步，React會對updateBatchNumber加1操作，這個字段類似于當前處理DOM的ID，看下代碼里的注釋，看下代碼里的注釋：
在更新過程中加入隊列的更新必須在批量操作執行完后再執行。否則，假設dirtyComponents為有組件A，B，其中A的子組件為B，B有子組件C，如果C有更新,則B將再次被壓入隊列，導致B被更新兩次。對于這種情況，我們只能通過檢查批量更新的計數器來跳過這次更新。（‘Any updates enqueued while reconciling must be performed after this entire batch. Otherwise, if dirtyComponents is [A, B] where A has children B and C, B could update twice in a single batch if C’s render enqueues an update to B (since B would have already updated, we should skip it, and the only way we can know to do so is by checking the batch counter).’）
這個設計避免了同一個組件的重復更新。
最后，我們遍歷完整個dirtyComponents隊列，然后把每個組件傳遞給了ReactReconciler.performUpdateIfNecessary，這個方法會在ReactCompisteCompoent里被調用，所以，最終我們又回到了ReactCompsiteComponet里的updateComponet方法。現在，我們可以更深入的研究下這個方法。
（未完待續）
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/95909.html
摘要：技術上來說，當方法被調用后或者發生改變后，方法都會被調用。下一步，會設置為。之后，檢測當前更新是否由更新引起的。這是因為，使用是導致組件持久化更新，而會被方法的返回值重新賦值。 接上文， React流程圖：https://bogdan-lyashenko.gith... 更新組件 關于組件的更新，我們先看下代碼里的注釋： 對于已掛載組件的更新過程，React會首先調用component...
摘要：接上文，流程圖我們已經知道掛載的工作流程，現在我們換個方向研究下方法，這個也是的重要組成部分。這個問題，我們會在下一篇文章中進行解答。。。 接上文， React流程圖：https://bogdan-lyashenko.gith... this.setState 我們已經知道掛載的工作流程，現在我們換個方向研究下--setState方法，這個也是React的重要組成部分。 首先，為什么我...
摘要：源碼里有個獨立的模塊管理組件的所有子元素。第一個，實例化子元素使用并掛載它們。至于具體掛載流程，基于子元素類型的不同而有不同的掛載過程。掛載的過程基本完成了。 接上文， React流程圖：https://bogdan-lyashenko.gith... 創建初始子組件 在之前的步驟里，組件本身的構建已經完成，接下去，我們分析它們的子元素。總共分為兩步：掛載子元素（this.mountC...
摘要：當鼠標事件發生時，組件的最外層會進行處理，然后通過幾層包裝器的處理后，會開始進行批量更新操作。在這之后，會將這些事件處理成常見到樣子。 接上文， React流程圖：https://bogdan-lyashenko.gith... 回到最初 在流程圖中，也許你已經注意到，setState方法可以通過幾種方式觸發，更準確的說，可以分為是否由外部引起的（也就是是否由用戶觸發）。讓我們看下如下...
摘要：接著，將返回的元素和之前的進行比較的，以驗證是否真的需要更新。我們看下代碼，代碼比較簡單好，對應于我們的這個列子，我們對于方法的更改并不會對方法造成影響。所以我們進入下一步，也就是對于節點的更新。 接上文， React流程圖：https://bogdan-lyashenko.gith... 如果組件真的需要更新 在組件剛開始更新過程時，如果有定義componentWillUpdate方...
閱讀 638·2021-11-25 09:43
閱讀 1906·2021-11-17 09:33
閱讀 824·2021-09-07 09:58
閱讀 2062·2021-08-16 10:52
閱讀 482·2019-08-30 15:52
閱讀 1722·2019-08-30 15:43
閱讀 974·2019-08-30 15:43
閱讀 2924·2019-08-29 16:41
