帥氣純真少年！日本最帥初中生選美冠軍出爐
日本第一帥哥初一生選美大賽冠軍現(xiàn)已正式出爐，冠軍是來(lái)自千葉縣的宗田悠良。日本一直熱衷于各種選美大賽，從“最美JK”起到“最美女星&r
出品 | 51CTO技術(shù)棧（微信號(hào)：blog51cto）
React的一個(gè)改動(dòng)細(xì)節(jié)引起了前端圈的聲討。
“這項(xiàng)改動(dòng)違背了React的第一設(shè)計(jì)原則！”
“這會(huì)顯著降低使用React框架的網(wǎng)站的性能。”
“這是一個(gè)令人惱火、無(wú)法理解的改動(dòng)！”
提起React，作為世界上最受歡迎和使用最多的UI框架，許多網(wǎng)絡(luò)“大牌”都有它的身影：不用提新潮一代的Netflix、Airbnb、Discord 等，僅誕生地Meta（Facebook、Instagram 和 Whatsapp）就已經(jīng)足夠讓其揚(yáng)名天下。
考慮到 React 用于創(chuàng)建數(shù)十億人使用的用戶界面，這樣說(shuō)也不為過(guò)：互聯(lián)網(wǎng)流量的很大一部分是由 React “處理”的。
這里的主要話題，正在討論的變化正是React19版本。
隨著React 19全新功能和 DX 改進(jìn)，處理并行fetching問(wèn)題的方式發(fā)生了變化：禁用了同一 Suspense 邊界內(nèi)兄弟節(jié)點(diǎn)的并行渲染。這實(shí)質(zhì)上為在這些兄弟節(jié)點(diǎn)內(nèi)部獲取的數(shù)據(jù)引入了數(shù)據(jù)獲取瀑布。
這個(gè)小變化起初并沒(méi)有引起人們注意，卻被被一位細(xì)心的前端大牛Dominik發(fā)現(xiàn)了發(fā)到海外社交媒體上，并表示這可能會(huì)顯著降低許多依賴 React 的網(wǎng)站的性能，一時(shí)間引起了網(wǎng)友們的鼎沸討論。
一切都從Dominik發(fā)的這條推文開(kāi)始：
圖片
帖子中指出：React19查詢現(xiàn)在是以瀑布形式運(yùn)行。
現(xiàn)在，對(duì)于那些不認(rèn)識(shí) Dominik（又名TkDodo）的人來(lái)說(shuō)，他與傳奇的Tanner Linsley一起是廣泛使用的TanStack Query的核心維護(hù)者之一。
一切都從這條推文開(kāi)始：
圖片
Dominik（又名TkDodo）何許人？他與傳奇的Tanner Linsley一起是廣泛使用的TanStack Query的核心維護(hù)者之一。
帖子中指出：React19在Suspense處理并行fetching的方式跟React18不一樣了？查詢現(xiàn)在是以瀑布形式運(yùn)行。
隨后引起了連鎖反應(yīng)：
1.“這是一個(gè)令人惱火，不可理解的改動(dòng)！不僅客戶端組件中也變動(dòng)了，甚至RSC中的并行fetch也變了。這對(duì)react-query而言是一場(chǎng)災(zāi)難。”
圖片
2.“可想而知，這也會(huì)影響lazily加載的組件（react.lazy）！”
圖片
3.我能理解Dominik的痛苦：這難道不違背React第一設(shè)計(jì)原則：compositon嗎？如果我理解正確的話，現(xiàn)在你無(wú)法再使用復(fù)雜的預(yù)取技巧來(lái)編寫(xiě)數(shù)據(jù)需求。或者你必須將所有數(shù)據(jù)提取提升到公共父級(jí)。
圖片
此次React 19禁用了同一 Suspense 邊界內(nèi)兄弟節(jié)點(diǎn)的并行渲染，這實(shí)質(zhì)上為在這些兄弟節(jié)點(diǎn)內(nèi)部獲取的數(shù)據(jù)引入了數(shù)據(jù)獲取瀑布。
以下是此類(lèi)事情的一個(gè)例子：
圖片
https://github.com/facebook/react/pull/26380#issuecomment-2166178673
所有這一切中最糟糕的是，除了性能會(huì)有嚴(yán)重下降，而且還將影響很多依賴這種模式的人，但只有一行項(xiàng)目符號(hào)毫不客氣地提到了這一變化。
很多人也許納悶：究竟是怎么回事？下面我們就細(xì)細(xì)道來(lái)。
為了理解這到底是什么，我們首先需要快速回顧一下 React 的 Suspense。
Suspense 是一個(gè) React 組件，它允許您顯示一個(gè)回退，直到其子組件完成加載，要么是因?yàn)檫@些子組件是延遲加載的，要么是因?yàn)樗鼈冋谑褂脝⒂?Suspense 的數(shù)據(jù)獲取機(jī)制。
使用方式如下：
<Suspense fallback={<Loading />}> <ComponentThatFetchesDataOrIsLazyLoaded /></Suspense>盡管 Suspense 已經(jīng)成為 React API 的一部分很長(zhǎng)一段時(shí)間了，但是在很長(zhǎng)一段時(shí)間內(nèi)，它的唯一官方批準(zhǔn)用途是使用來(lái)延遲加載組件React.lazy，這對(duì)于對(duì)應(yīng)用程序進(jìn)行代碼分割并僅在需要時(shí)加載分割的部分非常有用。
當(dāng)與 一起使用時(shí)，當(dāng)?shù)谝淮螄L試渲染延遲加載的組件時(shí)（即，在延遲加載之前），它會(huì)觸發(fā) Suspense 邊界（即包裝組件）并渲染回退，直到獲取組件的代碼完成，然后它會(huì)渲染組件React.lazySuspense本身。
長(zhǎng)期以來(lái)，我們一直被承諾在客戶端上為 Suspense 提供官方數(shù)據(jù)提取支持（使用 RSC 時(shí)，它已經(jīng)在服務(wù)器上運(yùn)行），但直到現(xiàn)在我們才真正實(shí)現(xiàn)它，盡管如此，許多庫(kù)（TanStack Query 就是其中之一）已經(jīng)通過(guò)研究 React 的內(nèi)部結(jié)構(gòu)實(shí)現(xiàn)了它。正因?yàn)槿绱耍壳吧a(chǎn)中有許多應(yīng)用程序確實(shí)使用Suspense在客戶端上進(jìn)行數(shù)據(jù)提取。
從現(xiàn)在起（React 18.3.1），當(dāng)在同一個(gè) Suspense 邊界內(nèi)使用啟用 Suspense 的數(shù)據(jù)獲取或延遲加載多個(gè)組件時(shí)，React 會(huì)在退出渲染之前嘗試渲染所有兄弟組件，即使第一個(gè)兄弟組件已暫停。
實(shí)際上，這意味著這些兄弟節(jié)點(diǎn)中發(fā)生的數(shù)據(jù)獲取或延遲加載將全部并行啟動(dòng)。
下面是一個(gè)展示這個(gè)想法的例子：
function App() { return ( <> <Suspense fallback={"Loading..."}> <ComponentThatFetchesData val={1} /> <ComponentThatFetchesData val={2} /> <ComponentThatFetchesData val={3} /> </Suspense> </> );}const ComponentThatFetchesData = ({ val }) => { const result = fetchSomethingSuspense(val); return <div>{result}</div>;};
圖片
演示地址：https://stackblitz.com/edit/vitejs-vite-x3nv7r?file=src%2FApp.jsx
在這個(gè)例子中（在 React 18 中），即使fetchSomethingSuspense導(dǎo)致第一個(gè)ComponentThatFetchesData暫停，React 仍然會(huì)嘗試渲染它的兄弟，這將觸發(fā)每個(gè)兄弟的并行數(shù)據(jù)獲取。
通過(guò)查看每次觸發(fā)數(shù)據(jù)提取時(shí)記錄的控制臺(tái)，可以看出：所有數(shù)據(jù)獲取幾乎同時(shí)開(kāi)始。
現(xiàn)在讓我們看看當(dāng)我們?cè)?React 19（canary）中運(yùn)行完全相同的代碼時(shí)會(huì)發(fā)生什么：
圖片
演示地址：https://stackblitz.com/edit/vitejs-vite-55rddj?file=src%2FApp.jsx
當(dāng)我們?cè)俅尾榭纯刂婆_(tái)時(shí)，我們注意到現(xiàn)在有一個(gè)瀑布，因?yàn)槊總€(gè)數(shù)據(jù)提取僅在前一個(gè)數(shù)據(jù)完成后才啟動(dòng)。
發(fā)生這種情況是因?yàn)橐韵?PR：
圖片
在該 PR 引入更改之后，React 不會(huì)嘗試渲染同一 Suspense 邊界內(nèi)的所有兄弟組件，而是會(huì)在第一個(gè)掛起的組件上放棄，在這種情況下，您會(huì)首先嘗試渲染第一個(gè)組件，然后它會(huì)掛起，然后只有在其數(shù)據(jù)獲取完成并且您可以渲染它之后，您才會(huì)到達(dá)下一個(gè)兄弟組件，它將再次掛起，依此類(lèi)推每個(gè)兄弟組件。
此外，這種新行為不僅會(huì)影響使用 Suspense 進(jìn)行數(shù)據(jù)提取的使用，還會(huì)影響使用React.lazy，因?yàn)檫@是一種舊模式，所以得到了官方支持并且更加廣泛。
圖片
這一變化背后的理由（在前面提到的 PR 中寫(xiě)明）是，在實(shí)際暫停之前嘗試渲染所有兄弟節(jié)點(diǎn)元素消耗，并且會(huì)延遲顯示回退。
此外，這一變化與React 團(tuán)隊(duì)自 React 18 之前引入 Suspense 以來(lái)一直在推動(dòng)的“獲取時(shí)渲染”方法相輔相成。
理想情況下，我們不應(yīng)該在使用它的同一組件的渲染上啟動(dòng)數(shù)據(jù)提取，而應(yīng)該將其提升并盡早開(kāi)始提取數(shù)據(jù)。
雖然從性能角度來(lái)看這無(wú)疑是最好的方法，但它確實(shí)帶來(lái)了顯著的 DX 缺陷，因?yàn)闊o(wú)法共置組件及其數(shù)據(jù)要求。
這里不會(huì)深入討論這個(gè)話題，因?yàn)橐呀?jīng)有很多人討論了它，甚至有一個(gè)專(zhuān)門(mén)為解決這個(gè)問(wèn)題而創(chuàng)建的庫(kù)，但這里推薦某條特定觀點(diǎn)的推文：
這里的主要內(nèi)容是，如果不使用編譯器，就不可能同時(shí)擁有最佳的性能特性以及組件及其數(shù)據(jù)需求的搭配，而這正是 Relay 所做的。
幸運(yùn)的是，這個(gè)故事有一個(gè)圓滿的結(jié)局。在經(jīng)歷了大量公眾反對(duì)、激烈討論以及幕后爭(zhēng)論之后，React 團(tuán)隊(duì)最終決定暫時(shí)推遲這一改變。
圖片
這并不是社區(qū)第一次反對(duì)在不考慮 React 在 Meta 和 Vercel 之外的使用方式的情況下引入的更改。React 團(tuán)隊(duì)（尤其是 Vercel）推動(dòng)將 RSC 成為使用 React 構(gòu)建的基本組成部分就是一個(gè)例子。
很明顯，React 維護(hù)者和社區(qū)對(duì)于 React 的未來(lái)前景的看法存在分歧。這些問(wèn)題溝通會(huì)有哪些進(jìn)展？后續(xù)還有待觀察。
本文鏈接：http://www.tebozhan.com/showinfo-26-97902-0.html全世界互聯(lián)網(wǎng)變慢了！React社區(qū)鬧翻天，官方最終讓步！
聲明：本網(wǎng)頁(yè)內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問(wèn)題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請(qǐng)聯(lián)系：2376512515@qq.com 津ICP備18001702號(hào)
津公網(wǎng)安備 12010102000574號(hào)