Redux中的中间件思想
要想理解redux 的中间件思想， 我们先 看下compose这个文件做了什么， 这个文件其实做的事情十分简单。主要是用到函数式编程中的组合概念， 将多个函数调用组合成一个函数调用。
其实主要是reduce 的这个api,为了方面大家理解， 我就简单手写下数组reduce 的实现：
ok 这东西其实就是个累加器按照某种方式呗。我们接下来就直接进入compose函数话不多说直接看代码：
// 参数是函数数组 export default function compose(...funcs: Function[]) { // 处理边界情况 if (funcs.length === 0) { return <T>(arg: T) => arg } // 数量为1 就没有组合的必要了 if (funcs.length === 1) { return funcs[0] } // 主要是下面这一行代码， 你细品👌 return funcs.reduce((a, b) => (...args: any) => a(b(...args)))} 复制代码
OK， 我现在还是带大家分析下这行代码，同样是我举例子说明： 假设我们有这个3个函数：
funcs = [fa, fb, fc]
由于没有出初始值累加器的就是 fa 经过一次遍历后， accumulateur 变为下面的样子：
let m= （...args） => fa(fb(...args))
在经过一次遍历后， 此时b = fc 此时accumulateur 变为下面的样子：
**（...args） => m(fc(...args))**
我们将fc(...args） 看做一个整体带入上面m的函数 所以就变成了下面的样子
（...args）=> fa(fb(fc(...args)))
OK到这里 就大工告成了，fa, fb, fc 我们可以想象成 redux 的3个中间件， 按照顺序传进去，
当这个函数被调用的时候也会按照 fa, fb, fc 顺序调用。前面铺垫结束就直接开始分析？ compose 是如何 和Redux 做结合的。
applyMiddleWare
我先把整体结构分析下， 和函数参数分下：
// applyMiddlerware 会使用“...”运算符将入参收敛为一个数组 export default function applyMiddleware(...middlewares) { // 它返回的是一个接收 createStore 为入参的函数 return createStore => (...args) => { ...... } } 复制代码
createStore 就是 上面我们分析过的 创建数据中心Store ,而 args 主要是有两个， 还是createStore 两个约定入参 一个是reducer， 一个是 initState。
enhance-dispatch
接下来就是比较核心的， 改写dispacth, 为什么要改写dispatch, 还是举个例子说明。 不知道大家还记不记得 dispacth 接受的action 只能是对象， 如果不是对象的话会直接报类型错误。如图：
OK社区比较有名的redux-thunk 中间件， dispatch 可以接受一个函数， 难道是她绕过了我们的检查，那肯定不是，计算机肯定不会骗人的。 那只有一个原因。
应用了中间件的dispatch 和 没有用中间的dispatch 肯定是不等的，
dispatch = enhancer(dispacth) 肯定是增强的至于怎么个增强法 继续往下看。
const store = createStore(...args) let chain = [] const middlewareAPI = { getState: store.getState, dispatch: (...args) => dispatch(...args) } chain = middlewares.map(middleware => middleware(middlewareAPI)) // 绑定 {dispatch和getState} dispatch = compose(...chain)(store.dispatch) 复制代码
从代码中可以看到的第一步 其实就是将 getState 和 dispatch 作为中间件中的闭包使用， 有人会这里提问，这里为什么是匿名函数 ? 而不是store.dispatch ? 这里你可以自行先🤔下， 后面解答。
可能很多人看到这里还是很懵， 还是举个例子说明， 还记得上面的 fa , fb, fc 接下来 我就把他们展开。
function fa(store) { return function(next) { return function(action) { console.log('A middleware1 开始'); next(action) console.log('B middleware1 结束'); }; }; } function fb(store) { return function(next) { return function(action) { console.log('C middleware2 开始'); next(action) console.log('D middleware2 结束'); }; }; } function fc(store) { return function(next) { return function(action) { console.log('E middleware3 开始'); next(action) console.log('F middleware3 结束'); }; }; } 复制代码
ok 我们一步一步分析， 看到底做了什么。
chain = middlewares.map(middleware => middleware(middlewareAPI)) 复制代码
很显然 我们 的 middlewares = [fa, fb, fc] map 之后返回一个新的 chain 这时候的chain 应该是下面 这样子的：
chain = [ (next)=>(action)=>{...}, (next) => (action) => {...}, (next) => (action) => {...} ]
只不过chain中的每一个元素 都有getSate，dispatch 的闭包而已。
ok 继续往下走就到了compose 函数 还记得上面我们compose(fa, fb, fc ) 返回值是什么？
（...args）=> fa(fb(fc(...args)))
对的就是这个东西， 我们这里的chain 也是一样的， 所以这里的 dispatch 就变成了增强的dispatch 我们一起看下
dispatch = fa(fb(fc(store.dispacth)))
看到这里有人就问？ 每一个中间件的next 和 原先的store.dispacth 有什么不同 ？ 这和洋葱模型有什么关系？
那我就带你一步一步分析, 这里的dispatch 就是指的是当前的 fa(fb(fc(store.dispatch))) , 我们可以直接函数调用来分析，
fa 的参数 是 fb(fc(store.dispatch)) , 由于依赖fb, 所以调用fb, 然后发现fb 依赖的参数是 fc(store.dispacth), 紧接着又开始调用fc, ok 到这里终于结束了， 终于没有依赖了。 所以从上面的过程我们可以得到 next 其实是他上个中间件的副作用， 最后一个中间件的next 就是****store.dispatch。
副作用： 每个中间件的中的 （action ）=> {...}
我用流程图表示整个洋葱模型流程：
当我调用dispatch 的时候， 先打印 E, 然后发现 next 是副作用fb, 然后调用副作用fb, 打印c，发现 next 竟然是 副作用fc ,再去调用fc, 打印A， next 这时候就是 store.dispacth, 调用结束， 打印 b, 然后打印D， 最后打印 F 。 这样的一系列操作是不是有点像洋葱模型， 如果我可以一层一层拨开你的心， 哈哈哈哈， 太骚了， 好了回归主题。还记得我之前提出的问题？
1.为什么dispacth 是匿名函数？
2. 为什么dispacth 一个action后， 还是返回action
问题1： 为什么dispatch 是是一个匿名函数 ， 因为有的中间件原理的实现，并不会 next(action), 这时候需要肯定是增强的dispacth， redux-thunk 的执行原理， 就是当你传递一个函数， 直接调用这个函数，并把dispatch 的 权限 交给你自己处理。
function createThunkMiddleware(extraArgument) { return ({ dispatch, getState }) => next => action => { if (typeof action === 'function') { // 这个的dispatch 其实是增强的dispatch， // 如果用store.dispatch如果还有其他中间件就丢失了 return action(dispatch, getState, extraArgument); } return next(action); }; } 复制代码
这里看下源码：
// 这个其实dispatch 其实 是个闭包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))// compose 完之后将闭包更新成增强的dispatchdispatch = compose<typeof dispatch>(...chain)(store.dispatch) 复制代码
所以Redux 严格 意义上 并不算是洋葱模型， 他的洋葱模型是建立在你的每个中间件，都要next(action); 如果不 next(action) 其实就破坏了洋葱模型。
问题2： dispatch (action) 返回action, 就是为了方便下一个中间件的处理。
