Abstract States, Non-Abstract Parent States and Default Child States

[timkindberg]

I know we went back and forth on this several times already, but I think I may have found a need for this feature again.

It seems as though we are trying to get to a place where states can function completely on their own without any url routing (correct?). So how would we know which child state to load automatically without specifying a url of ''? Seems like we would need a default boolean property or something similar.

Let me also attempt to define abstract states, and non-abstract parent states. Please let me know if I'm on the right track.

Abstract State

• must be a parent state
• a state that cannot be activated directly (via transitionTo method) without activating one of its children.
• must have a default child state (either with empty url or default property)
• if no default child state is set, first child state found will be used as default
• can be navigated to via url, but this really just activates default child state

Non-Abstract Parent State

• a normal state which has child states
• can be activated and navigated to directly (via transitionTo method or url), though any view directives will not be populated until navigation to on of it's child state OR one of its child states is set as default child (either with empty url or default property)
• default child state is optional

[ksperling]

Yes, that's essentially whats currently implemented, minus the idea of a "default child".

In the sample, 'contacts' is abstract, so $state.transitionTo('contacts', ...) simply throws an exception. To go to 'contacts.list' via code you just $state.transitionTo('contacts.list', ...).

It is tempting to call 'contacts.list' the "default child" of 'contacts', because it uses URL '', however another way of looking at it (and this is how the current implementation treats it), is that there is no requirement for the URL of a child state to begin with the URL of it's parent state, and all state URLs are completely independent, "absolute" URLs (that get added to $urlRouterProvider).

The ability to define state.url relative to the parent state's URL is simply a convenience provided by $stateProvider.state(), because it's very common thing to do (and there is an 'escape' mechanism of prefixing the URL with '^' to tell $sP.state() to treat it as absolute).

In the sample app, it would be completely possible to change the URL of contacts.list to '^/list' (i.e. the absolute path '/list'), or to completely remove the URL from the 'contacts' state and instead copy&paste the '/contacts/' prefix into all it's child states URLs. Would you still call contacts.list the default child of contacts in that case?

[timkindberg]

Well I do see your point, I guess I just thought if someone can theoretically set a default child via an empty URL then they may also want the same ability when not using urls. I see how it's not as big of a deal as I initially imagined though so I'd say this is more a feature request now than an emergency. Will put in v.2.

[nabeelio]

I'd like to have abstract child states - basically for having a different "layout" that would be used. For example, a layout that is the default one, .state('default'); .state('default.contacts') .state('default.contacts.list') and then a .state('compact') .state('compact.contacts') .state('compact.contacts.list')

Where "default" and "compact" are different layouts - the reason for me being that there might be two different views for a child layout - ie; one inside of the main layout, and then the same one in a popout window, looking a bit different, but the same view being used. But in my case, the two views are nearly the same, just with some elements "turned off".

Right now I've done thing by splitting a lot of stuff, but the base templates for each controller violate DRY, and one change in one template piece that's shared will have to be changed across multiple files. I'm struggling to find a more efficient way to do this. I'm thinking of nested views, but having trouble conceptualizing on how I would organize it, maybe that's the way to go.

[nabeelio]

Nevermind, after reading about it some more, I think nested views are what I need to go. Just have to figure out the best way to organize it all. Maybe a ui-view for the body, and just sub-views inside of that view to put it all together.

[jeme]

After going over this again and again, I am wondering, what exactly is the use-case for "abstract states"?...

Taken the example, why not just do all the necessary stuff on .state('contacts') for the url /contacts, e.g. defining all views. instead of having the contacts.list state?...

[ksperling]

@nshahzad if you want to have the ability to switch between "compatible" layouts for the state, you could make 'template' or 'templateUrl' a function that switches between those layouts at runtime based on a user setting or a state parameter (the $stateParams object gets passed to the template or templateUrl function). This is probably easier than duplicating all your states.

[kmalin]

@ksperling : "The ability to define state.url relative to the parent state's URL is simply a convenience provided by $stateProvider.state(), because it's very common thing to do (and there is an 'escape' mechanism of prefixing the URL with '^' to tell $sP.state() to treat it as absolute)."

This feature (absolute paths when starting with '^' symbol) is very useful (at least in my project). I was thinking that it was the default behavior, but it seems like it's not. I was looking for it in the documentation, but couldn't find it there. But luckily I was able to find this thread. It would be nice if wiki would be updated. In fact, I will try to do it myself if no one minds.

[timkindberg]

@kmalin I see that you modified the wiki. Thanks!

[timkindberg]

@jeme & @ksperling I'd like to talk more about abstract states as well. I'm not sure they are a user-friendly aspect of ui-router. I brought it up multiple times early on and @ksperling felt strongly about them and I've gone back and forth on how I feel. I've seen new users use them incorrectly and also be very confused about them. I'm getting the notion that we need to look at this feature more deeply.

