Fork me on GitHub

hello, just wanted to know if there's any way to check what events are registered with re-frame... I want to validate the event keyword before calling dispatch.


I am using js/fetch which returns a js promise to get the initial value for my app-db. What is the best way to initialise the app-db using this since the promise requires a callback?


maybe put a loading state into your db initially, dispatch an event in the promise callback and update your db in that event?


@akiroz Thanks. I was trying to do this in line with but cannot make it work. I am unsure what to return from the :initialize-db handler since the fetch has not completed at this point.


@mac: Check out You'll want another dispatch in the callback which puts the response data into app-db. I personally use cljs-ajax rather than js/fetch.


Oops, now I see that akiroz posted that link already!


@akiroz You can get all registered event handlers like this (keys (:event @re-frame.registrar/kind->id->handler)) - don't think that is meant for public consumption though 🙂


@curlyfry No prob. I can get my "initialiser" to work after load using that approach, just not sure exactly what to do in the :initialise-db handler.


Hmm... alright, guess I'll skip the validation after all.


@mac Like akiroz said earlier, I think that is where you would do the fetch?


@curlyfry Ok, but what to return? The handler needs to return a new db - if I am not missing something.


@mac you can either return a db indicating the loading state or just an empty map.


better yet, use reg-event-fx if you're in re-frame 0.8.0 to indicate that your event handler doesn't manipulate db


@akiroz Bingo. I positively thought I had tried exactly that, but apparently not.


Is using core.async discouraged in re-frame? The reason I ask is because I can’t find any example projects or any docs that reference core.async.


@kalouantonis using core.async is perfectly fine with re-frame, people probably don’t have core.async+re-frame use cases to write about


you should look for general core.async articles, I guess


This is a bit of a tangent, but I have this issue where I have 2 event handlers called :sync and :zip-device. Now, :sync calls :zip-device for each connected device, spawning a new process that zips and monitors for failures. The :zip-device process needs to communicate files back to :sync to add them to an archive. So, :zip-device sends files that needs to be zipped to the :sync process and then :sync replies back with the status of each file. I’m really having difficulty getting this to work nicely with re-frame, am I going about this the wrong way? Is there a simpler way to do this without spawning a bunch of core.async processes? How do I synchronise state between them?


That’s why I guess I’m confused as the re-frames core.async support


@kalouantonis hmm, I don’t see a problem, re-frame gives you a tool to produce a linear sequence of events which get applied to app-state. from your description the situation is that your code produces bunch of :sync and :zip-device events which somehow modify app-state, as long as you communicate all information via events and not on side, you should be fine


can you give an example of your event stream?


:sync is basically a broker between devices and a zip archive.


@kalouantonis I don't really understand what this does exactly but I think you may want to use a :zip-device event for each device and in that handler you'd dispatch either :zip-device-success or :zip-device-failed


@kalouantonis I don’t quite understand why should re-frame have anything to do with communication between go “processes”, that seems to be orthogonal to me


re-frame internally uses core.async for events so that's bacially what you're doing.


why is :zip-device a handler in the first place? it does not have any effect on app-db when called


that should be a normal function which will provide a control channel back to the caller, so that the communication can be later performed


or any other means of communication (a callback, or rely on shared mutable state)


I see… The :zip-device handler should be using dispatch somewhere though to set the current device file state in app-db


Thats much clearer for me now, thanks. I guess there’s also an element of rubber 🦆 ing in typing it all out


@akiroz: Not super important, but the current re-frame doesn't use core.async anymore - it's been replaced with it's own finite state machine instead. Old versions were using core.async though, so the comparison should still be relevant.


Just had a PR merged into data-frisk-reagent that describes how to use it with re-frame:


It’s pretty neat, gives you a little collapsible tree of your app-db state on the page.


re-frame doesn’t encourage or discourage use of core.async in general, but the way that data and events flow means that you often don’t need it very much. In our re-frame (20k+ loc) I can think of only one place we use it, where we make three RPC calls, and collect them in a go block before dispatching them, and we may rewrite that one shortly too