引言

本文源于翻譯 Fetching data in React: the case of lost Promises 由公眾號 ikoofe 完成翻譯。

在某些場景里，前端開發(fā)同學(xué)會無意識的編寫出一些看似正確的代碼，這些代碼能夠通過所有測試以及代碼審查，但是在實際執(zhí)行時會導(dǎo)致應(yīng)用程序出現(xiàn)一些意想不到的問題：頁面上的數(shù)據(jù)毫無規(guī)律地隨機展示出來、搜索出的結(jié)果與查詢條件不匹配、切換選項卡的導(dǎo)航時出現(xiàn)錯誤的內(nèi)容。

當然，我們并不希望發(fā)生這些問題，那么如何避免這些問題呢？本文將繼續(xù)討論 React 數(shù)據(jù)獲取的一些方法和原理，并深入了解 Promise 在數(shù)據(jù)獲取時如何導(dǎo)致了條件競爭（race conditions）以及如何避免它們。

Promise 簡介

在本文正式開始之前，我們先了解一下 Promise 以及我們?yōu)槭裁葱枰?Promise。

當 JavaScript 執(zhí)行代碼時，通常是一步一步地同步執(zhí)行。Promise 是為數(shù)不多的異步執(zhí)行方法之一。有了 Promise，我們就可以直接觸發(fā)一個任務(wù)并立即進入下一步，而無需等待任務(wù)完成。當任務(wù)完成后，Promise 會通知我們。

數(shù)據(jù)獲取是 Promise 最重要和最廣泛使用的場景之一。不管是直接使用 fetch 還是使用像 axios 這樣的第三方類庫，Promise 的行為都是一樣的。

從代碼的角度來看，如下所示：

console.log('first step'); // will log FIRST
fetch('/some-url') // create promise here
  .then(() => { // wait for Promise to be done
      // log stuff after the promise is done
      console.log('second step') // will log THIRD (if successful)
    }
  )
  .catch(() => {
    console.log('something bad happened') // will log THIRD (if error happens)
  })
console.log('third step') // will log SECOND

整個過程是：在 fetch('/some-url') 中創(chuàng)建一個 Promise，然后在 .then 和 .catch 中處理后續(xù)的事情。當然，這個簡單的示例只是為了方便大家理解本文的后續(xù)部分。如果要完全掌握 Promise，需要閱讀資料來了解更多的細節(jié)，本文不做暫不展開介紹。

Promise 和條件競爭

Promise 會帶來條件競爭這個問題，下面以一個簡單的應(yīng)用頁面為例展開介紹：

頁面的左側(cè)是選項卡 tabs 的列，切換 tabs 就會導(dǎo)航到新頁面并發(fā)送一個數(shù)據(jù)請求，請求返回的數(shù)據(jù)渲染在右側(cè)。如果快速的來回切換 tabs 就會發(fā)現(xiàn)這里存在奇怪問題：右側(cè)的內(nèi)容會閃爍，數(shù)據(jù)看起來是隨機出現(xiàn)的。

這個問題是怎么發(fā)生的？讓我們看看頁面的實現(xiàn)。頁面有兩個部分。一個是根 App 組件，它管理 “page” 的狀態(tài)，并渲染了導(dǎo)航按鈕和實際的 Page 組件。

const App = () => {
  const [page, setPage] = useState("1");
  return (
    <>
      <!-- left column buttons -->
      <button onClick={() => setPage("1")}>Issue 1</button>
      <button onClick={() => setPage("2")}>Issue 2</button>
      <!-- the actual content -->
      <Page id={page} />
    </div>
  );
};

Page 組件接受 page 的 id 作為屬性，發(fā)送請求以獲取數(shù)據(jù)，然后渲染數(shù)據(jù)。Page 組件的實現(xiàn)（沒有加載狀態(tài)）如下所示：

const Page = ({ id }: { id: string }) => {
  const [data, setData] = useState({});
  // pass id to fetch relevant data
  const url = `/some-url/${id}`;
  useEffect(() => {
    fetch(url)
      .then((r) => r.json())
      .then((r) => {
        // save data from fetch request to state
        setData(r);
      });
  }, [url]);
  // render data
  return (
    <>
      <h2>{data.title}</h2>
      <p>{data.description}</p>
    </>
  );
};

