Fork me on GitHub
#re-frame
<
2018-09-23
>
sveri08:09:05

@mikethompson Thanks, thats a usefule link 🙂

urbanslug20:09:09

However, when I dispatch an event I don't find it being executed

urbanslug20:09:17

I basically have something like the events in events.cljs get dispatched successfully but the ones in pane1/events.cljs get ignored - pane1/events.cljs - events.cljs

urbanslug20:09:06

is that I have a root db.cljs which has say {:pane1 pane-1/default-db}

gadfly36120:09:27

@urbanslug is the namespace panel1.events being required in your core namespace? (Or by a namespace that is required by your core namespace)

urbanslug20:09:49

@gadfly361 it's not, should it?

gadfly36120:09:50

It's possible those events are not successfully being registered

gadfly36120:09:57

Yeah, it should

urbanslug20:09:21

haha my bad I thought it wasn't being reistered for some reason

gadfly36120:09:32

It's an easy thing to miss. They would register normally .. but the compiler (being unaware of the side effect) thinks that namespace isn't used so ignores it. By including it in the core namespace, you're telling the compiler specifically .. no I want to keep this!

urbanslug20:09:12

Doesn't seem to work, is there a way that I can be sure that it got registered

gadfly36120:09:51

In the console, what does it say when you try to dispatch the event

gadfly36120:09:14

You should get some kind if warning if it isn't registered

urbanslug20:09:44

wait I see something now

urbanslug20:09:33

They're being registered

urbanslug21:09:47

Thank @gadfly361 I appreciate the help. I just didn't have it required in the core.cljs

lvh22:09:28

I'm trying to build a diagramming tool with re-frame. There's an svg element containing all the diagram elements. I'm tracking clicks via an on-click handler on the svg element. But the effect of the click event depends on the currently selected tool. Is the correct way to do this to have the onclick handler @ a subscription to the event? the other way is to have a parent click event handler dispatch a new event depending on exactly what it needs to do: but then the event handler has to either read the database or subscribe to the currently selected tool, and that seems like more behavior than there should be in event handling

lvh22:09:29

(also that seems to promote that that the event handler knows how the current tool is stored, though I guess event handlers are already pretty tied to subscriptions that way)

mikethompson23:09:52

@lvh event handlers do the processing. They interpret the click. The currently selected tool would be in app-db and they have access to that data. The thought of subscribing to events seems very off-kilter

mikethompson23:09:57

subscriptions are just a way of obtaining the new state (created by the event handler when interpreting the event)

lvh23:09:44

So your event handlers typically process browser event objects? Doesn’t that make them harder to test?

mikethompson23:09:08

event handlers are just functions.

mikethompson23:09:44

They get two inputs (current state and event) and they compute an output (new state)

mikethompson23:09:52

So they are super easy to test

mikethompson23:09:33

Sorry, I'm going to have to fly. Be sure to read through the docs to get the right feel for how to architect.

mikethompson23:09:48

There are example apps, etc

mikethompson23:09:54

Further resources

lvh23:09:44

Sure, but a function can take a browser event object or a CLJS map