RxDart vs FxDart › #3 · Flatten orders into lines

Flatten orders into lines

Toss-up

• fx
• flatMap
• map

Requirement

Yesterday's four orders each hold two or three line items. Flatten them into one list of order/sku lines — every item under its order id, in source order — and print the line count. The data is in the code; both versions must print the lines shown under Expected output.

A-101/tea-01
A-101/mug-07
A-102/pen-11
A-102/ink-02
A-102/pad-05
A-103/mug-07
A-103/lid-04
A-104/tea-01
A-104/jar-03
A-104/lid-04
10 lines from 4 orders

Side by side

Why they differ

One-to-many flattening is bedrock in both models, and for a synchronous payload the two spellings are the same word: Stream.expand and FxDart's flatMap both take element to iterable, splice the pieces in source order, and hand the result to a formatting map. The panels are line-for-line parallel.

The interesting divergence is just offstage. When each order's lines arrived asynchronously, the Rx side would graduate to RxDart's flatMapIterable or flatMap — inner streams, where merge order becomes a real question (interleaving by completion unless you concatenate). FxDart's async flatMap on a pulled pipeline stays in source order by construction. But that is a tier-4 story; on this in-memory job both sides express the flatten directly — the Rx panel doesn't even need an RxDart operator, core Stream carries it — and the only trace is the async main. A tie.