Flutter State, Why is it a Mystery?

State, should it be this much of a mystery?

I’ve been banging on the keys for decades. Literally decades, starting in 1985.

That’s NINETEEN 85, not EIGHTEEN 85.

Each language has it’s own nuances, but generally you’re doing the same thing. Getting information, doing something with it, and giving it back by updating the UI or generating some sort of report, graph, spreadsheet...

That information, the data, is the state. Management of state is a management of the lifecycle of state, and primarily, how it is created, changed, and accessed, and how it updates the UI reactively.

Some of you may say, come on, there are like 30 different libraries/packages… to manage state, what are we even talking about. Just use … learn the way the author of the package has decided is best to manage the state in your app, and follow along.

Ok, maybe 3 or 4 years from now, you might be an expert in BLOC, or Riverpod, or Provider, or Get(x), or …

But what do you do if Flutter and Dart change and your state management system doesn’t?

We all know Flutter and Dart change. They change a lot. Is it good? Is it too much? How can you keep up, when you have a lot of dependencies that you don’t control?

Bottom line, you’ll spend hours with each upgrade, dealing with the changes. But why is state managed that way?

It seems that state, data is the key to all programming. What good is a program that doesn’t allow it’s state to change, and when it does, it doesn’t handle it? Do you have to pass information up and down a widget tree? Do you have to add a builder to each widget builder to handle state?

How much boiler plate code are you willing to deal with/manage? Do you want a build runner to write some of that boiler plate code, just to let you access your state?

I have a few ideas after 4 years programming in Flutter, and I’m going to see how it works out. I’m basing all of this on a few simple things:

1. A global state store, currently a singleton.
2. A simple abstract class for state controllers for each stateful widget.
3. A mixin for the stateful widgets to handle creation and destruction of the state and passing in a call back to the stateful widget’s setState.

That’s all folks. Nothing more, nothing less. All toll about 40 lines of code. All of it was written by copilot, after spending about 30 minutes of q and a with the AI. It’s as granular as I want, or not. Simple.

Code available upon request.