Blazor: More flexible Router / layout display

Currently, we have a hardcoded set of assumptions about what you want to do with a router, i.e.,

• You want to display the page inside its layouts
• You want to authorize access to the page, but still show its layouts regardless

The logic for this is all internal to Router and LayoutDisplay (being renamed to PageDisplay). Instead of this, we could reduce Router to be a templated component that just finds a page and parameters for you. Then you could choose how to render that, and where authorization wrappers go, etc., yourself.

Example:

<Router AppAssembly="@typeof(App).Assembly" Context="routeContext">
    <NotFoundContent>
        <LayoutDisplay Layout="@typeof(MainLayout)">
            <h1>Not found</h1>
            Sorry, there's nothing here.
        </LayoutDisplay>
    </NotFoundContent>
    <FoundContent>
        <AttributeAuthorizeView Page="@routeContext.Page">
            <Authorized>
                <LayoutDisplay Page="@routeContext.Page" PageParameters="@routeContext.Parameters" />            
            </Authorized>
            <NotAuthorized>
                <LayoutDisplay Layout="@typeof(MainLayout)">
                    <h1>Access denied</h1>
                    Go away.
                </LayoutDisplay>
            </NotAuthorized>
            <Authorizing>
                <LayoutDisplay Layout="@typeof(MainLayout)">
                    <h1>Please wait</h1>
                    Checking authorization...
                </LayoutDisplay>
            </Authorizing>
        </AttributeAuthorizeView>
    </FoundContent>
</Router>

This would completely nuke issue #10445 in the most comprehensive manner.

One drawback is the amount of repetition of specifying <LayoutDisplay Layout="@typeof(MainLayout)"> here, but doing this does eliminate any need for a DefaultLayout concept, and completely decouples Router, AuthorizeView, and LayoutDisplay from each other. They would no longer need to have any awareness of each others’ existence.

@rynowak @danroth27 @javiercn What’s your gut response to this? Does it look too complicated, or do you think the flexibility warrants all the explicit code?

Plan

• Implement LayoutView
• Implement RouteView
• Update Router to new factoring
• Implement AuthorizeRouteView
• Remove CascadingAuthenticationState No, keeping it.
• Remove PageDisplay
• Update E2E tests
• Update project templates

[rynowak]

Reactivating this based on API review discussions. This solve a bunch of hard layering problems that we think are worth taking on. We can think of a few practical design issues in this area that will help users as well, and decoupling all of these things is a good long term choice.

We’re planning to move the authorization features to Microsoft.AspNetCore.Components.Authorization

We’re planning to move the forms support to Microsoft.AspNetCore.Components.Forms.

We plan to drop Microsoft.JSInterop as a dependency from M.A.Components and it will no longer have any dependencies 👍

[SteveSandersonMS]

Done in #12800