在从一个基于Promise的大型应用程序中读了很多关于Observables之后,我了解它们利用流/事件模式的能力,但是,我觉得有时使用Observables感觉笨重和矫枉过正。
当您想要获取某些数据时,特别是对于分页数据,Observable是完美的。您可以为分页连接初始大小和偏移量,并对页面和大小进行更新,触发对observable的更新,并获取更多数据,转换它等。
但是,当我们做一些简单的事情,比如对/api/books/123
的DELETE请求,并且没有有价值的响应时,使用Observables就像没有“观察”一样感觉很尴尬,你必须通过订阅来“触发”请求。 。
下面是一个例子:
诺言
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.
});
所以我想到了一些事情:
await
来控制是否阻止Promise我在Observables周围看到的所有博主和文章似乎都专注于一直使用Observables,从不使用Promises。
This guy似乎是唯一一个对Observables“站立”的人,并试图争论为什么他们只应在他们有意义的时候使用,但所有的评论都是人们只是抨击他并说Observables仍然是银弹。
有人可以向我解释为什么在所有情况下都会对使用Observable有如此强烈的立场态度吗?
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.
});
可观察量比你提到的要多得多。虽然所有这些因素都很重要,但它们不是关于流媒体,不是关于事件处理,甚至不是关于组合。 Observable<T>
是T
的超级大国:一旦你得到它,你就无法回头。蜘蛛侠永远不会成为彼得帕克尔。特别是,这意味着你“提升”你的常规代码,从而赋予它很好的能力...... rx所做的所有令人敬畏的事情。
理解rx的最好方法是将其视为一个通用函数 - 随着时间的推移,它可以执行无限多的return
语句。试图摆脱那种靠近功能本身摆脱的那种。您不必试图摆脱它,而是必须尝试将解决方案融入其中,就像您根据特定签名的某些功能或甚至裸露导出的函数来定义您的抽象解决方案一样。在少数情况下,它要求您将一些不可观察(如承诺)的东西映射到语义上相同的可观察量(from(...)
就可以)。因此,您必须毫无疑问地自由使用这些映射器。
如果需要更详细的解释,请与我们联系。
我倾向于同意你的意见,尤其是对于这里的用例,甚至GET也是如此。对于Angular我喜欢.toPromise()
:
let book = await httpObservableService.GetBook('123').toPromise()