Link-side approach for sidebar link active highlight #2253
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
david-crespo
force-pushed
the
link-active-prefix
branch
from
853fd0f to
fd6f500
Compare
david-crespo
force-pushed
the
link-active-prefix
branch
from
fd6f500 to
44e177a
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #2173
This is an alternative to #2238 that avoids changing the paths. We had some issues with loader and back button behavior in the past that we fixed by having the sidebar link go directly to the first tab on the page (in this case
/system/inventory/sleds) instead of linking to the parent (/system/inventory), which is then responsible for doing a replace nav to get to the first tab path.As part of reviewing #2238 I reviewed the past conversations I could find about this problem
and I could not reproduce the issue with the solution #2238, but something still makes me nervous about it. So here is the other way to do it. I'm still sort of on the fence (not sure why I can't shake the worry about #2238), but seeing the two approaches side by side will help us think about it.
Clearly this is more complicated, adding logic where the other just goes along with how React Router works by default, so I'd rather do #2238 if we can.