引言

如果你嘗試過對 React 中的數(shù)據(jù)獲取 (data fetching) 進(jìn)行一些思考，就會發(fā)現(xiàn)它涉及了眾多內(nèi)容：數(shù)據(jù)管理類庫層出不窮，是否要擁抱 GraphQL；useEffect 是引起瀑布流的禍?zhǔn)?，救世?Suspence 尚處于實(shí)驗(yàn)階段；fetch-on-render、 fetch-then-render 和 render-as-you-fetch 這些模式不由得讓人上頭。那么問題來了，在 React 中獲取數(shù)據(jù)的 “正確方式” 是什么？本文將給予解答。

數(shù)據(jù)獲取的分類

一般來說，在現(xiàn)代前端中，我們可以將 “數(shù)據(jù)獲取” 大致分為兩類：初始數(shù)據(jù)獲取 (initial data fetching) 和按需數(shù)據(jù)獲取 (data fetching on demand)。

按需數(shù)據(jù)獲取，是用戶和頁面發(fā)生交互后再請求數(shù)據(jù)，以便提高頁面的交互體驗(yàn)。所有的自動填充、動態(tài)表單和內(nèi)容搜索都屬于這一類數(shù)據(jù)。在 React 中，通常是在事件的回調(diào)函數(shù)中請求這些數(shù)據(jù)。

初始數(shù)據(jù)獲取，是在打開頁面時我們期望立刻能看到數(shù)據(jù)，我們要在組件出現(xiàn)在屏幕之前拿到這些數(shù)據(jù)。這些內(nèi)容對于用戶體驗(yàn)比較重要，需要盡快展示出來。在 React 中，通常是在 useEffect (或者 componentDidMount) 中來發(fā)起這類數(shù)據(jù)請求。

有趣的是，雖然它們在概念上看起來完全不同，但獲取數(shù)據(jù)的核心原則和基本模式是完全相同的。對于大部分人來說，初始數(shù)據(jù)獲取通常是至關(guān)重要的。在這一階段，你的應(yīng)用程序給用戶留下第一印象，要么是 “慢如黃牛” 要么是 “快如閃電”。正是因?yàn)檫@個原因，本文將用大量的篇幅來介紹初始數(shù)據(jù)獲取，以及如何在保證性能的前提下正確的實(shí)現(xiàn)數(shù)據(jù)獲取。

React 獲取數(shù)據(jù)與類庫支持

首先要回答一個問題，在 React 中要用第三方類庫來獲取數(shù)據(jù)嗎？是，也不是。這要取決于我們的具體場景，如果我們只是簡單的請求一次數(shù)據(jù)，那么就不需要第三方庫支持。在 useEffect 中直接使用 fetch 即可：

const Component = () => {
  const [data, setData] = useState();
  useEffect(() => {
    // fetch data
    const dataFetch = async () => {
      const data = await (
        await fetch(
          "https://run.mocky.io/v3/b3bcb9d2-d8e9-43c5-bfb7-0062c85be6f9"
        )
      ).json();
      // set state when the data received
      setState(data);
    };
    dataFetch();
  }, []);
  return <>...</>
}

但是當(dāng)我們的場景變得復(fù)雜時，就會面臨一些棘手的問題。錯誤處理要怎么實(shí)現(xiàn)？如何處理多個組件從同一個接口獲取數(shù)據(jù)？這些數(shù)據(jù)是否要緩存？緩存時間是多久？競態(tài)問題 (race conditions) 要如何處理？如果要從屏幕上刪除組件，那該怎么辦？應(yīng)該取消這次請求嗎？內(nèi)存泄漏又要怎么解決？問題諸如此類。

上面提出的問題并不只是針對于 React，這些是網(wǎng)絡(luò)請求中數(shù)據(jù)獲取的常見問題。解決這些問題（還有更多）只有兩條路：要么重新發(fā)明輪子編寫大量代碼來解決這些問題，要么依靠一些已經(jīng)存在的成熟類庫。

