State Management

State is the data your interface currently depends on: which employee is selected, what the search box holds, who is signed in. Storing it is never the hard part. The hard part is deciding who owns each piece, and how the components that care find out it changed.

Blazor gives you three answers and they are not equal. Parameters, which you already know. Cascading values, for something genuinely ambient. A registered service, for state that several unrelated components need. They are listed in that order deliberately: each one reaches further than the last, and each one hides more of what a component depends on.

The advice that follows is one sentence long. Use the narrowest option that works, and move outwards only when passing values through has started to hurt for real rather than in theory.

@page "/board"
@rendermode InteractiveServer

<EmployeeFilter Term="term" OnTermChanged="ApplyTerm" />

<EmployeeList Employees="visible"
              SelectedId="selectedId"
              OnSelect="Select" />

@if (selected is not null)
{
    <EmployeeDetail Employee="selected" />
}

@code {
    private List<Employee> all = [];
    private List<Employee> visible = [];
    private int? selectedId;

    private Employee? selected => all.FirstOrDefault(e => e.Id == selectedId);

    private string term = "";

    private void ApplyTerm(string value)
    {
        term = value;
        visible = all
            .Where(e => e.Name.Contains(value, StringComparison.OrdinalIgnoreCase))
            .ToList();
    }

    private void Select(int id) => selectedId = id;
}

• Three children, one owner. The board holds the term and the selection; the children receive what they need and announce what happened. Nothing else in the application knows this state exists.
• The selection is stored as an id rather than as an Employee. The list can be reloaded and the selection survives, because an id stays valid where an object reference does not.
• This costs nothing to read. Open the file and the state is in front of you, along with every component allowed to affect it. No search is needed to find out what changes what.
• It is also the only option here that a compiler helps with. Rename a parameter and every caller breaks at build time. A service or a cascading value gives you no such warning.
• The limit is visible too. Add three more levels of components between the board and the row, and every level has to accept and forward parameters it has no interest in. That is the point where the next two options earn consideration — not before.

@inherits LayoutComponentBase
@inject IPortalUserAccessor UserAccessor

<CascadingValue Value="signedInUser" IsFixed="true">
    <div class="portal">
        <main id="main">@Body</main>
    </div>
</CascadingValue>

@code {
    private PortalUser? signedInUser;

    protected override async Task OnInitializedAsync() =>
        signedInUser = await UserAccessor.GetCurrentAsync();
}

@* Any descendant, at any depth, without a single parameter being forwarded *@
@code {
    [CascadingParameter]
    public PortalUser? SignedInUser { get; set; }

    private bool ShowAdminTools => SignedInUser?.IsHrAdmin is true;
}

• CascadingValue supplies a value to everything rendered inside it. Descendants pick it up with [CascadingParameter] and nothing in between has to forward it.
• Matching is by type by default, which is why the property type is PortalUser and not string. Two cascading values of the same type need a Name on both ends to stay distinguishable.
• IsFixed="true" says this value will not change while the layout lives. Blazor then skips the bookkeeping that lets it notify descendants, which is measurable in a deep tree. Set it and then change the value, and descendants keep the old one with no error to tell you.
• A missing cascading value is null, not an exception. Move the component somewhere without the ancestor and it renders with no user and no complaint, so the nullable type here is doing real work.
• Keep this for what is genuinely ambient: the signed-in user, a theme, a tenant, the authentication state the next lesson uses. Once you are cascading the selected employee, the dependency has become invisible in the markup and the coupling is back — just harder to see than a parameter.

// Services/SelectionState.cs
public sealed class SelectionState
{
    public int? SelectedEmployeeId { get; private set; }

    public event Action? Changed;

    public void Select(int? employeeId)
    {
        if (SelectedEmployeeId == employeeId)
        {
            return;
        }

        SelectedEmployeeId = employeeId;
        Changed?.Invoke();
    }
}

// Program.cs — per circuit in Blazor Server, so per user
builder.Services.AddScoped<SelectionState>();

• The value has a private setter and changes through a method. One place can change it, and that place raises the notification, so the two can never drift apart.
• The guard clause is not tidiness. Raising Changed when nothing changed re-renders every subscriber for nothing, and in a tree with twenty subscribers that is where a frame budget goes.
• Changed is a plain C# event and the service references nothing from Blazor. It stays unit-testable, and rendering concerns stay in the components where they belong.
• AddScoped means one instance per circuit in Blazor Server, which is one per user per tab. A singleton here would share one person's selection with everybody signed in, which is a data-disclosure bug rather than a rendering one.
• In WebAssembly scoped and singleton are the same thing, because the scope is the application in that tab. The registration still reads as the intent, and it behaves correctly if the component is ever moved to a server render mode.

@inject SelectionState Selection
@implements IDisposable

<p role="status">
    @if (Selection.SelectedEmployeeId is int id)
    {
        <span>Selected employee: @id</span>
    }
    else
    {
        <span>No employee selected</span>
    }
</p>

@code {
    protected override void OnInitialized() => Selection.Changed += OnSelectionChanged;

    private void OnSelectionChanged() => InvokeAsync(StateHasChanged);

    public void Dispose() => Selection.Changed -= OnSelectionChanged;
}

• StateHasChanged is needed here because nothing the framework invoked caused the change. Blazor re-renders automatically after an event handler it called; a notification arriving from a service is outside that, so you ask for the render yourself.
• InvokeAsync moves the call onto the renderer's synchronisation context. If the notification came from a timer, a background service or another component's async work, calling StateHasChanged directly is a threading bug that reproduces intermittently. Wrapping it costs nothing when you are already on the right context.
• Subscribing in OnInitialized rather than in the markup or a property means it happens exactly once per component instance.
• Dispose removes the handler. Skip it and the service keeps a reference to a component that has gone, so it is never collected and is still asked to render. In Blazor Server the circuit can live for hours, so the leak grows with every navigation.
• @implements IDisposable is what makes Blazor call Dispose when the component is removed. Writing the method without the directive compiles and never runs, which is a quiet way to keep the leak.
• role="status" so the change is announced. A banner that updates silently is information a screen reader user never receives.