com.raquo.airstream.core

This trait represents a reactive value that can be subscribed to.

It has only one direct subtype, Observable, which in turn has two direct subtypes, EventStream and Signal.

BaseObservable is the same as Observable, it just lives in a separate trait for technical reasons (the Self type param).

All Observables are lazy. An Observable starts when it gets its first observer (internal or external), and stops when it loses its last observer (again, internal or external).

Basic idea: Lazy Observable only holds references to those children that have any observers (either directly on themselves, or on any of their descendants). What this achieves:

• Stream only propagates its value to children that (directly or not) have observers
• Stream calculates its value only once regardless of how many observers / children it has) (so, all streams are "hot" observables)
• Stream doesn't hold references to Streams that no one observes, allowing those Streams to be garbage collected if they are otherwise unreachable (which they should become when their subscriptions are killed by their owners)

This trait lets the user set an ad-hoc name for this instance. Used for debugging and tracing.

Subclasses: BaseObservable, Observer

All the interesting stuff is in BaseObservable. This trait exists only as a sort of type alias for BaseObservable[Observable, A]. (I can't use an actual type alias for this due to an illegal cycle)

Signal is an Observable with a current value.

A Sink is something that can be converted to an Observer. The counterparty to Sink is a Source, something that can be converted to an Observable.

A Sink could be an Observer itself, an EventBus, a Var, or, via implicits, an external type like js.Function1.

The point of using Sink instead of Observer in your API is to let the end users pass simply eventBus instead of eventBus.writer to a method that requires Sink, and to achieve that without having an implicit conversion from EventBus to Observer, because then you'd also want an implicit conversion from EventBus to Observable, and those two would be incompatible (e.g. both Observable and Observer have a filter method).

A Source is something that can be converted to an Observable. The counterparty to Source is a Sink, something that can be converted to an Observer.

A Source could be an Observable itself, an EventBus, a Var, or, via implicits, a third party type like Future or ZIO.

The point of using Source instead of Observable in your API is to let the end users pass simply eventBus instead of eventBus.events to a method that requires Source, and to achieve that without having an implicit conversion from EventBus to Observable, because then you'd also want an implicit conversion from EventBus to Observer, and those two would be incompatible (e.g. both Observable and Observer have a filter method).

Observable that can become pending for the purpose of synchronization - see Transaction for pending logic