Extensive use of Ember.Evented as a pattern


Hi, is my first post to this forum. I am into my 4th Ember project and have found myself extensively using Ember.Evented mixin to communicate between targetObject and parentView. One example is in a recent application I have a {{alert-box}} component that I use as a generic alert box to show failed form validation messages. In a single form I could have up to 10 - 12 of these.

I find this pattern really flexible for me as I dont have to write too much code to find child components to exchange any messages. What I am not sure about does that have any performance side effects? I am not seeing much of this but I have a really powerful machine :smile: If it doesn’t cause much overhead why is Ember.Evented not mixed in by default?

Thanks Charlie


Why aren’t you using actions for this? Actions are custom events that bubble. I also have a custom alert box (actually a confirmation dialog). I trigger it by sending an action and handling that action in the application route (actions bubble if not handled from controller to route and then up the route tree). That then sets the content on the controller for the dialog and it is rigged up to appear when there is content on the controller. This promotes loose coupling as the sender doesn’t need to know anything about the handler.

The target for a view is by default the controller, so if you want to target the parent view you would need to set that explicitly on the view.


Thanks for this! I see that the action can be useful when you only need to communicate with 1 instance of the component in a particular view? In my case I have 12 instance of the {{alert-box}} and depending which validation fail 1 or more of these alert box appear. I can’t for the life of me see how using action here without me having to see which instance of the alert-box is the correct one (if you have some code?).

What I have also found recently is the on event listener doesn’t get switch off property and often see error saying I have am trying to set on destroy object. This happens more often if you are re-rendering views, so in my components now I override willClearRender and switch off the events.