Fork me on GitHub

@stefan.age there’s also, which I’m finding to be a nice sharp tool if you need explicit ordering.


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


and then coordinating dispatch


Thanks @rgm will check it out!


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


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..


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.


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


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


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