在redux項(xiàng)目開(kāi)發(fā)過(guò)程中，有時(shí)候我們需要自己去編寫(xiě)一些redux中間件， 但是中間件用法法一般都像下面這樣子：

export function myMidware ({dispatch, getState}) {
    //  返回一個(gè)接收dispatch為參數(shù)的函數(shù)
    return (dispatch) => (action) => {
        // do something
        return dispatch(action)
    }
}

//使用中間件
const store = createStore(reducer, applyMiddleware(myMidware))

一看到這種套娃的寫(xiě)法，整個(gè)人都是懵的。那么接下來(lái)我就帶著問(wèn)題給大家理解理解, 為什么中間件函數(shù)非要這么寫(xiě)， applyMiddleware究竟做了什么

廢話不多說(shuō)首先來(lái)看看applyMiddleware的源碼，看看它到底做了啥：

// 首先這個(gè)函數(shù)接收多個(gè)中間件函數(shù)，放在middlewares的數(shù)組中
export default function applyMiddleware(...middlewares) {
  // 返回一個(gè)接受createStore參數(shù)的函數(shù)， 這個(gè)函數(shù)執(zhí)行之后應(yīng)該返回一個(gè)增強(qiáng)版createStore函數(shù)
  // (...args) => { ... } 這里可以看成是一個(gè)增強(qiáng)版的createStore函數(shù)(從createStore源碼可以看出)
  return createStore => (...args) => {
    const store = createStore(...args)
    // 這里的dispatch是不希望你在創(chuàng)建中間件的時(shí)候調(diào)用它
    let dispatch = () => {
      throw new Error(
        'Dispatching while constructing your middleware is not allowed. ' +
          'Other middleware would not be applied to this dispatch.'
      )
    }

    // 把原版store的api構(gòu)造成對(duì)象準(zhǔn)備傳遞給中間件
    const middlewareAPI = {
      getState: store.getState,
      dispatch: (...args) => dispatch(...args) // 個(gè)人感覺(jué)這里不給用 其實(shí)就沒(méi)必要給到中間件構(gòu)造函數(shù)里面去
    }
    // 把構(gòu)造好的api對(duì)象傳遞給中間件，讓中間件擁有可以訪問(wèn)store的能力
    const chain = middlewares.map(middleware => middleware(middlewareAPI))
    // compose函數(shù)可以把多個(gè)中間件函數(shù)的數(shù)組，合成一個(gè)中間件函數(shù)的形式，然后再執(zhí)行中間件
    // 并將得到的新的函數(shù) 當(dāng)作新的dispatch函數(shù)
    dispatch = compose(...chain)(store.dispatch)
    // 返回一個(gè)增強(qiáng)了dispatch函數(shù)的store
    return {
      ...store,
      dispatch
    }
  }
}

從上面的代碼解讀可以看出， applyMiddleware函數(shù)，做了已下事情：

• 返回一個(gè)新的createStore函數(shù)，這里叫它 superCreateStore函數(shù)
• 在supterCreateStore函數(shù)中，執(zhí)行了createStore函數(shù)，可見(jiàn) args其實(shí)就是reducer，看createStore函數(shù)源碼可知傳入的就是reducer
• superCreateStore函數(shù)中執(zhí)行中間件函數(shù)，得到了一個(gè)新的dispatch函數(shù)，這里叫它superDispatch

• 最后supterCreateStore函數(shù)返回了一個(gè)新的store對(duì)象，這個(gè)對(duì)象改造了dispatch函數(shù)

看完了源碼，接下來(lái)就開(kāi)始理解這個(gè)思路了，套娃開(kāi)始：

首先是applyMiddleware

• createStore( reducer, enhancer) 返回一個(gè) store
• applyMiddleware(...middleWares) 返回 enhancer增強(qiáng)器
• enhencer就是一個(gè)函數(shù)，接收 createStore為參數(shù)，返回一個(gè)superCreateStore函數(shù)
• superCreateStore函數(shù)和createStore一樣，接手reducers作為參數(shù)，返回一個(gè)新的store

再來(lái)理解中間件函數(shù)執(zhí)行過(guò)程

• 在superCreateStore 中，第一次執(zhí)行中間傳入了 middlewareAPI, 得到了dispatch增強(qiáng)器
• dispatch增強(qiáng)器通過(guò)compose組合后，還是個(gè)dispatch增強(qiáng)器，再執(zhí)行傳入store.dispatch，也就是store原本的dispatch函數(shù)作為參數(shù) 得到了superDispatch函數(shù)

到此我們就已經(jīng)完全理解了中間件的執(zhí)行過(guò)程及其作用，其實(shí)就是返回了一個(gè)dispatch增強(qiáng)器函數(shù)的函數(shù)，得到的增強(qiáng)器函數(shù)接收dispatch返回一個(gè)新的dispatch 函數(shù)，dispatch執(zhí)行后會(huì)返回action，就是這樣的邏輯， 這樣我們就可以在action被dispatch到store之前，做一些處理。

compose函數(shù)正是一個(gè)鏈?zhǔn)秸{(diào)用dispatch增強(qiáng)器的函數(shù)，每次執(zhí)行一個(gè)函數(shù)都會(huì)返回一個(gè)增強(qiáng)過(guò)的dispatch函數(shù)，給下一個(gè)中間件， 下面貼一下compose函數(shù)的代碼， 感興趣的可以理解一下：

export default function compose(...funcs) {
  if (funcs.length === 0) {
    return arg => arg
  }

  if (funcs.length === 1) {
    return funcs[0]
  }
  // 這里的args就是dispatch
  return funcs.reduce((a, b) => (...args) => a(b(...args)))
}

傳送門(mén)