FastBoot changes seem to break setting Application#customEvents within initializer

[machty]

In 1.11 I can no longer set application.customEvents within an initializer because the application instance passed to an initializer is different from whatever this is in this line of code:

https://github.com/emberjs/ember.js/blob/master/packages/ember-application/lib/system/application-instance.js#L179

[tomdale]

Looks like we're eagerly copying these properties over to the instance before initializers are run (https://github.com/emberjs/ember.js/blob/master/packages/ember-application/lib/system/application.js#L325-L326). Should be easy enough to set them after initializers are run and everything should continue to work.

[runspired]

• bumping this to my participating feed

[pixelhandler]

@runspired this is the issue related to our discussion on last Friday. For example. I have an addon that has an initializer that sets a few customEvents on the application.customEvents hash. In the past the custom events were registered just fine. I'm not sure which release broke that behavior of using an initializer to add custom events from an addon.

@machty @tomdale is this something I can help with?

[pixelhandler]

@machty @tomdale @runspired So here is where I think the advantage is for using customEvents that are added by an initializer…

• An addon that defines customEvents to be used by an app, e.g. new events such as gestures or other mobile events, perhaps a fastClick event would be an example that someone may want to addon.
• Communication between DOM elements, which happen to be Ember Components. Actions may not work in some cases. There are use cases where it's nearly impossible to wire the targetObject to a component that is nested below a chuck of DOM, perhaps DOM elements that were added via rendering an outlet (new context).

For the ember-off-canvas-components addon I chose to use custom events and used an initializer to add them to application.customEvents. The example app for the addon has an outer viewport component that listens for custom events and toggles a property to open/shut an off-canvas component. The on-canvas and off-canvas components may have an outlet inside. Perhaps in a template that is rendered to the outlet, an off-canvas-closer or an off-canvas-opener component lives in that template. It's scope is the controller for the template, or whatever the new thing will be - a component for that template. Since the nesting is so flexible, all that needs to happen is that the outer viewport listens for specific custom events, e.g. toggleOffCanvas and does it's work.

Now that the initializer does NOT successfully setup the customEvents has on the application this addon is dead in the water.

I've tried doing some finagling with wiring the targetObject but that is a lot of ceremony; or perhaps in some cases impossible. So, for the ember-off-canvas-components addon, the contextual solution is loose communication between components using custom (DOM) events, not actions. (This may not sound as favorable as all the hotness of "bindings down actions up" sounds.

In my opinion, custom events should still be first class citizens in an ember app and in ember components that arrive in an app via an addon (using an initializer of course, not some crazy re-opening of a private object/factory). Of course, custom events, were the hotness prior to "bindings down and actions up" (well prior to Ember.js); and they still work great and can provide a solid solution for communicating between DOM elements (components) where the components have a common parent element (component).

[tomdale]

@pixelhandler I agree with you that addons should be able to register custom events. Right now, the API wasn't really designed to handle that use case (it's designed for apps to specify the set of events they want, not addons). I would be very open to a PR/RFC that added public API for addons to register events that the Event Dispatcher can listen to.

[pixelhandler]

@tomdale ok great. I'll work on an RFC and followup with a PR if I can pull it off.

[pixelhandler]

@machty @tomdale I created an RFC - emberjs/rfcs#69