Provider with StateNotifiers
The Chronicles of Flutter state management 8.
Statenotifiers are one of the classes of immutable state management solutions. Unlike ChangeNotifiers whose state are mutable, state notifiers prevent the direct ability to change the state value.
Lets therefore create the perfect segue for state notifiers: immutability.
If you have been programming for a while you should have realized that avoiding to explicitly mutate code is a great practice.
But why is immutability such a great appeal?
- Predictability: Immutable code is highly predictable making code easier to reason with and model what it does as you can easily know what to expect. This is quite an appeal as there is a growing demand for optimistic updates where you go ahead and do a particular action such as updating the frontend before the function or request completes because you can predict what the outcome of your code can be.
- Transparency: Immutability provides the opportunity to write code that is transparent and determinant, no unintended side effects, functions or methods can easily be pure as a result they will always return same output given same input.
Those two principles can be very vital as it makes code easier to test and debug because the possibility for unexpected outcomes are limited and can be contained.
Okay, immutable state management.
States should be pure so that interfaces and backends should be apologetically impure as should be and therefore states should serve as the source of truth since both use the state to communicate with each other.
With immutable state management, states are immutable and can not be changed (changes are confined to the notifier, by methods).
State Notifiers.
State Notifiers are extensions of value notifiers, but enforces immutability in the sense that the value of the state can only be modified within the notifier and not outside or anywhere else.
With statenotifiers, it is easier to
- In a less error prone and convenient manner compare previous and current states.
- Debug the states since there is only one point of modification and less side effects.
- Unlike change notifiers, listeners are automatically triggered when a state changes with no explicit call to notify listeners needed.
Let’s take a look:
We have our blueSquare widget that is as evident from the name, but displays a number that indicates the number of time it has been clicked. Lets use stateNotifier to achieve this.
First state notifier is an external package which means we will have to install it, you can use the dart: Add Dependency feature if you are using flutter version greater than 2.5 or follow the instructions here.
NB: state notifier being an external package means it can be used with all your dart projects and not just flutter.
As we can clearly see from the example above, we have in less code (compared to the changenotifier example) laid down a basic notifier for our clicks. It is imperative to always remember that the statenotifier super class is of a particular state type.
With change-notifier, we used the ChangeNotifierProvider class to listen to the changes, with state-notifiers, we have an equivalent StateNotifierProvider class that serves the same purpose. Just like the state-notifier package being an external package, the StateNotifierProvider exists in the flutter_state_notifier package and hence we need to add that to our pubspec.yaml file with instructions on how to do that here.
As we see, the StateNotifierProvider doesnt quite exactly look like the ChangeNotifierProvider because we are indicating that it exposes both the Notifier or the controller as the documentation will say (a notifier is some sort of a controller so they are kinda interchangeable) and the state itself. This eases with removing the complexity of rebuilding when the notifier is referenced when there is no need for it.
Also, as we know, we don't have the state as a class member and so if the provider does not expose the state for access, then how can we have access to it? We may decide to use
Provider.of<ClickStateNotifier>(context).stateBut that will be giving the possibility of changing the state outside of the notifier and then the immutability will not be enforced, so state notifiers does not permit this.
As you may or may not know, provider provides extension methods that eases with readability and makes separate concerns; read, watch and select, where we use read for when we dont want to listen to changes and watch for when we want to listen to changes.
To conclude, note that in this our example it was barely providing a value and you can always create more complex immutable state classes that you can use with the state notifier to provide state in your app.
Immutable state management is amazing ( yes I am being biased) and you will see more of them as well as mutable solutions as we explore more state management approaches in flutter.
Thanks and see you in the next one.
