大家好，我卡頌。

成都創(chuàng)新互聯(lián)公司從2013年創(chuàng)立，是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司，擁有項(xiàng)目成都網(wǎng)站設(shè)計、成都做網(wǎng)站網(wǎng)站策劃，項(xiàng)目實(shí)施與項(xiàng)目整合能力。我們以讓每一個夢想脫穎而出為使命，1280元青島做網(wǎng)站,已為上家服務(wù),為青島各地企業(yè)和個人服務(wù),聯(lián)系電話:028-86922220

雖然主流前端框架都遵循：

• 狀態(tài)驅(qū)動視圖
• 單向數(shù)據(jù)流

理論上并不存在某一框架可以實(shí)現(xiàn)，其他框架無法實(shí)現(xiàn)的特性。

但是，確實(shí)存在某些框架（比如Vue、Qwik）可以，但React無法解決的問題。這就是「極致性能優(yōu)化」問題。

本文來聊聊React性能優(yōu)化無法解決的問題。

props下鉆

前端框架普遍遵循「單向數(shù)據(jù)流」。既然是單向數(shù)據(jù)流，那就存在跨組件傳遞props的情況。

這種情況被稱為「props下鉆」（props drilling）。

比如，在下面的應(yīng)用中：

• 組件定義狀態(tài)number。
• 組件消費(fèi)number。
• 組件包含改變number的方法setNumber。

這種將props（這里的number）層層向下傳遞（從到）的情況，就是「props下鉆」：

「props下鉆」是非常常見的場景。面對這種場景，React的性能怎么樣呢？

props下鉆的性能

思考一個問題：對于上面的例子，當(dāng)調(diào)用中的setNumber方法改變number后，哪些組件會重新render？

答案是：的所有子孫組件都會重新render。

這顯然與我們的預(yù)期不符。

直覺上看，起碼、及其子孫組件不應(yīng)該render，畢竟他們都不依賴number。

為了達(dá)到這個目標(biāo)，我們需要使用React.memo包裹、，這顯然會帶來額外的心智負(fù)擔(dān)。

為了減少開發(fā)者的心智負(fù)擔(dān)，在2021年的React Conf，黃玄帶來了React Forget編譯器，他能夠?yàn)楝F(xiàn)有業(yè)務(wù)代碼生成等效于useMemo、useCallback的代碼。

也就是說，理想情況下，他能夠代替開發(fā)者完成React項(xiàng)目的性能優(yōu)化。

但是，回到我們的例子會發(fā)現(xiàn) —— 即使做了性能優(yōu)化，也無法達(dá)到最理想的狀態(tài)。

整個應(yīng)用中只有消費(fèi)了number，理想情況下，當(dāng)number變化后，應(yīng)該只有需要render。

但在React中，即使性能優(yōu)化后，與沿途的組件也會render：

而默認(rèn)情況下（不優(yōu)化性能），整個應(yīng)用都會render：

造成這一問題的原因在于 —— 對于任一狀態(tài)，React不知道哪些組件依賴他。

在「props下鉆」場景下，雖然與沿途的組件僅僅是傳遞number（而不是依賴他），但React無從得知。

那如果明確的表示依賴關(guān)系，是不是能解決這個問題呢？

比如，我們不使用props，而是在定義context number，再在中消費(fèi)number：

遺憾的是，在React中context的實(shí)現(xiàn)也是依賴組件樹的遍歷（可以理解為React內(nèi)部實(shí)現(xiàn)的「props下鉆」），所以并不能解決這個問題。