Enable global event dispatcher listeners to be lazily created.

[rwjblue]

Prior to this change, all events that would ever possibly be used would be eagerly setup by the event dispatcher's setup method. Unfortunately, this has (at least) two major downsides:

• As of Chrome 51, adding listeners for touch events (touchstart, touchmove, touchend, etc) without the passive flag issue a performance focused warning. See https://www.chromestatus.com/feature/5745543795965952 for more details.
• A number of the events that we have historically listened for fire massive numbers of events (mouseenter, mousemove, etc) and most applications do not really use these events.

The two primary entry points into using the event dispatcher are the action element modifier and Ember.Component's implementing the "event delegation" methods.

This commit enables the event listeners in the event dispatcher to be lazily setup on demand by updating the action modifier manager and the curly component manager to invoke the event dispatchers setupHandler method lazily when needed.

TODO:

• Fix issue with LinkComponent -- it uses evented interface to handle events instead of implementing a method.
• Performance test against a few "real" apps (ensuring that the extra work being done per-component is not resulting in worse overall initial render performance)
• Determine if we would like to have some events eagerly setup and others lazy

[simonihmig]

Love it!

[simonihmig]

The order of arguments has changed, and should be reflected in the DocBlock.

[simonihmig]

This change makes this method less "private" I think, at least "private" in the OOP-sense of being able to call it from outside (remains "private" in the semver-sense that it shouldn't be used in user-land). At least when @ember/jquery overrides the EventDispatcher with its jQuery-based implementation when Ember 4.0 will have dropped jQuery support, it has to properly support that method as it will be called from other places. Just to remind us of this... (see emberjs/ember-jquery#31)

[rwjblue]

Ya, unfortunately @private here is mostly serving as a marker for semver version of privateness. @ember/jquery is "first party" and will be supported regardless...

[simonihmig]

This also needs to be "semi-public", in terms of @ember/jquery, see the other comment...

[simonihmig]

Determine if we would like to have some events eagerly setup and others lazy

There will definitely be events like click that virtually no app ever will not use, but AFAICT the overhead of lazy setup seems to be pretty neglectable in this implementation here, as once the event handler is set up, any new component instantiation will skip it in the setup loop!?

I certainly hope nobody uses any wild pattern like this, setting up the event handler at runtime, which would stop working I guess:

export default Component.extend({
  // ...
  setupListeners() {
    this.mouseEnter = (e) => { this.doSomething() };
  }
});

While I can't remember this to be said explicitly somewhere, but I hope we can safely assume that event handler methods are supposed to live only on the prototype!? Or at least be present after instance creation (like an event handler created as a native class instance field).

[rwjblue]

once the event handler is set up, any new component instantiation will skip it in the setup loop!?

Yes, exactly!

I hope we can safely assume that event handler methods are supposed to live only on the prototype!? Or at least be present after instance creation

Yep, that is absolutely an assumption this PR is making.

[simonihmig]

This can be closed, as it is superseded by #19227!

[locks]

Closing as per previous comment!