This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (5)
- # babashka (23)
- # beginners (3)
- # business (6)
- # clj-kondo (40)
- # clojure (81)
- # clojure-berlin (1)
- # clojure-france (12)
- # clojure-nl (1)
- # clojure-norway (1)
- # clojurescript (4)
- # cursive (7)
- # data-science (1)
- # datascript (1)
- # emacs (9)
- # events (1)
- # fulcro (37)
- # malli (3)
- # meander (5)
- # membrane (2)
- # nrepl (1)
- # parinfer (1)
- # pathom (9)
- # re-frame (31)
- # reitit (10)
- # sci (2)
- # shadow-cljs (3)
- # sql (3)
- # tools-deps (16)
- # uncomplicate (4)
- # vrac (1)
beginners question: is it not possible to register multiple event handlers to the same event? in this example only the second handler is actually invoked when the event is triggered, but it seems like it would be quite nice if it did call both handlers 🙂
> is it not possible to register multiple event handlers to the same event? Indeed, it is not.
ah that’s a shame! would be nice if you could add some additional functionality just by hooking into existing events, for example
reg- function, you can get the associated handler and the re-reg a new handler that incorporates the old one with the same ID.
> what would be the re-frame way here? just do everything in the one handler? It depends on the specifics.
thanks that’s already very helpful! can you help me find the
re-reg docs? not seeing it here: https://cljdoc.org/d/re-frame/re-frame/0.10.6/api/re-frame.core
By "re-reg" I didn't mean a specific function - it's just a shorthand for "re-register". You have to call the relevant
reg-* function again, like on your image above.
But let me say in advance - even though above I wrote "depends on the specifics", in all likelihood such a pattern will lead to a glorious spaghetty of a code where different order of
require calls will result in drastically different behavior. You don't want that.
If you feel like a particular handler is too crowded, just split it into multiple functions, and then combine those functions into a single handler function.
Well, it's not the implementation that's complicated - it's the original idea. :) In your example on the image, it all depends on the order of the
reg-* calls. And such calls can be in different namespaces.
makes sense, i was hoping to use the events to add a new feature to my app without changing the already written code, like at all, but seems i would have to update the main event handler at least
Feature flags can be implemented at the app level - no need to go into the re-frame level.
yeah agreed! i definitely don’t want to fork re-frame 🙂 i’m thinking about the open-closed principle here, i would prefer to have a set of tests & implementation and then never need to touch that old code again, even when I add new things
Ah, I didn't mean forking re-frame, by "the re-frame level" I meant implementing dynamic feature flags via abusing the dynamic nature of the
I think this is one of those easy vs simple things. I’d stick with having one “composed” handler. There’s a new functionality to help with composition.
Is there a conventional way to delay recomputing a subscription? E.g. I have a subscription that is a dependency in a component that is always on screen. The subscription can be pretty expensive and is re-run after a lot of common events, which causes some lag in the UI.
reg-sub-raw you could compute and store the value with a debounced event. The UI-facing sub would then just retrieve the precomputed value.
Similar to how it's implemented here: https://github.com/day8/re-frame/blob/master/docs/Subscribing-To-External-Data.md
Here is what I did for this: https://gist.github.com/isaksky/2cc3779b52305e992c6150863454a9af
I think I may have found a mistake though, on line 45, the
e variable is shadowing the
e from above, which caused some funky results with the input signals
Np. Oh right, because the
input-signals gets called with the internal event vector on 47 and 56. Does that explain the problem you saw?
Yep, they were getting called with
[::computation-id->sub query-id] (the internal event vector)