@sveri the todomvc example has some guidance https://github.com/Day8/re-frame/blob/master/examples/todomvc/src/todomvc/events.cljs#L59-L68

and https://github.com/Day8/re-frame/blob/master/examples/todomvc/src/todomvc/events.cljs#L59-L68

@mikethompson Thanks, thats a usefule link 🙂

So I'm using the app structure for larger apps as described here: https://github.com/Day8/re-frame/blob/master/docs/Basic-App-Structure.md#larger-apps

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

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

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

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

@gadfly361 it's not, should it?

It's possible those events are not successfully being registered

Yeah, it should

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

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!

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

?

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

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

Nothing

hmmm

wait I see something now

They're being registered

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

@urbanslug np!

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

(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)

@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

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

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

event handlers are just functions.

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

So they are super easy to test

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

There are example apps, etc

Further resources

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