Error transitioning to an abstract route with an index route

[blikblum]

I had initially the following route structure where routeClass or routeView is the route handler:

  route('application', {path: '/', routeClass: ApplicationRoute}, function () {
    route('contacts', {routeClass: ContactsRoute}, function () {
      route('contactdetail', {path: ':contactid', routeClass: ContactDetailRoute})
    })
  })
});

When a transition matches application i'm redirecting to contacts

  if (transition.path === '/') {
    transition.redirectTo('contacts')
  }

Then i needed to render an empty view when no contact is selected so i changed 'contacts' route to abstract and created a child index route ('contactnoselection'):

router.map(function (route) {
  route('application', {path: '/', routeClass: ApplicationRoute}, function () {
    route('contacts', {routeClass: ContactsRoute, abstract: true}, function () {
      route('contactnoselection', {path: '', viewClass: ContactNoSelectionView})
      route('contactdetail', {path: ':contactid', routeClass: ContactDetailRoute})
    })
  })
});

If i enter the URL with #contacts hash, it works but it fails when redirecting to 'contacts' route with "No route is named contacts" message.

While i could change the redirect to 'contactnoselection' route, this is far from ideal. If eventually i change the 'contacts' index route or decide to revert back to not using index route, i will need to update the redirectTo call again.

Posting here, to know if there are other alternatives and if is doable to allow transition to an abstract route with an index route

[blikblum]

After thinking more, and looking how eventually a solution could be implemented in cherrytree, i realized that such change is not worth the extra code and the potential confusion that creates.

I ended renaming contactnoselection to contacts.default and redirecting to it instead of contacts

[blikblum]

In a third though, after i stumbled in another issue that cannot resolved with the current features, i reconsidered my position and realized that is worth the extra code

PR #161 fixes it

[blikblum]

Fixed in 2.4.1