console.log("first step");fetch("/some-url") // 創(chuàng)建 Promise  .then(() => { // 等待 Promise 完成      console.log("second step"); // 成功    }  )  .catch(() => {    console.log("something bad happened"); // 發(fā)生錯誤  })console.log("third step");

import "./styles.scss";import { useState, useEffect } from "react";type Issue = {  id: string;  title: string;  description: string;  author: string;};const url1 =  "https://run.mocky.io/v3/ebf1b8f3-0368-4e3b-a965-1c5fdcc5d490?mocky-delay=2000ms";const url2 =  "https://run.mocky.io/v3/27398801-05e2-4a62-8719-2a2d40974e52?mocky-delay=2000ms";const Page = ({ id }: { id: string }) => {  const [data, setData] = useState({} as Issue);  const [loading, setLoading] = useState(false);  const url = id === "1" ? url1 : url2;  useEffect(() => {    setLoading(true);    fetch(url)      .then((r) => r.json())      .then((r) => {        setData(r);        console.log(r);        setLoading(false);      });  }, [url]);  if (!data.id || loading) return <>loading issue {id};  return (    
      
My issue number {data.id}
      
{data.title}
      
{data.description}
    
  );};const App = () => {  const [page, setPage] = useState("1");  return (    
      
        
          
             setPage("1")}>Issue 1          
          
             setPage("2")}>Issue 2          
        
              
    
  );};export default App;

const App = () => {  const [page, setPage] = useState("1");  return (    <>             setPage("1")}>Issue 1       setPage("2")}>Issue 2                

另一個就是Page組件，它接受活動頁面 的id作為props，發(fā)送一個 fetch 請求來獲取數據，然后渲染它。簡化的實現（沒有加載狀態(tài)）如下所示：

const Page = ({ id }: { id: string }) => {  const [data, setData] = useState({});  // 通過 id 獲取相關數據  const url = `/some-url/${id}`;  useEffect(() => {    fetch(url)      .then((r) => r.json())      .then((r) => {        setData(r);      });  }, [url]);  return (    <>      
{data.title}
      
{data.description}
      );};

這里通過id來確定獲取數據的url。然在useEffect中發(fā)送 fetch 請求，并將獲取到的數據存儲在state中。那么競態(tài)條件和奇怪的行為是從哪里來的呢？

這可以歸結于兩個方面：Promises 的本質和React 生命周期。

從生命周期的角度來看，執(zhí)行如下：

那么 Promises 的本質就生效了：useEffect中的 fetch 是一個 Promise，它是異步操作。它發(fā)送實際的請求，然后 React 繼續(xù)它的生命周期而不會等待結果。大約 2 秒后，請求完成，.then開始執(zhí)行，在其中我們調用setData來將獲取到的數據保存狀態(tài)中，Page組件使用新數據更新，我們在屏幕上看到它。

如果在所有內容渲染完成后再點擊導航按鈕，事件流如下：

但是，如果在第一次 fetch 正在進行但尚未完成時單擊導航按鈕，這時id發(fā)生了變化，會發(fā)生什么呢？

這樣，競態(tài)條件就產生了。在導航到新頁面后，我們會看到內容的閃爍：第一次 fetch 的內容先被渲染，然后被第二次 fetch 的內容替換。

如果第二次 fetch 在第一次 fetch 之前完成，這種效果會更加有趣。我們會先看到下一頁的正確內容，然后將其替換為上一頁的錯誤內容。

來看下面的例子，等到第一次加載完所有內容，然后導航到第二頁，然后快速導航回第一頁。頁面效果如下：

在線實例：https://codesandbox.io/s/app-without-race-condition-reversed-yuoqkh?from-embed

可以看到，我們先點擊 Issues 2，再點擊的 Issue 1。而最終先顯示了 Issue 1 的結果，后顯示了 Issue 2 的結果。那該如何解決這個問題呢？

其實這一個并不是解決方案，它更多地解釋了為什么這些競態(tài)條件實際上并不會經常發(fā)生，以及為什么我們通常在常規(guī)頁面導航期間看不到它們。

