Fork me on GitHub
#re-frame
<
2017-01-30
>
glebkaf06:01:20

Hi there! How should I handle async coeffects? I’m using this fx for loading data from async-storage, but i realised that it should be cfx instead, is there way to handle it properly?

(reg-fx :localstorage  (fn [{:keys [on-success on-fail]}]
                         (-> (async-storage/load)
                             (.then on-success)
                             (.catch on-fail))))

mikethompson10:01:47

@glebkaf If you are loading something async then it should be handled with an effects handler like re-frame-http-fx (i don't mean you should use re-frame-http-fx, just that the process will be the same) https://github.com/Day8/re-frame-http-fx

glebkaf12:01:02

@mikethompson Yeah, thanks 🙂 I'm already using effect handler like this aswell as async-flow, just thought that it should be cofx since my event handler "requires localstorage from the world". I'm wished something like this:

(reg-event-fx 
    :some-id 
    [(inject-cofx :asyncstore)]  
    (fn [{:keys {lasyncstore}} _]
    ; proceed with asyncstore
    )) 
🙃

mikethompson10:01:12

If this is one step in a boot sequence, which involves coordinating multiple async actions, you might need https://github.com/Day8/re-frame-async-flow-fx

heeton21:01:34

Perf question: who’s using dispatches for literally everything in their re-frame apps? My code is getting a bit cumbersome building up and reducing big mappings of functions to process data in an event handler. I’ve started to see that I could simplify it into lots of dispatch calls - with the new 0.8 pure dispatch syntax, any cool optimisations going on? I.e. if I dispatch in an event handler, is it processed right away or might it be some fraction of a second later in a different requestAnimationFrame?

musheddev22:01:18

@heeton From what I understand any dispatch will be ran in the next animation frame.

heeton22:01:24

@musheddev Even though we can start to inspect the return from a pure event handler and immediately execute?

mikethompson22:01:28

No, not really true. The dispatch will be run pretty much immediately.

mikethompson22:01:42

Just to be clear: Next Annimation frame is potentially 16ms away. But a dispatch is handled virtually immediately.

heeton22:01:24

@mikethompson virtually meaning ? My scenario would involve doing maybe a dozen minor calculations and assignments to the DB via dispatching instead of reducing a set of operations over the db myself in one handler. Should I be concerned potentially skipping into new frames, or is it a non-issue?

heeton22:01:55

Classic relational transaction sort of stuff. If I handle an event and decrease one user’s bank account balance, then dispatch an event to increase another’s, am I ever likely to get an in-between state that isn’t consistent? Or do they happen at effectively the same time no matter if I’m doing hundreds of things like that.

musheddev22:01:14

@mikethompson So events dispatched through an event handler would executed immediately in the order listed like a function call, while events dispatched through an ui event handler would be queued to the next animation frame?

mikethompson22:01:04

@musheddev no, every dispatch is put into a queue the same way. Then handled FIFO

mikethompson22:01:36

@heeton See goog.async.nextTick for definition of immedaitely

heeton22:01:52

Sweet, thanks

qqq22:01:44

is there a good article anwhere on Om.next vs reframe ?