摘要
在 React 的世界中，狀態管理方案不下幾百種，但其中最經典的，莫過於 Redux 。如果你想學習函數語言程式設計，那麼 Redux
原始碼就是最好的學習材料。考慮到不少小夥伴用的是 Vue ，本人爭取讓這篇文章寫得通俗易懂，讓沒有接觸過 React 技術棧的同學也能掌握
Redux 。
Redux 屬於典型的“百行程式碼，千行文件”，其中核心程式碼非常少，但是思想不簡單，可以總結為下面兩點：
全域性狀態唯一且不可變（Immutable） ，不可變的意思是當需要修改狀態的時候，用一個新的來替換，而不是直接在原資料上做更改：
let store = { foo: 1, bar: 2 }; // 當需要更新某個狀態的時候 // 建立一個新的物件，然後把原來的替換掉 store = { ...store, foo: 111 };
這點與 Vue 恰好相反，在 Vue 中必須直接在原物件上修改，才能被響應式機制監聽到，從而觸發 setter 通知依賴更新。
狀態更新通過一個純函式（Reducer）完成。純函式（Pure function）的特點是：
- 輸出僅與輸入有關；
- 引用透明，不依賴外部變數；
- 不產生副作用；
因此對於一個純函式，相同的輸入一定會產生相同的輸出，非常穩定。使用純函式進行全域性狀態的修改，使得全域性狀態可以被預測。
1. 需要了解的幾個概念
在使用 Redux 及閱讀原始碼之前需要了解下面幾個概念：
Action
action 是一個普通 JavaScript 物件，用來描述如何修改狀態，其中需要包含 type 屬性。一個典型的 action 如下所示：
const addTodoAction = {
type: 'todos/todoAdded',
payload: 'Buy milk'
}Reducers
reducer 是一個純函式，其函式簽名如下：
/**
* @param {State} state 當前狀態
* @param {Action} action 描述如何更新狀態
* @returns 更新後的狀態
*/
function reducer(state: State, action: Action): Statereducer 函式的名字來源於陣列的 reduce 方法，因為它們類似陣列 reduce 方法傳遞的回撥函式，也就是上一個返回的值會作為下一次呼叫的引數傳入。
reducer函式的編寫需要嚴格遵頊以下規則：
檢查reducer是否關心當前的action
- 如果是，就建立一份狀態的副本，使用新的值更新副本中的狀態，然後返回這個副本
- 否則就返回當前狀態
一個典型的 reducer 函式如下：
const initialState = { value: 0 }
function counterReducer(state = initialState, action) {
if (action.type === 'counter/incremented') {
return {
...state,
value: state.value + 1
}
}
return state
}Store
通過呼叫 createStore 建立的 Redux 應用例項，可以通過 getState() 方法獲取到當前狀態。
Dispatch
store 例項暴露的方法。更新狀態的唯一方法就是通過 dispatch 提交 action 。store 將會呼叫 reducer 執行狀態更新，然後可以通過 getState() 方法獲取更新後的狀態：
store.dispatch({ type: 'counter/incremented' })
console.log(store.getState())
// {value: 1}storeEnhancer
createStore 的高階函式封裝，用於增強 store 的能力。Redux 的 applyMiddleware 是官方提供的一個 enhancer 。
middleware
dispatch 的高階函式封裝，由 applyMiddleware 把原 dispatch替換為包含 middleware 鏈式呼叫的實現。Redux-thunk 是官方提供的 middleware，用於支援非同步 action 。
2. 基本使用
學習原始碼之前，我們先來看下 Redux 的基本使用，便於更好地理解原始碼。
首先我們編寫一個 Reducer 函式如下：
// reducer.js
const initState = {
userInfo: null,
isLoading: false
};
export default function reducer(state = initState, action) {
switch (action.type) {
case 'FETCH_USER_SUCCEEDED':
return {
...state,
userInfo: action.payload,
isLoading: false
};
case 'FETCH_USER_INFO':
return { ...state, isLoading: true };
default:
return state;
}
}在上面程式碼中：
- reducer首次呼叫的時候會傳入initState作為初始狀態，然後switch...case最後的default用來獲取初始狀態
- 在switch...case中還定義了兩個action.type用來指定如何更新狀態
接下來我們建立 store ：
// index.js
import { createStore } from "redux";
import reducer from "./reducer";
const store = createStore(reducer);store 例項會暴露兩個方法 getState 和 dispatch ，其中 getState 用於獲取狀態，dispatch 用於提交 action 修改狀態，同時還有一個 subscribe 用於訂閱store的變化：
// index.js
// 每次更新狀態後訂閱 store 變化
store.subscribe(() => console.log(store.getState()));
// 獲取初始狀態
store.getState();
// 提交 action 更新狀態
store.dispatch({ type: "FETCH_USER_INFO" });
store.dispatch({ type: "FETCH_USER_SUCCEEDED", payload: "測試內容" });我們執行一下上面的程式碼，控制檯會先後列印：
{ userInfo: null, isLoading: false } // 初始狀態
{ userInfo: null, isLoading: true } // 第一次更新
{ userInfo: "測試內容", isLoading: false } // 第二次更新3. Redux Core 原始碼分析
上面的例子雖然很簡單，但是已經包含 Redux 的核心功能了。接下來我們來看下原始碼是如何實現的。
createStore
可以說 Redux 設計的所有核心思想都在 createStore 裡面了。 createStore 的實現其實非常簡單，整體就是一個閉包環境，裡面快取了 currentReducer 和 currentState ，並且定義了getState、subscribe、dispatch 等方法。
createStore 的核心原始碼如下，由於這邊還沒用到 storeEnhancer ，開頭有些if...else的邏輯被省略了，順便把原始碼中的型別註解也都去掉了，方便閱讀：
// src/createStore.ts
function createStore(reducer, preloadState = undefined) {
let currentReducer = reducer;
let currentState = preloadState;
let listeners = [];
const getState = () => {
return currentState;
}
const subscribe = (listener) => {
listeners.push(listener);
}
const dispatch = (action) => {
currentState = currentReducer(currentState, action);
for (let i = 0; i < listeners.length; i++) {
const listener = listeners[i];
listener();
}
return action;
}
dispatch({ type: "INIT" });
return {
getState,
subscribe,
dispatch
}
}createStore 的呼叫鏈路如下：
- 首先呼叫 createStore 方法，傳入 reducer 和 preloadState 。preloadState 代表初始狀態，假如不傳那麼 reducer 必須要指定初始值；
- 將 reducer 和 preloadState 分別賦值給 currentReducer 和 currentState 用於建立閉包；
- 建立 listeners 陣列，這其實就是基於釋出訂閱模式，listeners 就是釋出訂閱模式的事件中心，也是通過閉包快取；
- 建立 getState 、subscribe 、dispatch 等函式；
- 呼叫 dispatch 函式，提交一個 INIT 的 action 用來生成初始state，在 Redux 原始碼中，這裡的 type 是一個隨機數；
- 最後返回一個包含 getState 、subscribe 、dispatch 函式的物件，即 store 例項；
那麼很顯然，外界無法訪問到閉包的值，只能通過getState函式訪問。
為了訂閱狀態更新，可以使用 subscribe 函式向事件中心 push 監聽函式（注意 listener 是允許副作用存在的）。
當需要更新狀態時，呼叫 dispatch 提交 action 。在 dispatch 函式中呼叫 currentReducer（也就是 reducer 函式），並傳入 currentState 和 action ，然後生成一個新的狀態，傳給 currentState 。在狀態更新完成後，將訂閱的監聽函式執行一遍（實際上只要呼叫 dispatch ，即使沒有對 state 做任何修改，也會觸發監聽函式）。
如果有熟悉物件導向程式設計的小夥伴可能會說，createStore裡面做的事情可以封裝到一個類裡面。確實可以，本人用 TypeScript 實現如下（釋出訂閱的功能不寫了）：
type State = Object;
type Action = {
type: string;
payload?: Object;
}
type Reducer = (state: State, action: Action) => State;
// 定義 IRedux 介面
interface IRedux {
getState(): State;
dispatch(action: Action): Action;
}
// 實現 IRedux 介面
class Redux implements IRedux {
// 成員變數設為私有
// 相當於閉包作用
private currentReducer: Reducer;
private currentState?: State;
constructor(reducer: Reducer, preloadState?: State) {
this.currentReducer = reducer;
this.currentState = preloadState;
this.dispatch({ type: "INIT" });
}
public getState(): State {
return this.currentState;
}
public dispatch(action: Action): Action {
this.currentState = this.currentReducer(
this.currentState,
action
);
return action;
}
}
// 通過工廠模式建立例項
function createStore(reducer: Reducer, preloadState?: State) {
return new Redux(reducer, preloadState);
}你看，多有意思，函數語言程式設計和麵向物件程式設計竟然殊途同歸了。
applyMiddleware
applyMiddleware 是 Redux 中的一個難點，雖然程式碼不多，但是裡面用到了大量函數語言程式設計技巧，本人也是經過大量原始碼除錯才徹底搞懂。
首先要能看懂這種寫法：
const middleware =
(store) =>
(next) =>
(action) => {
// ...
}上面的寫法相當於：
const middleware = function(store) {
return function(next) {
return function(action) {
// ...
}
}
}其次需要知道，這種其實就是函式柯里化，也就是可以分步接受引數。如果內層函式存在變數引用，那麼每次呼叫都會生成閉包。
說到閉包，有些同學馬上就想到記憶體洩漏。但實際上閉包在平時專案開發中非常常見，很多時候我們不經意間就建立了閉包，但往往都被我們忽略了。
閉包一大作用就是快取值，這和宣告一個變數在賦值的效果是類似的。而閉包的難點就在於，變數是顯式宣告，而閉包往往是隱式的，什麼時候建立閉包，什麼時候更新了閉包的值，很容易被忽略。
可以這麼說，函數語言程式設計就是圍繞閉包展開的。在下面的原始碼分析中，會看到大量閉包的例子。
applyMiddleware 是 Redux 官方實現的 storeEnhancer ，實現了一套外掛機制，增加 store 的能力，例如實現非同步 Action ，實現 logger 日誌列印，實現狀態持久化等等。
export default function applyMiddleware<Ext, S = any>(
...middlewares: Middleware<any, S, any>[]
): StoreEnhancer<{ dispatch: Ext }>個人觀點，這樣做的好處就是提供了造輪子的空間
applyMiddleware 接受一個或多個 middleware 例項，然後再傳給createStore：
import { applyMiddleware, createStore } from "redux";
import thunk from "redux-thunk"; // 使用 thunk 中介軟體
import reducer from "./reducer";
const store = createStore(reducer, applyMiddleware(thunk));createStore 入參中只接受一個 storeEnhancer ，如果需要傳入多個，可以使用 Redux Utils 中的 compose 函式將它們組合起來。
compose 函式在後面會介紹
看上面的用法，可以猜測 applyMiddleware 肯定也是個高階函式。之前說到 createStore 前面有些if..else邏輯因為沒用到 storeEnhancer 所以被省略了。這邊我們一起來看下。
首先看 createStore 的函式簽名，實際上是可以接受 1-3 個引數。其中 reducer 是必須要傳遞的。當第二個引數為函式型別，會識別為 storeEnhancer。如果第二個引數不是函式型別，則會識別為 preloadedState ，此時還可以再傳遞一個函式型別的 storeEnhancer ：
function createStore(reducer: Reducer, preloadedState?: PreloadedState | StoreEnhancer, enhancer?: StoreEnhancer): Store可以看到原始碼中引數校驗的邏輯：
// src/createStore.ts:71
if (
(typeof preloadedState === 'function' && typeof enhancer === 'function') ||
(typeof enhancer === 'function' && typeof arguments[3] === 'function')
) {
// 傳遞兩個函式型別引數的時候，丟擲異常
// 也就是隻接受一個 storeEnhancer
throw new Error();
}當第二個引數為函式型別，將它作為 storeEhancer 處理：
// src/createStore.ts:82
if (typeof preloadedState === 'function' && typeof enhancer === 'undefined') {
enhancer = preloadedState as StoreEnhancer<Ext, StateExt>
preloadedState = undefined
}接下來是一個比較難的邏輯：
// src/createStore.ts:87
if (typeof enhancer !== 'undefined') {
// 如果使用了 enhancer
if (typeof enhancer !== 'function') {
// 如果 enhancer 不是函式就丟擲異常
throw new Error();
}
// 直接返回撥用 enhancer 之後的結果，並沒有往下繼續建立 store
// enhancer 肯定是一個高階函式
// 先傳入了 createStore，又傳入 reducer 和 preloadedState
// 說明很有可能在 enhancer 內部再次呼叫 createStore
return enhancer(createStore)(
reducer,
preloadedState
)
}下面我們來看一下 applyMiddleware 的原始碼，為便於閱讀，把原始碼中的型別註解都去掉了：
// src/applyMiddleware.ts
import compose from './compose';
function applyMiddleware(...middlewares) {
return (createStore) => (reducer, preloadedState) => {
const store = createStore(reducer, preloadedState);
let dispatch = () => {
throw new Error();
}
const middlewareAPI = {
getState: store.getState,
dispatch: (action, ...args) => dispatch(action, ...args)
}
const chain = middlewares.map(middleware => middleware(middlewareAPI));
dispatch = compose(...chain)(store.dispatch);
return {
...store,
dispatch
}
}
}可以看到這裡程式碼並不多，但是出現了一個函式巢狀函式的情形：
const applyMiddleware = (...middlewares) =>
(createStore) =>
(reducer, preloadedState) => {
// ...
}分析一下原始碼中的呼叫鏈路：
- 呼叫 applyMiddleware 時，傳入中介軟體例項，返回 enhancer 。從剩餘引數的用法看出，支援傳入多個 middleware ；
- 由createStore呼叫 enhancer ，分兩次傳入 createStore 和 reducer 、preloadedState ；
- 內部再次呼叫 createStore ，這次由於沒有傳 enhancer ，所以直接走建立 store 的流程；
- 建立一個經過修飾的 dispatch 方法，覆蓋預設 dispatch ；
- 構造 middlewareAPI ，對 middleware 注入 middlewareAPI ；
- 將 middleware 例項組合為一個函式，再向 middleware 傳遞預設的 store.dispatch 方法；
- 最後返回一個新的 store 例項，此時 store 的 dispatch 方法經過了 middleware 修飾；
這裡涉及到 compose 函式，是函數語言程式設計正規化中經常用到的一種處理，建立一個從右到左的資料流，右邊函式執行的結果作為引數傳入左邊，最終返回一個以上述資料流執行的函式：
// src/compose.ts:46
export default function compose(...funcs) {
if (funcs.length === 0) {
return (arg) => arg
}
if (funcs.length === 1) {
return funcs[0]
}
return funcs.reduce(
(a, b) =>
(...args) =>
a(b(...args))
)
}思考題：如果希望把執行順序改為從左往右，需要怎麼改？
通過這邊的程式碼，我們不難推斷出一箇中介軟體的結構：
function middleware({ dispatch, getState }) {
// 接收 middlewareAPI
return function(next) {
// 接收預設的 store.dispatch 方法
return function(action) {
// 接收元件呼叫 dispatch 傳入的 action
console.info('dispatching', action);
let result = next(action);
console.log('next state', store.getState());
return result;
}
}
}看到這裡，我想大多數讀者都會有兩個問題：
- 通過 middlewareAPI 獲取的 dispatch 函式和 store 例項最終暴露的 dispatch 函式都是經過修飾的嗎；
- 為了防止在建立 middleware 的時候呼叫 dispatch ，applyMiddleware 給新的 dispatch 初始化為一個空函式，且呼叫會丟擲異常，那麼這個函式究竟在何時被替換掉的；
大家可以先試著思考一下。
說實話，本人在閱讀原始碼的時候也被這兩個問題困擾，大多數技術文章也都沒有給出解釋。沒辦法，只能通過除錯原始碼來找答案。經過不斷除錯，終於搞清楚了，middlewareAPI 的 dispatch 函式本身其實就是以閉包形式引入的，這個閉包可能沒多少人能看得出來：
// 定義新的 dispatch 方法
// 此時是一個空函式，呼叫會丟擲異常
let dispatch = () => {
throw new Error();
}
// 定義 middlewareAPI
// 注意這裡的 dispatch 是通過閉包形式引入的
const middlewareAPI = {
getState: store.getState,
dispatch: (action, ...args) => dispatch(action, ...args)
}
// 對 middleware 注入 middlewareAPI
// 此時在 middleware 中呼叫 dispatch 會丟擲異常
const chain = middlewares.map(middleware => middleware(middlewareAPI));然後下面這段程式碼其實做了兩件事，一方面將 middleware 組合為一個函式，注入預設 dispatch 函式，另一方面將新的 dispatch 初始的空函式替換為正常可執行的函式。同時由於 middlewareAPI 的 dispatch 是以閉包形式引入的，當 dispatch 更新之後，閉包中的值也相應更新：
// 將 dispatch 替換為正常的 dispatch 方法
// 注意閉包中的值也會相應更新，middleware 可以訪問到更新後的方法
dispatch = compose(...chain)(store.dispatch);也就是說，createStore 生成的例項暴露的 dispatch 和 middleware 獲取的都是修飾後的 dispatch ，並且應該是長這樣：
function(action) {
// 注意這裡存在閉包
// 可以獲取到中介軟體初始化傳入的 dispatch、getState 和 next
// 如果你打斷點，可以在 scope 中看到閉包的變數
// 同時注意這裡的 dispatch 就是這個函式本身
console.info('dispatching', action);
let result = next(action);
console.log('next state', store.getState());
return result;
}4. 處理非同步 Action
由於 reducer 需要嚴格控制為純函式，因此不能在裡面進行非同步操作，也不能進行網路請求。有些同學可能會說，雖然 reducer 裡面不能放非同步程式碼，但是可以把 dispatch 函式放在非同步回撥中呼叫呀：
setTimeout(() => {
this.props.dispatch({ type: 'HIDE_NOTIFICATION' })
}, 5000)在 React 元件中通常用 connect 把 dispatch 對映到元件的props 中，類似 Vuex 中的 mapAction 用法。
確實可以！Redux 作者 Dan Abramov 在 Stackoverflow 上面有一個非常好的回答，其中就贊同了這種用法：
本人將 Dan Abramov 的核心觀點總結如下。
- Redux 確實提供了一些處理非同步 Action 的替代方法，但應該只在當你意識到你編寫了大量模板程式碼的時候再去使用。否則就用最簡單的方案（如無必要，勿增實體）；
- 當多個元件需要用到同一個 action.type 時，為避免 action.type 拼寫錯誤，需要抽離公共的 actionCreator，例如：
// actionCreator.js
export function showNotification(text) {
return { type: 'SHOW_NOTIFICATION', text }
}
export function hideNotification() {
return { type: 'HIDE_NOTIFICATION' }
}
// component.js
import { showNotification, hideNotification } from '../actionCreator'
this.props.dispatch(showNotification('You just logged in.'))
setTimeout(() => {
this.props.dispatch(hideNotification())
}, 5000)上面的邏輯在簡單場景下完全可行，但是隨著業務複雜度增加會出現幾個問題：
- 通常狀態更新有好幾個步驟，而且存在邏輯上的先後順序，例如通知的展示和隱藏，導致模板程式碼較多；
- 提交的 action 沒有狀態，如出現競爭條件可能導致狀態更新出 bug ；
- 出於上面的問題，需要抽離非同步的 actionCreator ，把涉及狀態更新的操作封裝進去，便於複用，同時為每次 dispatch 生成唯一 id ：
// actions.js
function showNotification(id, text) {
return { type: 'SHOW_NOTIFICATION', id, text }
}
function hideNotification(id) {
return { type: 'HIDE_NOTIFICATION', id }
}
let nextNotificationId = 0
export function showNotificationWithTimeout(dispatch, text) {
const id = nextNotificationId++
dispatch(showNotification(id, text))
setTimeout(() => {
dispatch(hideNotification(id))
}, 5000)
}然後在頁面元件中這樣使用，解決了模板程式碼和狀態更新衝突問題：
// component.js
showNotificationWithTimeout(this.props.dispatch, 'You just logged in.')
// otherComponent.js
showNotificationWithTimeout(this.props.dispatch, 'You just logged out.')- 細心的同學應該注意到，這邊傳遞了 dispatch 。這是因為，正常來說只有元件中能訪問到 dispatch ，為了能讓外部封裝的函式也能訪問，我們需要將 dispatch 作為引數傳過去；
- 這時有些同學會提出質疑，如果將 store 作為全域性單例，不就可以直接訪問了：
// store.js
export default createStore(reducer)
// actions.js
import store from './store'
// ...
let nextNotificationId = 0
export function showNotificationWithTimeout(text) {
const id = nextNotificationId++
store.dispatch(showNotification(id, text))
setTimeout(() => {
store.dispatch(hideNotification(id))
}, 5000)
}
// component.js
showNotificationWithTimeout('You just logged in.')
// otherComponent.js
showNotificationWithTimeout('You just logged out.')- 上面這樣從操作上來說確實可行，但是 Redux 團隊並不贊同單例的寫法。他們的理由是，如果 store 變為單例，會導致服務端渲染的實現變得困難，同時測試也不方便，如要改用 mock store 需要修改所有 import ；
- 基於上面的原因，Redux 團隊還是建議使用函式引數將 dispatch 傳遞出去，儘管這樣很麻煩。那麼有沒有一種解決方案呢？有的，使用 Redux-thunk 就解決了這個問題；
- 實際上，Redux-thunk 的作用是教 Redux 識別函式型別的特殊 Action ；
- 中介軟體啟用後，當 dispatch 的 Action 為函式型別，Redux-thunk 就會給這個函式傳入 dispatch 作為引數，需要注意最終 reducer 拿到的仍然是普通 JavaScript 物件作為 Action ：
// actions.js
function showNotification(id, text) {
return { type: 'SHOW_NOTIFICATION', id, text }
}
function hideNotification(id) {
return { type: 'HIDE_NOTIFICATION', id }
}
let nextNotificationId = 0
export function showNotificationWithTimeout(text) {
return function (dispatch) {
const id = nextNotificationId++
dispatch(showNotification(id, text))
setTimeout(() => {
dispatch(hideNotification(id))
}, 5000)
}
}在元件中使用如下：
// component.js
this.props.dispatch(showNotificationWithTimeout('You just logged in.'))好了，Dan Abramov 的觀點就總結到這裡。
看到這裡大家應該清楚 Redux-thunk 的作用了，Redux-thunk 本身並沒有提供非同步解決方案，實現非同步就是使用最簡單的方法，把 dispatch 函式放在非同步回撥中。很多時候我們會封裝非同步的 actionCreator ，在非同步操作中每次都需要把 dispatch 傳遞出來很麻煩，Redux-thunk 對 dispatch 函式進行高階封裝，允許接受函式型別的 Action ，同時給這個 Action 傳入 dispatch 和 getState 作為引數，這樣就不用每次手動傳遞。
在看原始碼之前，大家可以結合 applyMiddleware 原始碼，想一下 Redux-thunk 內部實現。
其實 Redux-thunk 實現原理非常簡單，程式碼如下：
// src/index.ts:15
function createThunkMiddleware(extraArgument) {
return ({ dispatch, getState }) =>
next =>
action => {
if (typeof action === 'function') {
return action(dispatch, getState, extraArgument)
}
return next(action)
}
}在 Redux-thunk 內部，首先會呼叫 createThunkMiddleware 方法得到一個高階函式然後向外匯出。這個函式就是我們之前分析的中介軟體結構：
({ dispatch, getState }) =>
next =>
action => {
if (typeof action === 'function') {
return action(dispatch, getState, extraArgument)
}
return next(action)
}首先在初始化階段，applyMiddleware 會為 thunk 先後注入 middlewareAPI （對應 dispatch 和 getState 形參）和 store.dispatch （即原本的 dispatch 方法，對應 next 形參）。
在初始化完成之後，store 例項的 dispatch 會被替換為一個經過修飾的 dispatch 方法（middlewareAPI 中的 dispatch 由於是閉包引用，也會被替換），用 dispatch.toString() 列印可以輸出如下內容：
// 注意這裡可以訪問到閉包中的 dispatch、getState 和 next
// 初始化完成後的 dispatch 實際上就是下面這個函式本身
action => {
if (typeof action === 'function') {
return action(dispatch, getState, extraArgument)
}
return next(action)
}接下來的事情就很簡單了，當我們提交一個函式型別的 Action ：
// actions.js
const setUserInfo = data => ({
type: "SET_USER_INFO",
payload: data
})
export const getUserInfoAction = userId => {
return dispatch => {
getUserInfo(userId)
.then(res => {
dispatch(setUserInfo(res));
})
}
}
// component.js
import { getUserInfoAction } from "./actionCreator";
this.props.dispatch(getUserInfoAction("666"));當提交的 action 為函式型別的時候，就呼叫這個函式，然後傳入 dispatch 、getState 、extraArgument 引數：
if (typeof action === 'function') {
return action(dispatch, getState, extraArgument)
}（從這裡可以看出，除了 dispatch 之外，在函式型別的 Action 內部還可以訪問 getState 和 extraArgument）
當非同步操作完成，呼叫 Redux-thunk 傳遞的 dispatch 方法提交物件型別 Action 時，還是進入這個被修飾的 dispatch 方法，只不過在判斷型別的時候，進入了另一個分支：
return next(action);這裡的 next 就是 Redux 原本的 dispatch 方法，會將物件型別的 Action 提交給 reducer 方法，最終執行狀態更新。
5. 總結
Redux 是一種非常經典的狀態管理解決方案。它遵循函數語言程式設計的原則，狀態只讀且不可變，只有通過純函式才能更新狀態。
但是 Redux 同樣也存在著不少問題。首先，對於新手來說，上手成本較高，使用之前需要先了解函數語言程式設計的概念和設計思想。其次，Redux 在實際開發中非常繁瑣，即使實現一個很簡單的功能，可能也需要同時修改 4-5 個檔案，降低了開發效率。作為對比，Vuex 的上手成本非常低，對於新手非常友好，使用也非常簡單，既不需要非同步中介軟體，也不需要額外的 UI binding ，在 Redux 中通過外掛提供的功能，全部內建開箱即用。
對此，Redux 官方提供了一個封裝方案 Redux Toolkit，社群也提供了很多封裝方案，例如 Dva 、Rematch 等等，旨在簡化 Redux 的使用，API 的封裝上很多地方就是參考了 Vuex 。甚至還出現了酷似 Vue 響應式、使用可變資料（Mutable）的 Mobx 狀態管理方案。此外，React 官方團隊也在近期推出了 Recoil 狀態管理庫。
參考
https://github.com/reduxjs/redux