Active class not always applied correctly when having subroutes

[denjaland]

When having subroutes, and applying an active class, it goes wrong when there are replacement variables.

Especially in a case where you navigate to .../:id/... it goes wrong; the route will be shown active using a startsWith() because we can not apply 'exact' because of the subrouting.

I think the parent should only be shown active is the part BEFORE the last SLASH in the route matches exactly in stead of working with .startsWith().

Vue.js / vue-router versions

2.1.6 / 2.1.1

Reproduction Link

https://jsfiddle.net/dwa0kde5/2/

Steps to reproduce

Click the links on the fiddle; the active class shows a red border to the links; you'll soon see where it goes wrong :-)

What is Expected?

When vieweing id 10 / 100 / 1XXX, the /1 route should NOT be active. I believe the slashes should be determining where the parent route ends.

What is actually happening?

[denjaland]

I added the following issue a note to better show the issue: https://jsfiddle.net/dwa0kde5/2/

[fnlctrl]

Actually it's intended behavior since you're not using exact matching:
http://router.vuejs.org/en/api/router-link.html

The default active class matching behavior is inclusive match. For example, will get this class applied as long as the current path starts with /a.

So you'll have to add the exact prop so that links with different params are not marked as active: https://jsfiddle.net/m1n7o6kj/

Though currently vue-router cannot achieve your desired result: mark current route and it's children's link active, and exclude other routes.

[denjaland]

You're not getting the issue; when setting the exact to true; the parent is no longer being active; in a multilevel navigation, you typically want to show the path in your activation that is active; click sub1; you want main1 and sub1 to be active. (Active on the main would "open" the submenu in the navigation)

[LinusBorg]

@fnlctrl I agree with @denjaland: The 'not-exact' match is too lose when using dynamic segments:

A link with a path of /users/1 should not match for /users/123, and should not get the active class - but it does.

[denjaland]

@LinusBorg - I guess you meant it should NOT match for /users/123, right?

[fnlctrl]

@LinusBorg That's inclusive match by design and by definition (and as explained in the docs, /a will match anything that starts with /a ).. So I didn't see it as a bug, but rather a not supported feature.

@denjaland Route matching works independently of current view state. A route is active only when it matches the url, with the current exact option (inclusive match or not).

[denjaland]

Right. But you do see the use case though?
In my opinion, it may have been designed like that, but the use case is pretty obvious, and I would definitely add support for it.
If you prefer to call it a feature request rather than a bug, be my guest :-)

[fnlctrl]

Right. But you do see the use case though?

Yeah... let's mark this as a feature request.

[LinusBorg]

@denjaland

@LinusBorg - I guess you meant it should NOT match for /users/123, right?

Yep - corrected.

@fnlctrl Well, I would argue that it's something in between a bug and an enhancement - the current functionality is definitely lacking when we have routes with dynamic segments, and weither it was designed to not support them is something Evan would have to explain ^^

But there's no need to argue semantics, we should simply see that we get this supported somehow.

[fnlctrl]

Well, it's indeed lacking, but it's been here all the way since the start of 2.0 and the behavior has been precisely documented (and people didn't seem to have trouble with it until now).. So I guess it's rather not designed to support(being unaware of this use case when designing) than designed not to support 😂

[RyuuGan]

I just want to add that it would be awesome if the link will be active if the subroute is matched, especially when the urls are not matching, like /countries and /country/:id.

https://jsfiddle.net/dwa0kde5/3/