Using an initializer customEvents can be added to an application

[pixelhandler]

Custom events should be first class citizens in an Ember app and in Ember Components that arrive to an app using an initializer (via an addon). Custom events work great and can provide a solid solution for communicating between DOM elements (components) in a scenario where the components have a common parent element and otherwise communication would be impossible.

See Rendered Markdown

• delay eagerly copying the customEvents property to the application instance
• set customEvents on the application after initializers are run

[stefanpenner]

Counter idea: what if custom events on components where auto registered on-demand?

[pixelhandler]

@stefanpenner yeah I'm content with any solution that make is possible for an addon to use custom events. Using an initializer worked prior to FastBoot then broke.

I think that idea is that custom events should be first class. With the current releases, since 1.10, custom events can only be setup when the application is extended or created. So, custom events in an addon are second class - the consuming app must register the custom events for the addon's custom events to work within the application.

Custom events are first class in browsers they should be in Ember apps and Ember CLI addons too.

[tomdale]

@stefanpenner I love this idea, but how do we determine which things are event names and which are just methods? In @pixelhandler's example, he's synthesizing fake events that aren't part of any web standard.

[stefanpenner]

@stefanpenner I love this idea, but how do we determine which things are event names and which are just methods?

maybe a decorator or a sibling to the actions hash called events.

All we need is a hint to the rendering system that a new event is required, its likely worth exploring some way to annotate this hint. This would also prevent all the speculative event listeners we have today, like mousemove etc.

[pixelhandler]

@tomdale I am talking about custom events not fake events, referring to https://dom.spec.whatwg.org/#interface-customevent and perhaps UI Events (to replace the CustomEvent constructor) http://www.w3.org/TR/DOM-Level-3-Events/ Also, JQuery has normalized the use of custom events for years - http://learn.jquery.com/events/introduction-to-custom-events/

[pixelhandler]

@stefanpenner I don't like the counter idea with auto-register or on-demand. Perhaps that would be good of for a separate RFC. Since the custom events are now registered using the Ember.create/extend it would be create do augment the customEvents property of the application and after augmenting during initialization the custom events will be registered. In addition if in the future there is a way to set customEvents on a component and have those just work, that would be a great alternative to using an initializer.

[runspired]

Tangentially related via general improvements to the event layer: http://jsperf.com/event-delegation-with-capture-vs-bubble

[tomdale]

@pixelhandler

Also, JQuery has normalized the use of custom events for years - http://learn.jquery.com/events/introduction-to-custom-events/

I think you think I was using the term "fake events" in the pejorative, which is not the case. I am onboard with people generating custom events.

All we need is a hint to the rendering system that a new event is required, its likely worth exploring some way to annotate this hint. This would also prevent all the speculative event listeners we have today, like mousemove etc.

👍, it would not be too hard to determine the subset of events actually used at render time and only set up event listeners for those. Trickiest part is the API most likely and making sure it doesn't impact render performance. Maybe we should wait until annotations are first class to design the API.

[rwjblue]

The fact that this was broken was a bug in Ember that was fixed by emberjs/ember.js#12056 and is included in 1.13.9+.

Closing...