Blazor: In-memory state container as cascading parameter

[lonix1]

[EDIT by guardrex: The current approach for the in-memory state container service is located at In-memory state container service.]

The "In-memory state container service" section shows a state container as a service.

For simple app-wide stuff, it is simpler to use a cascading value. I posted a related question (with working code) to StackOverflow. (UPDATE: "MrC" posted another very nice solution.)

For example, working code:

AppState.razor

<CascadingValue Value="this">
  @ChildContent
</CascadingValue>

@code {

  private bool _isDirty;

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

  protected override async Task OnAfterRenderAsync(bool firstRender) {
    await base.OnAfterRenderAsync(firstRender);
    if (firstRender) {
      await LoadStateFromLocalStorage();
    }
    if (!firstRender && _isDirty) {
      await SaveStateToLocalStorage();
      _isDirty = false;
    }
  }

  private bool _isDarkMode;
  public bool IsDarkMode {
    get {
      return _isDarkMode;
    }
    set {
      if (value == _isDarkMode) return;
      _isDarkMode = value;
      StateHasChanged();
      _isDirty = true;
    }
  }

  //other properties...

  private async Task LoadStateFromLocalStorage() {
    Console.WriteLine("LOADED!");
    await Task.CompletedTask;
  }

  private async Task SaveStateToLocalStorage() {
    Console.WriteLine("SAVED!");
    await Task.CompletedTask;
  }

}

App.razor

<AppState>
  <Router>
    ...
  </Router>
</AppState>                                                          

MyComponent.razor

<!--- markup --->

@code {
  [CascadingParameter] public AppState AppState { get; set; }

  //...
}

It would be nice to have that as another section, e.g. "In-memory state container as cascading parameter".

---

Document Details

⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

• ID: ae14b3e3-3271-b919-9e0a-6f317a6b2d2d
• Version Independent ID: e5e1273b-195e-5da1-b4aa-66bbcff1425b
• Content: ASP.NET Core Blazor state management
• Content Source: aspnetcore/blazor/state-management.md
• Product: aspnet-core
• Technology: aspnetcore-blazor
• GitHub Login: @guardrex
• Microsoft Alias: riande

[guardrex]

Thanks for sending this in, @lonix1. We will take a look at it. However, we're booked with a lot of high priority work right through the end of the year, so we won't be able to reach this until early 2023. It won't get lost tho! It will be on a tracking issue.

[lonix1]

No worries - I'm using the above to great effect. It may help others if offered as an alternative.

[guardrex]

Here's the @ShaunCurtis approach posted at SO.

Reference: https://stackoverflow.com/a/74080605

Here's a different solution that I think resolves most of the issues in your implementation. It loosely based on the way EditContext works.

First separate out the data from the component. Note the Action delegate that is raised whenever a parameter change takes place. This is basically the StateContainer in the linked MSDocs article.

public class SPAStateContext
{
    private bool _darkMode;
    public bool DarkMode
    {
        get => _darkMode;
        set
        {
            if (value != _darkMode)
            {
                _darkMode = value;
                this.NotifyStateChanged();
            }
        }
    }

    public Action? StateChanged;

    private void NotifyStateChanged()
        => this.StateChanged?.Invoke();
}

Now the State Manager Component.

1. We cascade the SPAStateContext not the component itself which is far safer (and cheaper).
2. We register a fire and forget handler on StateChanged. This can be async as the invocation is fire and forget.

@implements IDisposable

<CascadingValue Value=this.data>
    @ChildContent
</CascadingValue>

@code {
    private readonly SPAStateContext data = new SPAStateContext();

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

    protected override void OnInitialized()
        => data.StateChanged += OnStateChanged;

    private Action? StateChanged;

    // This implements the async void pattern 
    // it should only be used in specific circumstances such as here in a fire and forget event handler
    private async void OnStateChanged()
    {
        // Do your async work
        // In your case do your state management saving
        await SaveStateToLocalStorage();
    }

    protected override async Task OnAfterRenderAsync(bool firstRender)
    {
        if (firstRender)
            await LoadStateFromLocalStorage();
    }

    public void Dispose()
        => data.StateChanged -= OnStateChanged;
}

Additional context is in the discussion on the SO comment Q&A.

[guardrex]

@lonix1 ... AFAICT, we already have this approach covered (generally anyway ... i.e., a state-providing cascaded component) at ...

https://learn.microsoft.com/en-us/aspnet/core/blazor/state-management?view=aspnetcore-6.0&pivots=server#factor-out-the-state-preservation-to-a-common-location

[guardrex]

Yeah 🤔 ... That's close enough conceptually that we don't need to take action on this. This issue will remain associated with the topic on GitHub, so if devs select the View all page feedback link, they'll see this issue and can see the other example approaches/discussion from there.

Thanks for writing in on it. 👍

[lonix1]

"View all page feedback" link - amazingly useful feature. It's buried at the very bottom so I never noticed it until now. Thanks.

[guardrex]

Yeah ... I don't like what they did with that because it would have helped us probably HUNDREDS of times both with readers looking for things here and even US ... the doc 🐈🐈🐈 ... I've forgotten about it myself tucked way down there. Anyway ... that's where they want it, so that's where it will stay.

[lonix1]

I didn't notice the "Factor out the state preservation to a common location" section that you pointed me to, because it's only shown when choosing the blazor server option (I'm using wasm).

If it covers the same idea as what I posted above, and is applicable to wasm as well, maybe it should appear for wasm too?