redux-promise
解析这个中间的用法，以及原理
源码
import isPromise from 'is-promise';
import { isFSA } from 'flux-standard-action';
export default function promiseMiddleware({ dispatch }) {
return next => action => {
/**
* 判断是不是标准的FSA
*/
if (!isFSA(action)) {
/**
* 判断是不是promise,
* 如果是则执行，只会处理resolve的值，
* 反之交给下一个中间件
*/
return isPromise(action) ? action.then(dispatch) : next(action);
}
// 是标准的FSA, 判断是不是一个promise
return isPromise(action.payload)
/**
* 1.promise的时候，执行then,同时捕获异常，
* 在处理这两种情况以后，会分别添加另外一个约束error
* 这我们需要在reducer里面还需要判断error的值，
* 做不同的处理
*
* 2. 如果不是promise则交给下一个中间件
*
* */
? action.payload
.then(result => dispatch({ ...action, payload: result }))
.catch(error => {
dispatch({ ...action, payload: error, error: true });
return Promise.reject(error);
})
: next(action);
};
}
用法
虽然官方文档上面并没有举例是如何使用（至这篇文章编写时），但其实文档中已经说明的很清晰了，主要分为以下两种情况：
-
1.当中间接收到的是一个Promise实例，会dispatch掉resoved的值，对于reject的结果并不做任何处理。举例来说：
const testRes = () => { return new Promise((res, rej) => { res({ type: 'TEST_RESOLVE' }) }); } store.dispatch(testRes()); const testRej = () => { return new Promise((res, rej) => { rej({ type: 'TEST_REJECT' }) }); } store.dispatch(testRes());上面的两个例子，只有第一个会直接
dipatch,第二个不会有任何操作，其实查看源码就知道if (!isFSA(action)) { return isPromise(action) ? action.then(dispatch) : next(action); }action.then只接收了一个函数，所以不会处理reject的值，不过从几行代码，我们还可以得到几点信息。- 中间件内部是会自动地帮我们调用dispatch
-
resolve的值会被当做diapatch的参数被重新分发 -
resolve的值并不会继续流转到交给下一个中间件了
-
2.当中间件接收的是一个符合
FSA的action,会接着判断action.payload是不是一个promise,如果不是则直接转给下一个中间件，是则调用then,同时使用catch捕获异常，这里出现两种情况，查看源码：action.payload .then(result => dispatch({ ...action, payload: result })) .catch(error => { dispatch({ ...action, payload: error, error: true }); return Promise.reject(error); })- 当
promise的状态变成resolved的时候回进入then里面，并且重新dispatch(action) - 当
promise的状态变成rejected的时候回进入catch里面，并且重新dispatch(action), 同时会在action里面加一个error
从上面两种情况来看，当
action.payload为promise的时候，会被重新分发，并且不会走到下一个中间件。 - 当
建议
从上面的源码我们看出：
源码简单易懂，使用promise来解决异步，省去了额外的学习成本。但是同样由于过于简单，无法完成我们项目中一些特定的需求，比如我们想请求一个列表数据，在请求的时候我们想做一些loading的动画，由于这个中间件是直接拦截掉action, 并最终经过判断处理同样只会分发一次，这样在解决上面的应用场景中，不是很适合，同样我们判断请求成功或者失败的时候需要额外的判断error,其实是增增加了额外的约束。
