`default` parameter doesn't work as advertised
Closed this issue · 5 comments
The documentation http://angular-route-segment.com/ says:
default is a boolean value which can be set to true if this child segment should be loaded by default
when no child is specified in the route.
However, this doesn't seem to work in my setup:
$routeSegmentProvider
.when('/articles', 'article')
.when('/articles/new', 'article-new')
.when('/articles/:id', 'article.info')
.when('/articles/:id/text', 'article.text')
.when('/articles/:id/annotations', 'article.annotations')
.when('/articles/:id/settings', 'article.settings')
.segment('article-new', {
templateUrl: 'templates/article-new.html'
})
.segment('article', {
templateUrl: 'templates/article.html'
})
.within()
.segment('text', {
default: true,
templateUrl: 'templates/text.html',
dependencies: ['id']
},
})
.segment('annotations', {
templateUrl: 'templates/discussions-list.html',
dependencies: ['id']
})
;
$routeProvider.otherwise({redirectTo: '/articles/0af5e13'});
}
]);
};
Instead of loading the 'text'
route on /articles/:id
, nothing is loaded into the respective view. Everything works as expected for /articles/:id/text
.
Come to think of it, I'm wondering if not the parent route would be a better place for specifying which child is the default. Otherwise, it's easy to create ambiguous situations with more than one default: true
, for example.
@nschloe Was this indeed a bug? I'm evaluating this as a ui-router replacement and how quickly bugs get fixed is important.
default
also breaks IE, since that is a JS reserved word. See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/switch
@artch I upgraded and couldn't reproduce this anymore, so feel free to close as you see fit.
Apart from that, it'd probably still be cleaner not to set the default
in the child, but in the parent. This avoids ambiguity when two default
s are specified (which is possible right now).
Specifiying default
in children is handy in cases when you have separated modules with their routes definition, and you don't want to make parent modules know about their children. This "bottom-up" knowledge architecture is more flexible than "top-down".