91 - 《Bigfish 4 特性 03：默认最快的请求》

4 月会更新 20 篇 Bigfish 4（含 Umi 4）的新特性，这是第三篇。
本文是 CSR 的请求优化，不涉及 SSR。SSR 相关的会在后面找机会介绍。

可能有些同学会觉得这个功能杀鸡用牛刀，Bigfish 大部分应用是中台应用，使用者相比 C 端产品的耐受度高，产物大一点打开慢一点性能差一点无所谓。我理解这是 ROI 权衡后的无奈结果，又有谁不希望速度更快和体验更好呢？

本篇用一个例子和大家介绍问题和 Bigfish 的解。两个组件 A 和 B，A 嵌套 B，A 和 B 都有各自的请求和渲染逻辑。

现状

Bigfish 的现状是，除了做了特殊优化，大部分 Bigfish 应用的请求都在 useEffect 中发起请求，request hooks 可能是 useRequest、useSWR 等，请求库可能是 umi-request、axios 等。

renderA ▶ requestA ▶ renderB ▶ requestB

参考这个 DEMO， https://codesandbox.io/s/fast-glade-rqnhtt 。

这是最慢的请求，下一个要等上一个结束，也叫「请求瀑布」，在 React 文档中叫「Fetch-on-Render」。不仅如此，真实项目是要考虑工程化的，其中一点是产物如何加载，因为不管是请求发起还是渲染的逻辑，都来自于 JS 产物，而 JS 产物通常会基于路由做 code splitting，所以请求会变成这样。

loadInitialCode ▶ loadA ▶ renderA ▶ requestA ▶ loadB ▶ renderB ▶ requestB

默认最快的