Couple of questions 1) why do we show an error if there is no event handler found for an event. I feel this should just be a warning. 2) Also based on what I understand, we can just have one event handler for an event. This makes it a bit difficult to create purely decoupled libraries. e.g. I have a routing library, which emits events whenever URL changes and adds the new route and query params in the URL. Now there are multiple modules/libraries which could be interested in the same event.

yeah afaik re-frame doesn't implement a pubsub system (nor does it intend to)

but I've felt the need for something similar myself (with the ability to (de)register multiple subscribers)

maybe something based on https://google.github.io/closure-library/api/goog.pubsub.PubSub.html ?

it could be implemented on top of re-frame

hey guys, I need to abort a http request in re-frame. how can this be done ? I came across this issue: https://github.com/Day8/re-frame-http-fx/issues/3 any ideas ?

@pandeiro

>Could I alternately pass in a function that returns a {:dispatch-n [...]}?

Just create a reg-event-fx that returns a map with :dispatch-n. Use this event for your success handler

I feel reframe template has a flaw i.e. we call re-frame.core/reg-event-fx in the namespace

we should encapsulate it

in a function and then have a plain lifecycle around it

@pesterhazy can you please expand on how should I use https://google.github.io/closure-library/api/goog.pubsub.PubSub.html on top of reframe

the only hook I see is interceptors, which are declared along with event handlers

Can someone share a reason for not supporting multiple event handlers for an event ?

@rnagpal dispatch-n?

@pcj dispatch-n will help is emitting new events, but I want multiple handlers for the same event

I will try to write reg-event-fx-n which will merge the cofx

I will maintain a vector with all the handlers and their results will be merged

@rnagpal I guess to make event handling deterministic in the case of multiple events, you'd want to always evaluate them in the same order, right? Maybe the order they were registered in. That might get problematic as it would be determined (I think) by how your code is loaded -- how your requires are structure.

inside reg-event-fx-n I can call re-frame.core/reg-event-fx every time reg-event-fx-n is called, with the new composed handler

@jebberjeb you are right

Not sure if it'd be a problem in practice -- trying to imagine a scenario where it could be.

since in reframe handlers are one-to-one its okay to call/register re-frame.core/reg-event-fx straight away in the handlers. Each handler gets registered when the name space is loaded

I feel the pattern of registering a handler on namespace load is not good

@rnagpal interesting point re: pattern of registering on namespace load

@jebberjeb the problem you mentioned is the same when we use dispatch-n

I feel that is also not very deterministic

if we have dispatch-n and we are okay with the side effects I feel reg-event-fx-n without order will do no harm

hmm, if we dispatch-n aren't those events all handled in the order they're dispatched?

But the handler will not be aware of that order

@rnagpal > I feel the pattern of registering a handler on namespace load is not good There are always tradeoffs in design. With re-frame, I ended up at a certain point in the design space by juggling various tradeoffs. On the one hand, it is "not good" to globally side effect (which is what reg-sub and reg-event-db does). On the other hand, that decision is also deeply simplifying. Every re-frame app ever written is much simpler because of that trade-off. And, in practical terms, I haven't been badly affected by the theoretical "not good" associated with mutating global state.

So, I most certainly acknowledge the lack of theoretical purity, but I continue to be find the decision pleasing at a pragmatic level. In a similar way it is also potentially "not good' to have a global atom holding state. But the simplification it brings is quite powerful. Again, in practical terms, the benefit is substantial and the cost is minimal in most usecases. BUT ... what I claim above does break down though for some usecases - like using devcards. In these cases, the global, mutative design decisions do cause problems. Pros and Cons.