Hello everyone:
I can’t understand why the two controllers are deprecated?
I’m looking forward to get some suggestions from you, guys!
Everything is moving to components. Do you have a specific issue you’re trying to resolve?
@varblob Thank you, there’s no issue. I only want to know the reasons about the deprecated.
I can’t find the inconvenience about the two controllers.
Check out the routeable components section. It’s not that the two controllers were confusing, it’s that controllers as a whole were not different enough from components to be worth keeping. Deprecating ObjectController and ArrayController was simply a transition step to getting rid of controllers entirely. Once you’re not using the proxying behavior of the controller types, it becomes much easier to eventually switch to routeable components. Check out this guide: https://gist.github.com/samselikoff/1d7300ce59d216fdaf97
@kylecoberly Thank you. The two articles are very helpful. I think I get many transition plans and updates of ember 2.0.
I have a question about routeable components.
If I want change a property of current component in current route, the way of ember 1.*:
// I want to change the blog description in post route (current route).
var appctrl = this.container.lookup('controller:application');
appctrl.set('title', 'renamedTitle');
what is the way of ember 2.*? There’s no controller and view, how can I access a property of a component’s instance.
The idea is that you can’t, and you shouldn’t.
The idea is that there are two “channels” for communication. Let’s say you have this hierarchy of components: A > B > C.
The first channel goes down the interface hierarchy and is built upon bindings: If some change in A needs to be reflected in B, you would bind an attribute in B to an attribute in A. This binding will become one-way by default, so a change in B won’t be reflected in A. If the change in A needs to be reflected in C, you will have to bind the property across two components.
The second channel goes up the interface hierarchy and uses actions: The idea is that you will not change parent properties directly (this would make maintenance more difficult and limit the reusability), but you will notify the parent of a change by sending an action. It’s then up to the parent to decide what to do with that message.
This is referred to as “data down, actions up”.
1 Like
@Fryie It’s amazing to heard this.
But if my page is like this:
----------------- A ------------------------
----- B ----- ------------- C --------------
A , B and C component are parallel relation.
In C component, how can I notify A to change it’s count property? It seems the sendAction not work here.
If the reason they need to communicate is because they share some common ancestor (like a parent UI element), your action will reach the ancestor route and can decide what to propagate down. It they share some common functionality (like a media player), that functionality can be wrapped in a service and communicated with via that.