與其他工具比較
RTK Query 的靈感來自生態系統中的許多其他資料擷取函式庫。就像 Redux 核心函式庫的靈感來自 Flux 和 Elm 等工具 一樣，RTK Query 建構在 React Query、SWR、Apollo 和 Urql 等函式庫所普及的 API 設計模式和功能概念上。RTK Query 是從頭開始撰寫的，但它試圖使用這些函式庫和其他資料擷取工具中的最佳概念，並著眼於利用 Redux 的獨特優勢和功能。
我們認為所有這些工具都很棒！如果您正在使用其中一個工具，而且您對它感到滿意，並且它解決了您在應用程式中遇到的問題，請繼續使用該工具。此頁面上的資訊旨在幫助您了解功能、實作方法和 API 設計之間的差異。目標是幫助您做出明智的決策並了解取捨，而不是爭論工具 X 優於工具 Y。
您應該在什麼時候使用 RTK Query？
一般來說，使用 RTK Query 的主要原因是
- 您已經有一個 Redux 應用程式，並且您想要簡化現有的資料擷取邏輯
- 您希望能夠使用 Redux DevTools 來查看狀態隨著時間推移而變化的歷史記錄
- 您希望能夠將 RTK Query 行為與 Redux 生態系統的其他部分整合
- 您的應用程式邏輯需要在 React 之外執行
獨特功能
RTK Query 有一些值得考慮的獨特 API 設計方面和功能。
- 使用 React Query 和 SWR，您通常會自己定義掛勾，而且您可以在任何地方和即時執行此操作。使用 RTK Query，您可以在一個集中位置執行此操作，方法是預先定義具有多個端點的「API 切片」。這允許更緊密整合的突變模型，在觸發時自動使查詢失效/重新擷取。
- 由於 RTK Query 會在處理請求時發送正常的 Redux 動作，因此所有動作都會顯示在 Redux DevTools 中。此外，每個請求都會自動顯示在您的 Redux 函數中，必要時可以輕鬆更新整體應用程式狀態 (請參閱範例)。您可以使用端點 比對器功能 在您自己的函數中對快取相關動作進行額外處理。
- RTK Query 的主要功能與 Redux 本身一樣，與 UI 無關，且可與任何 UI 層搭配使用
- 您可以輕鬆地從中間軟體中使實體失效或修補現有的查詢資料 (透過
util.updateQueryData)。 - RTK Query 能夠 串流快取更新，例如在透過 Websocket 收到訊息時更新最初擷取的資料，並且內建支援 樂觀更新。
- RTK Query 提供一個極為精簡且彈性的擷取封裝器：
fetchBaseQuery。也可以很輕鬆地 將我們的客戶端替換成您自己的客戶端，例如使用axios、redaxios或自訂的客戶端。 - RTK Query 有一個 （目前為實驗性質的）程式碼產生工具，它會擷取 OpenAPI 規格或 GraphQL 架構，並提供給您一個已輸入的 API 客戶端，以及在事後增強已產生客戶端的方法。
權衡
未正規化或未重複資料刪除的快取
RTK Query 故意不實作會在多個請求中對相同項目進行重複資料刪除的快取。原因有幾個
- 一個完全正規化且跨查詢共用的快取是一個困難的問題
- 我們目前沒有時間、資源或興趣嘗試解決這個問題
- 在許多情況下，當資料失效時只需重新擷取資料即可，而且較容易理解
- 至少 RTKQ 可以協助解決「擷取一些資料」的一般使用案例，這對許多人來說是一個很大的痛點
套件大小
RTK Query 會為您的應用程式套件大小新增一個固定的單次數量。由於 RTK Query 建立在 Redux Toolkit 和 React-Redux 之上，因此新增的大小會根據您是否已在應用程式中使用這些元件而有所不同。估計的最小 + gzip 套件大小為
- 如果您已經使用 RTK：RTK Query 約 9 KB，hooks 約 2 KB。
- 如果您尚未使用 RTK
- 不含 React：RTK+依賴項+RTK Query 為 17 kB
- 含 React：19 kB + React-Redux，這是一個對等依賴項
新增額外的端點定義只會根據 endpoints 定義中的實際程式碼增加大小，通常只有幾個位元組。
RTK Query 中包含的功能可以快速彌補新增的套件大小，而且消除手寫資料擷取邏輯應該可以大幅改善大多數有意義的應用程式的規模。
比較功能集
值得比較所有這些工具的功能集，以了解它們的相似性和差異性。
此比較表格力求準確且公正。如果您使用這些函式庫中的任何一個，並認為可以改善資訊，歡迎透過開啟問題提出變更建議（附註或聲明證據）。
| 功能 | rtk-query | react-query | apollo | urql |
|---|---|---|---|---|
| 支援的通訊協定 | 任何，包含 REST | 任何，不包含任何 | GraphQL | GraphQL |
| API 定義 | 宣告式 | 使用時宣告式 | GraphQL 架構 | GraphQL 架構 |
| 快取方式 | 端點 + 序列化參數 | 使用者定義的查詢金鑰 | 類型/ID | 類型/ID? |
| 失效策略 + 重新擷取 | 宣告式，依類型和/或類型/ID | 手動依快取金鑰 | 每個實體層級的自動快取更新，手動依快取金鑰失效查詢 | 宣告式，依類型或每個實體層級的自動快取更新，手動依快取金鑰失效查詢 |
| 輪詢 | 是 | 是 | 是 | 是 |
| 平行查詢 | 是 | 是 | 是 | 是 |
| 相依查詢 | 是 | 是 | 是 | 是 |
| 略過查詢 | 是 | 是 | 是 | 是 |
| 延遲查詢 | 是 | 是 | 否 | ? |
| 自動垃圾回收 | 是 | 是 | 否 | ? |
| 正規化快取 | 否 | 否 | 是 | 是 |
| 無限捲動 | 待辦事項 | 是 | 需要手動程式碼 | ? |
| 預先擷取 | 是 | 是 | 是 | 是？ |
| 重試 | 是 | 是 | 需要手動程式碼 | ? |
| 樂觀更新 | 可以手動更新快取 | 可以手動更新快取 | optimisticResponse | ? |
| 手動快取操作 | 是 | 是 | 是 | 是 |
| 平台 | React 的 hooks，Redux 可用的任何地方 | React 的 hooks | 各種 | 各種 |
進一步資訊
- React Query「比較」頁面有額外的詳細功能集比較表格和功能討論
- Urql 維護者 Phil Pluckthun 寫了一篇關於「正規化快取」是什麼以及 Urql 快取如何運作的出色說明
- RTK Query「快取行為」頁面進一步說明了 RTK Query 為何不實作正規化快取