想象一下如下組件：

const App = () => {  const [page, setPage] = useState("issue");  return (    <>      {page === "issue" && }      {page === "about" && }      )}

這里我們并沒有傳遞 props，Issue和About組件都有各自的url，它們可以從中獲取數據。并且數據獲取發(fā)生在useEffectHook 中：

const About = () => {  const [about, setAbout] = useState();  useEffect(() => {    fetch("/some-url-for-about-page")      .then((r) => r.json())      .then((r) => setAbout(r));  }, []);  ...}

這次導航時沒有發(fā)生競態(tài)條件。盡可能多地和盡可能快地進行導航：應用運行正常。

在線實例：https://codesandbox.io/s/issue-and-about-no-bug-5udo04?from-embed

這是為什么呢？答案就在這里：{page === ‘issue’ && }。當page值發(fā)生更改時，Issue和About頁面都不會重新渲染，而是會重新掛載。當值從issue更改為about時，Issue組件會自行卸載，而About組件會進行掛載。

從 fetch 的角度來看：

當 React 卸載一個組件時，就意味著它已經完全消失了，從屏幕上消失，其中發(fā)生的一切，包括它的狀態(tài)都丟失了。將其與前面的代碼進行比較，我們在其中編寫了，這個Page組件從未被卸載，我們只是在導航時重新使用它和它的狀態(tài)。

回到卸載的情況，當我們跳轉到在 About 頁面時，Issue 的 fetch 請求完成時，Issue組件的.then回調將嘗試調用setIssue，但是組件已經消失了，從 React 的角度來看，它已經不存在了。所以 Promise 會消失，它獲取的數據也會消失。

順便說一句，React 中經常會提示：Can"t perform a React state update on an unmounted component，當組件已經消失后完成數據獲取等異步操作時就會出現這個警告。

理論上，這種行為可以用來解決應用中的競態(tài)條件：只需要強制頁面組件重新掛載。可以使用 key 屬性：

在線實例：https://codesandbox.io/s/app-without-race-condition-twv1sm?file=/src/App.tsx

?? 這并不是推薦使用的競態(tài)條件問題的解決方案，其影響較大：性能可能會受到影響，狀態(tài)的意外錯誤，渲染樹下的 useEffect 意外觸發(fā)。有更好的方法來處理競爭條件（見下文）。

解決競爭條件的另外一種方法就是確保傳入.then回調的結果與當前“active”的 id 匹配。

如果結果可以返回用于生成 url 的id，就可以比較它們，如果不匹配就忽略它。這里的技巧就是在函數中避免 React 生命周期和本地數據，并在useEffect中訪問最新的id。Reactref就非常適合：