這些類庫，比如 axios，將對一些功能進(jìn)行抽象和封裝，如請求取消等，但是并不提供針對 React 的 API。其他類庫，比如 swr，將為我們處理了幾乎所有的事情，包括緩存。但本質(zhì)上，技術(shù)的選擇在這里并不重要。世界尚不存在這樣的類庫，僅通過自身就能提高應(yīng)用程序的性能。它們只是讓一些事情變得更容易，同時也讓另外一些事情變得更困難。為了編寫高性能的應(yīng)用程序，我們始終需要了解數(shù)據(jù)獲取的基礎(chǔ)知識和數(shù)據(jù)編排的模式以及其他相關(guān)的技術(shù)。

React 應(yīng)用的性能

在介紹具體模式和代碼示例之前，讓我們先討論一下應(yīng)用的 “性能” 到底是什么。你如何確定這個應(yīng)用的 “性能” 是否良好呢？對于一個簡單的組件來說，相對比較直觀的：只需要測量渲染的耗時即可。數(shù)字越小，組件 “性能” 越好（速度更快）。數(shù)據(jù)獲取屬于典型的異步操作，在大型應(yīng)用中從用戶體驗(yàn)角度來看性能，就不是那么直觀了。

假設(shè)我們正在開發(fā)一個用來追蹤 issue 的應(yīng)用。頁面的左側(cè)是一個 Sidebar 側(cè)邊欄，展示了一個鏈接列表；中間部分是主內(nèi)容區(qū)，它的上半部分是用于展示 issue 的詳情區(qū)，比如標(biāo)題、描述等；issue 詳情區(qū)的下方是評論區(qū)。

假如這個應(yīng)用程序用下面三種不同的方式來實(shí)現(xiàn)：

• 展示一個 loading 狀態(tài)，直至所有數(shù)據(jù)加載完畢，然后一次性渲染出所有數(shù)據(jù)。大約花費(fèi)了 3s。
• 展示一個 loading 狀態(tài)，側(cè)邊欄的數(shù)據(jù)加載完成后，渲染出側(cè)邊欄，然后繼續(xù)保持 loading 狀態(tài)，直到中間的內(nèi)容區(qū)域的數(shù)據(jù)加載完成。側(cè)邊欄的需要 1s 的時間完成渲染，其他部分需要 3s 的時間。加到一起，大約花費(fèi)了 4s。
• 展示一個 loading 狀態(tài)，加載完主內(nèi)容區(qū)的 issue 并渲染它，保持 loading 狀態(tài)并加載側(cè)邊欄和評論的數(shù)據(jù)。側(cè)邊欄完成數(shù)據(jù)請求和渲染之后，繼續(xù)為評論數(shù)據(jù)的加載保持 loading 狀態(tài)。issue 的加載和渲染需要 2s，sidebar 在它之后需要 1s，評論需要額外的 2s 完成渲染。共計花費(fèi)了 5s。

那么這個頁面用哪種方案來實(shí)現(xiàn)的性能會更高呢？你是怎么認(rèn)為的呢？當(dāng)然，這個答案很棘手，還是要依據(jù)具體情況而定：

第一種實(shí)現(xiàn)方案總共花費(fèi) 3s，是所有實(shí)現(xiàn)方案中最快的。單純從數(shù)字的角度來看，毫無疑問它是勝出的。但是，在 3s 的時間里，它沒有為用戶呈現(xiàn)任何內(nèi)容，這段白屏也是所有實(shí)現(xiàn)方案中最長的。

第二種實(shí)現(xiàn)方案只用了 1s 就在頁面上顯示出了一部分內(nèi)容（Sidebar）。從盡可能快地展示內(nèi)容的角度來看，它無疑是勝出的。但是，它是所有方案中主內(nèi)容區(qū)耗時最長的。

第三種實(shí)現(xiàn)方案中，首先完成了主內(nèi)容區(qū)的 issue 加載。從主內(nèi)容區(qū)的加載速度來看，它是勝出的。但是，在從左到右的語言中，信息的自然流動方向是從左上到右下。這也是我們通常的閱讀方式。這個頁面違反了這個這個規(guī)則，這帶來了最糟糕的用戶體驗(yàn)。除此之外，它的加載時間是最長的。

