Marks the struct to be primarily considered an
Observable.
It must only be used for types that ONLY implement
Observable but do NOT implement
[Observer][crate::Observer] and other traits as that would make it a
SubjectLike.
Marks the struct to be primarily considered an [Observer][crate::Observer].
It must only be used for types that ONLY implement
[Observer][crate::Observer] but do NOT implement
SubscriptionLike as that would make it a
Subscriber.
Marks the struct to be primarily considered a
SubjectLike.
It must only be used for types that implement bothObservable and [Observer][crate::Observer]!
Marks the struct to be primarily considered a
Subscriber.
It must only be used for types that implement both
[Observer][crate::Observer] and SubscriptionLike!
A teardown is a closure which owns resources, by the nature of them being
moved into said closure. The closure itself is responsible for releasing
these resources.
To mark types that upgrade to themselves when used as a destination in an
Observables subscribe method. Usually subscribers fall into this category
as they are already subscribers, so there’s no need for an upgrade. But
there are a few regular observers too that chose to implement
SubscriptionLike to implement a unique behavior. These observers take it
upon themselves to manage their own closing logic, and maintain a teardown
for added teardowns.
For example, the PrintObserver does this to be able to print when it got
unsubscribed, and the MockObserver to be able to track all notifications
for assertions.
A Subject is something that is an Observable and Observer (Subscriber) at
the same time. Signals pushed into it will be received by the subscriptions
made from it, broadcasting them.
A SubscriptionLike is something that can be “unsubscribed” from, which
will close it, rendering it no longer operational. If it also owns
resources, it will also release those resources, usually by executing
Teardowns
When a subscription is established, the destination must only receive the
next, error and complete signals, but not unsubscribe. And since
subscribers and subjects are observers too, they could be passed as a
destination, but doing it naively would always unsubscribe them too when
the observable unsubscribes.
Never cannot be constructed as it’s an enum with no variants.
So it’s perfect to denote a signal that will never be emitted, like
Observables that never error, or emit. Or Operators who catch errors.