このページはまだ翻訳されていないため、英語で表示されます。 翻訳に参加する

withLatestFrom

On every source event, emits combine of it and the other stream's latest value — the other side is context, not a trigger.

FxEvents<R> FxEvents<T>.withLatestFrom<U, R>(Stream<U> other, R Function(T a, U b) combine) // chain (events)

Lecture

A request fires and should carry the config version that was current at that moment. An order comes in and should be priced at the exchange rate right now. Two streams are involved, but they are not equals: one drives, the other is consulted. withLatestFrom(other, combine) encodes that asymmetry — each source event emits combine(event, latestOfOther), while events on other update its remembered value and emit nothing.

That one-sidedness is the entire difference from combineLatest, where both sides trigger. Pick by asking: should a config update by itself produce output? If yes, combineLatest; if the config only matters when a request happens to fire, withLatestFrom.

Edges, honestly. Source events that fire before other has produced anything are dropped — there is no latest value to stamp them with (give other a startWith seed if that loss is wrong for you). Lifetime follows the source: when it closes the chain closes, and other's close is simply ignored — a live feed on the context side never holds the pipeline open. fxdart events layer, after Rx's operator of the same name.

Demo 1 · Stamping requests with the current config

Demo 2 · The other side never triggers, never blocks

Try it yourself

Exercise: price each order at the rate of its moment.

Related: combineLatest — both sides trigger · sampleOn — the trigger-and-latest idea with no combining · fxEventsstartWith, for seeding the context side