[FEATURE ember-views-event-capture] Uses useCapture and custom delegation.

[runspired]

This is a test implementation that would enable Ember to keep existing event behavior while converting to an event-capture based eventing model.

Instead of bubbling, events are captured immediately at the application root, then a walker is used to find the collect the views or actions which trigger for the event. Any handler which returns true causes the walker to continue walking the tree.

Notes:

• A could-be-improved perf test showing that this form of delegation can be faster than native bubbling even without cacheing event handler resolutions: http://jsperf.com/event-delegation-with-capture-vs-bubble

[sandstrom]

One benefit with bubbling is that the capture phase can be used for things needing to occur before Ember's event-handling.

We use it for some components where doing things within Ember was tricky, or when relying on fairly complex third-party code, which we didn't want to rewrite to Ember. In these cases, being able to act on events in the capture phase made integration with Ember simple.

So, for a feature like this it would be great if the ability to keep running in the bubbling phase remained.

[runspired]

I've been considering various options to preserve that ability without compromising this path towards better performance and delegation.

We're already thinking of moving events to an explicit handlers hash (ala EventManager today) or of using compile time to separate out the handlers so we know what events we need to account for.

This case you mention is currently the blocker to this idea moving forward more quickly, we have to be sure people understand what the switch would mean, and the ramifications. Ideally, I think we need two escape hatches.

The first lets you preserve bubbling and would only be used when no other manner of using third party widgets with ember would work. This is likely to be a short lived escape valve, as it would lead to a divide in how ember works introducing inconsistent and possibly buggy behavior.

The second (and better) escape valve would be to build a way to discover and delegate events to third party widgets. I've got 3 approaches to that in my head right now ranging from an explicit mapping done by the Dev, to tools for swapping out the lib's event handlers, to an intrusive overwriting of jQuery.on and addEventListener to collect outside listeners into ember's eventing.

It will take an RFC and further discussion to determine the best approach to handle this.

[runspired]

I just wanted to point out that there are two other limitations of this example implementation that can be easily resolved.

• handlers that return false only in some conditions won't prevent bubbling on future calls if they returned true the first time.
• handlers that return false only in some conditions don't resume bubbling if they returned false the first time and true at a later point.

Both of these are very easy changes to make, but I wanted to point this current limitation out to anyone exploring this.

[sandstrom]

@runspired sounds good, it's apparent that you've thought these things through, which is great. I'm generally positive towards this idea, but still wanted to point out some things where this may cause trouble in our application.

I'm sure there are solutions to these (the ones you presented sound good to me). As long as these things are considered I'm happy 😄

[runspired]

Related RFC: emberjs/rfcs#86

[rwjblue]

Closing as this seems to have gone stale, I'm happy to reopen if you would like to pick this back up again.

[runspired]

@rwjblue yes, abandoned. Building this into a universal eventing solution seems better to me.