Hi all,
I like to use components very much. But normally it is not possible to can communicate between 2 or more components.
For example what I imagine
If you have a typicle IDE there are often a property window where you can edit properties of a selected element or selected elements. By changing a value whtin the property window I like to update the selected component/element. The other side is … If I select a component the property window should display the properties of the selected element/component.
Is there a possibillity to use events within my ember application?
Computed properties are very usefull but If I have a deep structure of components, the related variables or properties are not ever available in my target components.
I think here events would be very better or not?
Can you giv me a tipp what could be a good or the best procedure?
Best regards,
Mario
Hi @GELight, in our app we have something kinda similar to what you describe in your IDE example. We’ve got a sidebar with several sub-components on the right side of the app, rendered in the application template, which will display an “item” when you click on an “item” anywhere else in the app. The way we do it is if you click on an “item” in one of our tables, or drag-drop one from the table to the sidebar, we fire an action out of the table components, etc. called something like “addToSidebar”. That action takes an “item” model and bubbles up to the application controller where we add that item model to the sidebar component as the “current item”. This has worked fairly well for us.
However if you are trying to bubble a click action from a deeply nested component all the way up to the root level component and then out to the application controller, and you’re running into issues with lots of nested actions or too much bubbling, the service route would probably make more sense. Then the component could inject the service, set a property on it, and then the sidebar could also inject the service and observe the “current thing”.
I’m no guru but I’d say either approach would work well and be fairly Ember-approved, just depends on how you’d prefer to think about it, or maybe your use case. Services generally represent application-level state and a details window like you described sounds like it would be application-level or near-application-level state, so i think it’s a good fit for a service if you decide to go that route.
Hey dknutson,
Very thanks for your long detailed answer.
To use a service it’s an idea but what speaks against this?
I could imagine me that the work with events are the future also in ember because events are a typical standard in much other dev. languages … isn’t it? 
Mario
Oh THOSE events. My bad
I know those are used pretty heavily in the internals of Ember, and it sounds like you can use them arbitrarily like you were describing too. That said, I haven’t run across much usage of them outside of the internal Ember events, so you may be sailing into uncharted territory. I wish I could tell you more but I’m not really knowledgeable about using eventable outside the framework itself.
I’ve used the global event bus service strategy before, to send events between components on disparate parts of the page: http://www.thesoftwaresimpleton.com/blog/2015/04/27/event-bus/