React新特性為什么產(chǎn)出這么慢

本篇內(nèi)容主要講解“React新特性為什么產(chǎn)出這么慢”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學(xué)習(xí)“React新特性為什么產(chǎn)出這么慢”吧!

有人曾說：每過一年，前端的入行難度提升一倍。

難度提升很大程度源于前端技術(shù)飛快的更新導(dǎo)致新技術(shù)加速出現(xiàn)，老技術(shù)加速淘汰。

但是，這里有個奇葩：React。

作為前端領(lǐng)域最廣為人知的技術(shù)之一，React2015年被「Jordan Walke」創(chuàng)造出來。

發(fā)展到今天，6年時間，不僅框架本身沒有沒落，框架所使用的JSX語法甚至已經(jīng)成了前端領(lǐng)域事實上的通用DSL。

在這激蕩的6年中，雖然前端領(lǐng)域天翻地覆，但是React的主要API和方法改動卻很少。

這一方面展示了React核心團隊卓越的前瞻性和框架設(shè)計能力。

另一方面，不禁讓人質(zhì)疑，React新特性為啥產(chǎn)出這么慢?江郎才盡啦?

尤其是前段時間，React17經(jīng)過了2年的迭代終于發(fā)出穩(wěn)定版，但是卻沒有新增特性。

這個問題的標(biāo)準(zhǔn)答案恐怕只有React團隊成員才知道。

不過，我們可以從源碼feature的迭代過程來管中窺豹。

新特性如何產(chǎn)出

如果把React比喻為一艘戰(zhàn)艦，他對外提供了「開炮」、「航行」等能力。

開發(fā)者就像戰(zhàn)艦的船員，使用這些能力操縱戰(zhàn)艦的行為。

當(dāng)React這艘戰(zhàn)艦需要開發(fā)新的能力，比如「高速航行」。

而「航行」依賴于戰(zhàn)艦的整套動力系統(tǒng)。

那么，一定會有大量動力系統(tǒng)的改造工作需要先行完成。

前期改造工作需要做多長時間呢?

縱觀React歷史，將組件樹的render從同步(Legacy Mode)變?yōu)榭芍袛嗟漠惒?Concurrent Mode)，花了2年。

這其中包括：

• 將底層架構(gòu)從遞歸(Stack Reconciler)變?yōu)楸闅v(Fiber Reconciler)

• 實現(xiàn)調(diào)度器(Scheduler)

• 實現(xiàn)調(diào)度算法(ExpirationTime，現(xiàn)在改為Lanes)

Fiber是如此出名，很多前端多聽說過。

今天，我們挑一個不出名的底層feature —— effect list。

讓我們看看他的迭代過程。

為什么選擇effect list

effect list是React源碼commit階段的一個特性，選擇他的迭代歷程講解是因為：

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2. 他是源碼內(nèi)部的feature，對開發(fā)者不可知

3. 表面上看起來這是一個不大的改動

4. 他的改動是為了上層新特性而做的底層調(diào)整

什么是effect list

React內(nèi)部工作大體可以分為3個階段：

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2. 調(diào)度更新

3. 決定什么組件需要更新

4. 更新組件

那么第三步如何知道要更新哪些組件呢?靠effect list。

如果將React Fiber樹比喻為圣誕樹，那么每個Fiber節(jié)點就是圣誕樹上的掛件。

其中需要更新的節(jié)點就是亮的彩燈。

如何找到亮的彩燈(需要更新的節(jié)點)呢?

從圣誕樹頂向下一個掛件一個掛件找么(從根節(jié)點依次向下遍歷)?

可行，但是效率太低。

為此，React的做法是：將需要更新的節(jié)點連接形成一條單鏈表。

查找時，只需要遍歷這條單鏈表就行。就像圣誕樹上的彩燈帶一樣。

這條彩燈帶(單鏈表)就是effect list。

計劃趕不上變化

effect list在React源碼中辛勤工作了2年。

但是，未來React新特性需要底層架構(gòu)支持遍歷整棵Fiber樹。

看我剛才的介紹，是不是去掉effect list，改為從根節(jié)點遍歷就行?

感覺這需求，我上我也行(并不是)。

于是，經(jīng)過一番內(nèi)部討論后，2020年7月7日，「bvaughn」老哥提了effect list改造相關(guān)的第一個PREffects list  refactor #19261

• 移除了effect list相關(guān)變量(firstEffect,lastEffect, nextEffect)

• 新增了subtreeTag標(biāo)記變量用于優(yōu)化遍歷Fiber樹的性能

感覺勝利在望，7月16日，老哥又繼續(xù)提了PR Effects list refactor continued: passive effects  traversal #19374

增加了對useEffect回調(diào)函數(shù)執(zhí)行流程的改動(沒錯，useEffect回調(diào)函數(shù)的執(zhí)行也屬于effect list的一個節(jié)點)

感覺勝利在望，OKR要到手了呢～

經(jīng)過漫長的測試、回歸，到了11月，Andrew發(fā)現(xiàn)effect  list的重構(gòu)造成某個指標(biāo)下降，但由于React源碼運行流程太過復(fù)雜，一時半會也查不出原因。

只能先回滾了，見PR Reset new fork to old fork #20254

今年1月中旬，終于驗證這個特性沒有問題，又重新改回去，見PR Re-land refactored implementation of layout  phase in new fork #20595

更難受的是，React源碼中為了區(qū)分新舊特性，每個文件都分為.new和.old兩個版本，每次勞動量都是雙份。

總結(jié)

兜兜轉(zhuǎn)轉(zhuǎn)，核心團隊2個成員從7月忙到第二年1月，每次PR，還需要其他成員review代碼。

終于將這個特性合并到master。

想想Andrew走在街上被React愛好者認(rèn)出來，親切詢問：嗨，Andrew，下半年你忙啥了?

Andrew：

從這個小feature的迭代歷程，你感受到React新特性迭代慢的原因了么?

到此，相信大家對“React新特性為什么產(chǎn)出這么慢”有了更深的了解，不妨來實際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進入相關(guān)頻道進行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！