This is the first in a short series of blog posts where I will go beyond the introductory level and dig a bit deeper into using the Fluxor library in a Blazor Wasm project.
If you have written any application using Microsoft's Blazor WebAssembly SPA (single-page application) framework, you will have immediately encountered the challenge of maintaining the state of your application's components while navigating around the application. The out-of-the-box template provides no mechanism for managing state, nor any guidance for how to start.
This can be easily seen using the template's example "Counter" page. Click on the button and see the counter increment. If you navigate away and come back, that previous counter state is lost as the component resets.
If you want to maintain that component's state, it's up to the developer to determine how.
In the video, Carl demonstrates one strategy for managing and interacting with application state by creating a "AppState" service and a cascading parameter that all of the components can reference. Good stuff.
But, since Blazor is essentially a SPA, it's useful to consider how other SPA frameworks manage state. For instance, how does React do it? As it turns out, there are a lot of state management libraries that can be used with React, but one of the original (and still most commonly used) libraries is Redux.
Redux uses a an architectural pattern called Flux, introduced by Facebook developers several years ago to help them manage the growing complexity of the Facebook application. There's a great video on YouTube where the Facebook engineering team explain how and why they developed the Flux pattern alongside React:
The Flux pattern is distinguished by its unidirectional flow of changes to a
Store that holds the application
State, mediated by a
Dispatcher that directs dispatched
Actions to the appropriate Store functions (
Effects) that manage the State in a controlled manner.
Is it possible to use the Flux pattern with Blazor? Sure it is. There are a couple of libraries that have been written to implement Flux in .NET, and the one that seems to have the most traction and which I have enjoyed using is Fluxor, by Peter Morris.
Fluxor is a zero boilerplate Flux/Redux library for Microsoft DotNet.
If you are new to Fluxor, or to the Flux/Redux approach in general then this YouTube video by Nick Chapsas is an excellent introduction The video is based on the original Blazor-Fluxor library, but the concepts are the same.
The aim of Fluxor is to create a multi-UI, single-state store approach to front-end development without the headaches typically associated with other implementations, such as the overwhelming amount of boiler-plate code required just to add a very basic feature.
The easiest way to get started is to read the documentation
Which includes tutorials that are numbered in an order recommended for learning Fluxor. Each will have a
README file that explains how the tutorial was created.
You can download the latest release /…
I first learned of Fluxor via this video from Nick Chapsas, as part of his excellent Blazor Tutorial series:
Nick has a great way of explaining concepts, and this video is no exception as he does an excellent job introducing an early version of the Fluxor library. Unfortunately, things move fast in the software development world, and the video is becoming a bit out-of-date as Fluxor has changed since November of 2019.
It was this last video that convinced me to give Fluxor a try. I'm glad I did.
However, as is the case with many introductory videos and tutorials, these only touch on the very basics of the topic. As I've developed more Blazor code, I've come across a number of cases that these introductions don't address, and some Fluxor features that they don't explain. I've also developed some conventions for code organization that I think are useful for any Blazor application that has more than a few features.
I'll share these insights in a series of blog posts, and the code on github. Please share your thoughts, and happy coding!