Signals (Reactivity Components) for Blazor Interactive Render Modes

[linkdotnet]

Summary

This proposal introduces a native-like reactive state management paradigm to Blazor using Signals (as in Angular Signals: https://angular.dev/guide/signals). It provides automatic dependency tracking to update components when data changes, eliminating the need to manually invoke StateHasChanged().

Motivation and goals

• Blazor does not automatically trigger UI updates for state changes
  occurring outside of standard UI event handlers or input parameter updates (e.g., inside background threads, async tasks, or timer callbacks). Developers are forced to manually invoke StateHasChanged(), which leads to boilerplate, error-prone code, and
  maintenance overhead.
• Provide a declarative mechanism inspired by modern frameworks (like
  Angular Signals) that automatically intercepts reads and triggers precise, automated
  component updates.

In scope

1. Reactive primitives for "state management" (Signal<T>, Computed<T> and friends)
2. Track dependencies between those so we know when to re-render something and update the dependency graph

Out of scope

1. I am not sure how SSR fits in here at this point in time. This proposal is strictly meant for Interactive Server/WASM.
2. Angular has many many more "signal" like things (resource or httpResource or even complete forms). While "nice", the initial batch of 3 to 5 (like Effect or Input) would be "good enough".

Risks / unknowns

Without deeply integrating into the Blazor Rendering Pipeline itself, we would need a wrapper component handling subscriptions etc. Therefore this could lead to a major driver of complexity inside the Blazor Renderer itself.

Examples

Here is an example taken from my blogpost where I dabbled with the idea. It utilizes a reactive wrapper as boundary. Ideally we wouldn't have that in the final design.

@page "/Signal"
@implements IDisposable

<h3>Signal use</h3>

<Reactive>
    <p>Elapsed time: @elapsedMilliseconds.Value milliseconds</p>
    <p>Computed elapsed time: @elapsedSeconds.Value seconds</p>
</Reactive>

@code {
    private readonly Signal<int> elapsedMilliseconds = Signals.Signal(0);
    private Computed<int> elapsedSeconds = null!;
    private Timer? timer;

    protected override void OnInitialized()
    {
        elapsedSeconds = Signals.Computed(() => elapsedMilliseconds.Value / 1000);
        timer = new Timer(
            _ => elapsedMilliseconds.Update(value => value + 1000),
            null,
            TimeSpan.Zero,
            TimeSpan.FromSeconds(1));
    }

    public void Dispose()
    {
        timer?.Dispose();
    }
}

[fedeAlterio]

Take a look to that implementation of signals in .NET. I think it's really close to what you are searching for. The syntax is really close too 😄

It supports Signals, Computed, LinkedSignals, Effects, Async computed and async effect (close to resources in angular), untracked, dictionary signals, observable collections signals.

It's built on top of R3. So, signals are basically observables (in angular you have Rxjs interop).

[linkdotnet]

@fedeAlterio thanks for the link. I quickly checked just the implementation. It relies on INotifyPropertyChanged and INotifyCollectionChanged.

Given my example above and my understanding - if you would use "Signals" that implement INotifyPropertyChanged Blazor would still not pick up the change. It doesn't treat those interfaces in any special way (also it can't if we use private fields).

So while this works for WPF and systems that operate on INotifyXChanged it doesn't work for Blazor.

It would need a deeper integration into the Renderer itself to make that happen.

[fedeAlterio]

Yes. Something is missing to make it work. The good thing is that the dependency tracking itself is not dependent from INotifyPropertyChanged, so what's missing is only a way to notify balzor that it should re-render. I think it should be easy to make it work, with few changes

[fedeAlterio]

@linkdotnet i made it work like this:

@page "/counter"
@implements IDisposable

@using SignalsDotnet
@using R3

@Tracked(@<div>
             <h1>Counter</h1>
             <p>
                 Count: @_count.Value <br />
                 Now: @_now.Value
             </p>

             <button class="btn btn-primary"
                     @onclick="() => _count.Value++">
                 Click me
             </button>
         </div>)

@code {

    readonly CancellationDisposable _cd = new();
    readonly Signal<int> _count = new(0);
    IReadOnlySignal<DateTime> _now = null!;

    protected override void OnInitialized()
    {
        _now = Observable
            .Interval(TimeSpan.FromSeconds(1))
            .Select(_ => DateTime.Now)
            .ObserveOnCurrentSynchronizationContext()
            .TakeUntil(_cd.Token)
            .ToSignal();
    }

    private RenderFragment Tracked(RenderFragment fragment) => renderTreeBuilder => Signal.ComputedObservable(() =>
        {
            fragment(renderTreeBuilder);
            return Unit.Default;
        }, () => default)
        .Skip(1)
        .Take(1)
        .TakeUntil(_cd.Token)
        .Subscribe(_ => StateHasChanged());

    public void Dispose() => _cd.Dispose();
}

Basically the trick is that Tracked helper. It wraps the rendering function around a computed, so that every signal accessed while rendering is tracked. Then i subscribe to changes to know when rerender again.

[linkdotnet]

Hey @fedeAlterio - exactly. See also my example above. What you called Tracked I called Reactive. An "arbitrary" boundary to achieve our goal (you can check the link - I went into more detail on my blog, but not necessary for this discussion at all).

But all of the boilerplate should be part of Blazor itself. Otherwise you will end up with a top-level Tracked which forces way too much work (as now the whole tree is potentially dirty).
The point of signals is having, well, a signal on what part of the tree is dirty deterministically.

[fedeAlterio]

I read your blog post, I think the implementation you gave is similar to what SignalsDotnet does. 😄

Each nested reactive block should have its own dependency-tracking boundary. Parent scopes should track only the signals they access directly, not those accessed by nested reactive scopes.
Note that something very similar is already implemented in SignalsDotnet here. If we set a signal, whatever runs inside that setter is not relevant for the current tracking scope, so a new scope is created.

In my opinion a general purpose Signals Library with some specific hooks for blazor/wpf/unity and so on could be a better solution than a specific implementation for blazor. What you think?

[linkdotnet]

Each nested reactive block should have its own dependency-tracking boundary. Parent scopes should track only the signals they access directly, not those accessed by nested reactive scopes.

I totally get that point - the downside of that is that the Developer Experience will suffer. When and if something renders, is a mere implementation detail and can vary widely across .NET versions (not that it does, but it could).

In my opinion a general purpose Signals Library with some specific hooks for blazor/wpf/unity and so on could be a better solution than a specific implementation for blazor. What you think?

Theoretically, yes - practically, I would lean towards the specialized one. Just from the PoV of ergonomics and complexity. Let alone, it is simpler to implement.

[fedeAlterio]

@linkdotnet In the meantime I adapted your excellent blog post to SignalsDotnet. If you want to try it out, you can find it here nuget readme.

Thank you again 😄

[linkdotnet]

@fedeAlterio nice - I try to fiddle around a bit with it and thanks for the shoutout.