Cross-store coordination

BlexManager

The manager aggregates every registered store into one global state tree, runs the middleware pipeline, feeds the DevTools bridge and applies time-travel snapshots. Most application code never touches it - you inject stores. You reach for the manager when you need coordination, a global snapshot, or dynamic registration.

Subscribing to actions

Subscribe and its filtered variants are the building block for coordination: react to one store's action and drive another. Handler exceptions are isolated and routed to OnError, so a misbehaving reactor cannot break dispatch for everyone else.

// Everything from one store type
manager.SubscribeTo<CounterStore>(ctx => Console.WriteLine(ctx.QualifiedName));

// One action, by bare or qualified name
manager.SubscribeToAction("Increment", ctx => _analytics.Track("increment"));
manager.SubscribeToAction("counter/Increment", ctx => { });

// Anything, with your own filter
manager.Subscribe(
    ctx => _log.Add(ctx.QualifiedName),
    filter: ctx => ctx.Args.Count > 0);

// Dispose the returned token to stop observing.

The action context

Every observer receives a BlexActionContext describing what just happened.

Async reactors

SubscribeAsync lets a reactor start async work - typically an effect on another store. The returned task is observed, so a failure is reported through OnError rather than surfacing as an unobserved exception.

manager.SubscribeAsync(
    async ctx => await profileStore.Reload(),
    filter: ctx => ctx.QualifiedName == "auth/SignIn");

Derived values that span stores

A subscription answers "tell me when this changed". The other half of the problem is "give me this value, cheaply, from several places at once" - and that is what [BlexComputed] does inside one store. CreateSelector lifts it to the manager: a lazy, memoized projection over the whole tree that recomputes at most once per action, however many readers ask for it.

// Created once, read from anywhere.
var summary = manager.CreateSelector(
    () => $"{orders.Units} unit(s) · {notifications.Unread} message(s)");

summary.Value;   // computes
summary.Value;   // cached
orders.Place("Widget", 2);
summary.Value;   // recomputes, once, for every reader

summary.Dispose();   // detaches from the manager

// In a component, let the base class own it:
protected override void OnInitialized()
{
    _summary = Manager.CreateSelector(() => Orders.Units + Cart.Lines.Count);
    OwnsSubscription(_summary);
}

Where to put the wiring

Three practical options, in rough order of preference:

• A component that owns the lifetime - OwnsSubscription(...) in OnInitialized. Good when the coordination only matters while some part of the UI is alive. This page does exactly that.
• Middleware - register an IBlexMiddleware that reacts in OnAction. Good for app-wide, always-on rules. See Middleware.
• A coordinator service - a scoped service that subscribes in its constructor and disposes its tokens. Resolve it once at startup so it exists.

Dynamic registration

Stores register themselves when first resolved from DI, and <BlexProvider> registers everything up front. For a lazily-loaded feature you can register and unregister by hand. An unregistered store keeps working standalone - its actions simply stop being observed.

var featureStore = new FeatureStore();
manager.Register(featureStore);      // now observed: middleware, DevTools, history, persistence

// ... when the feature is torn down
manager.Unregister(featureStore);    // still usable, just no longer observed