angular - 何时在 Angular 中使用 Observables 和 Promises

Question

在从一个基于 Promise 的大型应用程序中读了很多关于 Observables 的文章后，我理解了它们利用流/事件模式的力量，但是，我觉得有时使用 Observables 感觉笨拙和矫枉过正。

当你想获取一些数据，尤其是分页数据时，Observable 是完美的选择。您可以为分页连接初始大小和偏移量，并让页面和大小的更新触发对可观察对象的更新，并获取更多数据、转换数据等。

然而，当我们正在做一些简单的事情时，比如对 /api/books/123 的 DELETE 请求并且没有有值(value)的响应，使用 Observables 感觉很尴尬，因为没有什么可以“观察”和您必须通过订阅来“触发”请求。

举个例子:

promise

await myService.DeleteBook('123');
// the book is now deleted

可观察

myService.DeleteBook('123')
// the book is still there as the request isn't sent yet
.subscribe(x => {
   // finally in here the book is deleted, but 'x'
   // is pretty much worthless so this method pretty much does nothing.
});

所以我想到了一些事情:

1. 订阅一个DELETE请求感觉真的很别扭
2. 这是基本上没有任何好处的额外代码
3. 我喜欢通过简单地从行中添加/删除 await 来控制我是否阻止 Promise

我看到的所有关于 Observables 的博主和文章似乎都专注于一直使用 Observables 而从不使用 Promises。

This guy似乎是唯一一个“站出来”反对 Observables 并试图争论为什么只有在有意义的时候才应该使用它们的人，但所有的评论都是人们在抨击他并说 Observables 仍然是 Elixir 。

有人可以向我解释为什么在所有情况下都对完全使用 Observables 持如此强烈的固执己见吗？

Answer 1

myService.DeleteBook('123')
// the book is still there as the request isn't sent yet
.subscribe(x => {
   // finally in here the book is deleted, but 'x'
   // is pretty much worthless so this method pretty much does nothing.
});

• “x”并非完全没有值(value)。您仍然想检查响应并相应地显示成功消息或处理中的 HTTP 错误错误回调。正确的？使用 promises，您必须将其包装到 try/catch 中以处理 HTTP 错误。

• 关于 observables 的另一个最好的事情是它们可以与其他可观察和链接。如果你看一下 RXJS 操作符，你可以用它们做一些很酷的事情。是运营商使用可观察对象很有趣。

• 例如，在您的案例中，假设有一项要求显示删除前的警告对话框。您可以链接 delete observable带有可观察到的警告以及仅删除的过滤器运算符如果用户点击了"is"。这将更容易实现如果您使用的是 observables 而不是 promises。

• 同样出于一致性原因，您希望保持相同的订阅无处不在的图案。比如，你不想在一个地方使用 Promise和其他人的可观察到混淆其他开发者。