Fork me on GitHub
#re-frame
<
2021-09-10
>
Nico14:09:54

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 !

lispers-anonymous14:09:14

I have used this library to help manage things like that: https://github.com/Day8/re-frame-async-flow-fx

lispers-anonymous14:09:11

Essentially, you would be able to declare "once these 3 on-success events have been seen, dispatch another event"

Nico14:09:52

Oh nice ! thank you, I'll give it a look right now 🙂

p-himik14:09:52

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&amp;cid=C073DKH9P

👀 4
p-himik14:09:29

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.

p-himik14:09:25

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.

Nico14:09:02

oh ok, thanks for the tip @U2FRKM4TW. Noob question here, but what are you calling result accumulator ?

p-himik14:09:25

You store the results of those requests somewhere, right? If you store them all in a single vector by just conjing them without any regard for the order, then that vector is a simple result accumulator.

👍 2
p-himik14:09:50

And by "a vector" I of course mean a vector somewhere in re-frame's app-db. Not just any random vector.

lispers-anonymous14:09:17

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.

Nico14:09:45

Oh yes, clearly simple, understood 🙂

Nico14:09:58

Thank you both !

p-himik14:09:56

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.

Nico14:09:00

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 😄

👍 2
emccue15:09:16

@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

emccue15:09:49

is to just literally use promise.all - i like promesa for it, but anything works

emccue15:09:20

but in general making a little state machine is the way to handle it - a vector with things is one way to do that

🙏 2
emccue15:09:14

i like a set more since its clearer that order doesn't matter

Oliver George21:09:34

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…

Oliver George02:09:20

(But I carefully avoid logic in fat fx)

emccue02:09:46

I'm kinda suspicious of the word "unnecessary" - keeping things uniform has benefit even if individual tasks it might be "a bit much"

Oliver George05:09:13

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.