Fork me on GitHub

Newbie question here, how do you call another event from an event handler? Should I just use dispatch. Similarly, how do you call effect from another effect?


@electricladyland156 you would use the :dispatch effect


Which is different to calling dispatch


You'll need to read the docs on event handling and producing effects


@electricladyland156 Also ... be aware that this is not the best way to think about events. They are not like "calling a function" Generally, one event handler does not call another, like one function would call another. (I realize that this might be just a phrasing issue, but thought I should comment given you are new) Events generally represent "user intent" For example, the user might want to: - "View All Customers" or - delete triangle with id 4 And the associated event handler is what knows how to handle that user intent (it can compute the effect of the event)


It might change the panel being displayed and it might initiate an HTTP call to the backend server (these are the effects of the event)


It would be a little unusual for one event handler "to call" another.


To the extent that it does happen, it is probably a sign of something a little wrong with the design IMO


BTW, as well modeling "user intent", events can also model the "actions" of other external actors, like the arrival of an HTTP response or a websocket packet. The user is important, but ultimately they are just one of many external actors creating events to which the app must respond.


Ah, so that's the better way to explain it: events represent the motivated intent of an EXTERNAL actor to the application. And "the user" is the primary external actor. The job of an event handler is to compute the effects (on the application) of that event occuring.


When you have this view, you can see that one event does not normally involve creating another event. An event handler is not an external actor. It does not generate events.


Thank you for the explanation!


Hmm... does this mean event chains (via the :dispatch effect) suggest design issues?


I treat some events just like the described external actors. Simply because when the application is large, some chunk of functionality tends to be common to all parts of the application and is used by both external actors and some "internal" ones. I don't see any issues with having :dispatch effects that use such events. And yes, I could definitely extract the common functionality into functions. But that has issues - unnecessary boilerplate, inability to trace, inability to use interceptors exactly where I want them etc.


Another reason to have some events dispatch others is the fact the the problem of reusability of complex re-frame-based components is still not really solved. Because of that, right now I have a bunch of events that I pass around, including as arguments to other events that later dispatch them, as well as subs that sub to their arguments in sub signals.


I'm wondering if there's some pattern of composing effect maps, rather than chaining effects


Maybe. I haven't tried to solve this as I don't really see an issue here when "higher order events" are used sparingly. And being able to compose effect maps still doesn't solve the interceptors issue and potentially brings some effects ordering issue.


What's the biggest open source re-frame app around?


cool. useful 🙂 thanks


check memefactory or name-bazaar


I've seen several shadow-cljs.edn files with both included at top-level dependencies


you can only include one of those. shadow-cljs itself does not support classpath profiles. you can use project.clj or deps.edn if you need to replace those


yeah, that's what I thought


was just wondering if there was some magic somewhere that figured out which to use


I guess I should just subscribe to this 🙂


@p-himik Yeah, i don't really have a problem with the idea of "higher order evens" being used sparingly either. I'm just putting the best and "purest" case because otherwise I've seen some code bases where events are treated as a kind of function call.

👍 4

The original poster was sounding like they were going down that path a bit too much