Flutter - Why you should not use GetX?

The next article is my personal review and opinion about one of the most popular flutter packages.

GetX is one of the most popular packages for state management, but what is the problem with GetX?

GetX is not only focused on state management because it also allows you navigate between routes, show dialogs, snack bars without BuildContext, reactive programing, internationalization, change the app theme, dependency injection and more and more. Even with GetX you can make calls to your API REST.

All the above features seem to be great Right? The answer for me is NO and in this article I will explain you why.

Navigation with an unnecessary Custom MaterialApp or a CupertinoApp

To navigate without BuildContext with GetX you need to use a GetMaterialApp or a GetCupertinoApp also we need to create one instance of GetPage for named routes, here is the first problem for me because to navigate between routes without BuildContext you DON’T need a custom MaterialApp or CupertinoApp with the next simple code you can navigate without BuildContext

Bad use of navigation, dialogs and snack bars

Consider the next code. Could you find the problems?

When you have more experience in flutter you will have to write unit testings to ensure your code quality and correct behavior. The code above uses Get.offNamed and Get.dialog to navigate and show a dialog, but, internally they use a static context and here is the problem because navigation, show dialogs and snack bars cannot be tested using unit testing because there is no easy way to test these features with unit testing and less experienced flutter devs make the mistake of use GetX navigation, show dialogs and snack bars inside a GetxController. In most cases to test the above code you will have to use widget testing.

Unnecessary http and GraphQL client

GetX has a module called get_connect to make requests to your API REST, or make queries and mutations for GraphQL.

Now. What is the problem here? Most of the projects work with an API Rest or GraphQL but not with both, for me the get_connect module must be an external package and the developer should decide what client use.

You have clients like the official http client or dio also you have GraphQL clients on pub.dev

Problems with hot reload

GetX has their own dependency injection system and that is used for almost every module in GetX, but it is not stable yet. Some times you are writing code and next you save the code to see your changes but unexpectedly you have a red screen 😡 and if you go to the console and you will find a message that tells us that it did not find a dependency and ensure to call Get.put or Get.lazyPut this happens because GetX use bindings to decide when a dependency needs to be created or destroyed so when we show a view that depends of one instance of one class that extends of GetxController that instance will be stored inside the GetX dependency injection module and when we save the code then the hot reload rebuilds the widgets but sometimes GetX remove our controllers and with this we lost all our progress and we need to do a Hot restart.

A lot of code without comments, documentation

If you go to the source code of GetX project you will find thousands of lines of code with classes, methods, variables, etc. without any comment that explain the functionality of a function, a class, a variable, etc. This could be dangerous because it’s more difficult for other developers to help to maintain this project because is very difficult understand the code and the most of the responsibility falls on the author of the project.

Poor organization

If you analyze the source code and file structure you will find dart files with hundred of lines and multiples classes, functions and variables at the same file.

GetX needs to improve the way in which we operate with certain functionalities or certain modules, for example to navigate we can use Get.to, Get.toNamed, Get.offNamed, etc. For dependency injection we can use Get.put, Get.lazyPut and we have many functions like those that we have mentioned so why not use a prefix like Get.router for navigation, Get.dependencies for dependency injection, Get.dialogs for dialogs, etc.

Too many features without testing

GetX quickly became one of the most popular packages but it’s trying to cover more than it should, unit testing and widget testing help to check if your code works as it should and also to find and fix bugs when you made changes in your code. This means that when you have more code without testing increase possible bugs.

Currently GetX doesn’t have the enough tests to have at least 50% of code coverage.

Not friendly with testing

I have written a lot of tests in my flutter projects and recently I have taken a flutter project witch uses GetX and trust me write unit and widget tests is really very hard with GetX and in some cases is imposible test some features.

To test a simple page transition we only need to use tester.pumpAndSettle() but with GetX this not works 🤦‍♂️ and there are a lot of bugs of GetX that you can find while you are writing tests. For example why GetX observables locks the ui while you are testing a widget after a route navigation 🤷‍♂️.

Just Think. Why we don’t have more posts about unit and widget testing with GetX? Because experimented flutter devs don’t use GetX and devs who love GetX don't have the enough experience or they never write tests.

The correct way to use GetX

If you are planing to use GetX for your project use only the necessary features like state management, reactive programing and dependency injection. Try to avoid the GetX navigation and bindings to prevent red screen errors.

If you are using the GetX navigation, dialogs or snack bars only use them in your widgets, never use them into a GetxController, repositories or any other class in charge of handling the business logic.

Conclusion

GetX is a great project but it should be used carefully with good practices because it still needs to improve to use all their features without risks. If you need unit and widget testing think twice before use GetX.