Enrico Teterra 2020-09-13T18:54:43.013500Z

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 🙂

p-himik 2020-09-13T18:56:29.013900Z

> is it not possible to register multiple event handlers to the same event? Indeed, it is not.

Enrico Teterra 2020-09-13T18:57:44.014100Z

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

Enrico Teterra 2020-09-13T18:58:05.014300Z

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

p-himik 2020-09-13T18:58:20.014500Z

You can already do that, just not that way.

p-himik 2020-09-13T18:58:46.014700Z

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.

p-himik 2020-09-13T18:59:16.014900Z

> what would be the re-frame way here? just do everything in the one handler? It depends on the specifics.

Enrico Teterra 2020-09-13T19:03:41.015100Z

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

p-himik 2020-09-13T19:05:23.015400Z

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.

p-himik 2020-09-13T19:06:37.015600Z

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 Teterra 2020-09-13T19:06:54.015800Z

right, yeah seems complicated

p-himik 2020-09-13T19:07:26.016Z

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.

p-himik 2020-09-13T19:08:23.016200Z

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 Teterra 2020-09-13T19:14:03.016400Z

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

p-himik 2020-09-13T19:15:53.016600Z

Feature flags can be implemented at the app level - no need to go into the re-frame level.

p-himik 2020-09-13T19:16:41.016800Z

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

Enrico Teterra 2020-09-13T19:17:29.017Z

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

p-himik 2020-09-13T19:19:33.017200Z

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 George 2020-09-13T20:46:39.020200Z

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.

Oliver George 2020-09-13T20:50:12.023500Z

knubie 2020-09-13T20:50:59.023900Z

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.

isak 2020-09-14T14:51:14.028700Z

Here is what I did for this:

knubie 2020-09-15T13:59:51.032500Z

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

knubie 2020-09-15T14:00:51.032700Z

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

isak 2020-09-15T14:39:45.033100Z

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?

knubie 2020-09-15T14:44:02.033400Z

Yep, they were getting called with [::computation-id->sub query-id] (the internal event vector)

isak 2020-09-15T14:46:01.033900Z

Will fix, thanks

knubie 2020-09-15T14:57:52.034200Z


p-himik 2020-09-13T20:58:55.024Z

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.

p-himik 2020-09-13T20:59:13.024200Z

Similar to how it's implemented here:

p-himik 2020-09-13T20:59:28.024500Z

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