Fork me on GitHub
#re-frame
<
2017-07-24
>
rnagpal13:07:25

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.

pesterhazy13:07:13

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

pesterhazy13:07:49

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

pesterhazy13:07:20

it could be implemented on top of re-frame

binora18:07:16

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 ?

pcj18:07:42

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

pcj18:07:25

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

rnagpal19:07:19

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

rnagpal19:07:25

we should encapsulate it

rnagpal19:07:43

in a function and then have a plain lifecycle around it

rnagpal19:07:25

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

rnagpal19:07:57

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

rnagpal19:07:56

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

rnagpal19:07:28

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

rnagpal19:07:08

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

jebberjeb19:07:53

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

rnagpal19:07:43

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

jebberjeb19:07:54

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

rnagpal19:07:13

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

rnagpal19:07:52

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

jebberjeb19:07:48

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

rnagpal19:07:25

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

rnagpal19:07:38

I feel that is also not very deterministic

rnagpal19:07:26

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

jebberjeb19:07:37

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

rnagpal19:07:29

But the handler will not be aware of that order

mikethompson22:07:03

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

mikethompson22:07:37

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.