說起數(shù)據(jù)加載的機制，有一個繞不開的話題就是前端性能，很多電商門戶的首頁其實都會做一些垂直的定制優(yōu)化，比如讓請求在頁面最早加載，或者在前一個頁面就進行預(yù)加載等等。隨著 react18 的發(fā)布，請求機制這一塊也是被不斷談起，并且在后續(xù)其實也給出了明確的方向。

假如我們頁面中有三個組件 C1、C2、C3 依次嵌套，每個組件中有對應(yīng)的請求 F1、F2、F3，通常大多數(shù)人會使用 useeffect 和 state 變量來實現(xiàn)數(shù)據(jù)流的獲取，這樣就意味著必須在組件加載時才能發(fā)起請求，所有數(shù)據(jù)獲取都發(fā)生在組件的生命周期中，如下圖所示，我們可以將這種獲取數(shù)據(jù)的方式稱作瀑布流渲染，但是這種方式有一個問題是，在這種方法中，組件之間的數(shù)據(jù)獲取是按順序進行的，這實際上意味著它們彼此阻塞，如果組件的層級嵌套很深的話，就會導致頁面的加載時間特別長。



為了阻止組件間數(shù)據(jù)獲取的這種順序阻塞，另一種方法就是在組件加載前可以使用 Promise.all 獲取所有的請求數(shù)據(jù)，這樣在組件加載時就已經(jīng)獲取到所有的數(shù)據(jù)了。這種方式解決了組件加載順序阻塞彼此數(shù)據(jù)流獲取的問題，但是也產(chǎn)生了一個新的問題，在請求完成之前頁面都會是空白的。



基于第二種先請求后渲染的方式，還可以使用 Suspense 將請求和渲染并行化，Suspense 可以使得組件可以 “等待” 某些操作結(jié)束后，再進行渲染。而這種方式如果要用到實際項目中，還需要考慮 C1、C2、C3 對應(yīng)的請求寫在哪里，如果寫在組件中，那么加載還是慢的。如果拆分出來，就需要考慮文件拆分、code splitting 等工程化問題。



在認真的分析了以上三種方式以后，發(fā)現(xiàn)各有優(yōu)劣，同時基于上述方案，我也提供一個請求優(yōu)化的思路，首先將請求的 JS 單獨拆分出來打一個文件 request.js，在 html 頭部引入 request.js 并使用 async 屬性讓腳本并行執(zhí)行 (如下代碼所示)，這樣既可以保證我們的請求在最開始就能發(fā)出，也能不阻塞后續(xù) React 代碼打包的 js 文件的執(zhí)行，相當請求和渲染的代碼在并行執(zhí)行。

// html頭部引入request.js

在發(fā)送完請求之后，需要將返回的數(shù)據(jù)注入到 React 組件中，這部分怎么注入呢？簡單的代碼示例如下：

// request.js 中請求部分 evt是發(fā)布訂閱模式的一個實例
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);
    return rs;
});

// index.js react代碼邏輯

…….

useEffect(()=> {
if (InitData.data !== null) {
    // 這里已經(jīng)獲取到了請求的返回值
doSomething();
} else {
InitData.on("init_data", (data)=> {
    // 利用發(fā)布訂閱模式獲取到數(shù)據(jù)
doSomething();
});
}
}, []);

…….