Google’s Recommended Flutter State Management
Everyone gets confused by this state management list:
[list of states]
And thinks that is the same as what Google recommends for state management; well, it’s not! And what makes it complicated is not the community choices but the fact that we are implementing a workaround for not having true Full-MVVM. Thus, it’s still wrapped up in what the MVC pattern does well and not well and how to fix it, and how to dependency inject things.
Let me make this easy for a designer to see.
Background, What Is Implied By The Framework
No matter what SDK framework, all front-end frameworks, whether native or not, start out as MVC. But, it’s a special form of MVC as the true form is MV-small-c as since the framework controls the screen renders it’s acting as a Super-Controller. So what things are we attempting to overcome by modifying the MVC app pattern?
MVC from Wikipedia:
It was created during Xerox’s PARC days to write GUIs in small talk. And most people describe it as having the con of being directly coupled. That means you as the designer should read that as well its dependency of the Model is directly coupled to the view, implying that DATA-BINDING is also directly coupled.
Dependency-wise, what that means if we need that model for any other view that we have to directly couple it again to another view and write another controller, which gets into problems of those two model instances not being in sync with one another and showing different states to the user as they travel from one screen to another.
In short words, state management in Flutter is managing the decoupling of what the view needs, i.e., the data from the model and the business logic decoupling from the view.
So now, let me show you what the Flutter SDK framework itself actually implies that Google recommends as state management.
View Data Binding
In Flutter Doc’s state management example:
It starts using the SDK ChangeNotifier class and then moves on to the provider. ChangeNotifier encapsulates state changes, which is a fancy way to state data binding, as the data then gets bound to the view in a decoupled fashion if you follow the example of using change notifier and provider together.
As one move towards stream and RxDart, it’s still data binding, but instead of a listener such as Change Notifier, we are using something else to do the data binding via RxDart’s use of functional programming to treat every change as a state event.
Notice that the advanced Data Binding part is outside the Flutter SDK. What is wrong with Change Notifier? When we remove items in very big models, that task is not O(N¹), meaning it takes a long time for big models to record the change, which designer-wise translates to non-responding UI. This is why the Flutter Community came up with RxDart.
But that is only data binding, and we still have the model dependency and business logic separation parts. Let’s tackle the model dependency part.
Model Dependency In Views
The whole reason we have to decouple the model dependency to the view is, so we can fully use it on multiple screens of the app. As otherwise, we would get two model instances that have different states. Now, I need to explain why Google does not use IoC.
Google, four years ago, did play with IoC model injection in the form of a package called inject:
It’s not maintained. So why the dead-end? Since it’s an IoC container, the dependencies are hidden from the developer as you do not see errors until you attempt to compile the application, which means it’s a high learning hurdle for beginning flutter app designers.
Now let’s dig into the SDK for just a moment. The Flutter SDK just like the Android SDK, has concepts of a Build Context, and yes Apple has it too, and they call their Build Context implementation context.
Google had the idea that if we integrated the model dependency with the widget lifecycle, we could get:
1. All the errors via devtools integration.
2. State management of the model dependency because it is integrated with the widget lifecycle.
But, they did not have time to devote to a full solution fully; so they just came up with the core of the Inherited Widget and Inherited model classes:
And the Flutter Community ran with this and created both Provider and Riverpod, with the provider part being a better-inherited widget and the provider consumer widget replacing the inherited model features and improving it.
And last is the business logic separated from the view part so that we eventually get a decoupled controller.
Business Logic Decoupling
Google first introduced BLoC in 2018 at Google IO:
In separating out the presentation (view) from business logic (controller) via some smart decoupling, we still are doing direct state management. And just like the model dependency solution of provider and riverpod BLoC re-uses the concept of putting the business-logic-controller in the widget lifecycle so that we correctly get our streams closed that BLoC uses.
And that use-case-command pattern from MVP got transformed into a BLoC event command pattern part of a BLoC controller.
So what is the desirable stack since Google does recommend BLoC for state management?
The Flutter BLoC State Management Stack
The beginning Flutter State Management Stack Is this:
1. Inherited Widget and Inherited Model
2. Change Notifier
And the intermediate step is:
1. Replace Inherited Widget and Inherited Model with either Provider or Riverpod
2. Replace Change Notifier With Stream
3. Start Using BLoC as the Controller
And then you move towards this:
1. Provider or Riverpod
2. BLoC
3. RxDart way of using Streams
Provider And Riverpod BLoC Stacks
Provider BLoC stack:
- BLoC
2. Flutter BLoC
https://pub.dev/packages/flutter_bloc
3. Bloc Test
4. Bloc Concurrency
5. Replay bloc
6. Sealed Bloc
Riverpod BLoC stack:
- River Bloc
I am leaning towards always using the Provider and BLoC combination, as the riverpod BLoC implementation is not as robust feature-wise.
Conclusion
Despite that long state solution list that Google shows, they actually recommend the provider and BLoC combination for state management and that is somewhat fully reachable for every flutter app designer. And all it does is decouple the Model from the view and the controller from the view.
About Me
LinkedIn
https://www.linkedin.com/in/ansh-goyal-03936a191/
Twitter
https://twitter.com/anshgoyal749
Github
