Assemblysoft Services

Blazor Auto Render Mode in the Real World

Carl Randall -

Proven architecture patterns for performance, scalability, and great UX when your components can run on the server and in the browser.

Introduction

.NET 8 introduced one of the most important evolutions in Blazor: multiple render modes per component. It’s now possible to combine static server-side rendering (SSR), Blazor Server, and Blazor WebAssembly (WASM) within a single application.

Used well, this unlocks faster first paint, progressive enhancement, and resilient user experiences. Used poorly, it introduces duplicated data loads, unnecessary HTTP hops, and subtle UX inconsistencies.Assemblysoft perspective: we apply mixed render modes in production systems (dashboards, workflows, field-first experiences, and SaaS modules). The consistent differentiator is intentional data-flow architecture and keeping interactive components lean. Explore our work and approach at Assemblysoft Blazor Development and Software Modernisation.

Render Modes in .NET 8 and Beyond

Blazor now supports running components in several distinct execution models:

  • Static Server-Side Rendering (SSR)
  • Blazor Server
  • Blazor WebAssembly (WASM)
  • InteractiveAuto (WASM if available, otherwise Server)

In practice, this enables the best of both worlds: fast initial rendering from the server, and a rich interactive experience that can shift to WASM when available.

What InteractiveAuto Really Does

When you mark a component with @rendermode InteractiveAuto, Blazor can render it multiple times across environments. The typical lifecycle looks like this:Syntax error in textmermaid version 10.9.5

Key implication: component initialisation can run more than once. Data fetching must be designed to avoid duplication and flicker.

@rendermode InteractiveAuto

A Business-Oriented Example: Loading a Dashboard Summary

Rather than a weather demo, here’s a realistic line-of-business scenario: loading a Dashboard Summary used to power KPI cards.

@page "/dashboard"
@rendermode InteractiveAuto
@inject HttpClient HttpClient

<h1>Business Dashboard</h1>

@if (_dashboardSummary == null)
{
    <p><em>Loading summary…</em></p>
}
else
{
    <DashboardSummaryView Model="_dashboardSummary" />
}

@code {
    private DashboardSummaryModel? _dashboardSummary;

    protected override async Task OnInitializedAsync()
    {
        _dashboardSummary = await HttpClient
            .GetFromJsonAsync<DashboardSummaryModel>("api/dashboard/summary");
    }
}

Two problems show up quickly in production

  • Problem 1: Duplicate data fetching. Prerender fetch + interactive fetch = double load and possible KPI flicker.
  • Problem 2: Server-to-server HTTP calls. When running on the server, the component still calls your own API via HTTP.

In real delivery work, these issues disproportionately affect the “first impression” screens—dashboards, landing pages, project overviews—where UX matters most. For examples of outcomes achieved in production systems, see Assemblysoft case studies.

Best Practice 1: Persist State Across Render Modes

Use PersistentComponentState to prevent duplicate loads by persisting data fetched during prerender and restoring it during interactive startup.

@inject PersistentComponentState AppState
@implements IDisposable

@code {
    private DashboardSummaryModel? _dashboardSummary;
    private PersistingComponentStateSubscription _persistSubscription;

    protected override async Task OnInitializedAsync()
    {
        _persistSubscription = AppState.RegisterOnPersisting(PersistDashboardSummary);

        var restored = AppState.TryTakeFromJson<DashboardSummaryModel>(
            "dashboard-summary", out var cachedSummary);

        _dashboardSummary = restored
            ? cachedSummary
            : await HttpClient.GetFromJsonAsync<DashboardSummaryModel>("api/dashboard/summary");
    }

    private Task PersistDashboardSummary()
    {
        AppState.PersistAsJson("dashboard-summary", _dashboardSummary);
        return Task.CompletedTask;
    }

    public void Dispose()
    {
        _persistSubscription.Dispose();
    }
}

Client (Interactive)PersistentComponentStateServer (Prerender)Client (Interactive)PersistentComponentStateServer (Prerender)Load DashboardSummaryModelPersist "dashboard-summary"Restore "dashboard-summary"Render without refetch

Outcome: one fetch, stable KPI values, and reduced flicker. This is a common baseline optimisation in Assemblysoft dashboard builds.

Best Practice 2: Eliminate Server-Side HTTP with a Business Abstraction

