Redux 基礎教程實戰(zhàn)用中間件與 Redux Thunk 實現(xiàn)異步邏輯和數(shù)據獲取【免費下載鏈接】reduxA JS library for predictable global state management項目地址: https://gitcode.com/gh_mirrors/re/redux本篇內容基于 Redux 官方基金教程第 6 篇part-6-async-logic.md講解當應用數(shù)據不再只存在于客戶端、而需要通過與服務器進行 HTTP 請求來讀寫時Redux 是如何通過**中間件middleware**與Thunk 函數(shù)來承載異步邏輯的Redux 數(shù)據流在引入異步后會多出哪些環(huán)節(jié)、為什么 reducer 中不能寫副作用、applyMiddleware在源碼層面如何把多個中間件組裝成一條 dispatch 管線以及如何用 thunk 函數(shù)從服務端拉取待辦列表并保存新待辦。讀完本篇你將能夠配置帶 thunk 中間件的 store、編寫接收dispatch與getState的異步函數(shù)、在組件中 dispatch thunk 完成真實的數(shù)據獲取流程并在源碼與測試層面驗證這套機制的每個環(huán)節(jié)。前置知識與你將學到的內容本教程第 6 篇建立在 第 5 篇UI 和 React 的基礎上你已經會用react-redux讓組件與 Redux store 交互——調用useSelector讀取狀態(tài)、調用useDispatch拿到dispatch函數(shù)、并用Provider組件讓 hooks 訪問到 store。本篇學習目標Redux 數(shù)據流在處理異步數(shù)據時是如何工作的如何用 Redux 中間件編寫異步邏輯處理異步請求狀態(tài)request state的模式。前置要求熟悉使用 HTTP 請求從服務器獲取和更新數(shù)據理解 JS 中的異步邏輯包括 Promise。值得先了解的一點Redux Toolkit 提供了專門的數(shù)據獲取與緩存方案 RTK Query它可以消除為數(shù)據獲取編寫任何 thunk 或 reducer 的需要。Redux 官方教程將 RTK Query 作為數(shù)據獲取的默認推薦方案而 RTK Query 正是建立在本篇講解的同一套模式之上參見 RTK Query 概述 與 Redux Essentials, Part 7: RTK Query Basics。本篇講的是這些底層機制本身。示例 REST API 與 HTTP 客戶端為了讓示例項目既隔離又貼近現(xiàn)實教程配套的示例應用redux-fundamentals-example-app在初始搭建時就內置了一個內存版的假 REST API使用 Mirage.js 這個 mock API 工具配置。該 API 以/fakeApi作為所有端點的基礎 URL并對/fakeApi/todos支持常見的GET/POST/PUT/DELETEHTTP 方法定義在示例應用的src/api/server.js中。項目還包含一個小型 HTTP API 客戶端對象暴露client.get()和client.post()方法用法類似 axios 等常見 HTTP 庫定義在示例應用的src/api/client.js中。本節(jié)的 HTTP 調用都通過這個client對象發(fā)往內存中的假 REST API。Redux 中間件與副作用單看一個 Redux store它對異步邏輯一無所知它只會同步地 dispatch 動作、通過調用根 reducer 函數(shù)更新狀態(tài)并通知 UI 發(fā)生了變化。任何異步性都必須發(fā)生在 store 之外。在前面的教程中我們說過Redux reducer 絕不能包含副作用。副作用指的是任何能夠被函數(shù)返回值之外的外部世界觀察到的狀態(tài)或行為改變。常見的副作用包括向控制臺打印日志保存文件設置異步定時器發(fā)起 HTTP 請求修改函數(shù)外部存在的某個狀態(tài)或直接改變mutate函數(shù)參數(shù)生成隨機數(shù)或唯一隨機 ID如Math.random()或Date.now()。然而任何真實應用都總要在某個地方做這些事情。既然 reducer 里不能放副作用那副作用應該放在哪里Redux 中間件正是為了讓你可以編寫帶副作用的邏輯而設計的。正如 第 4 篇 中所述Redux 中間件在看到一個被 dispatch 的動作時可以做任何事打印日志、修改動作、延遲動作、發(fā)起異步調用等等。而且由于中間件構成了包裹在真實store.dispatch函數(shù)外的一整條管線這意味著你實際上可以向dispatch傳遞不是一個純 action 對象的值——只要某個中間件攔截了這個值、并且不讓它一路到達 reducer 就行。中間件還能訪問dispatch和getState。也就是說你可以在中間件里編寫異步邏輯并且依然能夠通過 dispatch 動作與 Redux store 保持交互。Redux 作者在 StackOverflow 上多次解釋過為什么異步流需要中間件其核心論點與本節(jié)一致狀態(tài)更新必須同步、可預測而副作用必須被移出 reducer 到 dispatch 管線上。用中間件啟用異步邏輯下面看兩個例子展示中間件如何讓我們編寫能與 Redux store 交互的異步邏輯。一種可能是寫一個查找特定 action 類型的中間件在看到這些動作時運行異步邏輯import { client } from ../api/client const delayedActionMiddleware storeAPI next action { if (action.type todos/todoAdded) { setTimeout(() { // 延遲這個 action 一秒 next(action) }, 1000) return } return next(action) } const fetchTodosMiddleware storeAPI next action { if (action.type todos/fetchTodos) { // 發(fā)起 API 調用從服務器拉取 todos client.get(todos).then(todos { // 用接收到的 todos dispatch 一個 action storeAPI.dispatch({ type: todos/todosLoaded, payload: todos }) }) } return next(action) }注意這兩個中間件的寫法都是三層嵌套函數(shù)——最外層接收storeAPI中間層接收next最內層接收action。這與本倉庫src/types/middleware.ts中Middleware類型的定義完全對應// src/types/middleware.ts節(jié)選 export interface MiddlewareAPID extends Dispatch Dispatch, S any { dispatch: D getState: () S } export interface Middleware _DispatchExt {}, S any, D extends Dispatch Dispatch { ( api: MiddlewareAPID, S ): (next: (action: unknown) unknown) (action: unknown) unknown }也就是說中間件的契約就是(api) (next) (action) 任意返回值其中最內層函數(shù)的參數(shù)類型是unknown——這從類型層面就承認了dispatch 進來的一切都不保證是普通 action 對象攔截非對象值比如函數(shù)正是中間件的合法職責。源碼視角applyMiddleware 如何組裝中間件管線以上三層嵌套函數(shù)最終是由applyMiddleware串成管線的?？幢緜}庫的實現(xiàn) src/applyMiddleware.tsexport default function applyMiddleware(...middlewares: Middleware[]): StoreEnhancerany { return createStore (reducer, preloadedState) { const store createStore(reducer, preloadedState) let dispatch: Dispatch () { throw new Error( Dispatching while constructing your middleware is not allowed. Other middleware would not be applied to this dispatch. ) } const middlewareAPI: MiddlewareAPI { getState: store.getState, dispatch: (action, ...args) dispatch(action, ...args) } const chain middlewares.map(middleware middleware(middlewareAPI)) dispatch composetypeof dispatch(...chain)(store.dispatch) return { ...store, dispatch } } }從這段源碼可以讀出幾個關鍵事實applyMiddleware本身是一個 store enhancer它返回createStore (reducer, preloadedState) store這樣的高階函數(shù)最終返回一個覆蓋了dispatch的新 store。這也解釋了教程第 4 篇中中間件是構建在一個非常特殊的內建 store enhancer 之上的這句話。函數(shù)注釋中還特別提示由于中間件可能是異步的applyMiddleware應當是 enhancer 組合鏈中的第一個。每個中間件拿到的dispatch是指向管線入口的遞歸引用middlewareAPI.dispatch調用的是閉包中會被重新賦值的dispatch變量最終被賦值為組合后的完整管線。因此中間件內部再 dispatch 的動作會從第一個中間件重新走完整條管線而不會被漏掉。管線的組裝發(fā)生在構建期middlewares.map(middleware middleware(middlewareAPI))先對每個中間件調用最外層函數(shù)拿到各自的wrapDispatch再compose(...chain)(store.dispatch)把它們從右向左嵌套把原始的store.dispatch作為鏈尾即最后一個中間件的next。compose的實現(xiàn)見 src/compose.ts即compose(f, g, h) (...args) f(g(h(...args)))——這決定了applyMiddleware(a, b)時a是管線最外層、最先執(zhí)行b最后執(zhí)行并緊鄰真實store.dispatch。構建期禁止 dispatch在中間件裝配完成之前dispatch被臨時指向一個會拋出 Dispatching while constructing your middleware is not allowed 的函數(shù)src/applyMiddleware.ts防止你在中間件外層函數(shù)里 dispatch 時繞過尚未裝配的管線。這些行為都有測試背書見 test/applyMiddleware.spec.tswarns when dispatching during middleware setupL9-L20驗證了第 4 點的拋錯行為wraps dispatch method with middleware onceL22-L45驗證中間件外層函數(shù)只被調用一次且拿到的 API 上確實有getState和dispatchpasses recursive dispatches through the middleware chainL47-L65驗證中間件內部 dispatch 的動作會重新經過整條管線。編寫一個異步函數(shù)中間件上一節(jié)的兩個中間件都太具體各只干一件事。我們當然希望有一種辦法把任意異步邏輯提前寫成一個獨立函數(shù)與中間件定義解耦同時這個函數(shù)還能訪問dispatch和getState來與 store 交互。如果我們寫一個允許向dispatch傳一個函數(shù)而不是 action 對象的中間件呢這個中間件檢查一下動作是否其實是函數(shù)如果是就立刻調用它。這樣異步邏輯就能寫在中間件定義之外的獨立函數(shù)里。這樣的中間件大概長這樣// 示例異步函數(shù)中間件 const asyncFunctionMiddleware storeAPI next action { // 如果這個action其實是個函數(shù)…… if (typeof action function) { // 那就調用它并把 dispatch 和 getState 作為參數(shù)傳入 return action(storeAPI.dispatch, storeAPI.getState) } // 否則它是一個普通 action——繼續(xù)往下傳 return next(action) }有了它我們就可以這樣使用const middlewareEnhancer applyMiddleware(asyncFunctionMiddleware) const store createStore(rootReducer, middlewareEnhancer) // 寫一個以 dispatch 和 getState 為參數(shù)的函數(shù) const fetchSomeData (dispatch, getState) { // 發(fā)起一次異步 HTTP 請求 client.get(todos).then(todos { // 用接收到的 todos dispatch 一個 action dispatch({ type: todos/todosLoaded, payload: todos }) // dispatch 之后讀取更新后的 store 狀態(tài) const allTodos getState().todos console.log(Number of todos after loading: , allTodos.length) }) } // 把上面寫的函數(shù)傳給 dispatch store.dispatch(fetchSomeData) // 日志輸出Number of todos after loading: ###注意這個異步函數(shù)中間件讓我們向dispatch傳入了一個函數(shù)。在函數(shù)內部我們先寫了一段異步邏輯HTTP 請求請求完成后再 dispatch 一個普通的 action 對象。這里有一個容易忽略的邊界如果沒有中間件攔截把函數(shù)傳給dispatch會在 store 的原始dispatch里直接失敗。從源碼看src/createStore.ts 中對 action 的校驗會檢查action.type是否為字符串非普通對象的值根本無法通過 reducer 校驗流程倉庫也提供了 src/utils/isAction.ts 這樣的工具函數(shù)其判定標準就是是純對象且type為字符串。換言之函數(shù)型 dispatch 之所以可行完全依賴于中間件先于 store 內部邏輯攔截了它——這正是文檔所說只要中間件攔截該值、不讓它到達 reducer的底層依據。本倉庫的測試輔助代碼里就有一個與上面asyncFunctionMiddleware幾乎一模一樣的最小 thunk 實現(xiàn)見 test/helpers/middleware.tsexport const thunk: Middleware{ R(thunk: (dispatch: Dispatch, getState: () any) R): R } ({ dispatch, getState }) next action typeof action function ? action(dispatch, getState) : next(action)而 test/applyMiddleware.spec.ts 中名為works with thunk middleware的測試用例就用它驗證了完整閉環(huán)dispatch 一個 thunk 函數(shù)后thunk 內部 dispatch 的普通 action 能正確更新 store 狀態(tài)。Redux 的異步數(shù)據流那么中間件和異步邏輯對 Redux 應用的整體數(shù)據流有什么影響和普通 action 一樣我們首先要處理一個用戶事件比如點擊按鈕然后調用dispatch()傳入某種東西——一個純 action 對象、一個函數(shù)或其他可以被中間件查找識別的值。這個被 dispatch 的值到達中間件后中間件可以發(fā)起一次異步調用等異步調用完成后再 dispatch 一個真正的 action 對象。在 第 2 篇 中我們見過表示常規(guī)同步 Redux 數(shù)據流的示意圖。當 Redux 應用加入異步邏輯后就多了中間件運行 HTTP 請求等邏輯、再 dispatch action 的額外環(huán)節(jié)。異步數(shù)據流看起來就是文章開頭那張圖UI 事件觸發(fā)dispatch值進入中間件管線中間件在異步等待HTTP 請求、定時器等結束后 dispatch 真實 actionaction 再經過剩余中間件到達 reducer狀態(tài)更新后通知 UI 重新渲染。使用 Redux Thunk 中間件實際上Redux 官方早就有了那個異步函數(shù)中間件的標準版本叫做Redux Thunk 中間件npm 包redux-thunk。thunk 中間件讓我們編寫以dispatch和getState為參數(shù)的函數(shù)。thunk 函數(shù)內部可以包含我們想要的任何異步邏輯這些邏輯可以按需 dispatch action、讀取 store 狀態(tài)。把異步邏輯寫成 thunk 函數(shù)讓我們可以在事先不知道將使用哪個 Redux store 的情況下復用這些邏輯。術語說明thunk 是一個編程術語指一段執(zhí)行延遲工作delayed work的代碼。更多用法可參考 Writing Logic with Thunks 使用指南。配置 StoreRedux thunk 中間件作為 npm 包redux-thunk發(fā)布需要先安裝npm install redux-thunk安裝后更新 todo 應用的 Redux store 以使用這個中間件import { createStore, applyMiddleware } from redux // highlight-next-line import { thunk } from redux-thunk import { composeWithDevTools } from redux-devtools-extension import rootReducer from ./reducer // highlight-next-line const composedEnhancer composeWithDevTools(applyMiddleware(thunk)) // store 現(xiàn)在具備了在 dispatch 中接受 thunk 函數(shù)的能力 const store createStore(rootReducer, composedEnhancer) export default storecomposeWithDevTools(applyMiddleware(thunk))正是把applyMiddleware返回的 enhancer 交給 DevTools 組合函數(shù)再傳給createStore對應 src/applyMiddleware.ts 中 enhancer 包 enhancer 的高階結構。從服務器獲取 Todos現(xiàn)在我們的 todo 條目只能存在于客戶端瀏覽器里。我們首先需要一種方式在應用啟動時從服務器加載待辦列表。先寫一個 thunk 函數(shù)它發(fā)起 HTTP 調用請求/fakeApi/todos端點、取得 todo 對象數(shù)組然后 dispatch 一個以該數(shù)組為 payload 的 action。由于這與 todos 功能整體相關thunk 函數(shù)寫在todosSlice.js里示例應用文件import { client } from ../../api/client const initialState [] export default function todosReducer(state initialState, action) { // 省略 reducer 邏輯 } // Thunk 函數(shù) // highlight-start export async function fetchTodos(dispatch, getState) { const response await client.get(/fakeApi/todos) dispatch({ type: todos/todosLoaded, payload: response.todos }) } // highlight-end這個 API 調用只希望在應用第一次加載時執(zhí)行一次。可以放的地方有好幾處在App組件的useEffecthook 里在TodoList組件的useEffecthook 里直接在index.js里緊跟在導入 store 之后。這里先試放在index.js里import React from react import { createRoot } from react-dom/client import { Provider } from react-redux import ./index.css import App from ./App import ./api/server // highlight-start import store from ./store import { fetchTodos } from ./features/todos/todosSlice store.dispatch(fetchTodos) // highlight-end const root createRoot(document.getElementById(root)) root.render( React.StrictMode Provider store{store} App / /Provider /React.StrictMode )刷新頁面后UI 上沒有可見變化。但如果打開 Redux DevTools 擴展應該能看到一個todos/todosLoaded動作被 dispatch 了其中包含由我們的假服務器 API 生成的一些 todo 對象注意雖然我們已經 dispatch 了動作但狀態(tài)并沒有發(fā)生任何變化。我們需要在 todos reducer 中處理這個動作狀態(tài)才會更新。給 reducer 加一個 case 來把數(shù)據加載進 store。因為數(shù)據是從服務器取來的我們要完全替換已有的 todos所以直接返回action.payload數(shù)組讓它成為 todos 的新state值import { client } from ../../api/client const initialState [] export default function todosReducer(state initialState, action) { switch (action.type) { // 省略其他 reducer case // highlight-start case todos/todosLoaded: { // 直接返回新值整體替換現(xiàn)有 state return action.payload } // highlight-end default: return state } } export async function fetchTodos(dispatch, getState) { const response await client.get(/fakeApi/todos) dispatch({ type: todos/todosLoaded, payload: response.todos }) }由于 dispatch 一個動作會立刻更新 store我們也可以在 thunk 里調用getState在 dispatch 之后讀取更新后的狀態(tài)值。例如在 dispatchtodos/todosLoaded動作前后各打印一次 todo 總數(shù)export async function fetchTodos(dispatch, getState) { const response await client.get(/fakeApi/todos) // highlight-next-line const stateBefore getState() console.log(Todos before dispatch: , stateBefore.todos.length) dispatch({ type: todos/todosLoaded, payload: response.todos }) // highlight-next-line const stateAfter getState() console.log(Todos after dispatch: , stateAfter.todos.length) }這正體現(xiàn)了中間件 API 中getState的價值從 src/applyMiddleware.ts 可以看到middlewareAPI.getState直接引用了 store 的getState因此 thunk 內部讀到的永遠是當下最新的狀態(tài)。保存 Todo 條目接下來每當創(chuàng)建新待辦條目時我們也需要更新服務器。正確做法是不要立即 dispatchtodos/todoAdded動作而是先向服務器發(fā)起一次攜帶初始數(shù)據的 API 調用等待服務器返回新保存的 todo 條目副本然后再用這個 todo 條目 dispatch 動作。但如果直接把它寫成一個 thunk 函數(shù)會立刻遇到一個問題thunk 是寫在todosSlice.js里的獨立函數(shù)發(fā)起 API 調用的代碼并不知道新 todo 的文本是什么async function saveNewTodo(dispatch, getState) { // ? 我們需要新 todo 的文本但它從哪來 // highlight-next-line const initialTodo { text } const response await client.post(/fakeApi/todos, { todo: initialTodo }) dispatch({ type: todos/todoAdded, payload: response.todo }) }我們需要一種方式寫一個接收text參數(shù)的函數(shù)由它創(chuàng)建真正的 thunk 函數(shù)使得 thunk 能利用text值發(fā)起 API 調用。外層函數(shù)返回這個 thunk 函數(shù)讓我們可以把它傳給組件里的dispatch// 寫一個同步的外層函數(shù)接收 text 參數(shù) export function saveNewTodo(text) { // 然后創(chuàng)建并返回異步 thunk 函數(shù) return async function saveNewTodoThunk(dispatch, getState) { // ? 現(xiàn)在可以用 text 值并把它發(fā)送到服務器 const initialTodo { text } const response await client.post(/fakeApi/todos, { todo: initialTodo }) dispatch({ type: todos/todoAdded, payload: response.todo }) } }現(xiàn)在可以在Header組件中使用它import React, { useState } from react import { useDispatch } from react-redux // highlight-next-line import { saveNewTodo } from ../todos/todosSlice const Header () { const [text, setText] useState() const dispatch useDispatch() const handleChange e setText(e.target.value) const handleKeyDown e { // 如果用戶按下了回車鍵 const trimmedText text.trim() if (e.which 13 trimmedText) { // highlight-start // 用用戶輸入的文本創(chuàng)建 thunk 函數(shù) const saveNewTodoThunk saveNewTodo(trimmedText) // 然后把 thunk 函數(shù)本身 dispatch 出去 dispatch(saveNewTodoThunk) // highlight-end setText() } } // 省略渲染輸出 }由于我們清楚自己會立刻把 thunk 函數(shù)傳給組件中的dispatch可以省去那個臨時變量直接調用saveNewTodo(text)把得到的 thunk 函數(shù)原樣傳給dispatchconst handleKeyDown e { // 如果用戶按下了回車鍵 const trimmedText text.trim() if (e.which 13 trimmedText) { // highlight-start // 創(chuàng)建 thunk 函數(shù)并立刻 dispatch dispatch(saveNewTodo(trimmedText)) // highlight-end setText() } }此時組件實際上并不知道自己在 dispatch 一個 thunk 函數(shù)——saveNewTodo函數(shù)封裝了真正發(fā)生的事情。Header組件只知道用戶按回車時它需要 dispatch某個值。這種寫一個函數(shù)來準備將要傳給dispatch的東西的模式就是所謂的action creator 模式在 Part 7: 標準 Redux 模式 中會進一步展開?，F(xiàn)在可以看到更新后的todos/todoAdded動作被 dispatch最后需要修改的是 todos reducer。當我們向/fakeApi/todos發(fā)起 POST 請求時服務器會返回一個全新的 todo 對象包含新的 ID 值。這意味著 reducer 不必自己計算新 ID、也不必填其他字段——它只需要構造一個包含新 todo 條目的新state數(shù)組const initialState [] export default function todosReducer(state initialState, action) { switch (action.type) { // highlight-start case todos/todoAdded: { // 返回一個新的 todos 狀態(tài)數(shù)組新 todo 條目追加在末尾 return [...state, action.payload] } // highlight-end // 省略其他 case default: return state } }這樣新增 todo 就完全正常工作了狀態(tài) diff 如下提示thunk 函數(shù)既能用于異步邏輯也能用于同步邏輯。thunk 提供了一種方式來編寫任何需要訪問dispatch和getState的可復用邏輯。本教程小結到目前為止我們已經成功更新了 todo 應用可以用 thunk 函數(shù)向假服務器 API 發(fā)起 HTTP 請求從而獲取待辦列表并保存新的待辦條目。在這個過程中我們看到了 Redux 中間件是如何讓我們發(fā)起異步調用、并在異步調用完成后通過 dispatch 動作與 store 交互的。核心結論回顧Redux 中間件被設計用于編寫帶副作用的邏輯副作用是改變函數(shù)外部狀態(tài)/行為的代碼例如 HTTP 請求、修改函數(shù)參數(shù)、生成隨機值中間件在標準 Redux 數(shù)據流中加了一個額外環(huán)節(jié)中間件可以攔截被傳給dispatch的其他值中間件可以訪問dispatch和getState因此可以在異步邏輯中 dispatch 更多動作Redux Thunk 中間件讓我們可以向dispatch傳函數(shù)thunk 函數(shù)讓我們可以提前寫好異步邏輯而無需事先知道將使用哪個 Redux storeRedux thunk 函數(shù)接收dispatch和getState作為參數(shù)可以 dispatch 已從 API 響應中收到這些數(shù)據之類的動作。從本倉庫源碼看這套機制的骨架非常緊湊applyMiddlewaresrc/applyMiddleware.ts以 enhancer 形式把中間件鏈組合成新的dispatchMiddleware/MiddlewareAPI類型src/types/middleware.ts定義了三層嵌套函數(shù)契約與dispatch/getState兩個能力composesrc/compose.ts完成從右到左的管線嵌套而 test/applyMiddleware.spec.ts 中的用例則逐一驗證了構建期禁 dispatch、中間件僅裝配一次、內部 dispatch 重走管線、以及與 thunk 配合的完整行為。下一步到這里我們已經覆蓋了使用 Redux 的所有核心部分編寫根據 dispatch 的動作更新狀態(tài)的 reducer用 reducer、enhancer 和中間件創(chuàng)建并配置 Redux store使用中間件編寫會 dispatch 動作的異步邏輯。在 Part 7: 標準 Redux 模式 中我們將研究真實 Redux 應用常用的若干代碼模式讓代碼更一致并隨應用增長更好地擴展?！久赓M下載鏈接】reduxA JS library for predictable global state management項目地址: https://gitcode.com/gh_mirrors/re/redux創(chuàng)作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考