Flutter, state and states_rebuilder
Disclaimer: My knowledge of the things I speak about in this article is only surface level. I am still exploring the wonderful world of Flutter like you. I have especially avoided talking about performance penalties of the solutions I mention just because of the reason mentioned above.
So, since you are already here to read about states_rebuilder I am going to go ahead and assume that you already know what Flutter and state is. In case you didn’t, Flutter is an open source, reactive, cross platform, performant framework to develop mobile apps from Google and state of an application at any point in time is nothing but a description of its present. This is, however, a very loose definition. For example, when you select an option from a dropdown you did change it’s state, when you type something into a text field you changed its state, how the change of state is dealt with is completely use case dependent.
State Management in Flutter
Stateful widgets in Flutter can keep track of their state and react to changes made to it by re-rendering the associated UI tree. This is made possible by using the setState method they inherit. Now, since you know that the application state of a reactive app is simply a build up of sub states (children) along with an optional global state you might think we have the perfect answer to state management right as part of the framework. This is only partially true, while setState exists, it has a few limitations. One that I have suffered from is how quickly a reusable or a parent widget grows messy. That is not to say that setState should not be used, it should be used in isolation and when the requirement of feature additions is known and manageable.
Google recommends Business Logic Components as the state management tool perfect for building Flutter applications. BLoC basically works by isolating the business logic of a widget into a separate class and using streams to exchange events and responses between the BLoC class and a UI widgets. BLoCs like redux require a lot of boilerplate and concious decision making. Now, for a use case like mine where time to market needs to be as little and penalty for making wrong choices needs also needs to be as little as possible, this is not all that great.
states_rebuilder is an interesting middle ground, with the implicit reactivity features it provides you can treat any vanilla Dart class as a BLoC component in the states_rebuilder context and pass it around using injection. This results in a very manageable state management experience while still keeping the volume and readability of code small enough.
If you have ever used Flutter, there is no way you haven’t come across the legendary Flutter Counter example, I took the liberty to patch the example and use states_rebuilder instead of setState . Please know that this stands to just showcase how integration of states_rebuilder works and nothing more. Here, learn from a diff.
I have also added the ability to change the increment factor in the app. Check it out at https://github.com/ksdme/states-rebuilder-counter/commit/e8dab89f63648f1b2931d0efc7bd50d57165cb46.
