In this article you will read a comparison of the different state management approaches in the Flutter Framework from my full-stack and beyond point of view.
Who gives a F* about these Design Patterns?
From a business standpoint, it is only indirectly important. If a developer knows them well enough, he will eliminate the possibility of bugs in their conception. Beyond that, no end-user give a damn about the source code complexity that may waste more of your time. What your value as a programmer and software solution creator is – speed of development, deployment and delivery.
Flutter State – Plain Widgets
The most “vanilla” option that comes out of the box in the Flutter SDK is using StatelessWidget and StatefulWidget. Stateless widgets are read-only, static visual elements. They are more optimal and better in terms of memory and performance and more. Statefull is for dynamic and reactive visual components that are redrawn on state change.
The source code starts stinking when the user interface code contains in itself too much state and too much business functionality. Coding many different layers in one place is a precondition for bugs.
Flutter State – Provider
The Provider Plugin or recommendation – moves away the state from the widget. Now, all views become Stateless. They are changed and updated thanks to Change Notifiers behind the scene of the provider components and builders.
Flutter State – MVVM
There are several packages that may ease your Model View View-Model choice of architecture:
- https://pub.dev/packages/stacked
- https://pub.dev/packages/mvvm_builder
- Or Code it on your own
The idea of MVVM is separation of the model and data source, the logic/service and the view. It is similar to Model View Controller.
Flutter State – BLOC
You could read about the bloc pattern from https://bloclibrary.dev/#/gettingstarted and https://pub.dev/packages/bloc and see the implementation in flutter: https://pub.dev/packages/flutter_bloc. In my view, it is semantic topology. You will not find the same old layers, because you are forced to think about:
- All the possible States as in Finite-State Machine. To be truly finite, you must have figured out all possible situations.
- All the possible Events/Transitions. Their names should indicate something semantical. They may seem like CRUD or the programming operations, but they have more “meaning”. These are the links between the nodes [states].
- How are displayed all the states from the FSM to the User Interface?
The source code may seem to increase more in terms of quantity and complexity. Grasp the mathematical idea, and the flow of thinking and the implementation will be like translating block diagram to code.