Add a type-checked way to enforce that an Observable only emits once (e.g. Single).

[voithos]

Feature Request

Is your feature request related to a problem? Please describe.
In many cases, an Observable will only ever emit a single value before completing (e.g. simple HTTP request), but there's no current way to encode that in the type system or to know what the lifetime of the subscription will be so as to properly clean up resources.

Describe the solution you'd like
A specialized type of Observable that only emits a single value - basically similar to RxJava's Single. The type would help communicate behavior, so that (for example) users subscribing to a Single Observable won't have to worry about unsubscribing. Ideally the type invariant would be preserved through operators, where appropriate.

Describe alternatives you've considered

• Just document the Observable's behavior in a comment on whatever creates the Observable. This is OK for developers using it directly, but breaks down when the Observable is passed through different functions and is manipulated via operators.
• Use take(1), etc, to enforce at runtime. This leads to overly-defensive code that may use take(1) needlessly multiple times in a single pipeline.

Other notes
This was brought up in #2469, along with Maybe and Completable, but was quickly closed without much discussion. Several people made good arguments for it, which I don't think were addressed, and I think there's a solid use case for something like this being in RxJS itself.

[cartant]

I can see the appeal of being able to do this, but until TypeScript supports something like the feature mentioned in this tweet, I don't think it's something we should do. And, even with such a feature, given the way that pipe is typed, this would introduce considerable complexity.

That's my two cents.

[kwonoj]

I would empathy for usefulness / demand of this, but my stand has not changed much : first, I don't see strong reason to introduce somewhat separate type variant from observable, secondly as Nicholas mentioned above I doubt this will play nice with all types we do constructed based on observable contract. And last, if those type issue's solvable I'd strongly suggest to start from userland instead of core library directly introduce it.

[benlesh]

A better solution for this would be to have a different type entirely with a similar signature. Task, etc. Because some of the operations it would have would be different than Observable. For example, first would not make sense on a Task.

This is something to think about and discuss, basically a Promise, only not eager and therefor overall more useful. Alternatively, we could have some operations that return a Promise or even a function that returns a Promise.

All in all, though, this is pie-in-the-sky and there are a lot of other higher priority things to fix before we can address this, given that Observable, as a type, is fully capable of handling single values cleanly.

[BioPhoton]

@benlesh as explained in the comments from you, @cartant and @kwonoj we won't implement this feature and therefore can close this issue.

If not please explain why this issue should stay open.

[michaeljota]

It's not as helpful as a Single type, but you could use toPromise when consuming the observable. This way would be safe for anyone reading the code that observable should emit only once, or at least the latest emitted value is the one you care about.

[passsy]

Related to #2469 which contains more discussion