對于方案的選擇，通常取決于我們要向用戶傳遞什么樣的信息。把自己當(dāng)作一個講故事的人，而頁面就是我們要講述的故事。這個故事中最重要的部分是什么呢？次重要的部分又是什么呢？故事的情節(jié)是否連貫?zāi)兀磕闶窍氩鸾獬刹煌恼鹿?jié)講述呢，還是立刻讓用戶看到故事的全貌呢？

只有當(dāng)你對故事的樣子有所了解，才是將故事整合在一起，并盡可能快地優(yōu)化故事的時候。同理，應(yīng)用的性能優(yōu)化也是如此。而讓我們解決問題的不是各種類庫，Graphql 或 Suspense，而是下面的知識：

• 開始數(shù)據(jù)獲取的合適的時機(jī)是什么？
• 在數(shù)據(jù)獲取正在進(jìn)行時，我們能做些什么？
• 在數(shù)據(jù)獲取完成之后，我們應(yīng)該做些什么？

以及使用一些技術(shù)手段，讓我們在這三個階段中控制數(shù)據(jù)請求。但在開始介紹這些技術(shù)之前，我們需要了解兩個更基礎(chǔ)的內(nèi)容：React 生命周期和瀏覽器資源，以及其對我們目標(biāo)的影響。

React 生命周期與數(shù)據(jù)獲取

在我們設(shè)計數(shù)據(jù)請求的方案時，需要特別注意 React 生命周期被觸發(fā)的時機(jī)。比如下面的代碼：

const Child = () => {
  useEffect(() => {
    // do something here, like fetching data for the Child
  }, []);
  return <div>Some child</div>
};
const Parent = () => {
  // set loading to true initially
  const [isLoading, setIsLoading] = useState(true);
  if (isLoading) return 'loading';
  return <Child />;
}

在 Parent 組件中，Child 組件能否渲染取決于 state 的值。在 Child 組件中，useEffect 里的數(shù)據(jù)請求會被觸發(fā)嗎？很明顯不會被觸發(fā)。只有 Parent 組件中的 isLoading 被置為 false 時，Child 組件才會被渲染并且觸發(fā)數(shù)據(jù)請求。那么再看下面的這段代碼：

const Parent = () => {
  // set loading to true initially
  const [isLoading, setIsLoading] = useState(true);
  // child is now here! before return
  const child = <Child />;
  if (isLoading) return 'loading';
  return child;
}

功能基本完全一致：當(dāng) isLoading 被置為 false 時 展示 Child，如果為 true 則展示 loading 狀態(tài)。不同的是，把 <Child /> 元素放在了 if 條件的前面。這樣改變之后，Child 組件中的 useEffect 會被觸發(fā)嗎？答案不是那么明顯，我看到過很多人在這里糾結(jié)。答案同樣是不能觸發(fā)請求。

盡管我們寫下了 const child = <Child /> 這樣的代碼，但是這句代碼并不會渲染組件。<Child/> 只不過是一種語法糖，在函數(shù)中用來描述將要創(chuàng)建的元素。只有這種描述信息在實(shí)際可見的渲染樹中，它才會被渲染 -- 比如在組件中作為返回值。在這之前，它什么都不做，安安靜靜地待在那里。

當(dāng)然，還有許多關(guān)于 React 生命周期的事情需要了解：生命周期觸發(fā)的順序是怎樣的，繪制之前和之后會觸發(fā)哪些內(nèi)容，是什么減慢了什么以及如何觸發(fā)的，LayoutEffect 鉤子怎樣使用等等。但是，當(dāng)你已經(jīng)很好地協(xié)調(diào)了所有事情，在一個復(fù)雜的應(yīng)用中掙扎了幾秒之后，所有這些就會變得密切相關(guān)了。在這里就不展開討論這個問題了，否則這篇文章會變成一本書。

瀏覽器限制和數(shù)據(jù)獲取

也許你會有這樣的想法：這太復(fù)雜了，難道我們就不能盡快發(fā)出所有請求，并且將數(shù)據(jù)放入某個全局存儲，然后在可用時使用它？為什么還要為生命周期和請求編排而煩惱呢？

