新聞中心
大家好,我卡頌。

成都創(chuàng)新互聯(lián)公司從2013年創(chuàng)立,是專業(yè)互聯(lián)網(wǎng)技術(shù)服務公司,擁有項目成都網(wǎng)站設(shè)計、成都做網(wǎng)站網(wǎng)站策劃,項目實施與項目整合能力。我們以讓每一個夢想脫穎而出為使命,1280元青島做網(wǎng)站,已為上家服務,為青島各地企業(yè)和個人服務,聯(lián)系電話:028-86922220
雖然主流前端框架都遵循:
- 狀態(tài)驅(qū)動視圖
- 單向數(shù)據(jù)流
理論上并不存在某一框架可以實現(xiàn),其他框架無法實現(xiàn)的特性。
但是,確實存在某些框架(比如Vue、Qwik)可以,但React無法解決的問題。這就是「極致性能優(yōu)化」問題。
本文來聊聊React性能優(yōu)化無法解決的問題。
props下鉆
前端框架普遍遵循「單向數(shù)據(jù)流」。既然是單向數(shù)據(jù)流,那就存在跨組件傳遞props的情況。
這種情況被稱為「props下鉆」(props drilling)。
比如,在下面的應用中:
組件定義狀態(tài)number。 組件消費number。 組件包含改變number的方法setNumber。
這種將props(這里的number)層層向下傳遞(從
「props下鉆」是非常常見的場景。面對這種場景,React的性能怎么樣呢?
props下鉆的性能
思考一個問題:對于上面的例子,當調(diào)用
答案是:
這顯然與我們的預期不符。
直覺上看,起碼、
為了達到這個目標,我們需要使用React.memo包裹、
為了減少開發(fā)者的心智負擔,在2021年的React Conf,黃玄帶來了React Forget編譯器,他能夠為現(xiàn)有業(yè)務代碼生成等效于useMemo、useCallback的代碼。
也就是說,理想情況下,他能夠代替開發(fā)者完成React項目的性能優(yōu)化。
但是,回到我們的例子會發(fā)現(xiàn) —— 即使做了性能優(yōu)化,也無法達到最理想的狀態(tài)。
整個應用中只有
但在React中,即使性能優(yōu)化后,
而默認情況下(不優(yōu)化性能),整個應用都會render:
造成這一問題的原因在于 —— 對于任一狀態(tài),React不知道哪些組件依賴他。
在「props下鉆」場景下,雖然
那如果明確的表示依賴關(guān)系,是不是能解決這個問題呢?
比如,我們不使用props,而是在
遺憾的是,在React中context的實現(xiàn)也是依賴組件樹的遍歷(可以理解為React內(nèi)部實現(xiàn)的「props下鉆」),所以并不能解決這個問題。
Signal
解決這個問題的關(guān)鍵在于 —— 明確狀態(tài)與組件的依賴關(guān)系。
這種建立組件與狀態(tài)之間依賴關(guān)系的技術(shù)叫「響應式更新」(熟悉Vue的同學應該不陌生),也有些框架稱其為Signal。
應用這種技術(shù)的框架(比如Vue、Qwik),當狀態(tài)變化,只有依賴該狀態(tài)的組件會更新。
總結(jié)
正是由于React底層架構(gòu)的原因,導致應用的性能優(yōu)化無法達到最理想的狀態(tài)。
這同時也是為什么React中有很多性能優(yōu)化API(比如React.memo、useMemo、 useCallback...),而采用Signal技術(shù)的框架沒有這些性能優(yōu)化API的原因。
標題名稱:現(xiàn)有React架構(gòu)無法解決的問題
網(wǎng)站網(wǎng)址:http://www.5511xx.com/article/ccshpee.html


咨詢
建站咨詢
