stopOn & startOn
Two gates driven by a second stream: stopOn closes the chain when the trigger fires, startOn opens it.
Lecture
A push chain has no natural end. A pull pipeline stops when the
consumer stops asking, but a live feed — a socket, a sensor, a
Stream.periodic — keeps producing until something
cancels it. Forgetting to do that is the classic leak:
a screen is disposed, the widget is gone, and its subscription is
still awake, still allocating, still calling setState on
a corpse.
stopOn(trigger) makes the shutdown part of the chain
rather than a variable you have to remember to cancel. The first
event on trigger closes the output and cancels
both subscriptions — the source's and the trigger's.
Nothing the trigger carries is read, only that it fired, so its type
is Stream<void> and any stream at all will do.
startOn(trigger) is the mirror: source events are
dropped until the trigger fires once, and passed for
good afterwards. It is the "wait until ready" gate — do not act on
taps until the session has loaded. Note that it is unrelated to
startWith, which prepends a
value rather than gating the start; the two names sit close together
and mean quite different things.
The …On suffix is the events layer's convention for
"driven by a trigger stream", shared with
sampleOn and
chunkOn. fxdart events layer,
after Rx's takeUntil and skipUntil — the
names differ because Fx.takeUntil already means the
predicate-driven takeUntilInclusive on the pull side,
and one name cannot mean two things in one library.
Demo 1 · The off switch
Demo 2 · The on switch
Try it yourself
Exercise: a session window, built from both gates.
FxSubscriptions — the other half of teardown: cancel many subscriptions at once ·
sampleOn — the same trigger convention, for reading instead of stopping ·
race — cancellation decided by whoever speaks first