dotnet
[Blazor] Add an API to describe the render mode (if any) a component is running in
Adds an API to describe the current host render mode if any a component is running in.
Fixes https://github.com/dotnet/aspnetcore/issues/49401
Sample usage:
<p id="host-render-mode">@_message</p>
@code {
private string _message = "";
protected override void OnInitialized()
{
if (Platform is { RenderMode: InteractiveServerRenderMode })
{
_message = $"Host Render Mode: Interactive Server";
}else if (Platform is { RenderMode: InteractiveWebAssemblyRenderMode })
{
_message = $"Host Render Mode: Interactive Webassembly";
}
else
{
_message = "Host Render Mode: Static";
}
}
}
Adds a new ComponentPlatform type that the renderer provides (gets exposed through RenderHandle) to provide details on the platform the component is currently running on.
All 4 renderers provide an implementation, and they indicate the name, whether the platform is interactive, and any render mode associated with the platform (if any).
The approach here is great for finding out the current rendering platform, but doesn't address finding out the effective rendermode at least in the sense that I was proposing.
For example, even when a component is running on the Static platform, it might also have rendermode InteractiveServer. Developers may need to vary behavior based on whether the component is going to become interactive, since (for example) an RCL component might produce a different UI shape entirely based on whether interactive controls are going to be available later.
Suggestion: let's keep this PR simple as it is, and just eliminate the ComponentPlatform.RenderMode property since it would be misleading (e.g., it would report rendermode null for all components during SSR even when you've set a nonnull rendermode on them). Then later as a separate work item if we have time, we can add some further ComponentBase.RenderMode property that gets the effective per-component rendermode.
What do you think?
Suggestion: let's keep this PR simple as it is, and just eliminate the ComponentPlatform.RenderMode property since it would be misleading (e.g., it would report rendermode null for all components during SSR even when you've set a nonnull rendermode on them). Then later as a separate work item if we have time, we can add some further ComponentBase.RenderMode property that gets the effective per-component rendermode.
What do you think?
Sounds good, let me think for 5 minutes if what you suggest is straightforward to do, and maybe I just go ahead and do it. If I see any trouble with it, I'll just remove it for now.
Sounds good, let me think for 5 minutes if what you suggest is straightforward to do, and maybe I just go ahead and do it. If I see any trouble with it, I'll just remove it for now.
Renderer already has a virtual method GetComponentRenderMode.
On EndpointHtmlRenderer this is already overridden to return the info by doing a linear walk up the list component hierarchy to look for the closest boundary. As long as we're OK with this doing a linear walk up the hierarchy on each property evaluation (or I guess we could cache after the first read), we can just use that and it's pretty simple. Would just need to override the method on all the other renderers besides EndpointHtmlRenderer and make them return whatever rendermode is fixed on that renderer.
However there is quite a bit more to test, as there are more combinations (e.g., need to cover all the renderers, and each case where it's possible to set rendermodes). So I'll leave it with you whether you want to incorporate that into this PR or not!
However there is quite a bit more to test, as there are more combinations (e.g., need to cover all the renderers, and each case where it's possible to set rendermodes). So I'll leave it with you whether you want to incorporate that into this PR or not!
Not sure what you mean by this, I think the main change would be that EndpointHtmlRenderer walks the tree to find the rendermode, but all other renderers just provide static results as they do already (server does server, wasm does wasm, webview does null).
The main difference is that endpoints returned null, and now we are saying it'll return Auto, WebAseembly or Server based on the render mode for the root component (figuring it out with the help of the renderer), am I getting this wrong?
So, it's only about checking those non-interactive returns the render mode instead of null, isn't it?
By "a bit more to test" I just mean writing E2E tests in the PR, not things getting tested at runtime :)
The main difference is that endpoints returned null, and now we are saying it'll return Auto, WebAseembly or Server based on the render mode for the root component (figuring it out with the help of the renderer), am I getting this wrong?
Yes exactly.
Yes exactly.
Cool, check if https://github.com/dotnet/aspnetcore/pull/55577/commits/c2b67f90982ed90819d0b3a4eca41e3674bc2ba2 matches your expectations and I'll add more tests.
Cool, check if https://github.com/dotnet/aspnetcore/commit/c2b67f90982ed90819d0b3a4eca41e3674bc2ba2 matches your expectations and I'll add more tests.
Yay! Other than minor details yes that looks great.