Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: NavLink always active for root url #9261

Closed
JulSeb42 opened this issue Sep 14, 2022 · 11 comments
Closed

[Bug]: NavLink always active for root url #9261

JulSeb42 opened this issue Sep 14, 2022 · 11 comments
Labels

Comments

@JulSeb42
Copy link

What version of React Router are you using?

6.4.0

Steps to Reproduce

Add to your navigation component and visit another page:

<NavLink to="/">Home</NavLink>

Expected Behavior

This code being compiled to

<a href="/">Home</a>

while being on any other route like /about

Actual Behavior

This is compiled to:

<a aria-current="page" class="active" href="/">Home</a>

while being on /about

@JulSeb42 JulSeb42 added the bug label Sep 14, 2022
@kiliman
Copy link
Contributor

kiliman commented Sep 14, 2022

I believe you need to add the end prop to match exact path.

If the end prop is used, it will ensure this component isn't matched as "active" when its descendant paths are matched. For example, to render a link that is only active at the website root and not any other URLs, you can use:

<NavLink to="/" end>Home</NavLink>

https://reactrouter.com/en/main/components/nav-link

@JulSeb42
Copy link
Author

Thanks it's working. But I always did it without the end prop and it always worked, why did this change? (I started with the v5, so it's been a while haha)

@timdorr timdorr closed this as completed Sep 14, 2022
@timdorr
Copy link
Member

timdorr commented Sep 14, 2022

@JulSeb42
Copy link
Author

Ok weird, I have a few other projects using V6 and it was working without end. Anyways, thanks!

@t-fritsch
Copy link

Same here : with rr 6.1 and 6.3 (not tested with 6.0 nor 6.2) NavLink had "end" behavior by default, why did it change in 6.4 ? Shouldn't this be considered as a regression or a breaking change ?

@brophdawg11
Copy link
Contributor

I don't believe anything changed about end from 6/3 to 6.4. It defaulted to end=false in 6.3.0 as well: https://github.com/remix-run/react-router/blob/v6.3.0/packages/react-router-dom/index.tsx#L317

Here's a quick code sandbox showing the behavior: https://codesandbox.io/s/navlink-end-behavior-otpymz?file=/src/index.js

@t-fritsch
Copy link

Thanks a lot for your reply and codesandbox, @brophdawg11, I played a little bit with it and I think that the problem seems to occur on root NavLinks (<NavLink to="/">).

In your code, if you navigate to "/parent", the "/" NavLink isn't active in 6.0, 6.1, 6.2, 6.3. It gets activated only in 6.4.

image

image

Having parents active by default when children routes are visited seems legit, but having the "Home" link always active by default seems quite weird. Pre 6.4 versions were fine on this, don't you think ?

@brophdawg11
Copy link
Contributor

Thank you for digging deeper into that @t-fritsch, I don't think any of us quite caught the nuance around the end behavior change from 6.3 to 6.4 for root paths. I just fixed this in #9497 and should have a prerelease out tomorrow and a stable 6.4.3 early next week.

@t-fritsch
Copy link

Awesome ! Thanks a lot @brophdawg11 🙏

@awreese
Copy link
Contributor

awreese commented Jul 15, 2023

So why is the root "/" route treated differently? According to docs the end prop should need to be added to path="/" to get the behavior of not matching sub-routes, otherwise it should be matched, right?

end
The end prop changes the matching logic for the active and pending states to only match to the "end" of the NavLink's to path. If the URL is longer than to, it will no longer be considered active.

Without the end prop, this link is always active because every URL matches /.

<NavLink to="/">Home</NavLink>

To match the URL "to the end" of to, use end:

<NavLink to="/" end>
  Home
</NavLink>

Now this link will only be active at "/".

Are the docs just flat out wrong? Have they been incorrect this entire time, save for v6.4.0-6.4.2?

@brophdawg11
Copy link
Contributor

I think the docs were incorrect - updated in #10757.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants