Flutter state management framework GetX experience

Flutter state management framework GetX experience

Because the Flutter version used in our business is 1.12.13 and the corresponding Dart version is 2.7, only the 2.0.7 version of the GetX package is used.

The GetX framework is indeed more convenient to use when setting up a page. It can decouple the logic code and the interface more conveniently, without the need to create many template files.
However, this flexibility also means that the standards are not uniform, and it is not suitable for team collaboration; when used in a team, it feels like it still needs to be used with a lightweight structured framework, such as BLoC.

After writing a demo using this version of GetX, I found several problems:

1. It doesn't feel like a stable version, there are some obvious problems; and 2.0.6 to 2.0.7 are only a small version, the global state management logic seems to have relatively large changes;
2. Reactive programming is not supported. This version of state management is still based on state logic; because you want to decouple pages and logic more efficiently, you may need to use a reactive programming framework;
3. Related functions may be relatively few, not as comprehensive as the latest version;

Demo site: https://github.com/FantasyWind2016/state_manage_demos

Functional understanding

Route management

The GetX framework implements a context-free routing jump, but it still needs to take over the creation of the MaterialApp and hold the navigatorKey in the Get object. After the routing jumps, the context is no longer needed to obtain it.
Therefore, all context-related logic optimizations are bound together, such as various bullet frames, such as crash monitoring; if each function is independent, it will be nested one layer after another. Therefore, the need for no context can give rise to the need for plug-in. For example, make a separate MaterialApp hosting framework to allow other services to access. Similar to GetService in the higher version of GetX.

State management

This version of the GetX framework can be seen to be relatively simple, especially its state management part. It is equivalent to implementing a simple subclass of GetBuilder for StatefulWidget, and then allowing a custom state—GetController to be passed in from outside, while the outside is passed in. State needs to control its own setState timing.
The Widget that needs to be updated according to the state is wrapped with GetBuilder, and the business logic is placed in a subclass of GetController, so that the purpose of separating the Widget configuration and the business logic is achieved.
In addition, because the instantiation of the custom state is not created by the custom statefulWiget, the modified state instance does not hold the BuildContext, so there is no need to route the jump in the business logic (that is, the subclass of GetController). Method to use Navigator. However, the GetX framework supports non-context routing jumps. I don't know if this is a coincidence or whether the two solutions are causal.
However, if it is considered based on the MVVM architecture thinking, the routing jump can be placed in the View layer, and the GetController responsible for logic does not need to directly perform the routing jump, so as long as GetX implements responsive programming, it can jump at the Widget layer. Then the problem can also be solved. But if this solution is adopted, the pages that need to be routed still need to use StatefulWidget, because StatelessWidget does not hold a context object.
If you want to abandon StatefulWidget as much as possible, then no context routing jump is still needed.

Dependency management

The description of this function in the GetX documentation is Dependency Injection, but it feels that the so-called dependency injection of GetX is not the same as the usual concept, but is more like dependency lookup.
Dependency injection is an implementation of the IoC (inversion of control) mode. The process of managing dependencies is that the IoC container obtains the dependent instance and binds it to the instance that depends on it, which is the so-called "injection".
In GetX, instance A provides a Get.find()method to quickly obtain the instance B that it depends on through GetX , but the calling Get.find()method is directly initiated by A, and there is no "injection" process.
The effect of GetX's dependency management is a bit similar to reflection, which is a shortcut to obtain instances through classes. But because Flutter officially disabled the reflection mechanism, reflection is actually not available. The basic way of using GetX is to Get.find()obtain an instance of a specified type or name from an instance pool. The changes that may occur in this process (ie, inversion of control) are the find()returned instance types.