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核心團(tuán)隊卓越的前瞻性和框架設(shè)計能力。
另一方面，不禁讓人質(zhì)疑，React新特性為啥產(chǎn)出這么慢?江郎才盡啦?
尤其是前段時間，React17經(jīng)過了2年的迭代終于發(fā)出穩(wěn)定版，但是卻沒有新增特性。
這個問題的標(biāo)準(zhǔn)答案恐怕只有React團(tuán)隊成員才知道。
不過，我們可以從源碼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階段的一個特性，選擇他的迭代歷程講解是因為：
- 他是源碼內(nèi)部的feature，對開發(fā)者不可知
- 表面上看起來這是一個不大的改動
- 他的改動是為了上層新特性而做的底層調(diào)整
什么是effect list
React內(nèi)部工作大體可以分為3個階段：
- 調(diào)度更新
- 決定什么組件需要更新
- 更新組件
那么第三步如何知道要更新哪些組件呢?靠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)，核心團(tuán)隊2個成員從7月忙到第二年1月，每次PR，還需要其他成員review代碼。
終于將這個特性合并到master。
想想Andrew走在街上被React愛好者認(rèn)出來，親切詢問：嗨，Andrew，下半年你忙啥了?
Andrew：
從這個小feature的迭代歷程，你感受到React新特性迭代慢的原因了么?
