[Blazor] Mechanism for rendering a "remote" component on to the page.

[javiercn]

We are going to have a basic HTML renderer inside Microsoft.AspNetCore.Components.Web and it needs to support rendering the descriptors/instructions for server and webassembly components, we need a mechanism that allows it to do so.

One way to go about it is to embed this knowledge inside the component itself, this would mean that our HTML renderer knows the shape of the descriptor.

Another way to go about it, is to put the code inside Microsoft.AspNetCore.Components.Endpoints. This will mean that Microsoft.AspNetCore.Components.Endpoints is the one that knows about the format and Microsoft.AspNetCore.Components.Server (and webassembly) are the ones that know about how to read them.

It is convenient because the auto mode, needs to emit both descriptors on to the page.

Finally, we can put the code for reading/writing descriptors inside Microsoft.AspNetCore.Components.Server and Microsoft.AspNetCore.Components.Webassembly.

• At startup, each assembly registers in DI their own handler.
• During the render process we query each handler with the render mode.
  • If the handler supports the render mode, it emits the descriptor into the page.
  • If the handler does not support the render mode, it does nothing.

This has a few benefits:

• The code that emits the handler is the same code that reads it back, which means changes are localized and easy to test.
• "Auto" gracefully degrades if you for example don't have Blazor Server plugged in.
• You can't render a component for a concrete render mode, if the app has not added support for it.
  • For example, if you try to render a component that only renders on Server, you'll get an exception at the time the descriptor is emitted.

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[SteveSandersonMS]

This feature area was handled in preview 4, so I'll close this now.