为什么我们需要返回一个流而不是直接分派一个值？答案

【问题标题】：Why we need to return a stream instead of direct dispatch a value?为什么我们需要返回一个流而不是直接分派一个值？
【发布时间】：2021-12-07 07:19:54
【问题描述】：

在工作区，我的同事告诉我，我必须而不是写这个

import store from './store.ts'

// Epic code
...
mergeMap(data => {
    store.dispatch(someActionCreator(data))
    return EMPTY
})
...

应该这样写

// Epic code
...
mergeMap(data => {
    return of(someActionCreator(data))
})
...

我知道所有用 of rxjs 操作符编写的动作都会自动包装在 dispatch 函数中并自动调度，但是为什么像第一个示例那样调度所有动作是不好的呢？ p>

是的，我们不会返回任何 stream$，但如果它是序列中的最后一次迭代，我们真的需要返回这个 stream$ 而不是手动调度吗？

【问题讨论】：

我不认为 redux-observable 对用 of() 包裹的操作有什么特别的作用（你能提供一个链接到文档的链接吗？）。但是，不同之处在于，通过在效果内调用dispatch，您可以在该效果仍在处理时开始处理另一个效果。

【解决方案1】：

在大多数运算符中不引起“副作用”被认为是最佳实践。副作用可以描述为在 Operator 链“外部”某处修改/改变状态的语句。

使用dispatch 调用，您直接导致状态的突变，这可以被认为是副作用。

为什么应该避免副作用有很多意见。我可以举几个：

纯粹性：操作员应始终为相同的输入产生相同的输出，包括对外部状态的更改。通过保持运算符的纯洁性，可以对它们进行适当的单元测试，并且您可以保证运算符在所有用法中的行为一致。
可重用性：操作符的设计原则上应使它们可以在其他地方提取和重用。这意味着它们应该没有外部依赖项，例如直接在您的运算符中存储。
约定：运算符应被视为修改一个或多个传入数据流的函数的集合。对此流操作结果的任何“反应”都应在“订阅”中完成。这是一个有助于使 Observable 行为一致的约定。换个说法：当有人订阅你的 Observable 时，他们应该能够预料到没有副作用。在 redux 的情况下，那个“某人”就是框架。
声明式范式：操作符应该主要描述输入和输出之间的关系，而不是包含“指令”或语句，例如“做这个，然后做那个”。这种范式被认为可以减少整体错误，因为它消除了对系统底层状态的依赖。

顺便说一句，整个运算符模式的起源是函数式编程，在这种情况下，像您所描述的那样的调用在技术上是不可能的。

所以我认为你的问题的答案主要是意见驱动的。从技术上讲，我相信它不会改变您的用例中的任何内容。此外，上面提出的观点应该持保留态度，因为如果您订阅例如，您总是会在某处引起副作用。 mergeMap 中的 HTTP API。

【讨论】：