Fork me on GitHub
#re-frame
<
2019-08-16
>
rgm10:08:04

@stefan.age there’s also https://github.com/Day8/re-frame-async-flow-fx, which I’m finding to be a nice sharp tool if you need explicit ordering.

rgm10:08:01

the docs talk a lot about using it for app startup, but it’s handy for converting other this-before-thats into data

rgm10:08:13

and then coordinating dispatch

stefan14:08:42

Thanks @rgm will check it out!

stefan14:08:45

I’m probably doing something wrong with dispatch-n because the 2nd event is still dispatching with the previous state value even though it subscribes to a piece of state that the first event should be changing

Lu15:08:01

I’m really wild guessing, but if you are using an interceptor you need to return {:db db} in your event or you lose all the interceptor updates..

herald14:08:25

I still think chaining the dispatches (event A dispatches B which dispatches C and so on) is the safest way to guarantee ordering. From my memories of reading the re-frame-async-flow-fx docs, it has a significant performance overhead, which is why you use halt? true to clean up its sniffers when you're done using it to initialize your app.

lwhorton18:08:37

it’s admittedly pretty verbose to chain events through handlers and subsequent dispatches, but the async-flow-fx abstraction isn’t a no-tradeoff solution

lwhorton18:08:56

it also doesnt fit a lot of use cases very well (its mostly for single-use events like bootstrapping an app). i’ve seen codebases go from event chains -> some custom abstraction -> flow-fx -> back to event chains. iirc @mikethompson mentioned a while back that he’s been chewing on some solutions to this via state machines? not sure if that got anywhere

johanatan20:08:30

what's the current state of doing reframe + devcards? is there a devcards alternative that is compatible with reframe?