React Query 是一個強大的資料管理工具，主要用來處理 API 請求、快取、同步更新、錯誤處理等功能，讓 React 更有效率地管理伺服器端的資料
- 核心功能包含：資料取得、快取管理、資料變更、自動同步、錯誤處理與重試機制
- 適合處理伺服器端資料管理，不建議用於管理本地 UI 狀態
什麼時候應該使用 React Query？
React Query 主要用於管理與伺服器之間的非同步資料（如 API 請求），特別適合處理以下場景：
- 資料取得（Data Fetching）
- 從 REST API 或 GraphQL 取得資料，並自動處理快取、背景更新、重新整理等。
- 快取與自動同步（Caching & Synchronization）
- 快取伺服器回傳的資料，並在網路狀態變更（如重新連接）或頁面聚焦時自動重新取得最新資料。
- 無需複雜的全域狀態管理
- 專注於伺服器資料，避免為了簡單的 API 呼叫建立冗長的 Redux actions 和 reducers。
- 需要即時更新的場景
- 例如即時數據儀表板、聊天室、投票系統等。
可以在現有 Redux 專案中引入 React Query 嗎？
React Query 與 Redux 並不衝突，因為：
- Redux 更適合管理應用程式的全域 UI 狀態（如使用者登入狀態、主題切換、通知等）。
- React Query 專注於處理伺服器狀態（Server State），像是 API 資料的快取、更新與同步。
React Query vs Redux：優缺點分析
| 特色 | React Query | Redux |
|---|---|---|
| 用途 | 管理伺服器資料（Server State） | 管理全域應用狀態（Client/UI State） |
| 資料來源 | 主要來自 API 請求 | 可以是任何狀態（API、UI、用戶輸入等） |
| 資料快取 | ✅ 內建快取、自動同步、背景更新 | ❌ 需手動實作快取邏輯 |
| 開發成本 | 較低，API 呼叫邏輯簡潔 | 較高，需定義 action、reducer、middleware |
| 狀態持久化 | ❌ 主要針對短期伺服器資料 | ✅ 可搭配 localStorage 進行狀態持久化 |
| 適合場景 | 資料密集型應用、需要快取或即時更新 | 複雜的 UI 狀態管理、多層級組件的狀態共享 |
React Query 與 Redux 在共享資料場景的比較
| 功能 | React Query | Redux |
|---|---|---|
| 快取支援 | ✅ 內建快取、自動更新 | ❌ 需自行實作快取邏輯 |
| API 請求管理 | ✅ 自動管理請求狀態、重試、錯誤處理 | ❌ 需額外寫 actions、reducers 處理 |
| 資料同步 | ✅ 快取同步，資料變更時所有組件自動更新 | ❌ 需手動觸發 state 更新 |
| 開發複雜度 | 較低，邏輯簡潔 | 較高，需額外管理 actions、middleware |
| 適合的場景 | 資料密集型應用、即時更新需求 | 複雜的應用邏輯、UI 狀態管理 |
什麼情況下應該同時使用 React Query 和 Redux？
- 伺服器狀態 & 客戶端狀態分離：
- 伺服器資料（Server State）： 交給 React Query 處理 API 取得與快取。
- 應用程式狀態（App State）： 交給 Redux 處理登入狀態、Modal 開關、UI 控制等。
- 複雜邏輯的需求：
- 如果伺服器資料需要進行大量轉換後才能使用，Redux 可以作為中介進行額外的狀態處理。
- 逐步遷移：
- 如果想從 Redux 逐步遷移到 React Query，可以先在新功能中使用 React Query，保留舊功能使用 Redux，等穩定後再進行重構。
如何選擇 React Query 和 Redux？
✅ 選擇 React Query 的情境：
- 須頻繁從 API 取得資料，且資料需在多個組件中共享。
- 需要自動快取、自動重新取得資料、錯誤處理等功能。
- 減少與後端不必要的 API 請求，提升前端效能。
✅ 選擇 Redux 的情境：
- 管理複雜的 UI 狀態（如 Modal 開關、多層巢狀的表單狀態）。
- 需跨多個頁面維持全域狀態，且資料不依賴 API（如用戶偏好設定）。
- 與既有的 Redux 架構深度整合，且不想引入額外的資料管理工具。
✅ 常見的最佳實踐：React Query 與 Redux 並存
- React Query：負責 API 資料的快取與管理。
- Redux：負責純粹的 UI 狀態管理或複雜邏輯。