Comparison of the use of Flutter state management framework
In the project, different frameworks are used to complete the state management of the same function Demo, which is used to compare the similarities and differences of the functions of different frameworks in the state management.
The functions include global account information, login page form, and modified user information page data reverse display.
Project source code: https://github.com/FantasyWind2016/state_manage_demos/
Framework introduction
Because the current version of Flutter used by the project is 1.12.13, the appropriate framework version is selected instead of the latest version.
Normal mode
The global state uses EventBus to synchronize the state; manually setState in the page.
No page layering.
GetX2.0.7
The low version of GetX is not stable, and there are some obvious problems.
It does not support reactive programming itself.
It contains routing management and basic bullet boxes, so StatefulWidget can be completely discarded.
This version of GetX manages all state objects by itself, without the help of InheritedWidget, so the logic is clearer, and it is easy to troubleshoot problems.
MobX1.2.0
Divided into two libraries, mobx and flutter_mobx, mobx mainly provides responsive programming capabilities and basic state management. flutter_mobx provides tools used in flutter.
By generating code and intercepting every getter and setter of the state, the goal of accurate refresh is achieved.
The advantage of use is that there is no need to write the notify code for more detailed data.
Because the binding relationship between state and widget in mobx is achieved by intercepting getter and setter methods, the Observer does not need to declare the type of state when the page is used.
Although it comes with the ability of reactive programming, it always feels weird to use, not as convenient as RxDart.
Scaffolding is needed to automatically generate and update template code. However, because the logic of MobX does not rely on the system framework, there should not be many incompatibility issues caused by the upgraded version of Flutter.
BLoC4.0.0
BLoC is a framework similar to redux, which can be clearly seen from the architecture diagram, but it has also made some simplifications and added some ease-of-use adjustments.
All state objects are shared through InheritedWidget, so they are strongly dependent on context. This is very difficult for people who have used GetX or MobX before.
The state flow process similar to Redux always makes people feel like writing a lot of template code.
Provider4.0.0
Compared with other frameworks in terms of function, it is simpler. In addition to refreshing the granularity, the problem of the operating mechanism cannot be completely solved; it still provides an optimized solution in the largest range.
Other shortcomings can be used in conjunction with other frames, or you can make some wheels manually.
Flutter_Redux0.7.0
Redux is basically the official version of Redux BLoC. In addition to the difference in naming, the other is the richness of tools.
Another major point is that Redux's asynchronous operation requires the help of redux_thunk, and BLoC solves it by itself.
RxDart0.25.0
In fact, it is a reactive programming framework, and it needs to cooperate with StreamBuilder to abandon EventBus when used for state management.
Function comparison
| Frame name | GetX | MobX | BLoC | Provider | Redux | RxDart |
|---|---|---|---|---|---|---|
| Github Star | 2.5k | 1.8k | 6.5k | 3.4k | 1.4k | 2.8k |
| Pub Likes | 3359 | flutter_mobx: 285, mobx: 539 | flutter_bloc:1807,bloc:812 | 3512 | flutter_redux:219,redux:176 | 945 |
| Global State Object Management | Get.put() | Singleton | BlocProvider | ChangeNotifierProvider | StoreProvider | Singleton |
| Whether to rely on context | not depend on | not depend on | rely | rely | rely | not depend on |
| Page state object management | Create manually | Create manually | BlocProvider | ChangeNotifierProvider | StoreProvider | Create manually |
| How to use the page | GetBuilder<T> | Observer | BlocBuilder<B, S> | Consumer<T> | StoreConnector<T> | StreamBuilder(stream:) |
| Code intrusion | Inherit GetController | Inherit Store, generate code | Inherit Bloc, have template code | Inherit ChangeNotifier | Template code | no |
| Trigger refresh method | update(this) | automatic | mapEventToState | notifyListeners | reducer() | automatic |
| Can monitor independently | Do not | Observable, responsive programming | No, BlocListener<B, S> | Can't | store.onChange | Subject.listen |
| Can Stateful be abandoned | can | Routing similar operations depend on context | Routing similar operations depend on context | Save the context manually | Save the context manually | Save the context manually |
| Update granularity | class | Attributes | Default class, condition filtering | Default class, Selector filter, builder supports child | class | Attributes |
| Learning cost | low | Medium: labeling, scaffolding | Low: standard process | low | Moderate: Template code | High: Understand reactive programming |
| The cost | low | Low: a small amount of template code | Moderate: Template code | low | Moderate: Template code | low |
| Feature richness | Has route management | no | Provide MultiBlocProvider, plug-in | no | StoreConnector provides a complete life cycle | no |
| Version risk | Hijacked system method | Automatic code generation | Use more data | Official framework | Official community maintenance | Based on Dart |
to sum up
In terms of user experience, the three BLoC/Provider/Redux are relatively similar, BLoC is relatively mature, and Provider is now the official framework, and Redux is relatively weak. But Provider only provides state management and has no restrictions on the code; while the BLoC and Redux code templates may be more suitable for multi-person collaborative development models.
MobX's thinking is unique and the effect is the best; but it feels relatively small, if it is a personal project, there is no maintenance pressure, and it will be more comfortable to use. However, this development status is rather embarrassing, because important projects will be afraid of maintenance issues, and small projects will not have such high requirements for page performance.
The goal of GetX is not only to solve the problem of state management, it wants to improve the efficiency of Flutter development as a whole, so it provides a lot of tools and methods. Personal use will be very efficient. If the team collaborates, it may overlap with the team’s own wheel function, which requires specific analysis of specific issues.
After all, RxDart is just a reactive programming tool framework. If you want to use it as a state management or code framework, you need to use some auxiliary tools.