What is its exact purpose that makes it unique and needed in ui-router? What problem is it solving??
Are there other ways to do the achieve the same outcome that an abstract state provides?
Is there a more layman term and solution?
How would a new person perceive an abstract state? How would they better understand what its for?

[nateabele]

AFAIK they are used to DRY state definitions, when multiple states share things in common (like abstract classes in OO programming). Maybe you can think of a good way to approach this from the docs?

[ksperling]

Maybe I find them intuitive because I think of states as being in some sense quite similar to classes in an OO language (I mostly do Java by day...)

@nateabele is right, they factor out commonalities.

As an example, say your app had 'clients' and a 'suppliers' parts with different top level nav. You could define an abstract 'clients' state with a template like this: <!-- client top level nav ... -> <div ui-view></div>, and each of the child states then put something meaningful into that ui-view. But the 'clients' state itself is abstract because the user would see a nav-bar only, with nothing in the ui-view.

Now you might say that you should put whatever the default child does into that abstract parent state and make it non-abstract, but that's not a good idea for two reasons:

• it makes it hard to change your mind about which child is the default, because the parent has subsumed the default child
• any other children suddenly inherit 'resolve' items from the default "child", and the enter/exit lifecycle differs etc...

I think the confusion comes from people thinking about the structure of their app too much in terms of URLs, and from the idea that if a URL like "/foo" maps to state FOO, and "/foo/bar" maps to state BAR, then BAR must be a child of FOO. It's as if each additional "/" means one more nesting level in the state tree. This is not the case!

Going with the sample app contacts.details and contacts.list states again, what's going on would probably be easier to understand if the URLs of those two pages were "/contacts/list" and "/contacts/details", and "/contacts" would be an invalid URL. But people (reasonably, given how things traditionally work on the web) expect /contacts to be the URL for the default child. If you were writing static HTML pages, you might have two files, "/contacts/index.html" and "/contacts/details.html". Note that they're both inside the "/contacts/" directory, index.html is on the same nesting level as any other child of contacts, the web server just happens to let you use a shorter URL to access it, so really it's not much of a 'default', it just happens to have a shorter URL.

[jeme]

@ksperling your example of "/contacts/index.html" and "/contacts/details.html" falls into the old days of the web, and people rarely use such structure in my experience any more... instead they would have "/contacts" and "/contacts/details", which would have to map to "/contacts/index.html" and "/contacts/details/index.html" in the traditional days...

Today we can decouple the URL from where the resource is actually located, it may not even be a file anywhere.

The thing is, "Abstract" doesn't really serve the explanation you put forth, that's the ability to define a default child that does that. All Abstract really does is to deny you the ability to go to that state...

And it's funny we keep saying "default child"... In my mind... there is no default child... there is a number of states and then there is the routes that map to them... so the actual mapping is just:

'/foo' = goto 'foo.default'
'/foo/bar' = goto 'foo.bar'
'/foo/baz' = goto 'foo.baz'

There is no url/routes that goes to foo.

And so I think we should turn the thing up side down when we explain it, and focus on what that "default" child does, and forget about "abstract" all together.

Abstract could go into it's own explanation on how to deny you the ability to activate a particular state. I think we will find that then, no one really ends up using abstract. (unless the state machine only understands a child route of `` if the parent is abstract, in which case this whole post is sort of invalid)

[ksperling]

@jeme I agree that there is fundamentally no default child -- but I think some of the confusion people have with designing their state hierarchies come from assuming that there is... seems like my web 1.0 analogy isn't a good explanation either.

You don't HAVE to use abstract, but it lets you do two convenient things:

• it lets you define a common URL prefix that the child states can inherit (if they use relative URLs) without having the presence of the URL causing a route to that state from being created
• it explicitly prevents you from accidentally transitioning into a state that's not meant to work by itself. As a feature t's on the same level as marking something as "const" in C or "final" or "abstract" in Java -- some people prefer to type less and do these things by convention, other people prefer to make these things explicit and have the tool/framework catch the issue early.

Given the miniscule amount of code the implementation of this feature takes up, I think it's worthwhile to have it. I don't think it's a very important feature for beginner / getting started docs.

If you have a child route of '', the child and the parent will end up with the same route, so you'll only ever hit the parent state unless you transition via code (because the parent route gets added first and routes are evaluated in order).

[nateabele]

Yeah, that's a good idea. Maybe just omit abstract states from the docs for beginners, and save it for a section with more advanced concepts (of which I'm sure there will be several).

[jeme]

If you have a child route of '', the child and the parent will end up with the same route, so you'll only ever hit the parent state unless you transition via code (because the parent route gets added first and routes are evaluated in order).

Hmmm.... So...

provider
  .route('/home', goto fubar)
  .route('/home', goto home);

Would go to Fubar i hear, that is opposite than what I do... for Angular-routing it would go to home...
That is why I ultimately only saw abstract as a way to block a state from being a target... and therefore less important. Which means that your (1) can be achieved without an abstract concept.