Clojurians Log v2
re-frame
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
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.
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.
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.
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.
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.
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.
https://github.com/day8/re-frame/issues/639#issuecomment-682250517
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.
Here is what I did for this: https://gist.github.com/isaksky/2cc3779b52305e992c6150863454a9af
Thanks for sharing @isak, 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
đź‘Ť
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.
Similar to how it's implemented here: https://github.com/day8/re-frame/blob/master/docs/Subscribing-To-External-Data.md
But in your case "external data" would be "data from a debounced computation".