是的，如果這個應(yīng)用程序很簡單，并且只需要很少的請求，我們確實(shí)可以這樣做。但在大型應(yīng)用程序中，我們可能有幾十個數(shù)據(jù)請求，這種實(shí)現(xiàn)方案很可能適得其反。甚至忽視了服務(wù)器的負(fù)載能否可以處理。假設(shè)服務(wù)器可以，問題是我們的瀏覽器卻不能！

你知道嗎，瀏覽器對相同 host 可以處理的并行請求數(shù)是有限制的。假設(shè)服務(wù)器是 HTTP1（仍占互聯(lián)網(wǎng)的70%），那么這個數(shù)字并沒有那么大。在 Chrome 中，最多只能有 6 個并行請求！如果你同時發(fā)起更多請求，剩下的所有請求都必須排隊，等待可以發(fā)送請求的時機(jī)。

在一個大型應(yīng)用程序中，有 6 個以上的初始數(shù)據(jù)獲取請求并非不合理。在我們上面提到的非常簡單的 “追蹤 issue 應(yīng)用” 示例中已經(jīng)有 3 個請求了，我們甚至還沒有實(shí)現(xiàn)任何有價值的東西。

想象一下，如果你只是添加了一個稍微慢一些的用于數(shù)據(jù)分析的請求，在應(yīng)用的最開始它幾乎什么都不做，最終它卻減慢整個體驗(yàn)，你會不會整個人都不好了。

下面是一個比較簡單代碼：

const App = () => {
  // I extracted fetching and useEffect into a hook
  const { data } = useData('/fetch-some-data');
  if (!data) return 'loading...';
  return <div>I'm an app</div>
}

假如在 App 中的數(shù)據(jù)請求非?？?，只用了 50ms。如果在 App 之前再加 6 個請求，每個請求耗時都是 10s，那么整個 App 的加載時間也要花費(fèi) 10s (當(dāng)然這里是在 Chrome 瀏覽器中運(yùn)行)。

// no waiting, no resolving, just fetch and drop it
fetch('https://some-url.com/url1');
fetch('https://some-url.com/url2');
fetch('https://some-url.com/url3');
fetch('https://some-url.com/url4');
fetch('https://some-url.com/url5');
fetch('https://some-url.com/url6');
const App = () => {
  ... same app code
}

假如我們刪除其中某個請求，那么請求的時間就會降低很多。

出現(xiàn)請求瀑布流的原因

最后，是時候認(rèn)真編碼了！現(xiàn)在，我們已經(jīng)擁有了所有需要的技術(shù)，并知道它們是如何組合在一起的，是時候開始編寫我們的 Issue 追蹤應(yīng)用了。讓我們來完成這個示例，看看如何講述這個故事。

讓我們首先完成組件布局，然后再進(jìn)行數(shù)據(jù)獲取。我們先實(shí)現(xiàn)應(yīng)用的 App 組件，它將渲染 Sidebar 和 Issue，Issue 中渲染評論 Comments。

const App = () => {
  return (
    <>
      <Sidebar />
      <Issue />
    </>
  )
}
const Sidebar = () => {
  return // some sidebar links
}
const Issue = () => {
  return <>
    // some issue data
    <Comments />
  </>
}
const Comments = () => {
  return // some issue comments
}

現(xiàn)在來實(shí)現(xiàn)獲取數(shù)據(jù)功能，首先將 fetch、useEffect 和狀態(tài)管理封裝到一個自定義 hook 中，代碼如下：

export const useData = (url) => {
  const [state, setState] = useState();
  useEffect(() => {
    const dataFetch = async () => {
      const data = await (await fetch(url)).json();
      setState(data);
    };
    dataFetch();
  }, [url]);
  return { data: state };
};

然后，我們將在更大的組件中請求數(shù)據(jù)：在 Issue 組件中請求 issue 數(shù)據(jù)，在 Comments 組件中請求評論列表。當(dāng)然，還要在等待請求結(jié)果的過程中展示 loading 狀態(tài)：

const Comments = () => {
  // fetch is triggered in useEffect there, as normal
  const { data } = useData('/get-comments');
  // show loading state while waiting for the data
  if (!data) return 'loading';
  // rendering comments now that we have access to them!
  return data.map(comment => <div>{comment.title}</div>)
}

在 Issue 中完成同樣的代碼，并且在 loading 結(jié)束之后，渲染 Comments 組件：

