Make states inherit views from their parent.

[groner]

In the substates example this would allow the crumbs view to be defined once with the specific bread crumbs for each state in a resolve clause for that state.

[jeme]

They already do, the crumb example is to show that child states can overwrite what their parent defines.

The difference is in what is called in the update chain... Whenever a state changes it determines from a top down what states are new states and what are the same states (with equal parameters)...

For equal states, the view service is notified to update a view only if it doesn't already exist, for changed or new states it gets notified to overwrite the view.

If you really wish to always update a single view, regardless of being changed or not, transitions + $view can be used... although I am looking for a way to make that simpler.

[groner]

So they do.

When I tested this with two states name root and root.home, root.home was not inheriting views from root.

It turns out root became root.root which was then a sibling of root.home instead of the parent. Should it be possible to change the root state?

[jeme]

There is an implicit 'root' state in the system. So it may be advice-able to avoid the use of that name.

For now there isn't any parameters associated with the root state, so there is nothing to change about it atm.

And well... maybe a clarification is needed, they don't copy down the views to the child objects, that would defeat the entire purpose, instead the "inheritance" happens in the way views are applied...

Demonstration: http://plnkr.co/edit/fiTy1GuEmAkmcGdPFIZi?p=preview

click around in about, and look in about.module.js

There is 2 concepts in play here... One is the general approach this is designed for, where we apply the "main" view is only 'updated' when we navigate from outside that tree of states (about, about.one, about.two)... So if we go directly from home to about.two it will apply the main view to 'about.html' as well as the template for the about view defined from about.two... but if we go from there to about.one, only the 'about' view is updated.

For view that should always be updated regardless, we have added the forced view, which we update through a transition, where we define that when we enter about.* we should apply that view...

[groner]

I can avoid prefixing states with the name root but I suspect others may trip over this.

Thanks for the example. I guess the distinction is that when ever about.one is active, about is also active and doesn't get updated unless a state redefines it or a transition forces it.

[jeme]

I know, but it had been a lower priority thing to fix...

However with https://github.com/dotJEM/angular-routing/commit/0d79373cbe81ab0e9b1a9fbf880f34fc1d3b3e8a the the internal root state is renamed to $root and acts as a reserved name... However since $ are not allowed in names in general then that should come natural... (internally we can bypass that)

Obviously it may raise an eyebrow when people see that their state they named root.home returns and claims it is $root.root.home but i think it will be easier to figure out at that point as the 2 names does not collide.

Obviously documentation is lacking in these parts.