Api proposal for `NotFoundEventArgs.Path`

[ilonatommy]

Background and Motivation

Blazor’s routing system uses the NotFoundEventArgs class to provide information when navigation rises NotFound event. Previously, this class did not expose the unmatched component path, limiting its usefulness for scenarios where the path is needed—such as in server-side rendering (SSR) streaming, where the framework or event listeners may need to fetch and render the correct “not found” component for a specific route.

This change adds a url parameter to the NotFoundEventArgs constructor and a Path property to the class. This allows internal components, such as the NavigationManager and event listeners, to pass and access the unmatched route, enabling rendering in SSR streaming scenarios. The naming is not consistent and should be unified to probably path or route or similar.

Proposed API

namespace Microsoft.AspNetCore.Components.Routing
{
    public class NotFoundEventArgs
    {
-       public NotFoundEventArgs();
+       public NotFoundEventArgs(string url);

+       public string Path { get; }
    }
}

Usage Examples

// User's custom router code subscribes to `OnNotFound`
NavigationManager?.OnNotFound += HandleNotFound;

// User's component rises not found:
NavigationManager.NotFound();

// internally, `NavigationManager` triggers the `NotFound` event with the not-found-route
// var args = new NotFoundEventArgs(NotFoundPageRoute);
// OnNavigateNotFound?.Invoke(args);

// Event listeners can now access the unmatched path to e.g. handle rendering in the case when streaming has started:
void HandleNotFound(NotFoundEventArgs args)
{
    // Use args.Path to fetch or render the correct NotFound component for SSR streaming
    if (
    var fetchUrl = $"/{NavigationManager.BaseUri}/{args.Path}";
    // Fetch and render logic:
}

Alternative Designs

• Previously, NotFoundEventArgs did not provide the not-found path, so we were always using a fixed path "not-found", forcing users to define not found component with exactly this route, without a way to customize it.

Risks

• The path can be confused with unmatched path of component that called NavigationManager.NotFound(). From this reason, better naming would be needed.
• If existing code uses the parameterless constructor, it may need to be updated to use the new constructor with the url parameter. The parameterless constructor was introduced in this release, after a previous API review: Api proposal fix for NotFound #61152 - it should not be a big issue.

[dotnet-policy-service]

Thank you for submitting this for API review. This will be reviewed by @dotnet/aspnet-api-review at the next meeting of the ASP.NET Core API Review group. Please ensure you take a look at the API review process documentation and ensure that:

• The PR contains changes to the reference-assembly that describe the API change. Or, you have included a snippet of reference-assembly-style code that illustrates the API change.
• The PR describes the impact to users, both positive (useful new APIs) and negative (breaking changes).
• Someone is assigned to "champion" this change in the meeting, and they understand the impact and design of the change.