const Issue = () => {
  // fetch is triggered in useEffect there, as normal
  const { data } = useData('/get-issue');
  // show loading state while waiting for the data
  if (!data) return 'loading';
  // render actual issue now that the data is here!
  return (
    <div>
      <h3>{data.title}</h3>
      <p>{data.description}</p>
      <Comments />
    </div>
  )
}

App 的代碼如下：

const App = () => {
  // fetch is triggered in useEffect there, as normal
  const { data } = useData('/get-sidebar');
  // show loading state while waiting for the data
  if (!data) return 'loading';
  return (
    <>
      <Sidebar data={data} />
      <Issue />
    </>
  )
}

當(dāng)運(yùn)行這段示例代碼，你會發(fā)現(xiàn)執(zhí)行起來很慢。我們這里所實(shí)現(xiàn)的是一個比較經(jīng)典的請求瀑布流。還記得上面提到的 React 生命周期嗎？組件只有作為返回值被返回時，才會被掛載和渲染，然后再去執(zhí)行組件內(nèi)部的 useEffect 和 數(shù)據(jù)請求。在這個實(shí)現(xiàn)方案中，各個組件在等待請求結(jié)果時，都返回的是 loading 狀態(tài)。只有數(shù)據(jù)加載完成后，子組件才開始在組件樹中渲染。然后子組件開始請求數(shù)據(jù)，展示 loading 狀態(tài)，重復(fù)著和父組件一樣的過程。

當(dāng)我們想要盡快的展示應(yīng)用頁面時，像這樣的瀑布流請求并不是一個好的解決方案。幸運(yùn)的是，還有其他的方法來處理這個問題。

解決請求瀑布流的方案

Promise.all 方案

最簡單的解決方案是，將這些請求盡可能的放在組件樹的最頂層。在我們的示例中，這個最外層就是根組件 App。值得注意的是，我們并不是簡簡單單的將代碼“換”個位置，還需要做一些額外的處理，像比如下面的代碼是不行的：

useEffect(async () => {
  const sidebar = await fetch('/get-sidebar');
  const issue = await fetch('/get-issue');
  const comments = await fetch('/get-comments');
}, [])

這是另外一種形式的瀑布流，只不過它位于一個組件中。當(dāng)我們請求 sidebar 數(shù)據(jù)時會 await，當(dāng)我們請求 issue 數(shù)據(jù)時會 await，請求 comment 數(shù)據(jù)時也會 await。當(dāng)所有數(shù)據(jù)都可用時才會開始渲染，這個過程要等待的時間：1s + 2s + 3s = 6s。我們要做的是將所有請求同時發(fā)出，以并行的方式請求數(shù)據(jù)。這些請求中用時最長的時間，就是我們要等待的時間：3s，這樣我們的性能就提升了 50%。

可以使用 Promise.all 來實(shí)現(xiàn)：

useEffect(async () => {
  const [sidebar, issue, comments] = await Promise.all([
    fetch('/get-sidebar'),
    fetch('/get-issue'),
    fetch('/get-comments')
  ])
}, [])

然后在父組件中把數(shù)據(jù)提供給 state 并通過 props 傳遞給子組件：

const useAllData = () => {
  const [sidebar, setSidebar] = useState();
  const [comments, setComments] = useState();
  const [issue, setIssue] = useState();
  useEffect(() => {
    const dataFetch = async () => {
      // waiting for allthethings in parallel
      const result = (
        await Promise.all([
          fetch(sidebarUrl),
          fetch(issueUrl),
          fetch(commentsUrl)
        ])
      ).map((r) => r.json());
      // and waiting a bit more - fetch API is cumbersome
      const [sidebarResult, issueResult, commentsResult] = await Promise.all(
        result
      );
      // when the data is ready, save it to state
      setSidebar(sidebarResult);
      setIssue(issueResult);
      setComments(commentsResult);
    };
    dataFetch();
  }, []);
  return { sidebar, comments, issue };
};
const App = () => {
  // all the fetches were triggered in parallel
  const { sidebar, comments, issue } = useAllData()
  // show loading state while waiting for all the data
  if (!sidebar || !comments || !issue) return 'loading';
  // render the actual app here and pass data from state to children
  return (
    <>
      <Sidebar data={state.sidebar} />
      <Issue comments={state.comments} issue={state.issue} />
    </>
  )
}

