Add a section on cascading values/parameters for state management with multiple subscribers

[hakenr]

Description

I think the Factor out the state preservation to a common location section has some issues that make it incomplete or problematic:

1. Prerendering Issue:
   The provided example fails during prerendering because ProtectedSessionStore.GetAsync cannot be invoked from OnInitialized. To fix this, prerendering must be disabled for the example to function correctly. See this code. A possible solution is changing the render mode to something like new InteractiveServerRenderMode(prerender: false).

2. Issue with Multiple Subscribers:
   The CounterStateProvider fails when more than one component subscribes to [CascadingParameter] private CounterStateProvider? CounterStateProvider. The cascading value in this case is the CounterStateProvider component instance (this), which doesn't change after being set (you could even set IsFixed="true"). Since the actual counter value (CurrentCount) changes internally, the CascadingValue component is not being re-rendered (allowing the new value to be distributed to subscribers) and updates to CurrentCount are not propagated to other components subscribed to the cascading value. (The only situation when CascadingValue component notifies the subscribers of changes is when the CascadingValue itself receives new parameters in SetParametersAsync.)

   Steps to Reproduce:

   • Follow the documentation steps, fixing the prerendering issue as mentioned above.
   • Create a new SubCounter.razor component, duplicating the content of Counter.razor but without the @page directive.
   • Add <SubCounter /> to Counter.razor so both components render simultaneously.
   • Test the two Increment buttons (one in Counter.razor and the other in SubCounter.razor). You'll notice that updating the counter in one component doesn't trigger updates in the other.

   

   The current implementation of CounterStateProvider doesn't include a mechanism to notify subscribers about state changes. Without such notifications, this approach is effectively just another way to inject a service into components. If the intent is to use cascading values/parameters for proper state management, the "state" (e.g., CurrentCount) should be the cascading value distributed, not the "provider" (e.g., the CounterStateProvider component).

   Suggestion for Improvement:
   To use cascading values/parameters effectively for state management, we could use CascadingValueSource<T>. This pattern is used in Blazor's built-in AuthenticationStateProvider, as seen in the AuthenticationStateCascadingValueSource implementation. By propagating the actual state (CurrentCount) rather than the provider, changes would trigger proper re-renders of subscribed components.

(I can try proposing new content using the CascadingValueSource, but it'll probably take some time to prepare since I'm pretty busy with other projects right now.)

Page URL

https://learn.microsoft.com/en-us/aspnet/core/blazor/state-management?view=aspnetcore-9.0&pivots=server

Content source URL

https://github.com/dotnet/AspNetCore.Docs/blob/main/aspnetcore/blazor/state-management.md

Document ID

e5e1273b-195e-5da1-b4aa-66bbcff1425b

Article author

@guardrex

Related Issues

[github-actions]

🍂🎃🏮 OOF: Back on Monday, 12/2 🥧☕🍂

Stand by! We're out of the office for the Thanksgiving holiday 🦃.

A green dinosaur 🦖 will be back on Monday (12/2) to assist.

[hakenr]

Runnable repro (described above): https://github.com/hakenr/BlazorDocCounterStateProviderIssueRepro

[guardrex]

UPDATE (12/5): Same deal here ... buried at the moment ⛰⛏😅 and held up with other tasks and internal projects. We'll get back to this as soon as possible. 🏃

[guardrex]

UPDATE (12/11): I'm still waiting on a free engineer (or Dan) to pitch in with feedback. Truly ... at this rate ... we might not reach this until 25Q1 because we're right on the edge of folks bugging out for the ⛄ holidays.

First off on what's currently there, I agree that there's a remark missing about disabling prerendering at the top for the section. There's a remark later in the section about seeing the Handle prerendering section, which includes an example that can't really can't just be dropped into place here. The example really should go something like this ...

@using Microsoft.AspNetCore.Components.Server.ProtectedBrowserStorage
@inject ProtectedSessionStorage ProtectedSessionStore

@if (isConnected)
{
    <CascadingValue Value="this">
        @ChildContent
    </CascadingValue>
}
else
{
    <p>Loading...</p>
}

@code {
    private bool isConnected;

    [Parameter]
    public RenderFragment? ChildContent { get; set; }

    public int CurrentCount { get; set; }

    protected override async Task OnAfterRenderAsync(bool firstRender)
    {
        if (firstRender)
        {
            isConnected = true;
            await LoadStateAsync();
            StateHasChanged();
        }
    }

    private async Task LoadStateAsync()
    {
        var result = await ProtectedSessionStore.GetAsync<int>("count");
        CurrentCount = result.Success ? result.Value : 0;
        isConnected = true;
    }

    public async Task IncrementCount()
    {
        CurrentCount++;
        await ProtectedSessionStore.SetAsync("count", CurrentCount);
    }
}

... and then a counter component would be like ...

<h2>Counter</h2>

<p>Current count: <strong>@CounterStateProvider?.CurrentCount</strong></p>
<button @onclick="IncrementCount">Increment</button>

@code {
    [CascadingParameter]
    private CounterStateProvider? CounterStateProvider { get; set; }

    private async Task IncrementCount()
    {
        if (CounterStateProvider is not null)
        {
            await CounterStateProvider.IncrementCount();
        }
    }
}

... and then we would end up at least working well for what's here, which then leads to the main thrust of your suggestion ...

The current implementation of CounterStateProvider doesn't include a mechanism to notify subscribers about state changes. Without such notifications, this approach is effectively just another way to inject a service into components. If the intent is to use cascading values/parameters for proper state management, the "state" (e.g., CurrentCount) should be the cascading value distributed, not the "provider" (e.g., the CounterStateProvider component).

... but they might have a difference of opinion on that, which is more like your last remark ... that they did intend for the provider to be cascaded like this.

We could be speaking to TWO scenarios here, the existing approach and "propagating the actual state (CurrentCount) rather than the provider, changes would trigger proper re-renders of subscribed components."

That's the part that I suspect that they'll like to see rolled in here, and IDK if they want to maintain the current explanation (with a changed section heading that explains this is about cascading the provider) and add a new section for cascading the state itself.

🤔 The thing that seems nice about the current approach is that the provider can provide a lot of flexibility to callers for processing ON state. This is a nice approach for scenarios that need it.

Anyway ... I would like to make a quick "addresses" PR myself here to fix up the prerendering piece. That part I think we agree is weak at the moment. I'll ping you for review on the PR.

[guardrex]

First round draft updates are on #34337 to at least get the ball rolling.

I think we'll be able to fix the obvious problems with the current section on that PR, and then this issue and anther PR will be about adding a section on ...

propagating the actual state (CurrentCount) rather than the provider, changes would trigger proper re-renders of subscribed components

We can continue to discuss that aspect here on the issue. I'm still trying to get a PU cat on here, so we'll see what they say when they arrive.