Shooting a Glance GetX and Endless Discussion About State Management Flutter

Alperen Ekin
HardwareAndro
Published in
5 min readOct 21, 2021

Since I started using Flutter, I have been hearing about state management and recently more and more about Flutter GetX. I have previously worked with Flutter Mobx, BLOC or Provider according to my needs and even though they are normally enough for the projects, I believe it is better to observe other possible approaches in order to see what we are able to do with these approaches. Also, we can not deny that GetX is widely used by the community.

Photo by Kym MacKinnon on Unsplash

First Impression

At the beginning I went over GetX pub.dev page. There exists a detailed explanation for GetX and answer the different type of questions you might think about while understanding it. I think the documentation is pretty good, and they also direct you to some YouTube videos which I followed later on. The first thing I realized after going to details of the package was it is more than a state management library. GetX actually involves Route Management, Dependency Management, Localization, Storage, Validation and additional features like Theme management, access to snackbar directly and so on. However, as a part of documentation there were things that I was not completely agree that I will mention later in this article.

So What Exactly Getx?

According to their explanation:

GetX is an extra-light and powerful solution for Flutter. It combines high-performance state management, intelligent dependency injection, and route management quickly and practically.

I played with it in Flutter for a while to see how to accomplish some simple operations and I have to admit it is relatively simpler compared to other approaches. Actually in documentation they did not forget to mention their competitors such as :

  • You don’t need context to access your controllers/blocs through an inheritedWidget.(Provider).
  • You will not need to use code generators(Mobx).
  • You will not need to create a class for each state.(Bloc)

The main goal behind the package was reducing the dependency by eliminatingthe context, which is sometimes difficult concept to understand for beginners.

In summary, it offers:

  • Better performance with better usage of resources such as removing the controller when it is not used anymore.
  • Higher decoupling and dependency injection by introducing their own way of injecting.
  • Context independent way of state management and navigation.

State Mangement With GetX

In order to cover state management part of the package, I believe providing a small project is a better approach. Therefore, I applied my way of coding on a YouTube example. In this perspective, I implemented a simple shopping app interface that’s fetches the products from an API. Since GetX is compatible with MVC approach, I tried to use it.

Model

To design the model and its fromJson, toJson methods, I use json to dart converter tool and adapt it according to null safety. It is enough to copy the response json that you receive from Postman request.

Controller

Controllers separately manages the business logic of the project, and it is accessed by the related view. The package provides us GetxController. One important feature of it memory control. When the controller is no longer used, it is automatically removed from the memory. Of course, it can be kept by declaring perminent:true.

There are 3 different ways to observe changes in variables: Obx, Getx and GetBuilder. I implemented the example with each of the approaches in different branches. I will try to explain them briefly.

Obx and Getx Controller

I think combining these two controller makes sense because they are pretty much the same. However, their usage in view is different, which I will cover later. The most important information to know about this is both of them use the streams and that’s how they reactively rebuild according to change in the variable. The package aims to simplify the usage of streams for developers.

The controller is used to fetch the products by sending request. As it can be seen above, It is possible to make a variable observable by adding .obs.

Using Obx in the View

Firstly, the controller should be instantiated with Get.put method. Once it is added to memory, It is available from any of child routes. In any other view it can be accessed by Get.find method once it is instantiated.

By wrapping the widget with Obx(), now we can observe the changes in the observables in this case the isLoading value. The usage it quite simple and it does not need any stateful widget or a setState method.

Using Getx in the View

When using Getx, the controller can be initialized in init Method of it. Getx also has its initState methods if you need to do some operations at the beginning. The rest is similar with Obx. We just wrap the widget with Getx.

Some advantages of using this one:

  • You can explicitly show which controller is used.
  • Can be used when controller previously was not registered.
  • Has its own init method.

Using GetBuilder

Unlike the others, GetBuilder is not reactive. Therefore it should be manually rebuilt by calling update() method.

In this example, after applying some changes in the UI, we call the update method to let the view know about it is time to rebuild.

In view, the usage is similar to Getx. The controller initialized while using it. The main difference that it does not listen the changes but we trigger it manually.

The advantages of GetBuilder:

  • Relatively lower memory usage.
  • Sometimes it makes more sense to update a group of variables together and we can do it manually.

Conclusion

As a newbie at Flutter Get package, my impression is the learning curve is relatively simpler than other packages. It is somehow confusing that there are 3 different ways for state management and each has different features but ultimately you can just use obx to manage it if you do not mind about memory and other issues for a small project.

I think the biggest problem about the package is it tries to control all the project. Therefore, at the end you are so dependent on a package. When the project gets larger, It would be harder to maintain. Also, once you have a problem related to it, you might have headache because of overdependence.

Thank you for reading. If you have anything to add on it, I’d be happy to hear.
See you next time 👌🏻👌🏻

--

--