Avoid server-to-server HTTP by abstracting the data load behind an interface. Provide two implementations: a direct server implementation and an HTTP-based client implementation.

Shared contract

public interface IDashboardSummaryService
{
    Task<DashboardSummaryModel?> LoadAsync();
}

Client implementation (HTTP)

public class ClientDashboardSummaryService : IDashboardSummaryService
{
    private readonly HttpClient _http;

    public ClientDashboardSummaryService(HttpClient http)
    {
        _http = http;
    }

    public Task<DashboardSummaryModel?> LoadAsync()
        => _http.GetFromJsonAsync<DashboardSummaryModel>("api/dashboard/summary");
}

Server implementation (direct domain/data access)

public class ServerDashboardSummaryService : IDashboardSummaryService
{
    public Task<DashboardSummaryModel?> LoadAsync()
    {
        // Direct database / domain access (EF Core, repositories, etc.)
        return Task.FromResult(new DashboardSummaryModel());
    }
}

Blazor ComponentIDashboardSummaryServiceClientDashboardSummaryService
HTTPServerDashboardSummaryService
Direct AccessAPI EndpointDatabase

This pattern improves performance and observability by removing unnecessary internal HTTP hops—especially important in high-traffic dashboards.

Assemblysoft commonly applies this approach when building modern line-of-business systems and multi-tenant SaaS modules. Learn more at Assemblysoft Software Development.

A Simpler (Often Better) Pattern: Server Host + Interactive Child

In many real-world screens, the cleanest approach is to separate responsibilities:

  • Host component: server-only, fetches data directly
  • Child component: interactive, receives data via parameters and focuses on UX

Server-only host component

@page "/dashboard"
@inject IDashboardSummaryService DashboardSummaryService

<DashboardSummaryPanel
    Model="_dashboardSummary"
    @rendermode="InteractiveAuto" />

@code {
    private DashboardSummaryModel? _dashboardSummary;

    protected override async Task OnInitializedAsync()
    {
        _dashboardSummary = await DashboardSummaryService.LoadAsync();
    }
}

Interactive child component (no fetching, no persistence plumbing)

@code {
    [Parameter]
    public DashboardSummaryModel? Model { get; set; }
}

Syntax error in textmermaid version 10.9.5Why Assemblysoft recommends this pattern: fewer moving parts, clearer separation of concerns, easier testing, and excellent UX. This is particularly effective for dashboards, planners, and workflow screens that need interactivity without re-implementing data access logic in every render mode.

How Data Crosses Render Mode Boundaries

When a server-rendered host passes parameters to an Auto-rendered child, Blazor serialises parameters, embeds them into the HTML payload, and rehydrates them on the client during interactive startup. You design for this behaviour by keeping the child component parameter-driven.

Practical takeaway: interactive components should generally avoid owning data-fetch responsibilities unless there is a strong reason.

When InteractiveAuto Delivers the Most Value

Based on delivery experience, InteractiveAuto is most valuable when:

  • Users perform meaningful interaction (forms, planners, filters, editable grids)
  • You want WASM performance benefits when possible, but need reliable fallback
  • First paint and perceived responsiveness matter (dashboard/landing screens)
  • Connectivity is variable and resilience is required

For purely read-only content, static SSR is often sufficient—and may reduce operational complexity.

Why Assemblysoft Takes a Deliberate Render Strategy

Blazor render modes are an architectural tool, not a novelty feature. Assemblysoft designs render strategies into:

  • Legacy system modernisation programmes
  • Multi-tenant SaaS platforms
  • Field-first applications and offline-capable modules
  • High-performance executive dashboards

If you are planning a Blazor build or modernisation and want to avoid rework while delivering a great UX, you can speak with Assemblysoft here: https://assemblysoft.com/contact.

Final Summary

Blazor Auto render mode enables fast, resilient, user-friendly applications—when paired with the right architecture.

  • Use PersistentComponentState to prevent duplicate loads and avoid KPI flicker
  • Abstract business logic behind interfaces to support both server-direct and client-HTTP execution
  • Avoid server-side HTTP where possible to reduce latency and tracing noise
  • Prefer the server host + interactive child pattern for clarity and maintainability

These patterns are proven in production and are designed to keep UX smooth while controlling operational complexity.