re-frame 2022-03-31 | Slack Archive

Oliver George04:03:30

A colleague asked how to use async apis in handlers. In this case async is needed to interrogate data before the event handler can apply business logic My approaches are • "two handlers + fx" but that feels fragmented/clumsy • "do async before dispatching" which can feel impoure as views are made responsible for some logic How about if event handlers could be registered like subs and include a signal fn.

(rf/reg-event-fx2
   :file-upload 
   (fn signal [[_ file]] (.text file))  <-- this would wait for promise to resolve before calling handler
   (fn compute [ctx text] ...))

p-himik07:03:15

That will break the expectation that the :fx block is synchronous and not concurrent with anything else, so I doubt that it'll happen. > • "two handlers + fx" but that feels fragmented/clumsy This is pretty much the correct approach. Same exact way e.g. :http-xhrio already works. And you can use e.g. https://github.com/ingesolvoll/re-chain to make it less clumsy.

Oliver George11:03:40

Thanks for the link. Readme certainly expresses the problem well.

Oliver George11:03:02

Thinking out loud and trying to frame this better. Around an event we might want async before logic, during logic or after logic. After is covered by fx During logic is messy code. Probably can be teased apart (i.e. prepare inputs, run pure logic, trigger side effects) Before logic (data preparation) is the case I'm considering. Delaying the event handler execution a bit to allow some async to resolve seems clean. Could be cofx returning a promise or (my idea above) of a signal fn with access to the event vector.

p-himik11:03:15

Before and after are the same: "After logic": the "do" part is in the fx, the "after" part is in the :on-success (or whatever) event. "Before logic": the "before" part is in the fx, the "do" part is in the :on-success event. Same-same.

emccue12:03:23

I vote two handlers + fx, and make a custom fx if you want to combine two mechanical steps

➕ 1

2022-03-31

Channels