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

Question

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

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

这让我想知道是否有任何特定的场景或原因我应该使用 promises 而不是 observables。在我看来，可观察对象提供了对异步操作更好的控制，并且还通过使用 RxJS 提供的 let-able 操作符提供了更多的功能。这一点，再加上只返回单个值的异步操作仍然可以被 Observables 处理的事实(因为它们只是一个只有单个值的流)让我认为真的没有一个特定的我想在 observable 上使用 promise 的场景。这样的场景存在吗？

我希望这个问题不要太主观，因为优缺点或 promises 和 observables 都是两种编程结构的客观属性。所以希望我不应该看到这个问题被关闭。

Answer 1

作为一名 Angular 开发人员，我不喜欢看到在我们以响应式(Reactive)编程风格构建基于可观察对象的应用程序时使用 promises。

没有滥用可观察对象，因为可以使用 promise 代替。

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

我会争辩说，当我们已经有了用于异步操作的可观察对象时，为什么要将 promises 引入响应式(Reactive)编程应用程序。

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