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

創(chuàng)新互聯(lián)公司-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性價(jià)比昌平網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫,直接使用。一站式昌平網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋昌平地區(qū)。費(fèi)用合理售后完善，10余年實(shí)體公司更值得信賴。

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

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

但是，這里有個(gè)奇葩：React。

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

發(fā)展到今天，6年時(shí)間，不僅框架本身沒有沒落，框架所使用的JSX語法甚至已經(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)過了2年的迭代終于發(fā)出穩(wěn)定版，但是卻沒有新增特性。

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

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

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

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

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

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

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

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

前期改造工作需要做多長時(shí)間呢?

縱觀React歷史，將組件樹的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)在改為Lanes)

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

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

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

為什么選擇effect list

effect list是React源碼commit階段的一個(gè)特性，選擇他的迭代歷程講解是因?yàn)椋?/p>

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

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

3. 表面上看起來這是一個(gè)不大的改動(dòng)

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

什么是effect list

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

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

2. 調(diào)度更新

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

4. 更新組件

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

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

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

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

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

可行，但是效率太低。

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

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

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

計(jì)劃趕不上變化

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

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

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

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

于是，經(jīng)過一番內(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樹的性能

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

增加了對(duì)useEffect回調(diào)函數(shù)執(zhí)行流程的改動(dòng)(沒錯(cuò)，useEffect回調(diào)函數(shù)的執(zhí)行也屬于effect list的一個(gè)節(jié)點(diǎn))

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

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

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

今年1月中旬，終于驗(yàn)證這個(gè)特性沒有問題，又重新改回去，見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愛好者認(rèn)出來，親切詢問：嗨，Andrew，下半年你忙啥了?

Andrew：

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

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

文章標(biāo)題：React新特性為什么產(chǎn)出這么慢
分享地址：http://chinadenli.net/article18/gohpdp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供ChatGPT、App開發(fā)、小程序開發(fā)、網(wǎng)站營銷、網(wǎng)站內(nèi)鏈、網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)