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?

https://github.com/Day8/re-frame/blob/master/docs/Talking-To-Servers.md

@akiroz Thanks. I was trying to do this in line with https://github.com/Day8/re-frame/blob/master/docs/Loading-Initial-Data.md 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 https://github.com/Day8/re-frame/blob/master/docs/Talking-To-Servers.md. 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: https://github.com/Odinodin/data-frisk-reagent#use-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