前传 中间件的由来
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)