This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-09-10
Channels
- # announcements (16)
- # aws (1)
- # babashka (2)
- # beginners (33)
- # biff (2)
- # clj-kondo (13)
- # cljs-dev (1)
- # cljsrn (3)
- # clojars (6)
- # clojure (198)
- # clojure-australia (3)
- # clojure-europe (41)
- # clojure-france (3)
- # clojure-nl (2)
- # clojure-spec (7)
- # clojure-uk (12)
- # clojurescript (57)
- # clojureverse-ops (1)
- # code-reviews (3)
- # community-development (2)
- # conjure (10)
- # data-science (1)
- # datomic (15)
- # depstar (2)
- # docker (2)
- # etaoin (1)
- # events (1)
- # exercism (5)
- # fulcro (23)
- # helix (23)
- # introduce-yourself (4)
- # jobs (6)
- # kaocha (1)
- # lsp (11)
- # meander (107)
- # off-topic (8)
- # pathom (3)
- # polylith (33)
- # re-frame (23)
- # reagent (7)
- # reitit (28)
- # remote-jobs (3)
- # sci (1)
- # shadow-cljs (2)
- # specter (5)
- # sql (38)
- # tools-deps (72)
- # web-security (9)
- # xtdb (32)
Hello, I'm facing a certainly simple issue in my re-frame app: in my initialization event handler, I have to fetch some data from a server using http-xhrio, and it consists in 3 distinct http requests. I'd like to dispatch an event when all my requests have arrived. In JS, I would use Promise.all() to synchronize everything, but what can I use in a cljs/re-frame environment ? Thanks a lot for your help !
I have used this library to help manage things like that: https://github.com/Day8/re-frame-async-flow-fx
Essentially, you would be able to declare "once these 3 on-success events have been seen, dispatch another event"
Don't use that library. Read this comment and the rest of the thread for "why": https://clojurians.slack.com/archives/C073DKH9P/p1631039809068800?thread_ts=1631015086.050100&cid=C073DKH9P
The simplest way is to check the size of the result accumulator. If it's equal to the amount of the requests you have sent, then it's all done. Nothing complicated.
It might be fine to use it if you know what it does, how it does it, when it does it, and why it does it. Lots of requirements for such a simple task.
oh ok, thanks for the tip @U2FRKM4TW. Noob question here, but what are you calling result accumulator ?
You store the results of those requests somewhere, right? If you store them all in a single vector by just conj
ing them without any regard for the order, then that vector is a simple result accumulator.
And by "a vector" I of course mean a vector somewhere in re-frame's app-db. Not just any random vector.
Works fine if they are in separate parts of app-db too. If each request places data in some part of app-db, just check each one, if all your data is there, time to dispatch your dependent event. Interesting approach I have never considered.
And if you issue such batches of requests rather often (well, more than in two places in your app, I'd say), then create a separate effect and effect handler for that, :multiple-http-xhrio
or whatever you prefer.
I definitely need more practice to get the right reflexes 🙂 Thank you @U2FRKM4TW, you're the guy who always puts me to the right track on clojurians 😄
@UEUT2N7AN what i have done is for really truly "global" data that is needed for the startup of the app and not any particular page
but in general making a little state machine is the way to handle it - a vector with things is one way to do that
Fat fx can save a lot of unnecessary plumbing… that’s the realm of the promise all approach. Using a reframe event loop obsessively can be unnecessary unless the app needs to manage the individual requests. Is handling the combine response somehow problematic…
(But I carefully avoid logic in fat fx)
I'm kinda suspicious of the word "unnecessary" - keeping things uniform has benefit even if individual tasks it might be "a bit much"
It became more pronounced for me when working on a mobile app. There are so many interactions with asynchronous APIs. Trying to map that into the event loop can be exercise in futility.