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

另一個(gè)就是Page組件，它接受活動(dòng)頁(yè)面 的id作為props，發(fā)送一個(gè) fetch 請(qǐng)求來(lái)獲取數(shù)據(jù)，然后渲染它。簡(jiǎn)化的實(shí)現(xiàn)（沒(méi)有加載狀態(tài)）如下所示：

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

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

這可以歸結(jié)于兩個(gè)方面：Promises 的本質(zhì)和React 生命周期。

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

那么 Promises 的本質(zhì)就生效了：useEffect中的 fetch 是一個(gè) Promise，它是異步操作。它發(fā)送實(shí)際的請(qǐng)求，然后 React 繼續(xù)它的生命周期而不會(huì)等待結(jié)果。大約 2 秒后，請(qǐng)求完成，.then開(kāi)始執(zhí)行，在其中我們調(diào)用setData來(lái)將獲取到的數(shù)據(jù)保存狀態(tài)中，Page組件使用新數(shù)據(jù)更新，我們?cè)谄聊簧峡吹剿?/p>

如果在所有內(nèi)容渲染完成后再點(diǎn)擊導(dǎo)航按鈕，事件流如下：

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

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

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

來(lái)看下面的例子，等到第一次加載完所有內(nèi)容，然后導(dǎo)航到第二頁(yè)，然后快速導(dǎo)航回第一頁(yè)。頁(yè)面效果如下：

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

可以看到，我們先點(diǎn)擊 Issues 2，再點(diǎn)擊的 Issue 1。而最終先顯示了 Issue 1 的結(jié)果，后顯示了 Issue 2 的結(jié)果。那該如何解決這個(gè)問(wèn)題呢？

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

想象一下如下組件：

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

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

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

這次導(dǎo)航時(shí)沒(méi)有發(fā)生競(jìng)態(tài)條件。盡可能多地和盡可能快地進(jìn)行導(dǎo)航：應(yīng)用運(yùn)行正常。

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

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

從 fetch 的角度來(lái)看：

當(dāng) React 卸載一個(gè)組件時(shí)，就意味著它已經(jīng)完全消失了，從屏幕上消失，其中發(fā)生的一切，包括它的狀態(tài)都丟失了。將其與前面的代碼進(jìn)行比較，我們?cè)谄渲芯帉?xiě)了，這個(gè)Page組件從未被卸載，我們只是在導(dǎo)航時(shí)重新使用它和它的狀態(tài)。

回到卸載的情況，當(dāng)我們跳轉(zhuǎn)到在 About 頁(yè)面時(shí)，Issue 的 fetch 請(qǐng)求完成時(shí)，Issue組件的.then回調(diào)將嘗試調(diào)用setIssue，但是組件已經(jīng)消失了，從 React 的角度來(lái)看，它已經(jīng)不存在了。所以 Promise 會(huì)消失，它獲取的數(shù)據(jù)也會(huì)消失。

順便說(shuō)一句，React 中經(jīng)常會(huì)提示：Can"t perform a React state update on an unmounted component，當(dāng)組件已經(jīng)消失后完成數(shù)據(jù)獲取等異步操作時(shí)就會(huì)出現(xiàn)這個(gè)警告。

理論上，這種行為可以用來(lái)解決應(yīng)用中的競(jìng)態(tài)條件：只需要強(qiáng)制頁(yè)面組件重新掛載?？梢允褂?key 屬性：

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

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

解決競(jìng)爭(zhēng)條件的另外一種方法就是確保傳入.then回調(diào)的結(jié)果與當(dāng)前“active”的 id 匹配。

如果結(jié)果可以返回用于生成 url 的id，就可以比較它們，如果不匹配就忽略它。這里的技巧就是在函數(shù)中避免 React 生命周期和本地?cái)?shù)據(jù)，并在useEffect中訪問(wèn)最新的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 與結(jié)果進(jìn)行比較，只有兩個(gè) id 相等時(shí)才更新?tīng)顟B(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 與結(jié)果進(jìn)行比較，僅當(dāng)結(jié)果實(shí)際上屬于該 url 時(shí)才更新?tīng)顟B(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有一個(gè)清理函數(shù)，可以在其中清理訂閱等內(nèi)容。它的語(yǔ)法如下所示：

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

清理函數(shù)會(huì)在組件卸載后執(zhí)行，或者在每次更改依賴項(xiàng)導(dǎo)致的重新渲染之前執(zhí)行。因此重新渲染期間的操作順序?qū)⑷缦滤荆?/p>url更改；清理函數(shù)被觸發(fā)；useEffect的實(shí)際內(nèi)容被觸發(fā)。

JavaScript 中函數(shù)和閉包的性質(zhì)允許我們這樣做：

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

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

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

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

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

對(duì)于競(jìng)態(tài)條件問(wèn)題，我們可以取消之前的請(qǐng)求，而不是清理或比較結(jié)果。如果之前的請(qǐng)求不能完成（取消），那么使用過(guò)時(shí)數(shù)據(jù)的狀態(tài)更新將永遠(yuǎn)不會(huì)發(fā)生，問(wèn)題也就不會(huì)存在。可以為此使用AbortController來(lái)取消請(qǐng)求。

我們可以在useEffect中創(chuàng)建AbortController并在清理函數(shù)中調(diào)用.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 () => {    // 中止請(qǐng)求    controller.abort();  };}, [url]);

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

中止一個(gè)正在進(jìn)行的請(qǐng)求會(huì)導(dǎo)致 Promise 被拒絕，所以需要在 Promise 中捕捉錯(cuò)誤。因?yàn)锳bortController而拒絕會(huì)給出特定類型的錯(cuò)誤：

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

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

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

對(duì)于 Promise：

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

使用 Async/await 這樣寫(xiě)：

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

使用 async/await 而不是“傳統(tǒng)”promise 實(shí)現(xiàn)的完全相同的應(yīng)用，將具有完全相同的競(jìng)態(tài)條件。以上所有解決方案和原因都適用，只是語(yǔ)法會(huì)略有不同?？梢栽谠诰€示例中查看：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

關(guān)鍵詞：