通過 id，我們確定從哪個 url 獲取數(shù)據(jù)。然后我們在useEffect 中發(fā)送數(shù)據(jù)請求，并將結(jié)果數(shù)據(jù)存儲在 state 中 —— 這一切都很標準。那么，條件競爭和奇怪問題是什么原因?qū)е碌哪兀?/p>

條件競爭的起因

這一切歸結(jié)為兩件事：Promise 和 React 生命周期。從生命周期的角度來看，會發(fā)生這些事情：

• App 組件被裝載（mounted）
• Page 組件被裝載，并默認的 prop 為 “1”
• Page 組件中的 useEffect 首次被執(zhí)行

然后 Promise 開始執(zhí)行：useEffect 中的 fetch 是一個promise 異步操作。它負責發(fā)送實際的數(shù)據(jù)請求，而 React 繼續(xù)它自己的工作，而不等待結(jié)果。大約 2s 后數(shù)據(jù)請求完成，在 .then 中調(diào)用 setData 并將數(shù)據(jù)保存在 state 中，Page 組件渲染出最新的數(shù)據(jù)，最終我們在屏幕上看到這些數(shù)據(jù)。

如果在渲染和完成所有內(nèi)容后，單擊導(dǎo)航按鈕，我們將看到以下事件：

• App 組件將其狀態(tài)更改為另一個 page
• state 觸發(fā) App 組件的重新渲染
• Page 組件也將重新渲染
• Page 組件中的 useEffect 依賴于 id；由于 id 已變化，將再次觸發(fā) useEffect
• useEffect 將用新 id 觸發(fā) fecth 請求，大約 2s 后將再次調(diào)用 setData，Page 組件更新，我們在屏幕上看到新數(shù)據(jù)

但是，如果 id 第一次變化觸發(fā)的 fetch 尚未返回，這時單擊導(dǎo)航按鈕切換 tabs 會發(fā)生什么？

• App 組件將再次觸發(fā)頁面的重新渲染
• useEffect 也將再次被觸發(fā)（id 已發(fā)生變化！）
• fetch 將再次被執(zhí)行，React 將一如既往地繼續(xù)工作
• 這時第一次數(shù)據(jù)請求完成。它仍然可以訪問到 Page 組件的 setData（組件只是被更新，組件仍然是之前的組件）
• 第一次請求成功后的 setData 將被觸發(fā)，Page 組件將使用該次請求的數(shù)據(jù)更新自身
• 第二次請求完成。它仍然在那里，掛在后臺，就像任何 Promise 一樣。該組件依然使用了同一個 Page 組件的 setData，它將被觸發(fā)，Page 再次更新自身，這一次使用的是第二次獲取的數(shù)據(jù)。

條件競爭出現(xiàn)了！點擊導(dǎo)航按鈕到新 page 后，我們看到了頁面內(nèi)容發(fā)生閃爍：首先渲染第一次請求的數(shù)據(jù)，然后替換成第二次請求的數(shù)據(jù)。

如果第二次數(shù)據(jù)請求在第一次數(shù)據(jù)請求之前完成，這種效果就更有趣了。我們將首先看到下一頁的正確內(nèi)容，然后它將被上一頁的不正確內(nèi)容替換。

解決條件競爭：強制重新掛載

嚴格來說，這并不是一個解決方案，它更多的是用來解釋為什么這些競爭條件不會經(jīng)常發(fā)生，以及為什么在常規(guī)頁面導(dǎo)航中我們碰不到競爭條件。我們用下面的代碼來實現(xiàn)上面的功能：

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

沒有向下傳遞 prop，Issue 和 About 組件使用各自的 url 來完成數(shù)據(jù)請求。在 useEffect 中進行數(shù)據(jù)獲取，這與之前的實現(xiàn)方式完全相同：

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

這樣在 tabs 導(dǎo)航時不會出現(xiàn)競爭條件。無論操作的次數(shù)和速度有多快，應(yīng)用程序都能夠正常運行。這是為什么呢？

