Expose the functionality in internal EndpointHtmlRenderer for integrating frameworks

[marinasundstrom]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

TL;DR; Expose the functionality in the EndpointHtmlRenderer so that integrating frameworks can use it to render components, with the potential to be interactive, to HttpContext.

---

I was looking into using Wordpress.NET as a CMS, and embedding interactive components.

Peachpie (PHP compiler) already supports rendering partial Razor Views, so I investigated whether it was possible to add similar support for Blazor.

Adding support for rendering components as static HTML was pretty easy. But the public API is limited to only rendering static HTML, and not any render mode with interactivity.

My code is here: https://github.com/marinasundstrom/BlazorPhp

Unfortunately, the EndpointHtmlRenderer is internal, otherwise I would just plug it in and pass the output to the HttpContext in my method in Peachpie.

Would you consider opening up this internal API?

Tracked in Peachpie repo: peachpiecompiler/peachpie#1124

Describe the solution you'd like

"Open up" (expose) the internal EndpointHtmlRenderer API for integrating frameworks - like Peachpie.

This will make it possible for them to serve interactive Razor components.

Additional context

No response

[marinasundstrom]

About a related issue for interactivity to work with both Minimal APIs, and this proposal: #50762

I found a workaround to make interactivity work: https://github.com/marinasundstrom/BlazorMinimalApiTest

[javiercn]

@marinasundstrom in principle I am against us making anything public without a clear scenario that justifies it.

Making something like EndpointHtmlRenderer public exposes Blazor guts to the world and drastically limits our ability to make changes in the future without having to consider the ramifications for extenders.

There might be other ways to achieve some scenarios, and we will want to weight the importance of those scenarios against the drawbacks of limiting our options in the futute. Unfortunately, there is no free lunch :(, so I'd rather we discuss specific scenarios to better understand what the options are.

[marinasundstrom]

Thanks for your response, @javiercn.

Sure, I would not open that up entirely either. But rather expose the functionality in a way that makes sense to developers, and is safe.

It is not an urgent matter. I just thought it would be a possible scenario for a Wordpress.NET application - as I'm contemplating about it. But I can always create a micro-frontend in Blazor instead.

But seriously, it should be investigated, what types of integrations there are with Blazor for other kinds of Web apps.

In the meantime, while experiment (I stress that I'm experimenting), I can perhaps use reflection to access those hidden classes and properties.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 9 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.

[mkArtakMSFT]

Thanks for contacting us.
While this may be a great idea, it is not aligned with our long-term vision to make it part of the framework. For many other ideas which don't belong to the framework we encourage the community to build and ship on their own, contributing to the expanding .NET Ecosystem.

You can learn more about our triage process and how we handle issues by reading our Triage Process writeup.