Application State Management

[harperjohn]

I have discussed this in a few posts at PracticalDotnet and I feel that is very important because it is so easy to ignore when the app is small/new and so easy to get "painted into a corner" of complexity by using the "simple in the small-scale options" that can quickly turn into a "tangled mess" as things move beyond small/trivial.

Jon gives a great summary here: https://jonhilton.net/blazor-state-management/

I used Jon's article as an excellent backgrounder/starting point, and did some modestly significant investigation, and without all the gory details, I am leaning towards "Flux"... https://facebook.github.io/flux/

Flux / Redux is supported by the browser, and has a lot of community/industry support and momentum. (the browser support is extremely interesting!!! You can see a detailed view of each or your state changes including data values... I was actually amazed by this!)

Frank Liu shows/prefers the "roll your own" approach to Flux
https://www.youtube.com/watch?v=o-8yBjtXzEo
https://www.youtube.com/watch?v=cwijbh6UZbA

And Peter Morris seems to have a really good and really (growing) popular solution
https://github.com/mrpmorris/Fluxor

I like the idea of "roll your own"... but I think Fluxor has already found and cleared so many bumps and hurdles that it would be wasteful (if not silly) to ignore it. At a minimum, I plan to fully understand it... But my first (somewhat high level) impression is that it will be an "easy" choice.

Paul Morris is an interesting guy, and he has other interesting projects... For example he is the creator/"continue-er" of Blazor Univiersity https://blazor-university.com/

Which I had already been using (and really enjoying) long before discovering Fluxor!

[DotNetDublin]

I think I'd need to do a bit of research before being able to make a meaningful contribution to this discussion and I note that on https://github.com/mrpmorris/Fluxor they recommend this YouTube video by Nick Chapsas who I enjoy.

That said I'm wondering (and watching the video may answer this) what benefits would Fluxor give me over "Option 3: Cascading Values" that Jon details in https://jonhilton.net/blazor-state-management/ which I've used in my projects?

Finally, do you see a current use case for Fluxor in the TimeKeeper application or is it more a case of doing the plumbing now so it's there if needed?

[harperjohn]

The Nick Chapsas video is really good for the general concepts, but the implementation is a bit out-dated (I think thinks have gotten much better/easier)

I guess it is sort of a "plumbing" kind of thing... coding plumbing, and more importantly mental plumbing.

And yes, I would like for us to do a compare/contrast to "Cascading Values"... but "Cascading Values" is just a language/environment feature, and not a design pattern.

For example "global data" is a language feature. And I claimed to "love global data" it would/should scare everyone. But Dependency Injection with a Singleton... is really just "global data"... but in the context of DI it becomes a safe/powerful/well-known-and-understood design pattern.

For example - I rarely use a simple/raw "array"... The data usually is a "list" or a "queue" or a "stack", etc. And by choosing a particular container class, I take the burden off of my self for designing yet another "container" and I take the burden off others who have to look at my code. It guides/forces the code/algorithms into more easily recognizable/understandable implementation.

I also rarely use my own "file formats" to write to disk. I prefer something like Sqlite for even the simplest file I/O because it is easier than almost all of the file I/O that would have to write. Without it, even me, as a team of one, if I wrote 10 different programs within a few years... I almost certainly would have 10 different file I/O functions/classes/approaches. I would make my own head spin...

I think that if someone told me that their code uses "Cascading Values"... I could rest a little bit knowing some general things to look for, but I would also have to "brace" myself to learn what (implied) "state management" layer they implemented.

I am hoping that Fluxor will have such a light code (and cognitive) footprint that it just becomes the easiest way to do any state management (big or small)

Notice in code how people use the standard containers everywhere! Lots of times they are used in the most simple of ways, but it is still easier to understand/update this code over "raw array" code. Plus, as soon as something like an iterator or LINQ is needed, it is right there ready to go.

So... I guess if Fluxor is light and useful enough we could just use it "everywhere", if not maybe (like EF/Dapper) we can use a hybrid approach.

In any case, with Blazor "everything is a component" and often a component contains child, grandchild, etc components, I think that State Management needs to be explicitly addressed.

Just to be clear - I am definitely not "married" to Fluxor, in fact I know that libraries carry their own cost/weight so I like to be "discriminating" with them, and I would love to find out that "cascading values" is not as "raw" as I think it might be, and I have been searching for "a way around" Fluxor... but the paths keep leading me back to Fluxor. The popularity of Flux/Redux seems to support this.

[DotNetDublin]

Thanks. Will be interesting to see what the others think and I'll try and do some research in the meantime.

In my current developer life I would really only look at something like Fluxor when I had a specific need that couldn't be met by using something like a cascading value however I'd probably change that view point once I had a bit of experience with it.

[DotNetDublin]

Just as I thought I should have watched the Nick Chapsas before commenting as even if the process has improved I appreciate the benefits Fluxor now provides.

In our project I can see a scenario where multiple components may need to know whether the user has a current timer running and Fluxor would allow us to do that efficiently.

What we could do is put a basic implementation of Fluxor into the project as early as possible so the code is there to be followed should it be needed as the application develops.