本页尚未翻译，因此以英文显示。 参与翻译

RxDart vs FxDart › #48 · Crawl pages until exhausted

Crawl pages until exhausted

FxDart wins async

• fx
• toAsync
• flatMap
• takeWhile
• map

Requirement

A paged orders API returns three orders per page and an empty list once the data runs out (page 4). Crawl page by page until the empty page, flatten the orders into one list, and print them plus how many pages were actually fetched — exactly four; the crawl must never request page 5. The fake API is in the code; both versions must print the lines shown under Expected output.

order#1
order#2
order#3
order#4
order#5
order#6
order#7
order#8
order#9
pages fetched: 4

Side by side

Why they differ

Pagination is the pull model: fetch a page, look at it, decide whether to ask for another. The FxDart side writes that down directly — an endless sync* cursor of page numbers that only advances when the pipeline demands the next one, map(fetchPage), takeWhile(isNotEmpty), flatten. Nothing bounds the cursor because demand is the bound: when takeWhile sees the empty page it simply stops pulling, and page 5 is never even generated.

The stream side gets to the same place, but only by borrowing pull mechanics: an endless async* cursor — plain Dart rather than an Rx operator — paused into demand-driven behavior by asyncMap's backpressure, and a takeWhile whose cancellation stops the crawl at the empty page. It works, and prints the same pages fetched: 4 — because pause, resume and cancel are exactly the stream model's back-channel for simulating "ask again when ready". The pull side did not need the simulation: demand is its normal mode. Jobs where the consumer's state decides whether more input should exist are pull-shaped, and this is the cleanest case of it.