建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
有人曾說(shuō)：每過(guò)一年，前端的入行難度提升一倍。
創(chuàng)新互聯(lián)公司自2013年起，先為?？诘确?wù)建站，?？诘鹊仄髽I(yè)，進(jìn)行企業(yè)商務(wù)咨詢(xún)服務(wù)。為?？谄髽I(yè)網(wǎng)站制作PC+手機(jī)+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問(wèn)題。
難度提升很大程度源于前端技術(shù)飛快的更新導(dǎo)致新技術(shù)加速出現(xiàn)，老技術(shù)加速淘汰。
但是，這里有個(gè)奇葩：React。
作為前端領(lǐng)域最廣為人知的技術(shù)之一，React2015年被「Jordan Walke」創(chuàng)造出來(lái)。
發(fā)展到今天，6年時(shí)間，不僅框架本身沒(méi)有沒(méi)落，框架所使用的JSX語(yǔ)法甚至已經(jīng)成了前端領(lǐng)域事實(shí)上的通用DSL。
在這激蕩的6年中，雖然前端領(lǐng)域天翻地覆，但是React的主要API和方法改動(dòng)卻很少。
這一方面展示了React核心團(tuán)隊(duì)卓越的前瞻性和框架設(shè)計(jì)能力。
另一方面，不禁讓人質(zhì)疑，React新特性為啥產(chǎn)出這么慢?江郎才盡啦?
尤其是前段時(shí)間，React17經(jīng)過(guò)了2年的迭代終于發(fā)出穩(wěn)定版，但是卻沒(méi)有新增特性。
這個(gè)問(wèn)題的標(biāo)準(zhǔn)答案恐怕只有React團(tuán)隊(duì)成員才知道。
不過(guò)，我們可以從源碼feature的迭代過(guò)程來(lái)管中窺豹。
新特性如何產(chǎn)出
如果把React比喻為一艘戰(zhàn)艦，他對(duì)外提供了「開(kāi)炮」、「航行」等能力。
開(kāi)發(fā)者就像戰(zhàn)艦的船員，使用這些能力操縱戰(zhàn)艦的行為。
當(dāng)React這艘戰(zhàn)艦需要開(kāi)發(fā)新的能力，比如「高速航行」。
而「航行」依賴(lài)于戰(zhàn)艦的整套動(dòng)力系統(tǒng)。
那么，一定會(huì)有大量動(dòng)力系統(tǒng)的改造工作需要先行完成。
前期改造工作需要做多長(zhǎng)時(shí)間呢?
縱觀React歷史，將組件樹(shù)的render從同步(Legacy Mode)變?yōu)榭芍袛嗟漠惒?Concurrent Mode)，花了2年。
這其中包括：
- 將底層架構(gòu)從遞歸(Stack Reconciler)變?yōu)楸闅v(Fiber Reconciler)
- 實(shí)現(xiàn)調(diào)度器(Scheduler)
- 實(shí)現(xiàn)調(diào)度算法(ExpirationTime，現(xiàn)在改為L(zhǎng)anes)
Fiber是如此出名，很多前端多聽(tīng)說(shuō)過(guò)。
今天，我們挑一個(gè)不出名的底層feature —— effect list。
讓我們看看他的迭代過(guò)程。
為什么選擇effect list
effect list是React源碼commit階段的一個(gè)特性，選擇他的迭代歷程講解是因?yàn)椋?/p>
- 他是源碼內(nèi)部的feature，對(duì)開(kāi)發(fā)者不可知
- 表面上看起來(lái)這是一個(gè)不大的改動(dòng)
- 他的改動(dòng)是為了上層新特性而做的底層調(diào)整
什么是effect list
React內(nèi)部工作大體可以分為3個(gè)階段：
- 調(diào)度更新
- 決定什么組件需要更新
- 更新組件
那么第三步如何知道要更新哪些組件呢?靠effect list。
如果將React Fiber樹(shù)比喻為圣誕樹(shù)，那么每個(gè)Fiber節(jié)點(diǎn)就是圣誕樹(shù)上的掛件。
其中需要更新的節(jié)點(diǎn)就是亮的彩燈。
如何找到亮的彩燈(需要更新的節(jié)點(diǎn))呢?
從圣誕樹(shù)頂向下一個(gè)掛件一個(gè)掛件找么(從根節(jié)點(diǎn)依次向下遍歷)?
可行，但是效率太低。
為此，React的做法是：將需要更新的節(jié)點(diǎn)連接形成一條單鏈表。
查找時(shí)，只需要遍歷這條單鏈表就行。就像圣誕樹(shù)上的彩燈帶一樣。
這條彩燈帶(單鏈表)就是effect list。
計(jì)劃趕不上變化
effect list在React源碼中辛勤工作了2年。
但是，未來(lái)React新特性需要底層架構(gòu)支持遍歷整棵Fiber樹(shù)。
看我剛才的介紹，是不是去掉effect list，改為從根節(jié)點(diǎn)遍歷就行?
感覺(jué)這需求，我上我也行(并不是)。
于是，經(jīng)過(guò)一番內(nèi)部討論后，2020年7月7日，「bvaughn」老哥提了effect list改造相關(guān)的第一個(gè)PREffects list refactor #19261
- 移除了effect list相關(guān)變量(firstEffect,lastEffect, nextEffect)
- 新增了subtreeTag標(biāo)記變量用于優(yōu)化遍歷Fiber樹(shù)的性能
感覺(jué)勝利在望，7月16日，老哥又繼續(xù)提了PR Effects list refactor continued: passive effects traversal #19374
增加了對(duì)useEffect回調(diào)函數(shù)執(zhí)行流程的改動(dòng)(沒(méi)錯(cuò)，useEffect回調(diào)函數(shù)的執(zhí)行也屬于effect list的一個(gè)節(jié)點(diǎn))
感覺(jué)勝利在望，OKR要到手了呢～
經(jīng)過(guò)漫長(zhǎng)的測(cè)試、回歸，到了11月，Andrew發(fā)現(xiàn)effect list的重構(gòu)造成某個(gè)指標(biāo)下降，但由于React源碼運(yùn)行流程太過(guò)復(fù)雜，一時(shí)半會(huì)也查不出原因。
只能先回滾了，見(jiàn)PR Reset new fork to old fork #20254
今年1月中旬，終于驗(yàn)證這個(gè)特性沒(méi)有問(wèn)題，又重新改回去，見(jiàn)PR Re-land refactored implementation of layout phase in new fork #20595
更難受的是，React源碼中為了區(qū)分新舊特性，每個(gè)文件都分為.new和.old兩個(gè)版本，每次勞動(dòng)量都是雙份。
總結(jié)
兜兜轉(zhuǎn)轉(zhuǎn)，核心團(tuán)隊(duì)2個(gè)成員從7月忙到第二年1月，每次PR，還需要其他成員review代碼。
終于將這個(gè)特性合并到master。
想想Andrew走在街上被React愛(ài)好者認(rèn)出來(lái)，親切詢(xún)問(wèn)：嗨，Andrew，下半年你忙啥了?
Andrew：
從這個(gè)小feature的迭代歷程，你感受到React新特性迭代慢的原因了么?
文章名稱(chēng)：React新特性為啥產(chǎn)出這么慢？江郎才盡啦？
當(dāng)前鏈接：http://www.5511xx.com/article/dhpgdoi.html
