摘要：假設(shè)等于，其中，，是三個(gè)中間件，等于，那么可以簡化為。最終返回中的方法以及經(jīng)過中間件包裝處理過的方法。以此類推，第二個(gè)返回的就是第一個(gè)中間件的形參。根據(jù)這個(gè)的討論，在中間件頂層調(diào)用了，結(jié)果導(dǎo)致無法執(zhí)行后面的中間件。

redux 主要包含 5 個(gè)方法，分別是：

createStore

combineReducers

bindActionCreators

applyMiddleware

compose

今天主要講解下 applyMiddleware 和 compose 這兩個(gè)方法。在 redux 中引入了中間件的概念，沒錯(cuò)如果你使用過 Express 或者 Koa 的話，一定不會(huì)對中間件陌生。我們知道，在 Koa 中，串聯(lián)各個(gè)中間件的正是 compose 方法，所以在 redux 中也同樣使用了這個(gè)命名，作用也是串聯(lián)所有中間件。

在正式講解前，我們先來看下 reduce 的用法。根據(jù) MDN 上的解釋，

reduce() 方法是對累加器和數(shù)組中的每個(gè)元素（從左到右）應(yīng)用一個(gè)函數(shù)，將其減少為單個(gè)值。

arr.reduce(callback[, initialValue])

參數(shù)

callback

執(zhí)行數(shù)組中每個(gè)值的函數(shù)，包含四個(gè)參數(shù)：

accumulator：累加器累加回調(diào)的返回值; 它是上一次調(diào)用回調(diào)時(shí)返回的累積值，或 initialValue

currentValue：數(shù)組中正在處理的元素。

currentIndex：數(shù)組中正在處理的當(dāng)前元素的索引。 如果提供了initialValue，則索引號(hào)為0，否則為索引為1。

array：調(diào)用 reduce 的數(shù)組

initialValue

用作第一個(gè)調(diào)用 callback的第一個(gè)參數(shù)的值。 如果沒有提供初始值，則將使用數(shù)組中的第一個(gè)元素。 在沒有初始值的空數(shù)組上調(diào)用 reduce 將報(bào)錯(cuò)。

返回

函數(shù)累計(jì)處理的結(jié)果

有了上面 reduce 的基礎(chǔ)，我們再來看下 compose 的代碼。compose 的代碼很簡單，10行代碼左右，但你看到 reduce 部分的時(shí)候，估計(jì)會(huì)一臉懵逼，短短的一行代碼看上去卻很繞。

/**
 * Composes single-argument functions from right to left. The rightmost
 * function can take multiple arguments as it provides the signature for
 * the resulting composite function.
 *
 * @param {...Function} funcs The functions to compose.
 * @returns {Function} A function obtained by composing the argument functions
 * from right to left. For example, compose(f, g, h) is identical to doing
 * (...args) => f(g(h(...args))).
 */
 
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)))
}

看注釋，它的作用應(yīng)該是

執(zhí)行 compose(f, g, h)
得到 (...args) => f(g(h(...args)))

我們來推導(dǎo)下，它是怎么得出這個(gè)結(jié)果的。假設(shè) funcs 等于 [f1, f2, f3]，其中 f1，f2，f3 是三個(gè)中間件，(a, b) => (..args) => a(b(...args)) 等于 f，那么 funcs.reduce((a, b) => (...args) => a(b(...args))) 可以簡化為 [f1, f2, f3].reduce(f)。

第 1 次執(zhí)行 f：

a = f1
b = f2 
返回 (...args) => f1(f2(..args))

第 2 次執(zhí)行 f：

a = (...args) => f1(f2(...args))
b = f3
返回 (...args) => a(f3(...args)) = f1(f2(f3(...args)))

通過上面的推導(dǎo)，證實(shí)了先前得出的結(jié)論

compise(f, g, h) = (...args) => f(g(h(...args)))

通過上面的分析，我們知道 compose 是對中間件的串聯(lián)，那么 applyMiddleware 就是對中間件的應(yīng)用了。最終返回 createStore 中的方法以及經(jīng)過中間件包裝處理過的 dispatch 方法。