這也是我們在本文開始介紹的第一種方案的實(shí)現(xiàn)方式。

并行 Promise 方案

如果我們不想等到所有的數(shù)據(jù)請求都完成，該如何處理呢？comments 的請求比較慢，而且在頁面中并不重要，因?yàn)樗枞?sidebar 渲染，是極其不明智的。是否能所有請求同時發(fā)出，各個組件獨(dú)自等待各自的請求結(jié)果嗎？

當(dāng)然可以，只需將這些 fetch 從 async/await 轉(zhuǎn)移到 Promise.then，在 then 的回調(diào)函數(shù)中處理數(shù)據(jù)。

fetch('/get-sidebar').then(data => data.json()).then(data => setSidebar(data));
fetch('/get-issue').then(data => data.json()).then(data => setIssue(data));
fetch('/get-comments').then(data => data.json()).then(data => setComments(data));

現(xiàn)在每個 fetch 請求都是并行的，在 App 的 render 函數(shù)中我們可用做更多的事情，比如：只要請求的數(shù)據(jù)給到 state，就可以渲染 SiderBar 和 Issue：

const App = () => {
  const { sidebar, issue, comments } = useAllData();
  // show loading state while waiting for sidebar
  if (!sidebar) return 'loading';
  // render sidebar as soon as its data is available
  // but show loading state instead of issue and comments while we're waiting for them
  return (
    <>
      <Sidebar data={sidebar} />
      <!-- render local loading state for issue here if its data not available -->
      <!-- inside Issue component we'd have to render 'loading' for empty comments as well -->
      {issue ? <Issue comments={comments} issue={issue} /> : 'loading''}
    </>
  )
}

在這個代碼中，只要數(shù)據(jù)準(zhǔn)備好就可以渲染 Sidebar、Issue 和 Comments 組件。這與前面提到的瀑布的行為完全相同。但是由于我們并行的觸發(fā)請求，總耗時從 6s 降低至 3s。我們大幅的提升了它的性能，同時保證了功能不受影響。

還有一件事不得不提，在這個方案中觸發(fā)了三次 state 變化，這會引起父組件三次重新渲染?？紤]到這些重新渲染發(fā)生在頂層組件，像這樣不必要的重新渲染會引起 App 中較多不必要的重新渲染。始終要牢記，組件的順序和組件的大小都會對性能產(chǎn)生影響。想要了解如何解決不必要的重新渲染，可以參考 React 重新渲染指南。

Data providers 抽象封裝數(shù)據(jù)獲取

像上面示例代碼中那樣，將數(shù)據(jù)加載提升到頂層組件，雖然在性能方面有很大的提升，但是對于應(yīng)用架構(gòu)和代碼可讀性來說簡直就是噩夢。把所有的數(shù)據(jù)請求和大量的 props 放在一起，讓我們得到了一個巨石組件。

存在一種簡單的方案：可以為頁面引入 “data providers” 的概念。在這里，data providers 是對數(shù)據(jù)請求的一種抽象，能讓我們在 app 中的某個地方請求數(shù)據(jù)，然后在其他地方訪問數(shù)據(jù)，可以繞過中間的所有組件。本質(zhì)上就像為每個請求做了一層迷你的緩存。在原生的 React 中，它其實(shí)就是一個 context：

const Context = React.createContext();
export const CommentsDataProvider = ({ children }) => {
  const [comments, setComments] = useState();
  useEffect(async () => {
    fetch('/get-comments').then(data => data.json()).then(data => setComments(data));
  }, [])
  return (
    <Context.Provider value={comments}>
      {children}
    </Context.Provider>
  )
}
export const useComments = () => useContext(commentsContext);

這三個請求中的邏輯完全相同，由于篇幅原因其他兩個的代碼不在這里列出。然后將我們的巨石組件 App 改造得更簡單：

