Esta página ainda não foi traduzida, por isso é exibida em inglês. Ajude a traduzir

RxDart vs FxDart › #36 · Fastest result first

Fastest result first

Toss-up async

• fx
• toAsync
• map
• concurrentPool

Requirement

Run six user lookups with distinct response times, at most 3 at once, and report the results in completion order — the fastest lookup prints first, regardless of where it sat in the input. The delays are chosen so the order is stable (user 2, then 1, 4, 3, 5, 6). The data is in the code; both versions must print the lines shown under Expected output.

user#2
user#1
user#4
user#3
user#5
user#6

Side by side

Why they differ

This is the mirror image of the previous example, and the verdict flips to even. Completion order is what a merge is: RxDart's flatMap(maxConcurrent: 3) subscribes to three inner streams and forwards whichever fires first, so "fastest first, three at a time" is the operator's literal behavior — nothing to add, nothing to undo.

A pull pipeline's default is the opposite — results come back in the order they were demanded — so FxDart offers completion order as a named variant: concurrentPool(3) keeps three pulls open and yields whichever resolves first, exactly like the merge. Each library reaches this requirement in one operator; the only real difference is which behavior each model gets for free and which one it had to name. Pick by the order you need — mapConcurrent when results must line up with inputs, flatMap / concurrentPool when latency to first result matters more.