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