How to detect Pre-Rendering of a Component

[ShaunCurtis]

What is the team's recommended way to get the render state of a component?

I currently use a service like this:

public interface IBlazrRenderStateService
{
    public Guid ServiceUid { get; }
    public BlazrRenderState RenderState { get; }
    public bool IsPreRender => this.RenderState == BlazrRenderState.PreRender;
}

public enum BlazrRenderState
{
    None,
    PreRender,
    SSR,
    CSR
}

And the Server implementation:

public class ServerRenderStateService : IBlazrRenderStateService
{
    private IHttpContextAccessor _httpContextAccessor;

    public Guid ServiceUid { get; } = Guid.NewGuid();

    public BlazrRenderState RenderState =>
        !(_httpContextAccessor.HttpContext is not null && _httpContextAccessor.HttpContext.Response.HasStarted)
            ? BlazrRenderState.PreRender
            : BlazrRenderState.SSR;

    public ServerRenderStateService(IHttpContextAccessor httpContextAccessor)
    {
        _httpContextAccessor = httpContextAccessor;
    }
}

Which uses the IHttpContextAccessor service.

Other programmers imply that I'm wrong in using it by quoting: "Microsoft does not recommend the use of IHttpContextAccessor". (They haven't yet suggested an alternative).

To quote https://learn.microsoft.com/en-us/aspnet/core/fundamentals/http-context?view=aspnetcore-6.0#ihttpcontextaccessorhttpcontext-in-razor-components-blazor

Don't use IHttpContextAccessor/HttpContext directly or indirectly in the Razor components of server-side Blazor apps. Blazor apps run outside of the ASP.NET Core pipeline context. The HttpContext isn't guaranteed to be available within the IHttpContextAccessor, and HttpContext isn't guaranteed to hold the context that started the Blazor app.

I understand why: users may/will grab, persist and then try and use the HttpContext object outside the context in which it was provided.

Your documentation describes it as the method of last resort, which I think is the case with Render State - https://learn.microsoft.com/en-us/aspnet/core/fundamentals/http-context?view=aspnetcore-8.0#access-httpcontext-from-custom-components.

The code is purely doing a proof of life and using that information to predict the state.

But, you may have a better method?

[Xyncgas]

Is AfterRender(bool firstRendered) to your liking

[ShaunCurtis]

OnAfterRender[Async] doesn't get called in pre-render mode. It's also a UI event [not part of the lifecycle] that gets called after a render event. How do you propose to detect the absence of an event.

[javiercn]

[CascadingParameter] HttpContext HttpContext {get; set; } on your component. If you are prerendering it will be populated, in any other case it will be null.

[ShaunCurtis]

I was about to quote you back some of the MS documentation about not using HttpContext in Blazor, but re-read this from https://learn.microsoft.com/en-us/aspnet/core/fundamentals/http-context?view=aspnetcore-8.0#ihttpcontextaccessorhttpcontext-in-razor-components-blazor

HttpContext can be used as a cascading parameter only in statically-rendered root components for general tasks, such as inspecting and modifying headers or other properties in the App component (Components/App.razor). The value is always null for interactive rendering.

"The value is always null for interactive rendering". We're only looking for proof of life, no dependency on it's existence. So your answer makes sense.

IHttpContextAccessor works, but needs the service defined.

Thanks.