dotnet/aspnetcore

Suggestion: Expose a parameter of `ShouldMatch` for `<NavLink />`

Closed

#18,163 opened on Jan 7, 2020

View on GitHubContributor guide
 (6 comments) (1 reaction) (0 assignees)C# (10,653 forks)batch import
Priority:1affected-fewarea-blazorenhancementfeature-blazor-builtin-componentshelp wantedseverity-minor

Repository metrics

Stars
 (37,933 stars)
PR merge metrics
 (Avg merge 16d 9h) (258 merged PRs in 30d)

Description

Is your feature request related to a problem? Please describe.

I want to custom the matching behavior of <NavLink />.

Let's say we want to process a url with a hash(See this thread on SO) :

http://localhost/#an-element-id

Sometimes we might think this url matches http://localhost , while some other users don't think so.

It would be great if we are allowed to custom this matching behavior. Usually, we can custom by inheritance or composition. However, the matching logic is hardcoded for the present.

  1. There's no public/protected ShouldMatch(string) method exposed. So it's difficult to achieve it by inheritance
  2. There's no ShouldMatch parameter exposed. It would be great if we can pass a ShouldMatch [Parameter] to this component.

Describe the solution you'd like

Expose a [Parameter] of ShouldMatch(string):

  • if user provides such a parameter, use it.
  • Otherwise, use the default logic.

Contributor guide

Research direction
Start by examining the NavLink component at src/Components/Web/src/Routing/NavLink.cs, focusing on the hardcoded ShouldMatch method. Look for patterns of similar parameters in the codebase. Implement a new ShouldMatch parameter of type Func<string, bool>? that overrides the default match behavior. Ensure the parameter is optional and document it. Also check existing tests for NavLink and add a test case for custom matching. Review any linked PRs or comments for further guidance.
Tech stack
csharp
Domain
frontend
Issue type
Feature
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
2
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
1-3 hours
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
Stale
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
Clear
Prerequisites
C#BlazorGit
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
70