我应该总是在可以使用 Promise 的地方使用 Observables 吗？

Question

我昨天发布了一个关于堆栈溢出的问题，我问用户群是否有一种方法可以在不显式使用 async 和 await 关键字的情况下等待异步操作的结果。原因是我需要等待操作完成，以便在触发任何其他 HTTP 请求之前使用返回的值。事实证明，它涉及使用 observables 订阅操作结果，然后使用 mergeMap 继续处理其他请求。

前几天我还阅读了一篇文章，其中概述了许多 JS/RxJs/Angular 开发人员通过在每个可能的异步操作中使用它们来“滥用”可观察对象，即使只返回一个值。文章概述了在这种特殊情况下，promise 会更合适，因为 observables 被认为是矫枉过正。

这让我想知道是否有任何特定的场景或原因我应该使用 Promise 而不是 observables。在我自己看来，observables 对异步操作提供了更好的控制，并且通过使用 RxJS 提供的 let-able 操作符提供了更多的功能。再加上仅返回单个值的异步操作仍然可以由 Observables 处理（因为它们只是一个只有单个值的流），这让我认为确实没有特定的我曾经想在可观察对象上使用承诺的场景。这样的场景存在吗？

我希望这个问题不要太主观，因为优点和缺点或承诺和可观察性都是这两种编程结构的客观属性。所以希望我不应该看到这个问题结束。

Answer 1

作为一名 Angular 开发人员，我不希望看到 Promise 被使用，因为我们正在以响应式编程风格构建基于可观察对象的应用程序。

没有滥用 observables，因为可以使用 Promise 代替。

Angular http 服务可以使用 Promise 作为 http 一个请求是一个火灾并得到一个单一的响应场景，而不是一个流，但在这种情况下，一个可观察的仍然是完全有意义的。

我会争辩说，既然我们已经有了异步操作的可观察对象，为什么还要将 Promise 引入反应式编程应用程序。

我 100% 认为 Angular 开发人员绝对不会在可以使用 Promise 的用例中滥用 observables。使用单一异步样式比混合匹配样式更一致，它还允许您在以后的 http 请求变为流时进行重构。