Choosing A Flutter State Management Solution
There is an easy way to choose a Flutter State Management Solution, let me show you how.
What Are We Building
What are we building? Unless you ask that question, you will get lost in all the Flutter State Management Solutions out there.
What Are We Building:
1. Does my app have deep widget trees, i.e. complex UI screens?
2. What does our OOP Architecture require in the form of communicating across application layers?
Let’s go through this step-by-step.
If your app has a simple thin widget tree UI screen, then you obviously could use Inherited Widget and Inherited Models. It’s the other thing that gets forgotten and where developers run into trouble.
OOP Architecture
The Dart is a mixed OOP and FP language. We still need to do an OOP architecture implementation, as FP is not mature enough to do all that OOP architecture can do just yet. Not to mention that FP math concepts are still a bit unreachable for most front-end developers.
The problem the architecture solves is how to get the Domain and the app API and 3rd party APIs to communicate with testing, the presentation layer, and the UI layer. The state solution becomes somewhat important as it is the mediation stuff that flows the events from these layers to the UI.
Developers over the past decade have found that Onion Layered Architecture solves these problems:
See the app services and domain services layers? Those two layers are a bunch of adaptors that are stable representations of the contract with the inner App API and the 3rd party APIs, and thus we can use them to mock services for testing and, we can use them to dependency inject them into the UI.
In the case of that thin widget tree, we can get away with using inherited widgets and inherited models as long as we remember that we need to use adaptors to connect the domain model to the UI. I state this because most inherited widget examples never ever show any domain adaptors. If not using adaptors, then you need to use service locators.
So what happens when we have medium to big widget tree UI screens?
State Management Solutions for Medium To Big Flutter Apps
We have two ways to go about this choice. A service locator non-widget DI solution or a widget-DI solution that can go further down the widget tree than an inherited widget. And we are going to limit it here in that we steer away from having to pick up advanced reactive using Rxdart and advance FP using such things as fuctors and monads.
On the widget-Di side, we have Cubit, Provider, and Riverpod. All those allow one to use the service locator pattern to load dependencies at the top app widget. On the non-widget-DI side, we have GetIt and GetX.
If you would like to move up from observables to builders and then to full reactive then you can use GetX as GetX has all 3 of those approaches with its state management solution.
Conclusion
If your app has small widget tree UI screens, then you use inherited widgets as your state solution. If your app is a bit more complex in widget tree UI screen sizes, then use either a provider-based solution or a non-widget-DI state management solution.
About Me, Fred Grott
I am a reformed Android, Java, Kotlin, and Front-End developer. I am a reformed ADHD’er and Code and Design Cowboy.
The Flutter Plugins I contribute to are:
Flutter Platform Widgets
https://pub.dev/packages/flutter_platform_widgets
Catcher
https://pub.dev/packages/catcher
Some useful guides are:
How I Learned To Trust My ADHD
https://readmedium.com/how-i-learned-to-trust-my-adhd-dbf4f80518cc
Flutter Perfect SetUp
https://readmedium.com/flutter-perfect-setup-c5462b412f78
Flutter Expert IDE SetUp
https://readmedium.com/flutter-expert-ide-set-up-25791ce690c
Globals Dart File IS An Anti Pattern
https://readmedium.com/globals-dart-file-is-an-antipattern-92975320e30c
Functional Programming in Flutter, Sandbox Your Functions
https://readmedium.com/functional-programming-in-flutter-sandbox-your-functions-ee679d3db7d5
Expert Catcher SetUp For Flutter Apps
https://readmedium.com/expert-catcher-setup-for-flutter-apps-a9ee3a6a9e08
And I am the nut starting to write a Flutter Dev App series of books during COIVD. Not only that, but I am organically creating my Flutter Developer Book chapters via Medium article writing.
The more formalized almost ready for book code is at:
https://github.com/fredgrott/ddi_flutter
My writing approach is somewhat different. The only way to master Flutter And Dart together is to do uncomfortable work. That is, every week to stretch me in mastering new things daily and expanding my thinking models tool-set.
Learning about state management, it means that I have to build state management demos with benchmarks fully naked and then build them with all the boilerplate including Flutter Platform Widgets and full testing.
With the UI itself, it means building a full UI catalog of UI solutions for col screen layout cases seen in top apps. It then means generating graphical layered pieces of screens for mockup tools.
On the CS-wise level, it means becoming an expert at reactive, including the advanced libraries. This intersects with state management, as specific reactive approaches have a role to play in statement management.
If you join me in building the exact stuff I am talking about, you will be Flutter Expert after building all this stuff.