[NcAppNavigationItem] has no option for exact route matching

[wofferl]

In v8 it was possible to use exact - Pass in true if you want the matching behaviour to be non-inclusive: https://router.vuejs.org/api/#exact for route matching. This was removed in v9.

I created a PR #7939 to bring back this option by using isExactActive: true if the [exact active class](https://v3.router.vuejs.org/api/#exact-active-class) should be applied. Allows to apply an arbitrary class.

[ShGKme]

In v8 there was exact prop because NcAppNavigationItem is a wrapper over RouterLink which had the exact prop in the past in Vue 2. In other words, removed NcAppNavigationItem's exact prop followed removed <RouterLink>'s exact prop.

This prop was removed in Vue Router v4 (Vue 3) ~5 years ago: https://github.com/vuejs/rfcs/blob/master/active-rfcs/0028-router-active-link.md

In my opinion, we should not bring back a prop removed in the base component.

[ShGKme]

The created PR also doesn't bring back the exact prop but acts like (also removed in vue router) exact-path prop, which could be even more confusing.

[ShGKme]

However, having all the links active inclusive is a problem indeed. To avoid it, we can:

1. Always use isExactActive instead if isActive
2. Allow to use active prop to override active state from the router

[wofferl]

However, having all the links active inclusive is a problem indeed. To avoid it, we can:

1. Always use `isExactActive` instead if `isActive`

Wouldn't this break the default for existing apps. Don't know if any app actual needs the non exact matching, however, the original introduction of disabling it was apparently for the Mail app (#29).

2. Allow to use `active` prop to override active state from the router

But why not use the information that is already available in the component instead of having the parent component determine whether the route is correct or not to set the active prop?

If it's just a matter of a confusing property name, we could also use a new, more appropriate one, such as exactMatch or strictMatch, or is this too short-sighted?

[ShGKme]

But why not use the information that is already available in the component instead of having the parent component determine whether the route is correct or not to set the active prop?

The original exact which checked query and hash is not available. isExactActive acts like exact-path.

And if we go to more options in the comparison, we have more and more ways to determine what is exact. Old vue-router had 4 different classes for exact matching.

[ShGKme]

Wouldn't this break the default for existing apps. Don't know if any app actual needs the non exact matching, however, the original introduction of disabling it was apparently for the Mail app (#29).

Using isExaсtActive seems a more reasonable default from the accessibility perspective (what actually is the current page).

As far as I remember, Mail also doesn't use not exact anymore, cc @ChristophWurst @GretaD

[wofferl]

But why not use the information that is already available in the component instead of having the parent component determine whether the route is correct or not to set the active prop?

The original exact which checked query and hash is not available. isExactActive acts like exact-path.

And if we go to more options in the comparison, we have more and more ways to determine what is exact. Old vue-router had 4 different classes for exact matching.

I see, that makes sense.