Fork me on GitHub
Enrico Teterra18:09:43

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.

Enrico Teterra18:09:44

ah that’s a shame! would be nice if you could add some additional functionality just by hooking into existing events, for example

Enrico Teterra18:09:05

what would be the re-frame way here? just do everything in the one handler?


You can already do that, just not that way.


For every 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.

Enrico Teterra19:09:41

thanks that’s already very helpful! can you help me find the re-reg docs? not seeing it here:


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.

Enrico Teterra19:09:54

right, yeah seems complicated


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.

Enrico Teterra19:09:03

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.


And it will definitely be easier to support and reason about.

Enrico Teterra19:09:29

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 reg-* functions.

Oliver George20:09:39

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.

👍 3

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.


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


But in your case "external data" would be "data from a debounced computation".


Thanks for sharing @U08JKUHA9, that’s really helpful.


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)


Will fix, thanks