This article presents a Redux-inspired architecture (more precisely, the Flux pattern) adapted to Blazor, using the Fluxor library as the reference implementation. The goal is not to add one more tutorial, but to lay out the architectural choices, their trade-offs and the traps to avoid. A final section covers a recent and particularly relevant use of the pattern: framing AI agents that act on your application’s state.

1. The problem: scattered state

In a “classic” Blazor application, state lives in several places:

• fields and properties of components (local state);
• [Parameter] and CascadingValue (state passed from parent to child);
• scoped or singleton services, often with a home-made OnChange event;
• browser storage (localStorage, sessionStorage);
• the URL (route, query string).

The symptoms are well known:

• Scattered mutations: any component can modify a shared service, so “who changed this value, and why?” becomes impossible to answer.
• Inconsistent refreshes: you have to remember to call StateHasChanged() in the right place, and each service invents its own notification mechanism.
• Async logic mixed with UI: API calls, try/catch blocks and loading flags pile up inside components.
• Hard-to-test code: presentation logic is buried in components that are difficult to isolate.

Redux is not the only answer, but it is a proven one, simple in its principles and remarkably readable at scale.

2. The principles of Redux

Redux rests on three rules, inherited from the Flux architecture:

1. A single source of truth: the application state is one tree (the store), split into features.
2. State is read-only: you never modify it directly. The only way to change it is to emit an action, an object describing what happened.
3. Changes go through pure functions: reducers take the current state and an action, and return a new state, with no side effects.

The flow is strictly unidirectional:

Component → Action → Reducer → New state → Component

Side effects (HTTP calls, storage, navigation) are isolated in a dedicated layer, the effects, which receive actions and emit other actions in return.

3. Why this model fits C# and Blazor

The pattern adapts naturally to the .NET ecosystem, for several reasons:

• C# records provide immutability and non-destructive copying with with, exactly what reducers need.
• Strong typing makes actions explicit: no magic strings, and the compiler checks consistency between emitters and consumers.
• Blazor’s rendering model relies on change detection and StateHasChanged(): a store that notifies subscribers when state changes plugs in cleanly.
• Dependency injection lets you supply effects with their services (HttpClient, API clients, logging) without coupling them to components.

4. Architecture overview

The building blocks of a Redux architecture for Blazor:

A simple organizing rule: one folder per feature, containing its state, actions, reducers and effects. This avoids giant technical folders (“Actions”, “Reducers”) that scatter the logic of a single feature.

/eShop
  /Catalog
    CatalogState.cs
    CatalogActions.cs
    CatalogReducers.cs
    CatalogEffects.cs
  /Cart
    CartState.cs
    ...

5. Implementation with Fluxor

Fluxor is the most widely used Redux/Flux implementation for Blazor. It works in Blazor Server and WebAssembly alike.

5.1 Installation and configuration

After adding the Fluxor.Blazor.Web package, register Fluxor in Program.cs:

builder.Services.AddFluxor(options =>
{
    options.ScanAssemblies(typeof(Program).Assembly);
#if DEBUG
    options.UseReduxDevTools();
#endif
});

Then initialize the store in the root component (App.razor or Routes.razor):

<Fluxor.Blazor.Web.StoreInitializer />

5.2 Defining state

State is an immutable record. It holds everything the UI needs, including loading and error indicators.

[FeatureState]
public sealed record CatalogState
{
    public bool IsLoading { get; init; }
    public string? Error { get; init; }
    public IReadOnlyList<Product> Products { get; init; } = [];

    // Parameterless constructor required by Fluxor
    private CatalogState() { }

    public CatalogState(bool isLoading, string? error, IReadOnlyList<Product> products)
        => (IsLoading, Error, Products) = (isLoading, error, products);
}

5.3 Defining actions

Actions are simple records, named as events. A useful convention is to separate the intent (“load the catalog”) from the outcomes (“loaded successfully”, “failed”).

