Replace RenderComponentAsync in templates with a new tag helper

[rynowak]

This would look like:

<component type="typeof(App)" render-mode="ServerPrerendered" />

We think this is much simpler and easier to explain. We want to avoid using async methods in Razor where they produce output, in very prominent cases, because there are lots of ways to get it wrong.

We won't delete RenderComponentAsync, the tag helper will call it, or will do the same thing.

[DamianEdwards]

Example Tag Helper implementation: https://gist.github.com/DamianEdwards/51c961a1597ec133bd4d5eef30efd9ca

[DamianEdwards]

Note that we currently don't have a non-generic overload of IHtmlHelper.RenderComponentAsync and we probably should. It would definitely make the Tag Helper much easier to author.

[Stamo-Gochev]

@rynowak What is the reason behind mixing blazor components and tag helpers? Can this be a blazor component instead?

[DamianEdwards]

@Stamo-Gochev this is literally the seam between Razor "views" (which means any cshtml file) and Razor Components (any razor file). They both use the Razor language, but use very different build and render pipelines. You can host a Razor Component in a Razor View, but not the other way around. This is about that call-site where you want to render a Razor Component from within a Razor View. Tag Helpers are the way to get HTML-element-like invocation/consumption syntax for APIs in Razor Views, so that's the primitive we'd use to enable a nice syntax for rendering a Razor Component from within a Razor View.

[pranavkm]

Looks like the Component element might become part of the spec: https://www.w3.org/TR/NOTE-HTMLComponents#component although I don't see it being used in a sample in that document. Should we use <component asp-type="..." to disambiguate?

[DamianEdwards]

Seems that spec is way old and effectively dead (like, from before 2000). Seems we can just continue on the original plan.

[javiercn]

@pranavkm Giving this to you as you took over.

[pranavkm]

Fixed as part of d299ae2