ASP.NET Community Standup – Blazor: Flavors of State Management with Blazor WebAssembly


[ad_1]
https://i.ytimg.com/vi/ovgNl_ck22w/hqdefault.jpg



Join us for the July Blazor Community Standup with William Liebenberg and Chris Clement!

Details from William Liebenberg:

Working with Blazor WebAssembly applications we often overlook the importance of appropriate state management. Without a good understanding and the right strategy, our applications can end up polluted with components that behave badly and we end up regretting the bad choices.

In this session, I will cover the simple state management flavours and then progress towards something more tasty like the Redux pattern. We will see what there is to like and dislike about each flavour. Next, we will take a step back and determine the appropriate seasoning of state management to pair with our application. You will leave this session having sampled all the wonderful flavours and be able to make great decisions to have the best development experience.

Community Links: https://www.theurlist.com/blazor_community_standup_july_2022

Featuring: William Liebenberg (@William_DotNet), Chris Clement (@christo_ment), Tanay Parikh (@_TanayParikh), Jon Galloway (@jongalloway)

Get your questions answered on the Microsoft Q&A for .NET – https://aka.ms/dotnetqa

Learn .NET with free self-guided learning from Microsoft Learn: http://aka.ms/learndotnet

#Blazor #WebAssembly #StateManagement

Original source


13 responses to “ASP.NET Community Standup – Blazor: Flavors of State Management with Blazor WebAssembly”

  1. I am with Andrew B. I rather build it by myself than relying on a third party package which does some magic. I don't want to let all my components inherit from a third party component. That is too much coupling to code from somebody else. And when time passes or new developer come in, they will not know what that third party package is doing or how to use it.

  2. So, I love AppState Pattern and manage it on a “StateManager<T>” service that I inject everywhere that needs the state of that object. When it updates I fire an Action that anything that has it injected can subscribe to and fire StateHasChanged as needed based on the changes.

  3. The answer to the question "Is that app state global to the app or to the current user?" wasn't entirely accurate. If you have an app that requires authentication and the current user changes the state, then logs out and logs in as a different user, the app is still running and, therefore, the state remains because it's registered as a singleton (which it has to be – or at least scoped – to work across different pages).

  4. My understanding of StateHasChanged – calling it causes blazor to render the entire UI again in the virtual DOM. It then compares to the actual DOM to see if there are any changes. If there are then Blazor only updates the parts that have changed.

    This is incredibly efficient and simple (compared to trying to track changes and work out which bits of ui need to be updated).

Leave a Reply