First class component support for Multi Page Applications

[javiercn]

Components play a prevalent role in modern web applications. They offer the widest reach when it comes to targeting multiple platforms with a single abstraction. However, the experience from multiple page apps (MVC/Razor pages) is "subpar". The only way to render a component is via an HtmlHelper or a TagHelper, both of which negate most of the benefits components offer compared to HtmlHelpers and TagHelpers.

Having the same level of support for components in Multiple Page Apps will empower developers and library authors to leverage primitive as the universal building block for web UIs across all platforms (WebView, SPA, MPA).

It will enable our existing MPA customers to leverage our current investments in Components to make progressive enhancement scenarios easier to implement and enhance their apps.

In addition to this, components offer a much better composition model than Tag Helpers and Html Helpers for a few reasons:

• You are able to author the UI and logic in a natural way within a single file.
• Composition/orchestration with other components is more natural via parameter passing and features like cascading parameters.
• Components don't require a directive to light up, they use a "strongly typed" model.
• Components have far fewer dependencies on the environment than TagHelpers; in most cases, there's no need to access HttpContext and similar request features to generate the UI.

It offers more natural integration points between MPAs and Blazor by reducing the friction of adding Blazor Server and WebAssembly components to your app. Rendering a Blazor Server or WebAssembly component can be reduced to adding a special attribute directive to the tag, like @server or @wasm. Prerendering can be handled in a similar fashion like @prerender or via some other similar mechanism.

Supporting render fragments can be a challenge, however it is doable with a clear set of rules on what is allowed and what is not, that are reasonably easy to explain.

• When rendering a static component is perfectly fine to pass in content as a render fragment.

• When rendering a Blazor server component we can enforce the render fragment to be a static local function to prevent closing over the existing request state. As to for being able to "retrieve" the "render" fragment on the server, we can capture this information within a compiler generated type that is what we serialize into the page comment.

• For WebAssembly we can avoid supporting RenderFragments or we can support a limited subset of RenderFragments that don't involve C# logic and can get lowered to a chunk of markup or similar. These get serialized as a "special" type and "deserialized" into a RenderFragment later on.

• https://github.com/dotnet/aspnetcore/issues/31772

• https://github.com/dotnet/aspnetcore/issues/21603

• https://github.com/dotnet/aspnetcore/issues/6348

[danroth27]

@javiercn Does this issue effectively cover https://github.com/dotnet/aspnetcore/issues/7528?

[javiercn]

@danroth27 no, this is more about being able to render components as tags inside MVC/Razor pages naturally and do things like render server/wasm components in that way too.

[javiercn]

@danroth27 this is largely a compiler ask, provided we figure out the runtime apis and the generated code (that bit is on us).

[domagojmedo]

Being able to just drop in wasm component in MVC/Razor page would 🔥 I know it's possible right now, but it would be great if it would be much simpler

[stap123]

This would be great, we would love to be able to use Blazor inside our current MVC views in the same way we can JS now. The main attraction (apart from no JS ;) ) I think is that we would be able to use a component library with all of it's benefits across all app types.

[savionlee]

This would be helpful with our in house MVC migration because I could leap to elements that would be better as blazor components with its own logic.

[sgf]

Multi Page App is a very important part of the Web. If Blazor supports building it, Blazor will become a real web development framework.We will can be use it do more.

[westonwalker]

The idea of building server-rendered apps like we do today with MVC or Razor pages but being able to use blazer components to break up the views sounds amazing.

[dlandi]

Are we there yet? Status? Thanks!

[SteveSandersonMS]

Thanks for all the positive remarks here. We are doing a few investigations to explore the options and will come up with design proposals when we can.

[mvacha]

Thanks for all the positive remarks here. We are doing a few investigations to explore the options and will come up with design proposals when we can.

That's uplifting to hear, I have to say that the whole Asp.net Core team has done a great job with Blazor. It is currently the most efficient way to create Single-Page Applications. However, when it comes to working with Razor Pages, the experience feels quite outdated and even frustrating in comparison to not only the JavaScript world but also Blazor. "Components" via partial templates and the unreliable hot reload feature are examples of this.

It is encouraging to learn that Multi-Page Applications are now receiving more attention. Many teams are recognizing the added complexity of SPAs and rediscovering the benefits of MPAs, as seen with projects such as Astro and Htmx.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[KennethHoff]

Is this not completed now in AspNetCore 8 with Blazor SSR?

[SteveSandersonMS]

Yes, I think that's correct. Thanks for the reminder!

@mkArtakMSFT @javiercn Perhaps the only part of the description that isn't complete is support for passing RenderFragment across mode boundaries. We do have a more specific issue covering that: https://github.com/dotnet/aspnetcore/issues/46991. So if you agree, we can close this. If there are any other bits of incomplete work perhaps separate issues could be created for those, since the broad goals of this issue are now achieved.