Implement Custom 404 Page

[tlmii]

Resolves #2599

The implementation here is more complex than it seems like it should be.

Blazor WASM uses the NotFound parameter of the Router component. But we're not using WASM and the docs say:

This section only applies to Blazor WebAssembly apps. [ ] Blazor Web Apps typically process bad URL requests by either displaying the browser's built-in 404 UI or returning a custom 404 page from the ASP.NET Core server via ASP.NET Core middleware (for example, UseStatusCodePagesWithRedirects / API documentation).

UseStatusCodePagesWithRedirects works as expected, but it is a bad user experience. The URL of the page is changed to e.g. /error/404 and so you lose the context of what you were trying to get to. It's better if the URL in the browser shows the page that really returned the 404.

UseStatusCodePagesWithReExecute is a better user experience. But the way it works in Blazor w/ interactivity is confusing.

The route specified in the call to UseStatusCodePagesWithReExecute has to exist. If it does not, you'll get the browser's 404 page. But when it does exist, it is not what the user ends up seeing. The user ends up seeing what's in the Router component's NotFound parameter (including whatever the default is if that parameter is not specified).

This issue seems relevant: dotnet/aspnetcore#51203 and this comment matches my experience exactly.

To work around all this I have a new blazor component with a page attribute that handles the route specified in UseStatusCodePagesWithReExecute and then I re-use that component directly from within the NotFound parameter.

This all works... just it feels wrong.

Note that the focus here is mostly about just making sure that we have a custom 404 page at all - not spending too much time on the content. We have a pending work item with the design folks that may lead to something better in the future, but that is likely post-GA.

Microsoft Reviewers: Open in CodeFlow

[tlmii]

@SteveSandersonMS @javiercn Is the above description the expected behavior? I notice that @danroth27 's issue is just on the backlog currently. Is there some other way we should be working around this in the interim?

[adamint]

Unfortunate. Approving as the design is fine and it is better than the current experience.

I don't love the text, which is 3 ways of saying the same thing - I'd suggest text like microsoft.com's 404 page, but that's more a nit than anything else

[adamint]

Is there a reason this size is not in terms of any existing variable>

[tlmii]

None of the existing variables go anywhere near that high. +6 is the largest and it was only 40px. Since it was only for one place on one page I didn't think it made sense to try to concoct a --type-ramp-plus-25-* recipe or whatever it'd be for that large.

[tlmii]

I don't love the text, which is 3 ways of saying the same thing - I'd suggest text like microsoft.com's 404 page, but that's more a nit than anything else

That's fair. Since it's a more developer focused site I wanted the status code to actually be featured (e.g. GitHub, somewhat AzDO rather than (or in addition to) more "consumer" oriented text. But I understand opinions may vary 😊

[leslierichardson95]

+1 to Adam's comments on the font but I also think that's more of a nit atm. The experience looks much better now than it did previously :)