Flutter Provider: What is it, what is it for, and how to use it?

Flutter has developed libraries that promote our digital solutions. One of them the most powerful is called Provider. I will explain its benefits and why you should use it.

Link to see this article in Spanish.

On the official Flutter documentation you find this description: “it is a wrapper of the InheritedWidget to make its implementation easier and more reusable.” But that is not the end…😂 Of course not.

This definition helps us to understand why was this tool born. As I always say, if you want to understand a tool, you have to analyze the problem solved.

To share information between the widget tree.

Let’s imagine that we want to share information through the widget tree and that every time we travel from one screen to another, we had to share an entity with common data between it. How consistent would this seem to you?, that does not make sense.

Also, the Flutter team came up with InheritedWidgets. These allow to share information throughout the widget tree and these contain other wigets.

However, the InheritedWidgets was tough to implement whereas you needed tools to consume and update data in a easy way. For that reason, The Provider package began as an extension of the InheritedWidget making easier the handling of information throughout the widget tree.

In the previous graph, you can see the performance of the Provider being the parent of all widgets. It can share the information with whoever needs it, and the Consumer can update the information of its parent.
Now that we understand the Provider’s meaning and its purpose let’s learn how to configure and use it.

Example App demo with Provider

Installing the Provider is not a difficult task just adding our dependencies on pubspec.yaml file.

dependencies:
  flutter:
    sdk: flutter
  provider:version

Then, you have several tools at your disposal:

ChangeNotifier: This one should be extended to provide an object that can be used to send change notifications to its listeners.
ChangeNotifierProvider: It has changes from a ChangeNotifier. Child widgets can access the state object and listen the changes
Consumer: Rebuilds part of a subtree when the listening state changes.
Provider.of: Allows descendant widgets to access the state object.

Building our first Provider

Let’s start by creating a provider:

As we can see in the code, the class extends the ChangeNotifier. In that way, the CatProvider shares the value of a cat’s name which can be checked or modified by its descendants. It is necessary to notify the listeners using the notify listeners method on the set function.

At this time, the first Provider is ready to use it. We know that it could be the parent widget of the other Widgets. So that, if we want the entire application to be visible, it must be like this:

Evidently, the ChangeNotifierProvider is the main Widget in the widget tree. Therefore, Widgets can access and modify the cat’s name set in the CatProvider. In the face of change, all of the widgets subscribed to the value will be notified.

Multiple Providers

Needing several providers to develop an APP could be usual, what can we do? Well, the Provider library gaves us a solution called MultiProvider that is a list of ChangeNotifierProviders which share their information with children. It is configured as follows:

As shown, the MultiProvider is the parent of all the widgets on the application and they have full access to all the information. The UserProvider was created just like the CatProvider by extending the ChangeNotifier:

Using Provider data

Once you have the Providers ready, it only needs to decide how to use them from our widgets through two options:

Consumer

The Consumer is a widget that listens to a Provider and transfer its information to the constructor. In addition, you can redraw the part of the tree contained by the Consumer changed to optimize the experience and you do not reconstruct the entire view but only the elements that have undergone changes. That is the way to use it:

The builder requires the entry of three parameters, two mandatory and one optional: BuildContext context, T value, Widget? Child. So, you can use the context and the Provider<T> to build a new widget in the tree with the features already described.

Therefore, using the Consumer could be a nice idea when you want to access the information to display and update on changes, You do not need to change the data from the Provider.

Provider.of

The Provider.of is the base of the Consumer and the the subscription to a Provider that allow us to access and modify the information.

Also, you can use it throughout the widget tree. Check the way to use it:

Evidently, the Provider.of is defined (lines 11 and 12), and then throughout the widget tree it can be used to read (line 17) or write (lines 19 and 20) the widgets — data delivered by the Provider.

To conclude…

The Provider library does not mean a diffult tool, on the contrary It is so useful between community. That is why, you should have heard: “Provider is a state manager.”, but this is already unlikely for you with this information.

However, it is such a suitable tool that can be used for the purpose explained. (If you want an article on state management with Provider, let me know in the comment box 👇🏻). I’m looking forward to reading you!

Do not hesitate to start generating solutions with the Provider. If you liked the article, please giveme some (20+gratitude level)*👏 applause. By the way, I will link you to a repository where we implement all these examples.

Best wishes!