public record LoadCatalogAction;
public record LoadCatalogSuccessAction(IReadOnlyList<Product> Products);
public record LoadCatalogFailureAction(string Error);

5.4 Writing reducers

A reducer is a pure static method. No network call, no clock, no random ID generation: same input, same output.

public static class CatalogReducers
{
    [ReducerMethod]
    public static CatalogState OnLoad(CatalogState state, LoadCatalogAction _)
        => state with { IsLoading = true, Error = null };

    [ReducerMethod]
    public static CatalogState OnSuccess(CatalogState state, LoadCatalogSuccessAction action)
        => state with { IsLoading = false, Products = action.Products };

    [ReducerMethod]
    public static CatalogState OnFailure(CatalogState state, LoadCatalogFailureAction action)
        => state with { IsLoading = false, Error = action.Error };
}

5.5 Handling side effects

Effects are the only place where you talk to the outside world. They are instantiated through dependency injection.

public class CatalogEffects(ICatalogApi api)
{
    [EffectMethod]
    public async Task OnLoad(LoadCatalogAction _, IDispatcher dispatcher)
    {
        try
        {
            var products = await api.GetProductsAsync();
            dispatcher.Dispatch(new LoadCatalogSuccessAction(products));
        }
        catch (Exception ex)
        {
            dispatcher.Dispatch(new LoadCatalogFailureAction(ex.Message));
        }
    }
}

5.6 Consuming state in a component

The component inherits from FluxorComponent, which subscribes to state, triggers a render on every change and unsubscribes cleanly on disposal.

@page "/catalog"
@inherits Fluxor.Blazor.Web.Components.FluxorComponent
@inject IState<CatalogState> State
@inject IDispatcher Dispatcher

@if (State.Value.IsLoading)
{
    <p>Loading…</p>
}
else if (State.Value.Error is not null)
{
    <p class="error">@State.Value.Error</p>
}
else
{
    <ul>
        @foreach (var p in State.Value.Products)
        {
            <li>@p.Name</li>
        }
    </ul>
}

@code {
    protected override void OnInitialized()
        => Dispatcher.Dispatch(new LoadCatalogAction());
}

The component no longer contains API calls, error handling or loading logic: it renders a state and emits intents.

6. Architectural decisions to make

6.1 What goes in the store, and what does not

The classic trap is putting everything in the store. A pragmatic decision grid:

• In the store: data shared across several screens, server data you want to cache, workflow state (cart, multi-step wizard), user preferences.
• Outside the store: purely local, short-lived component state (open menu, value of a field being typed, active tab), values derivable from the URL, data with no value in being traced.

If a piece of state is read by a single component and has no reason to outlive it, keep it local.

6.2 Blazor Server or WebAssembly

The hosting mode changes the scope of the store:

• Blazor WebAssembly: the store lives in the browser, one per tab. This is the closest to Redux on the JavaScript side.
• Blazor Server: the store is registered per circuit (scoped), meaning per connected user session. It must never be a singleton, or state will leak between users.
• Mixed interactive rendering (.NET 8 and later): state must be rebuildable when switching between render modes. Persist what is necessary (for example with PersistentComponentState) and rehydrate the store at initialization.

6.3 Selectors and derived data

Avoid duplicating computable values in state: a cart total is computed from its lines, not stored. Fluxor offers selectors (FeatureStateSelector) to expose derived views and limit unnecessary renders: a component subscribed to a selector is notified only when the selected value changes.

6.4 Feature granularity

Splitting by business domain (Catalog, Cart, Session, Notifications) works better than splitting by screen. Features communicate through actions, not direct references: one feature can react to another’s action through a reducer or an effect without knowing its internal state.

6.5 Persistence

To keep state between sessions (preferences, drafts), you can persist selected features to localStorage through an effect that listens to relevant actions, and rehydrate at startup. Never persist sensitive data in the browser, and version the format to handle evolution.

7. Testing

This is one of the major gains of the approach. Since reducers are pure functions, they can be tested without any component framework:

