[next] Different behaviour for default subRoute when using path vs. named route

[jwahdatehagh]

I have a nested routes with a default component:

routes: [
  { 
    path: '/home', 
    name: 'home',
    component: Home,
    children: [
      {
        path: '',
        name: 'home.index',
        component: HomeIndex
      }
    ]
  }
]

I'd expect for HomeIndex to be rendered into Home's <router-view> when i enter Home, but when i navigate to it using :to="{ name: 'home' }", only Home is rendered.

Using to="/home" directly works as expected.

Vue.js & vue-router.js version

2.0.0-rc.4, 2.0.0-rc.4

Reproduction Link

https://jsfiddle.net/jwahdatehagh/rdtgfrfb/

[LinusBorg]

This is expected behaviour and intentional. If you want to render the default path via name, you have to use it's name, not the parent name.

[jwahdatehagh]

Ok, thank you!

Can you explain the reasoning behind that? I think the uri should represent the state of the app. If :to="{ name: 'home' }" and to="/home" link to the same uri, why should the rendered state be different?

[LinusBorg]

I think the uri should represent the state of the app.

You're right about that, we should discuss this.

It's a bit related to your other ticket, #628 also I think - there it's about the question that /home and /home/ should both be matched as active even with exact.

@fnlctrl ping

[LinusBorg]

When using a named route-link, the route record is fetched by that name from a nameMap object.

https://github.com/vuejs/vue-router/blob/next/src/create-matcher.js#L33

When we use a path, the matched route is retrieved from a pathMap object. Here we get the defautl child route.

https://github.com/vuejs/vue-router/blob/next/src/create-matcher.js#L33

That's why it works differently I think.

Maybe the solution is as easy as this:

After getting the record by name, get the record again from the pathMap using ? record.path + '/', which should return the record for the default child route if there is one, and if there is none, it should return the same route object again.

[frankdugan3]

I just ran into this today. I agree that it is pretty unintuitive to have the named route-link resolve differently than the path when a default child route is defined. @LinusBorg your solution seems like it would produce intuitive results.

[LinusBorg]

after some discussion we will solve this with a warning: When the dev uses a named route that has a default child route, there will be a warning in the console.

Reasoning:

• If we don't change the current behaviour, there can be different behaviour between navigating to a URL from a named link, and visiting the same URL by typing it in the browser, as demonstrated by OP.
• But if we matched the parent route to the child default route, this may be unexpected for the developer because he expected to get the parent route object after transition, not the child route. So this would solve the issue for end users, but may introduce problems for the dev.
• Therefore, we want to discourage using the parent named route in these cases altogether. We will show a warning encouraging the dev to use the default child's named route instead.

We will reference the commit here when it's done.

[LinusBorg]

PR provided with #641 - currently in review.

[inca]

I'm not sure that refraining from using links to parent is the right thing to do.

Say I have item.view and its default child item.summary (among other children). I normally specify :to="{ name: 'item.view' }" in the link because I want it to stay active for all children subroutes. Basically, if child link is used, then we loose active link highlighting there (and it kinda sucks since there's params involved, too).

[jwahdatehagh]

Oh lol @inca so true...