Default <ui-view /> for abstract states without template?

[vegardlarsen]

Would it make sense to implement a default template containing a single <ui-view /> for abstract states? Consider the following setup:

$stateProvider
    .state("sub", { url: '/sub', abstract: true, template: '<ui-view />' })
    .state("sub.home", { url: '', templateUrl: 'subHome.html' })
    .state("sub.details", { url: '/:id', templateUrl: 'subDetails.html'})

It would allow you to drop the template on the abstract state, something which tripped me up for a while trying to create a hierarchy just like this.

[timkindberg]

After thinking on this a bit, it seems a little too magical to me. Nested states and abstract states are confusing for new users enough as it is. I don't think we want to secretly add templates with the potential of them not understanding. I think declaring it makes it very clear and is a good thing. If @nateabele or @ksperling disagree, they can reopen. Thanks though for contributing your thoughts!

[nateabele]

Agreed. This is one of the last parts I would make less explicit. That having been said, I have an idea for a decorator API that would allow people to define these sorts of rules themselves.

[vegardlarsen]

As a beginner to Angular and ui-router, it was quite confusing to me that it simply did not display anything when I omitted the template, nor did any sort of error message appear. Are there any cases where one would want a state without any template?

[nateabele]

There are some. Check the FAQ. However, trying to correctly match up states, especially nested states, to their proper <ui-view>s can be a bit confusing, even for non-novice users.

Therefore, since I'm working on extracting view-loading out into a service anyway, I plan on seeing what I can do about ways to inform the user when things don't match up.

[timkindberg]

Hmmm so you can't have an abstract state that doesn't have a template? Ok maybe this is something we should look at. Here's a plunkr: http://plnkr.co/edit/30U36Y?p=preview

I could have sworn that you could use a parent abstract state, to simply prepend a url partial to its child states. I even wrote it up in the Wiki that way. https://github.com/angular-ui/ui-router/wiki/Nested-States-%26-Nested-Views#abstract-states

@ksperling and @nateabele, I'll need you guys to review that wiki section again for me and tell me what things I may have incorrect. I had always thoughts that if you didn't specify a template for a parent state, then the child would use the first ancestor with a template. Perhaps that's what we should do, just keep going up the state tree until a valid ui-view is found.

[jeme]

@timkindberg well technically you can: http://plnkr.co/edit/UN78x9

But you need to use absolute view targeting...

[marklagendijk]

As a new user I also ran into this problem. I didn't solve it until I found this issue.
To me it would make most sense if it would work like @timkindberg described:

• if the parent has an template, use the ui-view in that template.
• if the parent doesn't have an template, try the grandparent (etc, up to the root).
• if an ancestor has a template without the required ui-view (no ui-view or not the needed named ui-view), throw an exception.

Btw, I really love this project! It's good to see that is is dynamic enough to allow for all possible situations, which I can think of :).

[martijndwars]

I've spent last hour on figuring out why my nested state did not display anything. I'd love to see the behavior described by marklagendijk implemented.

If you guys decide not to change the behavior because it makes things too magical, then I suggest updating the wiki. The example about To prepend url to child state urls is at least to say misleading since the contacts state (abstract) lacks a template. (As timkindberg already mentioned)

[timkindberg]

@martijndwars I modified the guide. Sorry about that.

[timkindberg]

To clarify, the feature being requested here is:

A child state should populate its parent's ui-view, but if the parent doesn't have one then it should continue to search up the state tree until an ancestor with a ui-view is found and populate that ui-view.

While this seems nice it also could lead to confusion when looking at another developer's states. So I think its safer to just explicitly target the ancestor ui-view with the views property, like @jeme pointed out. So let's close this and see if it continues to crop up.

[ksperling]

@timkindberg yeah I was considering this feature before, primarily based on the reasoning that inserting an abstract state that doesn't do anything to any views should keep any child states working as they are (same as inserting an empty class into an inheritance hierarchy in an OO language).

[marklagendijk]

I think the most important point is that exceptions (with descriptive messages) should be thrown if a child has an view defined, but its parent doesn't have an ui-view in its view.
Apart from that it doesn't make much difference.