I don't remember seeing it being mentioned in the docs or examples at all. I would go with the most brain-dead solution. Work with the data you have, check if you have enough pages on every step, and if not, request them and only then continue.

And if you're already using core.async in your CLJS codebase, perhaps this will be useful: https://gist.github.com/hiredman/1c2e76f5544752391d78ae3df84ab993

Hah, wow. I was in the middle of writing a message asking how an async-iteration fn might be done and looking over the core.async docs 😂

Heh. But note that, at least IIRC, core.async will increase your bundle size noticeably and is also kinda hard to debug.

Seems weird that iteration wouldn’t be able to handle async requests, but I’m not sure how you’d do that in a generic way suitable for clojure.core

There might be a niche for core.async/iteration. :) Dunno.

My brain-dead solution to this problem was to have the event handler that is dispatched on a successful response from the paginated API check to see if there is more data available and more data needed and if so dispatch the event that loads more data from the API. So it's a loop of two event handlers that dispatch each other until the response event handler decides it's time to quit

Landed on the same solution myself, haven’t had the time to clean it up but it involves some app-db storage because it’s modeled after iteration which is stateful. https://gist.github.com/hxegon/1a1084f2c7df2cd4e2a5a2e1c8ce286b

Was thinking about adding a finallyf parameter. I have a bunch of weird indexing/access events and subs on top of this that probably could be extracted into generic events/subs building on ::iteration

Added an example event using ::iteration