答案在這里：{page==='issue'&&<issue/>}。當 page 的值更改時，Issue 和 About 不會重新渲染，而是重新裝載。當值從 issue 更改為 about 時，Issue 組件將自行卸載，About 組件將裝載在它的位置上。

從數(shù)據(jù)獲取的角度來看：

• App 組件首先被渲染，然后裝載 Issue 組件并開始獲取數(shù)據(jù)
• 在數(shù)據(jù)請求過程中導(dǎo)航到下一個頁面，App 組件會卸載 Issue 組件并裝載 About 組件，然后開始它自己的數(shù)據(jù)獲取

當 React 卸載一個組件時，意味著它已經(jīng)不存在了。徹底消失了，從屏幕上消失了，沒有人可以訪問它，里面發(fā)生的一切，包括它的狀態(tài)都丟失了。與前面的代碼相比，我們在前面的代碼中編寫了 ＜Page id＝{Page} /＞，此 Page 組件從未被卸載，我們只是在導(dǎo)航時重新使用它。

所以回到卸載的場景。當 Issue 的數(shù)據(jù)請求在 About 組件上完成時，Issue 組件的 .then 將嘗試調(diào)用其 setIssue 來設(shè)置 state。但組件已經(jīng)不存在了，從 React 的角度來看，它已經(jīng)不存在。因此，這個 Promise 也將消失，它得到的數(shù)據(jù)也隨之消失。

順便提一下，你還記得曾經(jīng)有一個警告 “無法對未安裝的組件執(zhí)行React 狀態(tài)更新” 嗎？在組件消失之后完成異步操作（如數(shù)據(jù)獲?。瑫霈F(xiàn)這個警告。當然，現(xiàn)在這個警告已經(jīng)被 React 刪除掉了。

無論如何，理論上，這種方法可以用于解決的條件競爭問題：我們所需要做的是在導(dǎo)航變化時強制重新裝載 Page 組件。為此，我們可以使用 “key” 屬性：

<Page id={page} key={page} />

但是，并不推薦使用這個方案來解決條件競爭問題，它會引起一些潛在問題：可能會使性能受到影響，焦點和狀態(tài)會出現(xiàn)意外錯誤，以及觸發(fā)不必要的 useEffect。它并沒有從根本上解決問題，而是將問題掩蓋起來。但在某些場景下，如果小心使用，也不失為一種解決問題的方法。

解決條件競爭：丟棄錯誤數(shù)據(jù)

一種解決條件競爭更友好的方法，是確保傳入到 .then callback 的數(shù)據(jù)與當前被 “選中” 的 id 匹配；而不是清除整個已存在的 Page 組件。

如果返回的數(shù)據(jù)中包括了用于生成 url 的 “id”，我們可以比較它們是否一致。如果它們不一致，則忽略它們。這里需要做的是，要跳出 React 生命周期和函數(shù)的本地作用域，在 useEffect 訪問到最新的 id。React ref 非常適合這個場景：

const Page = ({ id }) => {
  // create ref
  const ref = useRef(id);
  useEffect(() => {
    // update ref value with the latest id
    ref.current = id;
    fetch(`/some-data-url/${id}`)
      .then((r) => r.json())
      .then((r) => {
        // compare the latest id with the result
        // only update state if the result actually belongs to that id
        if (ref.current === r.id) {
          setData(r);
        }
      });
  }, [id]);
}

如果返回的數(shù)據(jù)結(jié)果中沒有包含 id，我們可以比較 url：

const Page = ({ id }) => {
  // create ref
  const ref = useRef(id);
  useEffect(() => {
    // update ref value with the latest url
    ref.current = url;
    fetch(`/some-data-url/${id}`)
      .then((result) => {
        // compare the latest url with the result's url
        // only update state if the result actually belongs to that url
        if (result.url === ref.current) {
          result.json().then((r) => {
            setData(r);
          });
        }
      });
  }, [url]);
}

解決條件競爭：丟棄之前的數(shù)據(jù)

如果不喜歡上面的解決方案，或者認為使用 ref 來做這樣的事情。還有另一種方法：useEffect 有一個叫做 “cleanup” 的清除函數(shù)，在這個函數(shù)中我們可以清理訂閱之類的東西。在我們的場景中可以用來控制數(shù)據(jù)獲取。它的語法如下：

