Proposal for nested states

[marklagendijk]

Relates to #346 and #368.

Currently there are 4 ways of defining states:

1. Using 'dot' notation. For example name: 'contacts.list'
2. Use my ui-router.stateHelper to build states from a nested state tree.
3. Using the parent property with the parent name as string. For example: parent: 'contacts'
4. Using the parent property with the parent object. For example parent: contacts (where 'contacts' is an stateObject)

My proposal is to make the logic of stateHelper a part of ui-router itself, and make sure that all ways of defining nested states give a consistent result:

• A states name is always its full name. This means that it contains the full path of it parents in dot separated form. For example: 'root.contacts.list'.
• Each (non root level) state gets parent property. This parent property contains the state object of its parent.
• Each state which has descendent state gets a children property. This property contains all the child states of the state.

This way the different ways of declaring nested states always produce a consistent result. I think this consistency is very important.
We should also consider whether it would still make sense to support al 4 ways. In my opinion way 3 and 4 wouldn't add anything when 1 and 2 are already supported in the way I described above.

@nateabele, @timkindberg, I would like your opinion about this. I would be willing to implement this functionality, including tests.

[nateabele]

Really appreciate your work on this, and your being persistent in working on getting it resolved. A few thoughts in response:

A states name is always its full name. This means that it contains the full path of it parents in dot separated form. For example: 'root.contacts.list'.

Internally, yes. This shouldn't break the way people are currently defining states. Also, anywhere that a fully-qualified state name is required, (i.e. $state.includes()), those APIs should allow state definition objects to be interchangeable with string names.

This is important (a) because of the ability to move sub-trees around, and (b) to also have sub-trees that can be attached at multiple points on the main tree, which are both features that are frequently requested and are being planned for the future.

I assume you already agree with this, I just want to be clear.

Each state which has descendent state gets a children property. This property contains all the child states of the state.

This should only be direct descendants. Otherwise, traversing the state tree will be needlessly complicated. If there needs to be an easy way to retrieve all descendants, we can have a getter method.

We should also consider whether it would still make sense to support al 4 ways. In my opinion way 3 and 4 wouldn't add anything when 1 and 2 are already supported in the way I described above.

I think keeping all 4 ways does make sense, in light of the planned features mentioned above.

I would be willing to implement this functionality, including tests.

Sweet, sounds good to me.

[timkindberg]

Rock on, love it! I look forward to seeing the implementation.

[timkindberg]

Any news on this?

[marklagendijk]

@timkindberg unfortunately not. It might be a few weeks before I have the time for this.
I am still willing to do this, but if someone else wants to do it, and has time now, I won't mind.

[nateabele]

@marklagendijk No worries, take your time, and thanks for your thoughts so far. We have plenty of other things to focus on in the meantime.

[jelling]

What's the latest thinking on this? I ran into some issues today and have had various issues over the years with nested states being tricky to define. Could be wrong but felt like there were extra wrinkles with lazy-loading, too.

[stale]

This issue has been automatically marked as stale because it has not had
recent activity. It will be closed if no further activity occurs.

This does not mean that the issue is invalid. Valid issues
may be reopened.

Thank you for your contributions.