[Bug]: NavLink is active for partial segment matches (react-router-dom v6.4)

[fullsailor]

What version of React Router are you using?

react-router-dom@6.4.0

Steps to Reproduce

1. Define sibling routes /user and /user-preferences

   <BrowserRouter>
     <Routes>
        <Route path="/" element={<Root />}>
           <Route index element={<p>Index</p>} />
           <Route path="user" element={<p>User</p>} />
           <Route path="user-preferences" element={<p>User Preferences</p>} />
        </Route>
     </Routes>
   </BrowserRouter>

2. Show NavLinks to the routes

   const Root = () => (
      <>
         <NavLink to="user">Go to /user</NavLink>
         <NavLink to="user-preferences">Go to /user-preferences</NavLink>
      </>
   )

3. Navigate to /user-preferences path

Code Sandbox

Expected Behavior

The link to /user-preferences should have the active class and the link to /user should not have the active class. This is the behavior in react-router-dom@6.3.0

Actual Behavior

Both links have the active class.

[ddolcimascolo]

Erf. I haven't tested any further v6.4.0 because of #9265 but this looks like a second big regression... I'm willing to help but don't really know where to start 🙄

[kiliman]

What happens if you add end prop to your <NavLink>? It looks like it's matching on partial URL: basically isActive = path.startsWith('/user').

[fullsailor]

What happens if you add end prop to your <NavLink>? It looks like it's matching on partial URL: basically isActive = path.startsWith('/user').

Adding end does sort of workaround it, but it means that the child routes of /user no longer match. This worked without end in 6.3. My expectation is that isActive = useMatch('/user') != null.

There's a test that checks that partial segments do not apply the active class. If I change the /children route to /child-ren the test fails in 6.4.0 and passes in 6.3.0.

[fullsailor]

Two updates, first I found why the useMatch() hook has a different result than the component. useMatch('/user') will default the unset end parameter to true, while useMatch({pathname: '/user'}) (what NavLink will effectively call) will default end to false

My other finding is that I think the regression comes from this part of the regular expression defined in compilePath

// Otherwise, match a word boundary or a proceeding /. The word boundary restricts
// parent routes to matching only their own words and nothing more, e.g. parent
// route "/home" should not match "/home2".
// Additionally, allow paths starting with `.`, `-`, `~`, and url-encoded entities,
// but do not consume the character in the matched path so they can match against
// nested paths.
"(?:(?=[@.~-]|%[0-9A-F]{2})|\\b|\\/|$)";

Its treating - as a word boundary and therefore like as if /user-preferences is a child route of /user. It feels like the part that says allow paths starting with special characters, should mean only match if the path was something like /user/-preferences.

NavLink in 6.3 didn't use useMatch and this regular expression.

[albrimpaqarizi]

Hello mate,

First, in this case, I suggest splitting the pathname "user-preferences" to "user/preferences" but another solution is to make a custom NavLink component.

Like this:

const CustomNavLink = ({ className, children, to }) => {
  const { pathname } = useLocation();

  const match = to === pathname.split('/').join('');

  return (
    <NavLink to={to} style={{color: match ? 'red': 'black'}} >
      {children}
    </NavLink>
  );
};

[brophdawg11]

I looked into this briefly and I think this may be a previously undiscovered bug in matchPath that's now exposed more broadly since we changed NavLink to use it internally. We did this to better align its approach with our recommended approach for custom NavLink behavior in https://github.com/remix-run/react-router/blob/main/examples/custom-link/src/App.tsx.

Going to chat with @mjackson to confirm since he wrote most of the original approach in matchPath.

[brophdawg11]

Hey folks! Just merged the fix for this - planning to get a prerelease out today and a stable 6.4.2 next week 👍