// normal useEffect
useEffect(() => {
  // "cleanup" function - function that is returned in useEffect
  return () => {
    // clean something up here
  }
// dependency - useEffect will be triggered every time url has changed
}, [url]);

“cleanup” 的函數(shù)在組件卸載后執(zhí)行，或者在每次依賴項變化引起重新渲染之前運行。因此，重新渲染期間的執(zhí)行順序如下：

• url 發(fā)生變化
• 觸發(fā) “cleanup” 函數(shù)
• useEffect 的實際內(nèi)容被觸發(fā)

利用 JavaScript 函數(shù)和閉包，我們可寫出這樣的代碼：

useEffect(() => {
  // local variable for useEffect's run
  let isActive = true;
  // do fetch here
  return () => {
    // local variable from above
    isActive = false;
  }
}, [url]);

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

fetch Promise 雖然是異步的，但仍然只存在于該閉包中，并且只能訪問 useEffect 運行的局部變量。因此，當我們在 .then 回調(diào)中檢查 isActive 布爾值時，只有在最近的一次運行中，尚未執(zhí)行清理函數(shù)，才會將變量設(shè)置為 true。所以現(xiàn)在需要做的只是檢查是否處于活動的閉包中，如果是，則設(shè)置狀態(tài)。如果不是，什么都不做，數(shù)據(jù)將再次憑空消失。

useEffect(() => {
    // set this closure to "active"
    let isActive = true;
    fetch(`/some-data-url/${id}`)
      .then((r) => r.json())
      .then((r) => {
        // if the closure is active - update state
        if (isActive) {
          setData(r);
        }
      });
    return () => {
      // set this closure to not active before next re-render
      isActive = false;
    }
  }, [id]);

解決條件競爭：取消之前的請求

如果覺得在 React 生命周期的上下文中處理 JavaScript 閉包太復(fù)雜，那么還有另一種解決問題的方法。

我們可以取消之前的所有請求，而不是清理或比較數(shù)據(jù)結(jié)果。如果它們永遠都不會完成數(shù)據(jù)請求，那么也就永遠不會使用這些過時數(shù)據(jù)，條件競爭的問題也就不復(fù)存在。

在這里，我們可以使用 AbortController，實現(xiàn)的代碼也相對比較簡單：在 useEffect 中創(chuàng)建 AbortController 并在清理函數(shù)中調(diào)用 .abort()。

useEffect(() => {
    // create controller here
    const controller = new AbortController();
    // pass controller as signal to fetch
    fetch(url, { signal: controller.signal })
      .then((r) => r.json())
      .then((r) => {
        setData(r);
      });
    return () => {
      // abort the request here
      controller.abort();
    };
  }, [url]);

在每次重新渲染時，正在進行的請求將被取消，只允許最新的數(shù)據(jù)請求被解析并更新到 state。

中止正在進行的請求，會導(dǎo)致 Promise 被 reject，因此我們需要捕獲錯誤以消除控制臺中的可怕警告。正確處理 Promise reject 是一個很好的開發(fā)習慣，這是任何場景都下都應(yīng)該做的事情，與是否使用 AbortController 無關(guān)。

由 AbortController 引起的 reject 會拋出的特定類型的錯誤，因此很容易將它與其它常規(guī)錯誤區(qū)分開。

fetch(url, { signal: controller.signal })
  .then((r) => r.json())
  .then((r) => {
    setData(r);
  })
  .catch((error) => {
    // error because of AbortController
    if (error.name === 'AbortError') {
      // do nothing
    } else {
      // do something, it's a real error!
    }
  });

Async/await 會改變什么嗎？

Async/await 只是編寫 Promise 的語法糖。從執(zhí)行的角度來看，它們只是轉(zhuǎn)換為 “同步” 函數(shù)，但不會改變它們的異步特性。下面的 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，同樣會存在條件競爭問題，前面介紹的解決方案也依然適用，只是語法略有差異。

以上就是React 數(shù)據(jù)獲取條件競爭原理解析的詳細內(nèi)容，更多關(guān)于React 數(shù)據(jù)獲取條件競爭的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論