为啥 Angular 将 Observable 用于 HttpClient？

Posted 2023-03-07

【中文标题】为啥 Angular 将 Observable 用于 HttpClient？

【英文标题】：Why Angular uses Observable for HttpClient?为什么 Angular 将 Observable 用于 HttpClient？

【发布时间】：2018-11-02 21:01:23

【问题描述】：

根据https://angular.io/tutorial/toh-pt6

一般来说，一个 observable 可以随着时间的推移返回多个值。一个 来自 HttpClient 的 observable 总是发出一个值，然后 完成，不再发射。

确实如此，一旦请求完成，Http 请求/响应就不能再产生任何值了。那么 HTTPClient 在发出请求时返回 Observable 的主要原因是什么？仅仅是因为我们可以在 Observable 上应用大量运算符（重试、去抖动等）吗？或者还有其他我失踪的具体原因吗？

【问题讨论】：

保持 API 一致性。例如，无需引入 Promises。无论如何，Observables 比 Promises 更灵活。

这是一场持续的辩论。实际上，归结为：api 一致性，您可以取消可观察但不能承诺。

【参考方案1】：

您会找到的最佳答案是 Pascal Precth 的一位，他在 2015 年 12 月提出的一个专门问题上解释说：“Observables 对 http 有意义吗？” （但请随意阅读，很多其他答案也非常好！）

在我的头上： - 重试 - 取消 - 享受所有 Rxjs 运算符 - 可以将它们组合为流 - 在整个应用程序中进行反应性思考 - 一致性 - Observables 本质上是冷的，如果你想稍后触发它，不需要像 Promises 一样将它们包装到工厂函数中

【参考方案2】：

Observables 是 Angular 框架中的标准异步处理程序。

按照标准，我的意思是异步管道、路由保护、路由解析器、组件事件发射器和许多其他地方都支持可观察对象。

Angular 团队付出了很多努力来支持 Promise 作为其中许多功能的后备，但在底层这些 Promise 无论如何都只是转换为 observables。

通过使 Http 请求可观察，Angular 团队使核心中的异步操作与其他地方的所有操作保持一致。

与 Promise 相比，observables 仍有一些优势，但这主要是自以为是（就像我自己的观点一样）。

您可以轻松地在服务中混合使用 Http 请求和 WebSocket，并将 API 公开为可观察对象。服务的消费者不会知道其中的区别。 您可以轻松地将对数组的 Http 请求转换为单独发出每个项目的可观察对象。这使得向不同的消费者分派数据变得更加容易。 如果没有正确链接，Promise 可能会中断。可观察对象通常可以避免这些常见错误。

【讨论】：

我在哪里可以阅读更多关于“在引擎盖下这些承诺无论如何都只是转换为可观察对象”的信息？谢谢

【参考方案3】：

保持 API 一致性。例如，无需引入 Promises。无论如何，Observables 比 Promises 更灵活。此外，observable 可以跟踪其订阅者。一旦订阅者出现，就会进行 HttpClient 调用。如果您不订阅http调用，则不会发出请求。

这就是为什么如果你多次订阅 1 个 observable，就会发出多个请求。