Fork me on GitHub
#re-frame
<
2016-09-21
>
akiroz06:09:07

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.

mac06:09:22

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?

akiroz06:09:29

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

mac06:09:15

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

curlyfry07:09:02

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

curlyfry07:09:47

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

mac07:09:03

@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 🙂

mac07:09:06

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

akiroz07:09:45

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

curlyfry07:09:38

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

mac07:09:07

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

akiroz07:09:04

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

akiroz07:09:43

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

mac07:09:09

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

kalouantonis13:09:44

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.

darwin13:09:05

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

darwin13:09:01

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

kalouantonis13:09:04

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?

kalouantonis13:09:37

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

darwin14:09:05

@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

darwin14:09:18

can you give an example of your event stream?

kalouantonis14:09:51

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

akiroz14:09:19

@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

darwin14:09:56

@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

akiroz14:09:11

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

darwin14:09:33

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

darwin14:09:14

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

darwin14:09:58

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

kalouantonis14:09:00

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

kalouantonis15:09:58

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

shaun-mahood15:09:06

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

timgilbert20:09:10

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

timgilbert20:09:47

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

danielcompton22:09:43

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