为什么在Redux-Observable的Epic中要返回流而非手动dispatch值？

第一种手动dispatch写法的核心弊端 #

• 模块耦合度升高
  第一种写法需要手动引入store实例，增加了当前模块的外部依赖，也更容易触发循环引用问题。而第二种写法完全不需要感知store实例的存在，仅依赖RxJS和action creator即可完成逻辑，耦合度更低。
• 可测试性大幅下降
  Redux Observable的核心测试逻辑是通过给Epic输入特定action流，订阅Epic输出的action流，断言输出是否符合预期即可。手动调用store.dispatch的话，这个action不会出现在Epic的输出流里，测试时必须额外mockstore.dispatch才能验证调用逻辑，测试代码冗余度高，不符合框架的最佳测试实践。
• 丢失RxJS流的上下文管控能力
  所有在流操作符函数内的逻辑，只要没有纳入流的返回值，都会脱离RxJS的管控：
  1. 错误无法被流的catchError等操作符捕获，一旦store.dispatch或前面的业务逻辑报错，会直接抛出到全局，甚至导致整个Epic流终止运行
  2. 流取消机制失效：如果上游流触发取消（比如对应页面路由跳转、组件卸载导致流被takeUntil销毁），已经执行的手动dispatch无法撤回，而返回of(xxxAction)的话，取消状态下这个action根本不会被派发，自动避免脏数据
  3. 后续流扩展成本极高：如果之后要给这个action加防抖、节流、延迟、和其他事件流组合逻辑，第一种写法要完全重构，第二种只需要在返回的流上拼接对应操作符即可
• 违反框架约定，提升维护成本
  Epic的设计约定就是「输入action流，输出action流」，所有的action派发都应该通过输出流表达。把dispatch藏在操作符内部，后续维护人员排查action来源时，除了看Epic的输出链路，还要逐行翻所有操作符的内部逻辑，排查成本翻倍。

即便为执行序列的最后一步，也推荐返回流的原因 #

你无法保证当前逻辑永远是「最终形态」，业务需求变更是常态，现在图省事写手动dispatch，之后改需求的时候重构成本更高。另外统一采用返回流的写法可以保证全项目代码风格一致，不会出现部分逻辑走流、部分逻辑手动调用的混乱情况，也能从编码层面避免上面提到的错误逃逸、流取消失效等隐性bug。

内容的提问来源于stack exchange，提问作者Boris Lebedev