Managing State in Flutter

So far, you’ve seen some of the major state management solutions included with the Flutter framework. While the inherited widget works really well, it’s produces a lot of code that can get complex.

Not long ago, the flutter team understood that the inherited widget was not the optimal solution. There were busy working on project called scoped model as a way to provide a better state management experience when they realized that the community was coalescing behind a project called Provider.

Provider is a state management solution created by Remi Rousselet. Provider doesn’t aim to reinvent the native tools, but rather builds state management on top of them. In Remi’s talk about Provider he mentioned that provider was once referred to as Inherited Widgets for humans.

Google saw that it was getting traction in the community and seeing as how it didn’t replace their tools but instead, built upon them, provider quickly became the official tool for state management in Flutter.

In fact, in Flutter’s official documentation about Simple App State Management, the document reads, “If you are new to Flutter and you don’t have a strong reason to choose another approach, (Provider) is probably the approach you should start with. The provider package is easy to understand and it doesn’t use much code. It also uses concepts that are applicable in every other approach.

If there ever was an endorsement, that was it. The idea of Provider is that you add your data at the top of the tree using a provider object which you can just access lower down the widget the tree and it doesn’t require you to write a bunch of different classes to get it work. You just add your model class to the provider object and you are off to the races.

What’s nice about Provider is that you just aren’t exposing value that you read lower in the tree, but you can react to changes from them. In the previous episode, we rebuilt the entire widget tree for every change. That was fine in our case as the layout was really simple, but if you have a complex layout incorporating many different remote data sources. In such a case, a full rebuild is just out of the questions, especially if you are targeting a 60fps frame-rate.

Now you could lower the inherited widget down in the tree to just the area that is needed. But provider allows you to do the same in one line code. You can watch a value and if it changes, the widget will rebuild without you have to do anything.

In order for Provider to be notified of our changes, our model objects must extend the change notifier. This is where the MVVM really comes into play and you’ll see example of this in later in the course. Now the change notifier should sound familiar because you were introduced to ChangeNotifier’s cousin, ValueNotifier. ChangeNotifier works the same way as ValueNotifier.

The big difference is that the value notifier notifies its listeners when a single value changes whereas a change notifier can notify it’s listeners when many different changes occur. This notification informs Provider of a state rebuild. There’s a lot more to Provider and in the next episode, we will be putting Provider to the test.