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

創新互聯公司-專業網站定制、快速模板網站建設、高性價比昌平網站開發、企業建站全套包干低至880元,成熟完善的模板庫,直接使用。一站式昌平網站制作公司更省心,省錢,快速模板網站建設找我們，業務覆蓋昌平地區。費用合理售后完善，10余年實體公司更值得信賴。

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

難度提升很大程度源于前端技術飛快的更新導致新技術加速出現，老技術加速淘汰。

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

作為前端領域最廣為人知的技術之一，React2015年被「Jordan Walke」創造出來。

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

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

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

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

尤其是前段時間，React17經過了2年的迭代終于發出穩定版，但是卻沒有新增特性。

這個問題的標準答案恐怕只有React團隊成員才知道。

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

新特性如何產出

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

開發者就像戰艦的船員，使用這些能力操縱戰艦的行為。

當React這艘戰艦需要開發新的能力，比如「高速航行」。

而「航行」依賴于戰艦的整套動力系統。

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

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

縱觀React歷史，將組件樹的render從同步(Legacy Mode)變為可中斷的異步(Concurrent Mode)，花了2年。

這其中包括：

• 將底層架構從遞歸(Stack Reconciler)變為遍歷(Fiber Reconciler)

• 實現調度器(Scheduler)

• 實現調度算法(ExpirationTime，現在改為Lanes)

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

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

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

為什么選擇effect list

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

1. 鴻蒙官方戰略合作共建——HarmonyOS技術社區

2. 他是源碼內部的feature，對開發者不可知

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

4. 他的改動是為了上層新特性而做的底層調整

什么是effect list

React內部工作大體可以分為3個階段：

1. 鴻蒙官方戰略合作共建——HarmonyOS技術社區

2. 調度更新

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

4. 更新組件

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

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

其中需要更新的節點就是亮的彩燈。

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

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

可行，但是效率太低。

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

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

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

計劃趕不上變化

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

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

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

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

于是，經過一番內部討論后，2020年7月7日，「bvaughn」老哥提了effect list改造相關的第一個PREffects list  refactor #19261

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

• 新增了subtreeTag標記變量用于優化遍歷Fiber樹的性能

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

增加了對useEffect回調函數執行流程的改動(沒錯，useEffect回調函數的執行也屬于effect list的一個節點)

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

經過漫長的測試、回歸，到了11月，Andrew發現effect  list的重構造成某個指標下降，但由于React源碼運行流程太過復雜，一時半會也查不出原因。

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

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

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

總結

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

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

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

Andrew：

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

到此，相信大家對“React新特性為什么產出這么慢”有了更深的了解，不妨來實際操作一番吧！這里是創新互聯網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！

文章標題：React新特性為什么產出這么慢
分享地址：http://m.newbst.com/article18/gohpdp.html

成都網站建設公司_創新互聯，為您提供ChatGPT、App開發、小程序開發、網站營銷、網站內鏈、網站建設

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