One of the most controversial topics in Flutter is which state management solution to choose from. Because Flutter offers so many state management solutions.

Therefore, any new Flutter developer would be confused about choosing the right state management solution for their needs.

First, let me get one thing straight:

Writing good code or bad code doesn’t depend on a state management and depends on the developer itself

Therefore, you should know the best practices while writing the code.

All state management solutions have their own little differences and some of them make it better than other. But at the end of the day, the one you are most comfortable with and the one that saves you a lot of time might be the best one for you.

So if you are worried about the performance of your Flutter app then I can tell you for sure that it never depends on which state management solutions you use, But it more depends on the developer that how he/she is utilizing that state management solution and how clean code they are writing.

Now without further ado, let’s jump straight into it.

GetX

If you are new to Flutter and starting out with state management for the first time, Then I will recommend using GetX because of the following points,

• It doesn’t have any boilerplate code you have to write extensively

• It supports so many other things than just state management solutions, Like Routing, Dependency injection and Internationalization which a lot of the state management solutions don’t support by default.

• It offers utility methods and functions for changing the theme, getting MediaQuery data, Dialogs and bottomsheets and connecting to HTTP or WebSockets with GetConnect.

• If offers GetStorage to store your data in local storage

You might be thinking that if GetX offers these many things then why you should worry about any other state management solution?

The answer is GetX also has its cons such as,

• The code is not that much documented yet

• Testing coverage is less than 50 percent

• Only 743 out of 2454 API elements (30.3 %) have documentation

• It comes at a cost of not knowing about so many important Flutter topics such as BuildContext, Routing, Dependency Injection, Internationalization and so on.

Now, When should you use GetX?

If you are working as a freelancer and you want to complete the app in as much low time as possible then you should definitely go with GetX because it will save your development time by a lot margin.

But it doesn’t mean that you can’t finish a project in less time by using other state management solutions but by using GetX it can give you a lot more than state management.

So, If you are new to programming or new to Flutter, Or you are working as a freelancer and you want to complete a project with a tight deadline then for sure GetX might be the right option for you.

BLoC

BLoC is an abbreviation for Business Logic Component. It is a design pattern that was created by google to help separate business logic from the component.

In Flutter, we can use the BLoC pattern by using the bloc library. It uses the concept of Streams. This means that whenever a stream of events are created, subscribers can listen in on the stream of events. The subscribers are notified of new data when it is emitted into the stream.

Also, It has some pretty good points over any other state management solutions such as,

• It has 100 percent API documentation coverage and they have a proper website for the documentation

• It is used in a lot of companies

• The architecture is robust

• It will make your code more structured and robust thus making more stable and scalable

• Writing test is easy

Now as with any other state management solution, it also has its own cons like,

• It has too much boilerplate code

• The learning curve is high compared to other state management solutions

Riverpod

It is made by the same person who created one other popular state management known as Provider. It is also recommended by Flutter. It was built to solve the issues which were presented in the Provider state management. That’s why we’re not gonna cover the Provider state management here.

He created Riverpod because it was way hard to improve the Provider state management. In a way, if Provider is a candle then RiverPod is a lightbulb. They have very similar usages, but we cannot create a lightbulb by improving our candle.

It also has some good features like:

• Being able to have multiple providers of the same type

• It makes the pattern independent from Flutter, which means it includes being able to listen to providers without a BuildContext

• You can make a provider private

• It has proper documentation and a website for it

• It is testable like BLoC

• It allows clean handling of loading/error/success cases for API calls

Coming to its limitations part as every state management solution, It has its own limitations like,

• It gives you too much freedom to implement a state on your app. Which can be a challenge for new developers to choose the best approach

• It only supports up to six streams simultaneously

SetState with Inherited Widgets

In this article, I specifically avoided using the word ‘versus’ because choosing a package to manage your app states is up to one’s preference and experience. It’s possible even to go pure Flutter and do it with its own dependency injection and state management mechanisms.

I think a lot of people try to implement big state management solutions when they just have only a few screens in their app. You don’t have to implement other state management solutions when you just want to create a small app because setState can work perfectly fine without any issues in those scenarios.

It’s the most simple yet powerful state management solution for your Flutter app where you don’t have to worry about any other dependency or anything.

Now if you have to pass some data 5 to 6 widgets down then you can use Inherited widgets for that because they are provided by the Flutter framework itself so you don’t have to worry about external dependencies or anything. You can pretty much implement it using setState and Inherited widgets and it will work fine.

You can also go with ChangeNotfier or StatefulBuilder approach to manage the state of your UI.

But if your app is bigger then you should always go with other state management solutions.

So in summary,

• GetX — When you don’t want to get much into the state management itself and want more features than just state management which makes your work easy

• Riverpod / BLoC — When your project is much bigger and you want something more robust and maintainable along with some good test coverage and proper documentation, then you can go with either of this

• setState / Inherited Widgets — When your app size is small

There are also tons of more state management solutions other than this which I didn’t cover because I haven’t tried those yet.

Some of the state management solutions which I haven’t tried but I think can be honorable mentions are mobx, redux and scoped_model.

You can comment on which state management solutions you are using right now and what are the main benefits you are getting by using those so that other readers can understand more about those state management solutions too.

Connect with me on LinkedIn, Twitter and don’t forget to follow me here for more updates.