Blazor Tutorial - EP 25 - State Management with Flux in C# - Part 1

🎁ALL-ACCESS Subscription: Unlock access to all of my courses, both now and in the future at a low $19.99 / month.

💎Learn .NET MAUI while creating a Contacts App in .NET 7:

🔥Learn Blazor while creating an Inventory Management System in .NET 6

💎 Complete Guide to ASP.NET Core Identity

💎Complete Blazor Course: Build an e-commerce app with ASP.NET Blazor and Clean Architecture

💎 Complete Web API Course:

👍Architecture Course

[FrankLiuSoftware]

💎My New Blazor Course: Build an e-commerce app with ASP.NET Blazor and Clean Architecture

[petermorris]

Hi Frank - I'm the author of Fluxor (Flux for .Net)

Don't forget to implement IDisposable in your consuming component so you can remove the state changed listener, or your component will remain in memory for the lifetime of the app.

Instead of

AddStateChangedListeners(() => { StateHasChanged(); });

You can write


Then your IDisposable can remove StateHasChanged.

[FrankLiuSoftware]

I skipped demonstrating removing of the listeners. But in your code, please remove your listeners by implementing the IDisposable interface and detach your listeners from the store.

The reason for that is that the components are constantly being created and disposed, but the Stores are held in the memory till the connection is broken (Blazor Server) or you refresh the screen (In Blazor WebAssembly, when refreshing, the web assemblies are downloaded again to the front end, hence the stores are recreated). If you don't detach the listeners, the store will always hold a reference to the components which prevent the garbage collectors to delete the components from memory. Essentially, that makes the components scoped to the connection or singleton.

So don't forget to remove the listeners.

[matthewchristenson]

Hello and thank you for writing this tutorial! I have a question that I have had a hard time finding the answer to. When utilizing react, I understand that it's important to use immutable objects because there's a difference evaluation taking place to decide what parts of the dom would need to be changed. What I don't understand is that in Blazor when we're using broadcasts to say "the state is different now" why is it important that we use immutable types? Wouldn't it be a lot easier to just change values in mutable types, and then call the broadcast method enabling blazor components to re-render themselves based on the new state? I feel like I am missing something here and I would love to get your perspective!

[farrenyoung]

Thanks for your continued work on this series.