[Fact]
public void OnSuccess_StopsLoading_And_StoresProducts()
{
    var initial = new CatalogState(true, null, []);
    var products = new List<Product> { new(1, "Kettlebell 16 kg") };

    var result = CatalogReducers.OnSuccess(initial, new LoadCatalogSuccessAction(products));

    Assert.False(result.IsLoading);
    Assert.Single(result.Products);
}

Effects are tested with a mocked dependency (a mock of ICatalogApi) and a spy dispatcher that checks the emitted actions. Components are tested with bUnit by injecting a predefined state: you verify that a given state produces a given render.

8. Observability and debugging

Because the action flow is explicit, it becomes observable. With UseReduxDevTools(), the browser’s Redux DevTools extension shows every action, the state before and after, and lets you navigate through history (time travel). For an enterprise project, it is also a good anchor for telemetry: a middleware can log actions to Application Insights or OpenTelemetry, giving a clear correlation between user journeys and application behavior.

9. Common pitfalls

• Impure reducers: a call to DateTime.Now or Guid.NewGuid() inside a reducer breaks predictability and testing. Generate those values upstream, in the effect or the component, and carry them in the action.
• State mutation: exposing mutable List<T> in a record ruins immutability. Prefer IReadOnlyList<T> or ImmutableList<T>.
• Overly technical actions: SetIsLoadingAction describes a mechanic, not a business event. Prefer actions that say what happened (CatalogLoadRequested, ProductAddedToCart).
• A catch-all store: putting every UI boolean in it multiplies code without benefit.
• Excessive renders: a component subscribed to a large state re-renders on every change. Use selectors or split components.
• Underestimated boilerplate: one action, one reducer and sometimes an effect for a trivial change is the price of traceability. It has to be worth it.

10. When not to use Redux

Redux is a tool, not a goal. For a simple application with a few screens and little shared state, a scoped service with a change notification event is cheaper and perfectly sufficient. The pattern pays off when:

• several teams contribute to the same application;
• state is shared across many components or screens;
• user journeys are asynchronous and complex (workflows, synchronization, real time);
• traceability and diagnostics are strong requirements.

Other approaches exist in the .NET ecosystem, such as the MVU (Model-View-Update) pattern with Blazor, or lighter state containers. The right selection criterion is long-term maintenance cost, not what is fashionable.

11. Redux in the age of AI agents

When an AI agent acts on your application’s state, the Redux store becomes the boundary between what the AI proposes and what the application accepts. This section describes what that changes, and when it is worth it.

11.1 The problem: a non-deterministic actor

An LLM-based agent produces variable outputs, sometimes wrong, sometimes out of scope. Giving it direct access to mutable services or component state is like letting a brilliant but unpredictable intern modify production. The Flux pattern offers a structural answer: the agent never writes to state, it emits actions. Reducers, pure and deterministic, decide what actually changes.

11.2 Actions as a tool catalog

Typed actions form a closed vocabulary of what the application can do. This vocabulary translates almost directly into tools exposed to the agent (function calling or MCP): the action’s name and parameters provide the schema, and the compiler guarantees consistency on the C# side. Three useful rules:

• Allowlist: expose only a subset of actions to the agent, never the whole catalog.
• Intents rather than commands: the agent emits proposal actions (ChangeProposedAction), not actions that directly modify business data.
• Upstream validation: the effect receiving the agent’s output checks parameters (existence, permissions, bounds) before emitting the action.

11.3 Example: the agent proposes, the user decides

Consider an assistant that suggests adding a product to the cart. The agent does not modify the cart: it proposes, and the user approves or rejects. Actions describe each step explicitly.

public record ChangeProposal(Guid Id, string Description, CartItem Item);

public record UserAskedAssistantAction(string Prompt);
public record ChangeProposedAction(ChangeProposal Proposal);   // emitted after the agent call
public record ChangeApprovedAction(ChangeProposal Proposal);   // emitted by the user
public record ChangeRejectedAction(Guid ProposalId);           // emitted by the user
public record ProductAddedToCartAction(CartItem Item);         // business action

