深入理解redux数据流和异步过程管理

redux-saga中间件是这样启用的：

要调用run把saga的watchersaga跑起来：

watchersaga里面监听了一些action，然后调用workersaga来处理：

redux-saga会先把action透传给store，然后判断下该action是否是被taker监听的：

当发现该action是被监听的，那么就执行相应的taker，调用workersaga来处理：

比如login和logout会有不同的workersaga。

login会请求login接口，然后触发loginSuccess或者loginError的action。

logout会触发logoutSuccess的action。

reduxsaga的异步过程管理就是这样的：先把action透传给store，然后判断action是否是被taker监听的，如果是，则调用对应的workersaga进行处理。

reduxsaga在redux的action流程之外，加了一条监听action的异步处理的流程。

其实整个流程还是比较容易理解的。理解成本高一点的就是generator的写法了：

比如下面这段代码:

它就是对每一个监听到的xxx_action做同样的处理的意思，相当于takeEvery：

但是因为有一个while(true)，很多同学就不理解了，这不是死循环了么？

不是的。generator执行后返回的是一个iterator，需要另外一个程序调用next方法才会继续执行。所以怎么执行、是否继续执行都是由另一个程序控制的。

在redux-saga里面，控制workersaga执行的程序叫做task。workersaga只是告诉了task应该做什么处理，通过call、fork、put这些命令（这些命令叫做effect）。

然后task会调用不同的实现函数来执行该workersaga。

为什么要这样设计呢？直接执行不就行了，为啥要拆成workersaga和task两部分，这样理解成本不就高了么？

确实，设计成generator的形式会增加理解成本，但是换来的是可测试性。因为各种副作用，比如网络请求、dispatchaction到store等等，都变成了call、put等effect，由task部分控制执行。那么具体怎么执行的就可以随意的切换了，这样测试的时候只需要模拟传入对应的数据，就可以测试workersaga了。

reduxsaga设计成generator的形式是一种学习成本和可测试性的权衡。

还记得redux-thunk有啥问题么？多个异步过程之间的并行、串行的复杂关系没法处理。那redux-saga是怎么解决的呢？

redux-saga提供了all、race、takeEvery、takeLatest等effect来指定多个异步过程的关系：

比如takeEvery会对多个action的每一个做同样的处理，takeLatest会对多个action的最后一个做处理，race会只返回最快的那个异步过程的结果，等等。

这些控制多个异步过程之间关系的effect正是redux-thunk所没有的，也是复杂异步过程的管理必不可少的部分。

所以redux-saga可以做复杂异步过程的管理，而且具有很好的可测试性。

其实异步过程的管理，最出名的是rxjs，而redux-observable就是基于rxjs实现的，它也是一种复杂异步过程管理的方案。

redux-observable用起来和redux-saga特别像，比如启用插件的部分：

和reduxsaga的启动流程是一样的，只是不叫saga而叫epic。

但是对异步过程的处理，reduxsaga是自己提供了一些effect，而redux-observable是利用了rxjs的operator：

通过ofType来指定监听的action，处理结束返回action传递给store。

相比redux-saga来说，redux-observable支持的异步过程的处理更丰富，直接对接了operator的生态，是开放的，而redux-saga则只是提供了内置的几个effect来处理。

所以做特别复杂的异步流程处理的时候，redux-observable能够利用rxjs的操作符的优势会更明显。

但是redux-saga的优点还有基于generator的良好的可测试性，而且大多数场景下，redux-saga提供的异步过程的处理能力就足够了，所以相对来说，redux-saga用的更多一些。

前端框架实现了数据到视图的绑定，我们只需要关心数据流就可以了。

相比context的混乱的数据流，redux的view->action->store->view的单向数据流更清晰且容易管理。

前端代码中有很多异步过程，这些异步过程之间可能有串行、并行甚至更复杂的关系，放在组件里并不好管理，可以放在redux的中间件里。

redux的中间件就是对dispatch的层层包装，比如redux-thunk就是判断了下action是function就执行下，否则就是继续dispatch。

redux-thunk并没有提供多个异步过程管理的机制，复杂异步过程的管理还是得用redux-saga或者redux-observable。

redux-saga透传了action到store，并且监听action执行相应的异步过程。异步过程的描述使用generator的形式，好处是可测试性。比如通过take、takeEvery、takeLatest来监听action，然后执行workersaga。workersaga可以用put、call、fork等effect来描述不同的副作用，由task负责执行。

redux-observable同样监听了action执行相应的异步过程，但是是基于rxjs的operator，相比saga来说，异步过程的管理功能更强大。

不管是redux-saga通过generator来组织异步过程，通过内置effect来处理多个异步过程之间的关系，还是redux-observable通过rxjs的operator来组织异步过程和多个异步过程之间的关系。它们都解决了复杂异步过程的处理的问题，可以根据场景的复杂度灵活选用。

作者：zxg_神说要有光