前传 中间件的由来
redux的操作的过程，用户操作的时候，我们通过dispatch分发一个action，纯函数reducer检测到该操作，并根据action的type属性，进行相应的运算，返回state，然后更新view。
但是一个很重要的问题，reducer对于action会立即进行运算，并返回state，如果我们的操作是要获取服务端的数据，需要调用接口类似的异步操作呢？很明显这样操作不行。所以，middleware中间件诞生了，中间件就是处理reducer处理不了的问题，对reducer做一个补充，配合。
我们就以使用中间件来解决异步问题为例来说，中间件顾名思义，就是作为一个流程的一个中间处理程序存在，它是放到一个流程的中的。问题是在处理一部问题，我们把他放哪的问题
a、action只是一个跑腿的，把操作的相关数据带到reducer；
b、reducer只是个干活的，纯函数，计算一下嘛，返回新的数据，异步操作它搞不了；
c、view，理论上这或者是显示的，不会有太多的逻辑，中间件肯定不能放；
d、剩下的就是把action分发到reducer的dispatch了，我们可以在分发的时候做点手脚。
看看applyMiddleware
中间件知道放在哪了，我们看看实现中间件的重要api ----- applyMiddleware 的源码
function applyMiddleware() {
for (var _len = arguments.length, middlewares = Array(_len), _key = 0; _key < _len; _key++) {
middlewares[_key] = arguments[_key];
}
return function (createStore) { // 以下称这个方法为func1
return function () { // 以下称这个方法为func2
for (var _len2 = arguments.length, args = Array(_len2), _key2 = 0; _key2 < _len2; _key2++) {
args[_key2] = arguments[_key2];
}
var store = createStore.apply(undefined, args);// 调用createStore方法生成store
// 初始化一个新的dispatch，暂时认为_dispatch = store.dispatch，从效果上看是这样的，暂时不明白为什么这样写，有待大牛指点。
var _dispatch = function dispatch() {
throw new Error('Dispatching while constructing your middleware is not allowed. ' + 'Other middleware would not be applied to this dispatch.');
};
var middlewareAPI = {
getState: store.getState,
dispatch: function dispatch() {
return _dispatch.apply(undefined, arguments);
}
};
//让每一个中间件调用一次，参数为middlewareAPI，并把结果方法chain中，注意这个地方，是中间件的第一层，参数是{getState, dispatch}
var chain = middlewares.map(function (middleware) {
return middleware(middlewareAPI);
});
// 将各个中间件的功能组合到 dispatch 上，生成新的dispatch，注意此时是中间件的第二层， 参数是store.dispatch (关于 compose 解析)
_dispatch = compose.apply(undefined, chain)(store.dispatch);
return _extends({},
store, // 最终返回的是store数据和加强后的dispatch
{dispatch: _dispatch}
);
};
};
}
a、applyMiddleware 方法本身
它首先通过一个for循环，将它的形参以数组元素的形式放到 middleware 中，并返回了一个形参为 createStore 方法（即为标注的func1）；
b、形参为 createStore 方法（即为标注的func1）
这货很懒，只是返回了一个有很多参数的方法（即为标注的func2）；
c、很多参数的方法（即为标注的func2）
这个方法和 applyMiddleware 一样，它首先通过一个for循环，将它的形参以数组元素的形式放到 args中；
具体源码的解析，请看源码的注释；
中间件的编写
我在源码的解析中，写了两个注意，分别是中间件的第一层和第二层，多以中间件的外面两层应该是如下的：
const timeOutMiddleware = ({ dispatch, getState }) => {
return (storeDispatch) => {
return { ... };
};
}
根据 compose 的操作原理，每一个中间件，即 chain 中的每一个元素，参数都是前一个中间件的组合后的 dispatch，返回的都是在参数的基础上组合自己功能后的dispatch，chain最后一个元素参数是store.dispatch。因此return的应该是一个通过这些中间件加强后的 dispatch。在此，我们就可以根据action传入的数据进行区分，加入我们中间件具体需要处理的情况。如下：
const timeOutMiddleware = ({ dispatch, getState }) => (storeDispatch) => (action) => {
if (typeof action === 'function') {
return action(dispatch, getState);
} else {
return storeDispatch(action);
}
};
如上，我们如果传入正常的action，我们就执行正常的store.dispatch。如果我们 action 传入的是 function 类型，那么这就是我们中间件处理的情况了。在action的function中我们可以拿到 store 的 dispatch 和 store 的 getState。当然我们在这个方法中可以异步的获取服务端的数据，然后根据成功或者失败的结果，通过 dispatch 再次分发一个正常的 action 同步我们获取到的数据，执行相应的操作。如下
deleteStaff = (data) => { const { dispatch } = this.props; const { staffId } = data; const action = (dispatchd, getState) => { setTimeout(() => { dispatchd({type: 'DELETE', payload: {staffId}}); }, 3000); }; dispatch(action); };
这是一个方法，删除一条数据，通过 setTimeout 模仿异步，在3秒后，再次发一个 action，执行删除数据；
本文栗子的代码：https://github.com/wayaha/react-demos-middleware
（对您有帮助的话，请您帮我点颗 star）
