This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (1)
- # babashka (29)
- # beginners (53)
- # berlin (1)
- # cider (14)
- # clj-kondo (18)
- # cljsrn (16)
- # clojure (141)
- # clojure-france (4)
- # clojure-italy (8)
- # clojure-norway (1)
- # clojure-uk (57)
- # core-async (7)
- # cursive (3)
- # data-science (2)
- # datomic (12)
- # duct (5)
- # fulcro (27)
- # hoplon (37)
- # immutant (1)
- # jobs (2)
- # jobs-discuss (7)
- # kaocha (2)
- # leiningen (3)
- # music (17)
- # nyc (1)
- # off-topic (22)
- # pathom (27)
- # re-frame (33)
- # reitit (23)
- # shadow-cljs (20)
- # tools-deps (15)
- # vim (29)
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 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)
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.
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.
does anyone know why these include both
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
there's a bunch that just includes both; https://github.com/search?q=filename%3Ashadow-cljs.edn+day8.re-frame%2Ftracing-stubs&type=Code
I guess I should just subscribe to this 🙂 https://github.com/day8/re-frame-debux/issues/21
@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.