The assistant’s state contains only what the interface needs: the pending proposal and a thinking indicator.

[FeatureState]
public sealed record AssistantState
{
    public bool IsThinking { get; init; }
    public ChangeProposal? Pending { get; init; }
}

public static class AssistantReducers
{
    [ReducerMethod]
    public static AssistantState OnAsk(AssistantState s, UserAskedAssistantAction _)
        => s with { IsThinking = true, Pending = null };

    [ReducerMethod]
    public static AssistantState OnProposed(AssistantState s, ChangeProposedAction a)
        => s with { IsThinking = false, Pending = a.Proposal };

    [ReducerMethod]
    public static AssistantState OnApproved(AssistantState s, ChangeApprovedAction _)
        => s with { Pending = null };

    [ReducerMethod]
    public static AssistantState OnRejected(AssistantState s, ChangeRejectedAction _)
        => s with { Pending = null };
}

The effect bridges to the agent, then, only after approval, to the business action.

public class AssistantEffects(IAgentClient agent, ICartRules rules)
{
    [EffectMethod]
    public async Task OnAsk(UserAskedAssistantAction action, IDispatcher dispatcher)
    {
        var proposal = await agent.ProposeAsync(action.Prompt);

        // Guardrail: the LLM output is validated before it reaches state
        if (rules.IsAllowed(proposal.Item))
            dispatcher.Dispatch(new ChangeProposedAction(proposal));
    }

    [EffectMethod]
    public Task OnApproved(ChangeApprovedAction action, IDispatcher dispatcher)
    {
        dispatcher.Dispatch(new ProductAddedToCartAction(action.Proposal.Item));
        return Task.CompletedTask;
    }
}

The component displays the pending proposal with two buttons, Approve and Reject, each emitting the matching action. No decision logic lives in the UI, and no business change goes through without human validation.

11.4 Streaming, cancellation and errors

LLM responses arrive as streams. The pattern fits well: actions such as TokenReceivedAction, ResponseCompletedAction, ResponseFailedAction and GenerationCancelledAction describe the lifecycle, the effect manages the stream and the cancellation token, and components simply render the current state. This avoids scattering try/catch blocks and StateHasChanged() calls across the UI.

11.5 Traceability and evaluation

The action log is a natural trace of what the agent proposed, what the user accepted and what actually changed. It serves several purposes:

• Audit: who decided what, based on which proposal.
• Diagnostics: replay a session to understand unexpected behavior.
• Evaluation: replay the same inputs with another prompt or model version, and compare the proposals.

11.6 When it is not necessary

A simple chatbot that displays answers does not need Redux: a scoped service calling the LLM is enough. The pattern becomes relevant when the agent acts on the application (data changes, workflow triggers) and you need validation, undo or traceability. It also helps indirectly with AI-assisted development: a very conventional organization (one folder per feature, with state, actions, reducers and effects) gives a coding assistant such as GitHub Copilot a clear framework to follow, especially if these conventions are described in an instructions file.

Conclusion

Redux brings to Blazor what growing applications lack most: a clear discipline about how state changes. A single store, explicit actions, pure reducers and isolated effects turn scattered state into a readable, testable and observable flow. With Fluxor, the implementation stays lean and integrates naturally with dependency injection and Blazor’s component system.

In the age of AI agents, this discipline takes on an extra dimension: the store becomes the boundary between what the AI proposes and what the application accepts, with a complete trace of decisions.

The real architectural question is therefore not “Redux or not Redux?” but “what is the right perimeter for my application’s shared state?” Once that boundary is drawn, the Flux approach provides a proven framework to enforce it.

Further reading

• Fluxor repository and documentation: github.com/mrpmorris/Fluxor
• Microsoft documentation on state management in Blazor (ASP.NET Core Blazor state management)
• Redux DevTools, the browser extension to inspect actions and state