摘要:接上文,流程圖臟組件從流程圖里能看出,會遍歷數(shù)組,并在事務(wù)中調(diào)用。該事務(wù)有兩個包裝器,和。對于這種情況,我們只能通過檢查批量更新的計數(shù)器來跳過這次更新。這個設(shè)計避免了同一個組件的重復(fù)更新。
接上文,
React流程圖:
https://bogdan-lyashenko.gith...
從流程圖里能看出,React會遍歷dirtyComponents數(shù)組,并在事務(wù)中調(diào)用ReactUpdates.runBatchedUpdates。這個事務(wù)是個新事務(wù)。那么為什么要這么設(shè)計呢?
此事務(wù)的類型為ReactUpdatesFlushTransaction,在此之前我們已經(jīng)提到過,我們?nèi)タ聪缕湎鄳?yīng)的包裝器以方便我們理解這個事務(wù)具體完成什么任務(wù)。代碼里有如下注釋:
ReactUpdatesFlushTransaction包裝器會清空dirtyComponents數(shù)組,并且執(zhí)行所有已經(jīng)壓入隊列里的更新操作,這些操作一般都是由過程后的處理方法壓入的(比如,commponentDidUpdate方法)(ReactUpdatesFlushTransaction’s wrappers will clear the dirtyComponents array and perform any updates enqueued by mount-ready handlers (i.e., componentDidUpdate))
我們也驗證下是否代碼真的這樣運轉(zhuǎn)。該事務(wù)有兩個包裝器,NEST_UPDATES和UPDATE_QUEUEING。在事務(wù)的初始化階段,我們會先把dirtyComponentsLength存儲起來,然后在關(guān)閉階段,React進行組件比較。在更新過程中,很可能dirtyComponents組件都發(fā)生里改變,所以,需要不止一次的運行flushBatchedUpdates方法。代碼比較直白,沒有什么黑魔法。
但是,這里其實有個地方需要注意下,ReactUpdatesFlushTransaction覆蓋了Transaction.perform方法,之所以這么做,是因為,執(zhí)行更新時需要調(diào)用ReactReconcileTransacation里的行為(這個事務(wù)在掛載過程中也使用到了,目的是為了確保應(yīng)用狀態(tài)安全)。所以,在ReactUpdatesFlushTransaction.perform方法的執(zhí)行過程中,ReactReconcileTransaction方法會被調(diào)用到,所以,就是把事務(wù)方法在包了一次。
整個技術(shù)流程大概如此:
[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()
在此文的最后,我們會回到事務(wù)方法,在確認下事務(wù)是如何幫助方法完成的,但在此之前,我們先確認下ReactUpdates.runBatchedUpdates的實現(xiàn)。(srcrendererssharedstackreconcilerReactUpdates.js#125)
在執(zhí)行之前的第一步,就是把dirtyComponets進行排序,如何排序呢?基于mount order這個字段進行排序(一個整數(shù)值,在組件實例化時被設(shè)置進組件),這個字段代表父組件(它們也最先掛載)先更新,子組件接下去更新,以此類推。下一步,React會對updateBatchNumber加1操作,這個字段類似于當(dāng)前處理DOM的ID,看下代碼里的注釋,看下代碼里的注釋:
在更新過程中加入隊列的更新必須在批量操作執(zhí)行完后再執(zhí)行。否則,假設(shè)dirtyComponents為有組件A,B,其中A的子組件為B,B有子組件C,如果C有更新,則B將再次被壓入隊列,導(dǎo)致B被更新兩次。對于這種情況,我們只能通過檢查批量更新的計數(shù)器來跳過這次更新。(‘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).’)
這個設(shè)計避免了同一個組件的重復(fù)更新。
最后,我們遍歷完整個dirtyComponents隊列,然后把每個組件傳遞給了ReactReconciler.performUpdateIfNecessary,這個方法會在ReactCompisteCompoent里被調(diào)用,所以,最終我們又回到了ReactCompsiteComponet里的updateComponet方法?,F(xiàn)在,我們可以更深入的研究下這個方法。
(未完待續(xù))
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://www.ezyhdfw.cn/yun/95909.html
摘要:技術(shù)上來說,當(dāng)方法被調(diào)用后或者發(fā)生改變后,方法都會被調(diào)用。下一步,會設(shè)置為。之后,檢測當(dāng)前更新是否由更新引起的。這是因為,使用是導(dǎo)致組件持久化更新,而會被方法的返回值重新賦值。 接上文, React流程圖:https://bogdan-lyashenko.gith... 更新組件 關(guān)于組件的更新,我們先看下代碼里的注釋: 對于已掛載組件的更新過程,React會首先調(diào)用component...
摘要:接上文,流程圖我們已經(jīng)知道掛載的工作流程,現(xiàn)在我們換個方向研究下方法,這個也是的重要組成部分。這個問題,我們會在下一篇文章中進行解答。。。 接上文, React流程圖:https://bogdan-lyashenko.gith... this.setState 我們已經(jīng)知道掛載的工作流程,現(xiàn)在我們換個方向研究下--setState方法,這個也是React的重要組成部分。 首先,為什么我...
摘要:源碼里有個獨立的模塊管理組件的所有子元素。第一個,實例化子元素使用并掛載它們。至于具體掛載流程,基于子元素類型的不同而有不同的掛載過程。掛載的過程基本完成了。 接上文, React流程圖:https://bogdan-lyashenko.gith... 創(chuàng)建初始子組件 在之前的步驟里,組件本身的構(gòu)建已經(jīng)完成,接下去,我們分析它們的子元素??偣卜譃閮刹剑簰燧d子元素(this.mountC...
摘要:當(dāng)鼠標事件發(fā)生時,組件的最外層會進行處理,然后通過幾層包裝器的處理后,會開始進行批量更新操作。在這之后,會將這些事件處理成常見到樣子。 接上文, React流程圖:https://bogdan-lyashenko.gith... 回到最初 在流程圖中,也許你已經(jīng)注意到,setState方法可以通過幾種方式觸發(fā),更準確的說,可以分為是否由外部引起的(也就是是否由用戶觸發(fā))。讓我們看下如下...
摘要:接著,將返回的元素和之前的進行比較的,以驗證是否真的需要更新。我們看下代碼,代碼比較簡單好,對應(yīng)于我們的這個列子,我們對于方法的更改并不會對方法造成影響。所以我們進入下一步,也就是對于節(jié)點的更新。 接上文, React流程圖:https://bogdan-lyashenko.gith... 如果組件真的需要更新 在組件剛開始更新過程時,如果有定義componentWillUpdate方...
閱讀 720·2021-11-25 09:43
閱讀 2038·2021-11-17 09:33
閱讀 911·2021-09-07 09:58
閱讀 2138·2021-08-16 10:52
閱讀 543·2019-08-30 15:52
閱讀 1787·2019-08-30 15:43
閱讀 1188·2019-08-30 15:43
閱讀 2985·2019-08-29 16:41