Hello 
I’m trying to wrap my head about Routes & Controllers. From the documentation (v3.24) I get that each Route has a default Controller. Also, if I want a custom Controller it should be named the same as its corresponding route. Totally get that.
However, I have routes that ‘stack’ (my term). An obfuscated example:
"homes.edit" => /homes/:house_id
"homes.edit.kitchen" => /homes/:house_id/kitchen
If I have a HomesEditController and a HomesEditKitchenController would properties and actions in HomesEditController be available/accessible in HomesEditKitchenController? Would/could actions bubble up from HomesEditKitchenController to HomesEditController?
Or is better for me to NOT think of Controllers & Routes as being hierarchical?
Thank you for your time.
The short answer is I think you should think of routes as hierarchical but mostly in the context of rendering, not so much state and actions.
The Ember Router is in kind of a weird spot as it’s one of the biggest legacy pieces of Ember that has remained largely intact and is probably due for a bit of rethinking. I don’t think there’s a lot of clarity around some of these APIs you’re asking about. There have been proposals where you could reach up to parent routes and grab their models from the router service, etc (at least I’m pretty sure I’ve seen that sort of thing) in a controller or component. You can already do that within another route with this.modelFor('<parent route name>').
You can inject controllers into each other and you can specify controller and route actions that bubble up the hierarchy:
If the context of a template is a controller, actions used this way will bubble to routes when the controller does not implement the specified action. Once an action hits a route, it will bubble through the route hierarchy.
but you must use the {{action}} helper to do this so I wouldn’t really recommend relying on this much.
So… in summary I think it’s very good to think of routes hierarchically especially in the context of rendering and UI, and using modelFor is very common and totally fair game. I personally wouldn’t recommend using controller injection or action bubbling because those seem like things that are due for deprecation and removal much sooner, but that said it might be the best way in some cases, so up to you.
2 Likes
Thank you for the perspective. As usual your reply is insightful and educational.
I should have mentioned we’re heavily invested in components and, therefore, our templates are essentially a pass-thru for the components. I imagine this complicates the passing of controller state and actions a little bit.
Thank you, again.
Yeah that’s basically how I treat them. I think of controllers as basically just managing query param state for its route. Services can usually be used in any of the cases where you’d need action bubbling or other state sharing, and modelFor will give you the model for parent routes (which is pretty useful). So between all those things I don’t think controller injection or action bubbling is really necessary.
Think of Routes kinda like directories/pages you go to access a set of information related say to a component or resource. Like /home Or Default route: / The page you visit first and /: is for dynamic routes. Say we had a products page ‘/products’ Where will have a list of products and when a user clicks on one the products, will have to access the data-set of that product using it’s say identifier/id field. Since the structure of the products is usually similar say the following fields; Product. name/title, price, description, trader. You design a template that will display the image and the rest of the fields and for that reason you could access the template page using /products/:id. The : signifies dynamic route both for front n back-end frame’s/frameworks
Ember’s routing system is one the best and most mature though similar to other frame’s.
State is the values of the fields described above you could have in your route config file with the model. Usually the controller is used to say manipulate/format data to keep the routes clean.
And the concept of nested routes for example with products, you could configure different routes for /products and /products/:id Or you could nest :id route under the /product and will have shared state.
Hope this makes sense!!
And you have to read the documentation again!! Ember is a mature framework would be nice to study about other frameworks so you gain a better context
1 Like
There is always better help @ the discord channel
Thank for your reply @anyuruf 
I’ve requested assistance on Discord before. However, for this situation, I didn’t need Discord’s immediacy. Plus, I find Discord can be a bit too chaotic for me. However, it is fine a resource.
2 Likes