Thought I’d share my blog posthere for anyone else has dealt with the same problem.
I just started a two new Ember apps and I noticed a common pattern emerge. When I nest routes, the parent route has values that need to stay in sync with the current subroute. For instance, I often show a list view, with a detail view and the ability to edit and perform other actions on the detail view. If I have buttons in the parent template whose values and actions should change when the subroute changes, I found my routeVal computed property to save me from writing a ton of extra code. Old approaches involved transitioning manually via actions that ensured the state of these route-dependent values (but that assumes a certain order of navigation to a degree) or accessing the parent route’s controller inside the subroute’s setupController hooks and setting these values. I much prefer to have the values defined in one spot and on the controller the appropriate controller
This seems like a lot of extra work…
You blog post talks about keeping state of buttons and calling actions on the parent route - could you do what you’ve trying to do with the buttons in the child route/template? That would save a lot of this work…
I can’t see many cases (if any) where I would want a parent route to keep state for child routes… You could use components or partials or something if you didn’t want to replicate template logic
You can, but then I’d be duplicating my common html in each of the templates and anytime I change one file i’d need to change them all which is unnecessary code duplication. Even with partials, I need a copy of all the same variables used in the partials into each subroute which seems like an anti pattern to me.
Plus, I am using liquid outlets for transitions and I only want the stuff in the outlets to animate, not the whole page. From the perspective of the UI, the outer template remains visually unchanged minus hiding or showing of buttons and or changing of text. When I first started using Ember, I made a wizard using the exact approach you are talking about and I found it to be a lot more work. More typing, more duplication, much more difficult maintenance. New requirements came down and I had to go to each page and change a bunch of common code that really should have only been defined in one place.
The “extra work” only happens once when I decided to implement this solution and took me maybe 15 minutes to do. Now its arguably quicker than per route approach and certainly more DRY. Obviously there’s more than one way to skin a cat but I found this one to be the easiest and most maintainable.
Also, @jmurphyau looking at this question 