export default function applyMiddleware(...middlewares) {
  return createStore => (...args) => {
    const store = createStore(...args)
    let dispatch = () => {
      throw new Error(
        `Dispatching while constructing your middleware is not allowed. ` +
          `Other middleware would not be applied to this dispatch.`
      )
    }
    let chain = []

    const middlewareAPI = {
      getState: store.getState,
      dispatch: (...args) => dispatch(...args)
    }
    chain = middlewares.map(middleware => middleware(middlewareAPI))
    dispatch = compose(...chain)(store.dispatch)

    return {
      ...store,
      dispatch
    }
  }
}

我們通過一個(gè)具體的中間件 redux-thunk，來查看它內(nèi)部到底是怎么來執(zhí)行加載的中間件的。

function createThunkMiddleware(extraArgument) {
  return ({ dispatch, getState }) => next => action => {
    if (typeof action === "function") {
      return action(dispatch, getState, extraArgument);
    }

    return next(action);
  };
}

const thunk = createThunkMiddleware();
thunk.withExtraArgument = createThunkMiddleware;

export default thunk;

中間件中包含了三個(gè)箭頭函數(shù)，在 applyMiddleware 中的 map 操作后，返回了第二層箭頭函數(shù)，所以 chain 中存儲(chǔ)的是各個(gè)中間件的第二層函數(shù)。

根據(jù) compose 的分析，

dispatch = compose(...chain)(store.dispatch)
等于
dispatch = f1(f2(f3(store.dispatch)))

我們先執(zhí)行第三個(gè)中間件，并把返回結(jié)果作為第二個(gè)中間件的入?yún)⒗^續(xù)執(zhí)行，以此類推，下一個(gè)中間件的入?yún)⑹巧弦粋€(gè)中間件的返回。如果說這里第三個(gè)中間件是上面的 redux-thunk，那么函數(shù)中的 next 就是 store.dispatch，返回第三個(gè)箭頭函數(shù) action。這里返回的第三個(gè)箭頭函數(shù)，就是第二個(gè)中間件的 next 形參。以此類推，第二個(gè)返回的 action 就是第一個(gè)中間件的 next 形參。但是這里都還沒真正開始執(zhí)行中間件。

當(dāng)我們外部調(diào)用 store.dispatch(action) 方法的時(shí)候，才要真正開始執(zhí)行各個(gè)中間件。首先執(zhí)行中間件 f1，當(dāng)執(zhí)行到 next 的時(shí)候，開始執(zhí)行第二個(gè)中間件 f2，以此類推直到最后一個(gè)中間件，調(diào)用原生 store.dispatch 方法。

之所以要寫這么繞，也是為了符合 redux 單一數(shù)據(jù)源的原則，applyMiddleware 的寫法保證了 action 的流向，而且每一步的數(shù)據(jù)變化都是可以追蹤的。

對比了 4.0.0-beta.1 之前版本的 applyMiddleware 的區(qū)別，發(fā)現(xiàn)內(nèi)部 dispatch 從之前的 store.dispatch 改成了現(xiàn)在的直接拋出一個(gè)錯(cuò)誤。根據(jù)這個(gè) issues 的討論，在中間件頂層調(diào)用了 store.dispatch，結(jié)果導(dǎo)致無法執(zhí)行后面的中間件。這個(gè)調(diào)用應(yīng)該是在處理 map 操作的時(shí)候執(zhí)行的，此時(shí)的 applyMiddleware 還沒執(zhí)行完，store.dispatch 調(diào)用的還是原生 createStroe 中的方法才導(dǎo)致的這個(gè)問題。

另外如果在中間件中即 action 層使用 dispatch 會(huì)怎樣呢？我們知道我們可以通過 next 進(jìn)入到下個(gè)中間件，那如果調(diào)用 store.dispatch 的話又會(huì)從外層重新來一遍，假如這個(gè)中間件內(nèi)部只是粗暴的調(diào)用 store.dispatch(action) 的話，就會(huì)形成死循環(huán)。如下圖所示

redux middleware 詳解
Dispatching in a middleware before applyMiddleware completes