fix: revert navlink back to prior approach #9497
Conversation
🦋 Changeset detectedLatest commit: f809327 The changes in this PR will be included in the next version bump. This PR includes changesets to release 4 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
|
||
| let anchor = renderer.root.findByType("a"); | ||
|
|
||
| expect(anchor.props.className).not.toMatch("active"); |
There was a problem hiding this comment.
@mjackson Wanted to get your thoughts on the behavior of <NavLink to="/">. In 6.3 and before it seems like it was impossible to get that to apply as a partial match (end=false). Assuming that's intentional (since / is a weird case and matches everything), then this change reverts back to the previous logic from 6.3 and updates it for isPending.
There was a problem hiding this comment.
This looks right to me. A <NavLink to="/"> should not be active at /home.
|
|
||
| let anchor = renderer.root.findByType("a"); | ||
|
|
||
| expect(anchor.props.className).not.toMatch("active"); |
There was a problem hiding this comment.
This looks right to me. A <NavLink to="/"> should not be active at /home.
No description provided.