Components router refactoring. Fixes #10493 #10445

[SteveSandersonMS]

This factors out some of the behaviors that were previously hardcoded into Router and makes them independent primitives. Benefits:

• More flexibility to use different subsets of functionality, or to run things like authorization and routing in a different order if you want
• Implicitly fixes Router displays NotFoundContent without any layout #10445, which would otherwise be quite difficult to fix while also keeping a nice API shape
• Means we can later split off the entire concept of authentication/authorization into a separate optional assembly. It no longer needs to be in Microsoft.AspNetCore.Components.

Drawbacks:

• There's now more markup in App.razor in the templates. But you could also argue that making the workings more explicit is actually beneficial.

The overall design here is to simplify <Router> so it no longer knows about auth or layouts, and instead is only responsible for matching the URL to a route and rendering either a Found block (passing the matched route data) or a NotFound block.

We then introduce three new built-in components:

• <LayoutView>, which renders a specified content block inside a specified layout (and any ancestor layouts)
  • This will stay in M.A.Components
• <RouteView>, which wraps <LayoutView> and renders whichever page component corresponds to some given route data. The layout it nominates is the one on that page, if any, or falls back on a specified DefaultLayout (or failing that, no layout).
  • This will stay in M.A.Components
• <AuthorizeRouteView> which combines <AuthorizeView> with <RouteView>. It also takes a route data param, and tells the <AuthorizeView> to use the authorizedata on the matched page. The Authorized content is a <RouteView> that renders the page inside its layout. Optionally you can also specify NotAuthorized and Authorizing content.
  • It also implicitly adds a <CascadingAuthenticationState> to the output if you don't already have one
  • This will later move to the new M.A.Components.Authorization assembly

Then:

• <PageDisplay> is now obsolete and has been removed. It is superseded by whichever one of the above three matches your actual scenario.
• Project templates no longer need to include any explicit <CascadingAuthenticationState>, as that's provided by <AuthorizeRouteView> if you're using that. But we still have <CascadingAuthenticationState> as a public API, because that's relevant if you're using authorization without routing (common in native apps).
• Project templates no longer need a Pages/_Imports.razor file because it's more natural to put a DefaultLayout on the <RouteView>. Technically then you're no longer forced to put the layout file in a separate folder from the pages, though I'm not proposing to change the folder structure in the templates.

[rynowak]

missing docs.

[rynowak]

The no-auth case for this seems really simple and cool.

Something we could do (that would trade one kind of complexity for another) would be to add a <DefaultLayout> as a cascading value provider component.

I know you tend to prefer using Context="..." but I tend to not. Ultimately we could end up with something like:

<DefaultLayout Layout="typeof(MainLayout)">
<Router AppAssembly="@typeof(Program).Assembly">
    <Found>
        <RouteView RouteData="@context">
    </Found>
    <NotFound>
        <LayoutView>
            <p>Sorry, there's nothing at this address.</p>
        </LayoutView>
    </NotFound>
</Router>
</DefaultLayout>

In these case there's very little duplication and noise. These are nitpicks though, I'm happy with the result.

I'm not sure it's the right thing to use a cascasing value just to DRY-up the code, but it can make it less verbose.

[SteveSandersonMS]

Sure, I was definitely aware of this option but sided against it. I'm concerned with trying to make <LayoutView> generally useful in more scenarios than only the top-level App.razor file. It would be totally reasonable to use <LayoutView> at multiple levels, especially if we have nested routers in the future.

In cases where <LayoutView> is used outside App.razor, you really want to make it use the right layout for its own level, and not randomly inherit a choice from further up the tree (from some other file you can't necessarily find because there's no F12 way of getting to it). It seems greatly preferable for it to be a required explicit parameter.

Of course if someone wants, they can make their own <CascadedLayoutView> that consumed a cascading parameter and outputs a <LayoutView>. The feature is achievable in user code, but I don't fancy it as the built-in default, even if we need slightly more explicitness in App.razor.

[rynowak]

Awesome!