const Page = ({ id }) => {  // 創(chuàng)建 ref  const ref = useRef(id);  useEffect(() => {    // 用最新的 id 更新 ref 值    ref.current = id;    fetch(`/some-data-url/${id}`)      .then((r) => r.json())      .then((r) => {        // 將最新的 id 與結果進行比較，只有兩個 id 相等時才更新狀態(tài)        if (ref.current === r.id) {          setData(r);        }      });  }, [id]);}

在線示例：https://codesandbox.io/s/app-with-race-condition-fixed-with-id-and-ref-jug1jk?file=/src/App.tsx

我們也可以直接比較url：

const Page = ({ id }) => {  // 創(chuàng)建 ref  const ref = useRef(id);  useEffect(() => {    // 用最新的 url 更新 ref 值    ref.current = url;    fetch(`/some-data-url/${id}`)      .then((result) => {        // 將最新的 url 與結果進行比較，僅當結果實際上屬于該 url 時才更新狀態(tài)        if (result.url === ref.current) {          result.json().then((r) => {            setData(r);          });        }      });  }, [url]);}

在線示例：https://codesandbox.io/s/app-with-race-condition-fixed-with-url-and-ref-whczob?file=/src/App.tsx

useEffect有一個清理函數，可以在其中清理訂閱等內容。它的語法如下所示：

useEffect(() => {  return () => {    // 清理的內容  }}, [url]);

清理函數會在組件卸載后執(zhí)行，或者在每次更改依賴項導致的重新渲染之前執(zhí)行。因此重新渲染期間的操作順序將如下所示：

JavaScript 中函數和閉包的性質允許我們這樣做：

useEffect(() => {  // useEffect中的局部變量  let isActive = true;  // 執(zhí)行 fetch 請求  return () => {    // 上面的局部變量    isActive = false;  }}, [url]);

我們引入了一個局部布爾變量isActive，并在useEffect運行時將其設置為true，在清理時將其設置為false。每次重新渲染時都會重新創(chuàng)建useEffect中的變量，因此最新的useEffect會將isActive始終重置為true。但是，在它之前運行的清理函數仍然可以訪問前一個變量的作用域，并將其重置為false。這就是 JavaScript 閉包的工作方式。

雖然 fetch 是異步的，但仍然只存在于該閉包中，并且只能訪問啟動它的useEffect中的局部變量。因此，當檢查.then回調中的isActive時，只有最近的運行（即尚未清理的運行）才會將變量設置為true。所以，現在只需要檢查是否處于活動閉包中，如果是，則將獲取的數據設置狀態(tài)。如果不是，什么都不做，數據將再次消失。

useEffect(() => {  // 將 isActive 設置為 true  let isActive = true;  fetch(`/some-data-url/${id}`)    .then((r) => r.json())    .then((r) => {      // 如果閉包處于活動狀態(tài)，更新狀態(tài)      if (isActive) {        setData(r);      }    });  return () => {    // 在下一次重新渲染之前將 isActive 設置為 false    isActive = false;  }}, [id]);

在線示例：https://codesandbox.io/s/app-with-race-condition-fixed-with-cleanup-4du0wf?file=/src/App.tsx

對于競態(tài)條件問題，我們可以取消之前的請求，而不是清理或比較結果。如果之前的請求不能完成（取消），那么使用過時數據的狀態(tài)更新將永遠不會發(fā)生，問題也就不會存在?？梢詾榇耸褂肁bortController來取消請求。

我們可以在useEffect中創(chuàng)建AbortController并在清理函數中調用.abort()：

useEffect(() => {  // 創(chuàng)建 controller  const controller = new AbortController();  // 將 controller 作為signal傳遞給 fetch  fetch(url, { signal: controller.signal })    .then((r) => r.json())    .then((r) => {      setData(r);    });  return () => {    // 中止請求    controller.abort();  };}, [url]);

這樣，在每次重新渲染時，正在進行的請求將被取消，新的請求將是唯一允許解析和設置狀態(tài)的請求。

中止一個正在進行的請求會導致 Promise 被拒絕，所以需要在 Promise 中捕捉錯誤。因為AbortController而拒絕會給出特定類型的錯誤：

fetch(url, { signal: controller.signal })  .then((r) => r.json())  .then((r) => {    setData(r);  })  .catch((error) => {    // 由于 AbortController 導致的錯誤    if (error.name === "AbortError") {      // ...    } else {      // ...    }  });

在線示例：https://codesandbox.io/s/app-with-race-condition-fixed-with-abort-controller-6u0ckk?file=/src/App.tsx

上面我們說了 Promise 的競態(tài)條件的解決方案，那 Async/await 會有所不同嗎？其實，Async/await 只是編寫 Promise 的一種更好的方式。它只是將 Promise 變成“同步”函數，但不會改變它們的異步的性質。

對于 Promise：

fetch("/some-url")  .then(r => r.json())  .then(r => setData(r));

使用 Async/await 這樣寫：

const response = await fetch("/some-url");const result = await response.json();setData(result);

使用 async/await 而不是“傳統(tǒng)”promise 實現的完全相同的應用，將具有完全相同的競態(tài)條件。以上所有解決方案和原因都適用，只是語法會略有不同?？梢栽谠诰€示例中查看：https://codesandbox.io/s/app-with-race-condition-async-away-q39lgi?file=/src/App.tsx

參考：https://www.developerway.com/posts/fetching-in-react-lost-promises

關鍵詞：