Some thoughts on events and event handlers and mixins.

[Ruben Vreeken]

I've been wondering about the way enyo handles events and the possibility of creating something simpler and more flexible.

Currently, it appears there are two types of events:

- Component Events, as implemented in enyo.Component

- Registered Events as provided by the RegisteredEventSupport mixin.

Component events are triggered by the dispatchEvent method, and their handlers are defined in a handlers object. Each event will only execute a single event handler on any particular component.
The fact that there can be only one single handler for a particular event is a bit limiting, in particular when it comes to mixins. I've run into several situations where I'd like to extract common functionality into a mixin, but this functionality requires events.

The way I do this currently, is have the mixin extend the importProps method to have it manipulate the handlers object by mixing in a 2nd handlers object containing the handlers required to make the mixin do it's thing. The downside to this, is that now the mixin dictates the name of the event handler. If the component we're extending doesn't use the same name for the handler, things will break.

Registered Events do allow you to register multiple listeners, but, they are not triggered by the normal enyo Component's event flow, they don't bubble, and they don't waterfall. In particular, they don't tie into DOM events.

Wouldn't it be better to simply add support for multiple event handlers to enyo's Component Events and get the best of both worlds?

[Cole Davis]

Hi Ruben,

This has been a point of discussion internally for a long time. I agree with you, whole heartedly, that it is frustrating not to be able to have multiple handlers for the same event. And, as you’ve found, this became most evident when using mixins but occasionally when inheriting as well. There are some other issues with the event scheme that have been somewhat addressed in recent releases but I think the overarching reason the multiple handlers hasn’t is because it would cause additional initialization overhead – and that is something we are always trying to reduce. We certainly know of ways to handle it, it comes down to deciding convenience or performance and thus far we’ve chosen the (small) performance gain from avoiding supporting it outright. This could and probably should be addressed anew, however, and perhaps this is just the discussion to open it back up!

The RegisteredEventSupport isn’t designed to replace DOM event handling, they are separate paths and serve different purposes. Registered event handlers are not initialized automatically from an exposed declarative API but they are also more efficient in that they don’t bubble or waterfall. It is the right tool in some scenarios but certainly not as a replacement for DOM events. They are particularly useful with standalone-singleton-esque objects that are shared and emit custom events.

Thanks for bringing this up. I’ll ask about it internally and see if this is something we can look into further and keep you posted.

Cheers,

Cole

--
You received this message because you are subscribed to the Google Groups "Enyo Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to enyo-developme...@googlegroups.com.
To post to this group, send email to enyo-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/enyo-development/e6f7714d-4fe3-47de-98a6-c296f2bb14a0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ruben Vreeken]

Hey Cole,

I'm surprised this type of thing has such serious performance implications. Perhaps I don't know enough about the specific cases that cause performance issues, so it's difficult for me to judge the situation. If there are particular issues I don't mind having a stab at finding a solution for some performance bottle necks or such.

Personally, I think Component Events should support multiple handlers, it just seems like part of the whole concept of an event system. To be more specific, events are a notification mechanism, they inherently lack specific intent. If you want explicit intent you need commands, or a request-response mechanism. For intentful communication mechanisms like that it would make much more sense to have only one listener. I think Enyo gets this right in the case of enyo.Signals, which I usually view as some kind of event-aggregator (probably that's not entirely correct, but in terms of functionality it gets close).

If performance is a big deal for more complex applications, it might be an idea to create some infrastructure for message channels that aren't part of the component tree itself. Probably a lot of communication doesn't necessarily *need* to flow through every intermediate node in the component tree anyways. An interesting library that might provide some inspiration here is Backbone.Radio (https://github.com/marionettejs/backbone.radio). This might free up some room to allow multiple handlers for components that do have real use for it.

Anyways, that's my mostly theoretical view on the situation. I understand there might be other practical considerations at play. Let me know if you guys are opening up the discussion, I'd be happy to join in if I can be of any help.

--

Kind regards,

Ruben