【问题标题】:Understanding the share() RxJS operator in action together with Rx.Observable.ajax理解 share() RxJS 操作符以及 Rx.Observable.ajax
【发布时间】:2017-02-03 13:38:48
【问题描述】:

我正在尝试了解 RxJS 5 share() 运算符的行为。

根据教程和文档,share() 将冷的 observable 变成热的。

我正试图看到这一点。这是我尝试过的:

const search$ = Rx.Observable.ajax('https://www.googleapis.com/books/v1/volumes?q=javascript').share();

然后我第一次订阅:

search$.subscribe(console.log);

我从开发工具中看到发出了网络请求:

 Request URL:https://www.googleapis.com/books/v1/volumes?q=javascript

然后在重新运行相同的订阅时:

search$.subscribe(console.log);

我注意到另一个网络请求也发出了

有人可以解释为什么share() 运算符会显示这种行为吗?我原以为只会发出一个网络请求...

P.S. 使用 xxx.publishLast().refCount(); 而不是 xxx.share(); 可以完成这项工作,但我主要关心的是了解上述上下文中的 share() 行为。

【问题讨论】:

    标签: rxjs rxjs5


    【解决方案1】:

    sharepublish().refCount() 的快捷方式。 refCount-part 表示,只要至少有 1 个订阅者,流就是热/共享的 - 但是,当没有订阅者时,它会被重置/冷。当您的ajax-requests 完成时,流完成,并且在流完成后,任何订阅者都会自动取消订阅-> 将流的订阅者设置为 0 并因此重置流-这就是您遇到第二个网络的原因-寻求任何未来的订阅。

    为什么这适用于publishLast().refCount()? - 使用publishLast(),你会得到一个永远不会完成的流,因此没有订阅者会自动取消订阅,并且流永远不会被重置。


    对于缓存 HTTP 响应,您使用 publishLast().refCount() 的方法是完全有效的。

    【讨论】:

    • 感谢 olsn。这使得现在表现出的行为更加清晰。我还有一个疑问:publishLast().refCount() 和隐含的永不完成的流是否被认为是缓存 http 请求的好习惯?
    • 是的,但我已经更新了答案,并在此处添加了指向 rxjs-doc-section 的附加链接
    • 非常感谢这个详细的回复和链接!
    猜你喜欢
    • 2016-05-10
    • 2016-11-06
    • 2021-12-01
    • 2019-09-07
    • 2018-04-01
    • 2021-04-21
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多