Blazor: More flexible Router / layout display

[SteveSandersonMS]

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

[mkArtakMSFT]

Discussed this offline. We don't have clear picture regarding this adding value or not.

[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 👍

[javiercn]

How does this affect #10445. Should we fold this into here?

[javiercn]

If we are considering moving forms and authorization out of M.A.Components. Should we also consider move Routing support to Microsoft.AspnetCore.Components.Routing?
I think they are at the same "level" and would be worth considering. The main challenge would be the JS interop piece, but that would use standard swa infrastructure to be available from the package and we could do some magic to plug it in automatically.

• Router/NavLink/Location could invoke some JSInterop to load the script for interception magically.

Thoughts?