This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-03-10
Channels
- # announcements (48)
- # asami (8)
- # babashka (186)
- # beginners (56)
- # calva (42)
- # clerk (84)
- # clj-kondo (75)
- # cljdoc (21)
- # clojure (121)
- # clojure-art (1)
- # clojure-australia (1)
- # clojure-china (1)
- # clojure-conj (2)
- # clojure-europe (10)
- # clojure-filipino (1)
- # clojure-hk (1)
- # clojure-indonesia (1)
- # clojure-japan (1)
- # clojure-korea (1)
- # clojure-my (1)
- # clojure-nl (2)
- # clojure-norway (9)
- # clojure-sg (1)
- # clojure-taiwan (1)
- # clojure-uk (2)
- # clojurescript (11)
- # cursive (30)
- # datalevin (20)
- # datomic (4)
- # fulcro (5)
- # gratitude (1)
- # hyperfiddle (89)
- # introduce-yourself (1)
- # java (5)
- # jobs-discuss (8)
- # lsp (89)
- # malli (57)
- # membrane (16)
- # off-topic (12)
- # pathom (38)
- # releases (5)
- # shadow-cljs (17)
- # tools-deps (18)
- # xtdb (62)
What’s an idiomatic way to handle paginated APIs in re-frame? I just went down a rabbit hole trying to figure out using iteration
but it seems like a non-starter because JS doesn’t have blocking
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
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