当我看到所有这些鼓励你调度一个异步发出其他动作的动作的中间件时，我觉得我正在服用疯狂的药丸。我认为异步 CAN（也许应该？）在商店之前完成。
对我来说，Rx 的好处是你可以接收一个传入的动作流，将其中一些映射到其他动作的可观察对象，然后对整个结果进行平面映射以获得一系列有序的事件。然后，您可以通过将每个事件分派给它来将该结果流链接到存储中。
将异步放入操作中不仅会采用 Redux 的简单模型并使其复杂化，而且这意味着当您进行时间旅行调试时 - 您可能会触发新的 AJAX 请求（这可能会在您清理时重写您的历史记录？）。
我想我觉得将 RxJS 的强大功能放在商店前面对我来说很有意义，但我很困惑为什么将它放在商店旁边的库是有意义的。我同意 Observables 是 Epics 的一个很好的模型，但我想知道 Redux 是否正在被用来关心它不应该知道的事情。
背景：我看过这个视频https://www.youtube.com/watch?v=AslncyG8whg，学习 Rx 几年，Redux 半年。
商店增强剂相互缠绕。使用 Redux 的compose函数，传递给 compose 的增强器是从右到左排序的。因此，如果我使用const storeEnhancer = compose(applyMiddleware(...middlewares), DevTools.instrument())，DevTools 增强器将环绕真实商店，而中间件增强器将环绕 DevTools 增强器。
这意味着时间旅行调试将仅使用已通过所有中间件的操作，并且重放这些操作不会再次通过中间件链。换句话说，只有实际影响商店的操作才会被重播。
另一件需要考虑的事情是，像中间件这样的东西允许访问 store 的 API 以调度和检查状态，并且可以被认为是 store 的“内部”，但最终关键是它们是在“real”之上的层中处理的。 “存储本身。
您可能想阅读 Dan 关于中间件和异步行为的优秀文章：How to dispatch a Redux action with a timeout? 为什么我们需要中间件来实现 Redux 中的异步流？，这有助于澄清中间件的原因，以及http://redux.js.org/docs/FAQ.html#actions-side-effects上的其他链接和解释。