You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is related to the apparent current mis-behavior of shareReplay() as described in #3354, specifically my comment here, parts of which I have included below.
This issue proposes adding an operator similar to shareReplay(), but one which does not re-subscribe to the source Observable if a previous subscription had completed. As an example, consider an Observable that represents an HTTP request. Ideally:
It would be cold until subscribed to, because there's no need to execute the expensive operation (in this case, an HTTP request) unless something needs the result. So we cannot use connect().
After completing, it would not re-subscribe to the source but instead would use something like a ReplaySubject(1) to retain the last value (or multiple values, if it's chunked). Thus, publishReplay(1).refCount() or the old shareReplay(1) behavior isn't ideal because it re-subscribes every time the refCount goes from 0 -> 1.
If the source subscription gets cancelled before completion, then re-subscribing is ok since we never got a value anyway and thus can't use the underlying ReplaySubject.
This new operator would behave similarly to publishReplay(), refCount() or the old shareReplay() implementation, except it would just keep the ReplaySubject() around, even after subscribers have reached 0, if the source observable completes. This would allow unsubscribing as normal (which is a problem with the current shareReplay() implementation, see #3354), but would ensure that the source observable's emissions are reused if it completes.
Would something like this be desired / useful? From a cursory search, I haven't found any prior art for such an operator.
As for naming, some ideas include shareOnce(), shareReplayOnce(), safeShare().
Alternatively, it may (?) be possible to do this by having a specialized version of refCount() that can be used alongside a normal publishReplay(), but I haven't looked into this.
The text was updated successfully, but these errors were encountered:
This issue proposes adding an operator similar to shareReplay(), but one which does not re-subscribe to the source Observable if a previous subscription had completed.
shareReplay doesn't resubscribe to the source if the source completes, it caches the values and the completion and replays them on new subscriptions.
Either way, I'd recommend implementing a user-land operator and publishing it in this case. If it becomes popular or widely used, we can adopt it into the core library.
This is related to the apparent current mis-behavior of
shareReplay()
as described in #3354, specifically my comment here, parts of which I have included below.This issue proposes adding an operator similar to
shareReplay()
, but one which does not re-subscribe to the source Observable if a previous subscription had completed. As an example, consider an Observable that represents an HTTP request. Ideally:connect()
.ReplaySubject(1)
to retain the last value (or multiple values, if it's chunked). Thus,publishReplay(1).refCount()
or the oldshareReplay(1)
behavior isn't ideal because it re-subscribes every time the refCount goes from 0 -> 1.ReplaySubject
.This new operator would behave similarly to
publishReplay(), refCount()
or the oldshareReplay()
implementation, except it would just keep theReplaySubject()
around, even after subscribers have reached 0, if the source observable completes. This would allow unsubscribing as normal (which is a problem with the currentshareReplay()
implementation, see #3354), but would ensure that the source observable's emissions are reused if it completes.Would something like this be desired / useful? From a cursory search, I haven't found any prior art for such an operator.
As for naming, some ideas include
shareOnce()
,shareReplayOnce()
,safeShare()
.Alternatively, it may (?) be possible to do this by having a specialized version of
refCount()
that can be used alongside a normalpublishReplay()
, but I haven't looked into this.The text was updated successfully, but these errors were encountered: