來源 | OSCHINA 社區(qū)
作者 | 京東云開發(fā)者-京東零售 粱峰峰
原文鏈接：https://my.oschina.NET/u/4090830/blog/10098333
說起數(shù)據(jù)加載的機(jī)制，有一個(gè)繞不開的話題就是前端性能，很多電商門戶的首頁其實(shí)都會(huì)做一些垂直的定制優(yōu)化，比如讓請(qǐng)求在頁面最早加載，或者在前一個(gè)頁面就進(jìn)行預(yù)加載等等。隨著 react18 的發(fā)布，請(qǐng)求機(jī)制這一塊也是被不斷談起，并且在后續(xù)其實(shí)也給出了明確的方向。
假如我們頁面中有三個(gè)組件 C1、C2、C3 依次嵌套，每個(gè)組件中有對(duì)應(yīng)的請(qǐng)求 F1、F2、F3，通常大多數(shù)人會(huì)使用 useeffect 和 state 變量來實(shí)現(xiàn)數(shù)據(jù)流的獲取，這樣就意味著必須在組件加載時(shí)才能發(fā)起請(qǐng)求，所有數(shù)據(jù)獲取都發(fā)生在組件的生命周期中，如下圖所示，我們可以將這種獲取數(shù)據(jù)的方式稱作瀑布流渲染，但是這種方式有一個(gè)問題是，在這種方法中，組件之間的數(shù)據(jù)獲取是按順序進(jìn)行的，這實(shí)際上意味著它們彼此阻塞，如果組件的層級(jí)嵌套很深的話，就會(huì)導(dǎo)致頁面的加載時(shí)間特別長(zhǎng)。
為了阻止組件間數(shù)據(jù)獲取的這種順序阻塞，另一種方法就是在組件加載前可以使用 Promise.all 獲取所有的請(qǐng)求數(shù)據(jù)，這樣在組件加載時(shí)就已經(jīng)獲取到所有的數(shù)據(jù)了。這種方式解決了組件加載順序阻塞彼此數(shù)據(jù)流獲取的問題，但是也產(chǎn)生了一個(gè)新的問題，在請(qǐng)求完成之前頁面都會(huì)是空白的。
基于第二種先請(qǐng)求后渲染的方式，還可以使用 Suspense 將請(qǐng)求和渲染并行化，Suspense 可以使得組件可以 “等待” 某些操作結(jié)束后，再進(jìn)行渲染。而這種方式如果要用到實(shí)際項(xiàng)目中，還需要考慮 C1、C2、C3 對(duì)應(yīng)的請(qǐng)求寫在哪里，如果寫在組件中，那么加載還是慢的。如果拆分出來，就需要考慮文件拆分、code splitting 等工程化問題。
在認(rèn)真的分析了以上三種方式以后，發(fā)現(xiàn)各有優(yōu)劣，同時(shí)基于上述方案，我也提供一個(gè)請(qǐng)求優(yōu)化的思路，首先將請(qǐng)求的 JS 單獨(dú)拆分出來打一個(gè)文件 request.js，在 html 頭部引入 request.js 并使用 async 屬性讓腳本并行執(zhí)行 (如下代碼所示)，這樣既可以保證我們的請(qǐng)求在最開始就能發(fā)出，也能不阻塞后續(xù) React 代碼打包的 js 文件的執(zhí)行，相當(dāng)請(qǐng)求和渲染的代碼在并行執(zhí)行。
// html頭部引入request.js
<asyncsrc="/js/request.js"></>
在發(fā)送完請(qǐng)求之后，需要將返回的數(shù)據(jù)注入到 React 組件中，這部分怎么注入呢？簡(jiǎn)單的代碼示例如下：
// request.js 中請(qǐng)求部分 evt是發(fā)布訂閱模式的一個(gè)實(shí)例
window.InitData ={
data:null,
on:(msg,fn)=>evt .on(msg ,e =>fn(e )),
emit:(msg,data)=>evt .emit(msg ,data ),
};
fetch.then(rs =>{
InitData .data =rs ;
InitData .emit("init_data",rs );
returnrs ;
});
//index.js react代碼邏輯
…… .
useEffect(=>{
if(InitData .data !==null){
//這里已經(jīng)獲取到了請(qǐng)求的返回值
doSomething;
}else{
InitData .on("init_data",(data)=>{
//利用發(fā)布訂閱模式獲取到數(shù)據(jù)
doSomething;
});
}
},[]);
…… .
總體思路就是在 html 中最先加載單獨(dú)打包出來的請(qǐng)求文件并加入 async 屬性使腳本并行執(zhí)行，將返回的數(shù)據(jù)掛載到 window 下或者利用發(fā)布訂閱模式將數(shù)據(jù)注入到 react 組件中。這樣其實(shí)類似于邊請(qǐng)求邊渲染的模式，利用提前請(qǐng)求來減少加載的時(shí)間。后續(xù)也是希望能用工程化的方式去解決數(shù)據(jù)的請(qǐng)求機(jī)制。
未來的話在開發(fā)時(shí)肯定是更傾向于邊請(qǐng)求邊渲染的這種模式，在 React 的官網(wǎng)中也有說到未來計(jì)劃讓Suspense 處理更多的場(chǎng)景，包括獲取數(shù)據(jù)等等，在新發(fā)布的 React18 中 Suspense 也是支持了服務(wù)端渲染，包括近期開源的 remix 也都在優(yōu)化請(qǐng)求機(jī)制能夠讓應(yīng)用更快的加載。也歡迎有興趣的小伙伴一起來討論和實(shí)踐。