const App = () => {
  const sidebar = useSidebar();
  const issue = useIssue();
  // show loading state while waiting for sidebar
  if (!sidebar) return 'loading';
  // no more props drilling for any of those
  return (
    <>
      <Sidebar />
      {issue ? <Issue /> : 'loading''}
    </>
  )
}

用這三個的 provider 來包裹 App 組件，只要它們被掛載，就會立即并行請求數(shù)據(jù)：

export const VeryRootApp = () => {
  return (
    <SidebarDataProvider>
      <IssueDataProvider>
        <CommentsDataProvider>
          <App />
        </CommentsDataProvider>
      </IssueDataProvider>
    </SidebarDataProvider>
  )
}

在像 Comments 這種組件中（層級比較深的組件），只需通過 “data provider” 來訪問數(shù)據(jù)：

const Comments = () => {
  // Look! No props drilling!
  const comments = useComments();
}

在 React 之前請求數(shù)據(jù)

關(guān)于瀑布流問題，最后一條要了解的技巧。把數(shù)據(jù)請求放在 React 前面，會發(fā)生什么。這是一個非常危險的做法，需要謹(jǐn)慎的去使用。

讓我們再回顧一下 Comments 組件，在我們解決瀑布流問題的第一個方案中，在組件內(nèi)部進(jìn)行數(shù)據(jù)請求和處理：

const Comments = () => {
  const [data, setData] = useState();
  useEffect(() => {
    const dataFetch = async () => {
      const data = await (await fetch('/get-comments')).json();
      setData(data);
    };
    dataFetch();
  }, [url]);
  if (!data) return 'loading';
  return data.map(comment => <div>{comment.title}</div>)
}

注意第 6 行代碼，fetch('/get-comments') 是一個在 useEffect await 的 promise。在這個場景中，它并不依賴 React 的任何東西，沒有 對 props、state 或者其他內(nèi)部變量有依賴。所以，把它移動到最頂部，放在聲明 Comments 組件之前，會發(fā)生什么呢？并且然后在 useEffect 中 await 這個 promise 呢？

const commentsPromise = fetch('/get-comments');
const Comments = () => {
  useEffect(() => {
    const dataFetch = async () => {
      // just await the variable here
      const data = await (await commentsPromise).json();
      setState(data);
    };
    dataFetch();
  }, [url]);
}

發(fā)生了有趣的事情：fetch 基本上 “逃離” 了所有的 React 生命周期，只要頁面加載完 JavaScript 就會進(jìn)行數(shù)據(jù)請求，這時任何的 useEffect 還未被執(zhí)行，甚至根組件 App 中的第一個請求也還未被發(fā)出。當(dāng)這個請求發(fā)出去之后，JavaScript 進(jìn)程會去處理其他事情，而返回的數(shù)據(jù)會安靜地等待著被 resolve。我們在 Comments 的 useEffect 中做進(jìn)行 resolve。

再看一下第一個方案的瀑布流的圖：

將 fetch 移到 Comments 的外面：

從技術(shù)角度來講，可以將所有的 promise 移到組件的外面，這樣就可以解決瀑布流的問題，這樣就不需要做請求提升和 data providers。

但是為什么我們不去這樣做呢？為什么它不是一種通用的模式呢？

還記得上面提到的瀏覽器限制嗎，最多只能支持 6 個請求并行發(fā)出，剩下的請求要放到隊列中等待。像這種在 React 組件外部發(fā)出的請求，完全是不可控的。在應(yīng)用程序中，一個請求大量數(shù)據(jù)的組件，基本不可能立即開始渲染，以 “傳統(tǒng)” 瀑布方法實(shí)現(xiàn)該組件，在實(shí)際渲染之前不會打擾任何人。但如果使用這種 hack 方式，會存在那些關(guān)鍵的數(shù)據(jù)可能被阻塞的風(fēng)險。那么就會帶來這樣的問題：位于某個角落里毫不起眼、甚至還未被渲染的組件會拖慢整個應(yīng)用頁面。

對于這種模式，我只能想到兩種 “適用” 場景：在路由層預(yù)加載一些關(guān)鍵資源，以及在 lazy-loaded 組件中預(yù)請求數(shù)據(jù)。

在第一種情況下，您實(shí)際上需要盡快獲取數(shù)據(jù)，并且您肯定知道數(shù)據(jù)是比較關(guān)鍵的，并且是立即需要的。而且，lazy-loaded 組件的 JavaScript 只有在它們最終出現(xiàn)在呈現(xiàn)樹中時才會被下載和執(zhí)行，所以根據(jù)定義，在獲取和呈現(xiàn)所有關(guān)鍵數(shù)據(jù)之后。所以它是安全的。

使用第三方類庫做數(shù)據(jù)獲取

直到現(xiàn)在為止，在上面的所有的代碼示例中，我們使用的都是原生 fetch。目的是為了演示 React 中基礎(chǔ)的數(shù)據(jù)請求模式，以及這些模式與類庫無關(guān)的。無論你使用了和將要使用哪種第三方類庫，瀑布流方法的原則、在 React 生命周期內(nèi)外獲取數(shù)據(jù)的方法始終是一致的。

Axios 這樣和 React 無關(guān)的類庫，是在 fetch 的基礎(chǔ)上做了更復(fù)雜的抽象。我們可以將示例中的 fetch 更換為 axios.get，示例代碼的運(yùn)行結(jié)果不會有任何變化。

還有一些與 React 集成的類庫，使用了 hooks 和 query-like API，比如 swr 抽象處理了更多的東西： useCallback、state、以及錯誤處理和緩存等。而不是像下面這樣一大坨代碼，需要實(shí)現(xiàn)很多東西才能用于生產(chǎn)環(huán)境：

const Comments = () => {
  const [data, setData] = useState();
  useEffect(() => {
    const dataFetch = async () => {
      const data = await (await fetch('/get-comments')).json();
      setState(data);
    };
    dataFetch();
  }, [url]);
  // the rest of comments code
}

使用 swr 則簡單明了：

const Comments = () => {
  const { data } = useSWR('/get-comments', fetcher);
  // the rest of comments code
}

所有的事情都在底層處理好了：使用 useEffect 請求數(shù)據(jù)，將數(shù)據(jù)更新至 state，觸發(fā)組件重新渲染。

關(guān)于 Suspense

在介紹 React 數(shù)據(jù)獲取時，如果不提一下 Suspence，是不完整的。所以 Suspense 解決了哪些數(shù)據(jù)獲取方面的問題？并沒有解決多少問題。在寫這篇文章時，Suspense 數(shù)據(jù)獲取還是實(shí)驗(yàn)特性，所以我不建議在任何生產(chǎn)相關(guān)的環(huán)境中使用它。

但讓我們設(shè)想一下，如果 Suspense 的 API 已經(jīng)固化下來保持不變，并將在不久后正式發(fā)布。它會從根本上解決數(shù)據(jù)獲取問題嗎？它會使上述一切問題成為歷史嗎？一點(diǎn)也不會。因?yàn)?，我們?nèi)匀粫艿綖g覽器資源限制、受到 React 生命周期以及請求瀑布流的限制。

Suspense 只是一種非常復(fù)雜和聰明的方式，用來取代對 loading 狀態(tài)的處理。對于下面的代碼：

const Comments = ({ commments }) => {
  if (!comments) return 'loading';
  // render comments
}

只需提升 loading 狀態(tài)并執(zhí)行以下操作：

const Issue = () => {
  return <>
    // issue data
    <Suspence fallback="loading">
      <Comments />
    </Suspence>
  </>
}

在使用 Suspence 時，也不要忘記上面的所有核心原則和限制。

總結(jié)

接下來對本文的重點(diǎn)做一個總結(jié)：

• 在 React 中獲取數(shù)據(jù)不一定要用第三方類庫，但它們也很有用
• 性能是主觀的，始終取決于用戶體驗(yàn)
• 可用的瀏覽器資源有限，只有 6 個并行請求；不要濫用 pre-fetching
• useEffect 本身不會導(dǎo)致瀑布，它們只是組件組合和 loading 狀態(tài)帶來的自然結(jié)果

以上就是React 數(shù)據(jù)獲取與性能優(yōu)化詳解的詳細(xì)內(nèi)容，更多關(guān)于React 數(shù)據(jù)獲取性能優(yōu)化的資料請關(guān)注腳本之家其它相關(guān)文章！