(create: (context) => Home().fetchAddress),\n ],\n child: MyApp(),\n ),\n );\n}\n```\n\nThis widget just makes code more terse and readable. Which is always nice.\n\n\nIf you really want to be impressed by the creator of Provider,
Remi, check out his package called
nested, which provides widgets that can take a list of children and nest them. This is what `MultiProvider` is built on top of. \n
\n ChangeNotifier is built into the Flutter SDK, and it's \"purpose\" is to call `notifyListeners` whenever data changes that should in turn update your UI. In the example above, I am not using it in widgets, but it's important to note that this class is not available in other Dart environments.\n
\n\nThis is one way to encapsulate the state of your app inside of classes, but it presents a problem... if you wanted to use it in multiple widgets in different branches in your widget tree, it would quickly make your code super hairy and difficult to refactor. You'd basically be passing an instance of your `ChangeNotifier` all around the widget tree manually.\n\nBut, that is the _exact_ problem that `provider` solves.\n\n### ChangeNotifierProvider\n\nThis example is not going to be much different than the previous Provider lesson. The `ChangeNotifierProvider` is used exactly like the vanilla Provider. Let's start with the code, and they'll I'll highlight some important points.\n\nFirst, add the provider to the tree:\n\n```dart\nclass Person with ChangeNotifier {\n Person({this.name, this.age});\n\n final String name;\n int age;\n\n void increaseAge() {\n this.age++;\n notifyListeners();\n }\n}\n\n// here, you can see that the [ChangeNotifierProvider]\n// is \"wired up\" exactly like the vanilla [Provider]\nvoid main() {\n runApp(\n ChangeNotifierProvider(\n create: (_) => Person(name: \"Yohan\", age: 25),\n child: MyApp(),\n ),\n );\n}\n```\n\nAs you can see, wiring up a ChangeNotifierProvider is exactly the same as the Provider example from the previous lesson. Using it in widget tree is going to be similar:\n\n\nThe example I'm about to show you is the _most basic_ example, and probably not exactly how you'd consume the data from provider in your real app. That will be covered in the next lesson, so don't @ me.\n
\n\n```dart\nclass MyHomePage extends StatelessWidget {\n const MyHomePage({Key key}) : super(key: key);\n\n @override\n Widget build(BuildContext context) {\n return Scaffold(\n appBar: AppBar(\n title: const Text('Provider Class'),\n ),\n body: Center(\n child: Text( \n // reading this data is exactly like it was in\n // the previous lesson \n '''\n Hi ${Provider.of(context).name;}!\n You are ${Provider.of(context).age} years old''',\n ),\n ), \n floatingActionButton: FloatingActionButton(\n // this is where there's a difference.\n // when the FAB is tapped, it will call `Person.icreaseAge()` on the\n // person instance that was created by provider. \n onPressed: () => Provider.of(context, listen: false).increaseAge(),\n ),\n );\n }\n}\n```\n\nTwo important notes about that code:\n\n- Because this is a `ChangeNotifier`, the UI will re-build and the age will be increased. (Success!)\n- You may have noticed `listen: false` in the `of` method. The `listen: false` parameter is _mandatory_ whenever you're using Provider to fetch an instance and call a method on that instance. This has a practical application, though. Because you aren't listening, the widget doesn't need to re-render just because a change was made. In this example, there would be no reason to re-render the FloatingActionButton, even when the ChangeNotifier did notify it's listeners.\n\nFinally, just so you believe me, let's look at this running in a Flutter app:\n\n","created_at":"2020-07-25T15:03:29.864Z","id":101,"slug":"change-notifier-provider","title":"ChangeNotifierProvider","tutorial":11,"updated_at":"2020-08-05T19:36:11.877Z"},{"author":1,"content":"ProxyProvider is the tough to grok at first, but it's quite useful. It let's you pass values from one provided model to another, to create a value from two (or more) providers.\n\n\n\nRight off the bat, here's some things to keep in mind before looking at the code:\n\n- There are several kinds of ProxyProviders, which are proxy versions of the standard providers they resemble:\n - ProxyProvider\n - ChangeNotifierProxyProvider\n - ListenableProxyProvider\n- You can use up to 6 providers to combine values, but you must use the following classes to specify the number of providers that will be passing values into the proxy:\n - ProxyProvider0 (the base class)\n - ProxyProvider2 (pass values from 2 providers into the proxy)\n - ProxyProvider3\n - ProxyProvider4\n - ProxyProvider5\n - ProxyProvider6\n \nThose same classes exist for `ChangeNotifierProvider` and `ListenableProxyProvider`.\n\n### Using Proxy Provider\n\nExplaining the proxy provider in words is pretty esoteric and hard to grok, so let's look at some code. In the following example, our example friend 'Yohan' is growing up, and it's time for him to get a job. I am providing a `Person` object to the widget tree, and also a `Job` object. A `Job` requires a person for initialization.\n\nIn this situation, the `Job` is the _proxy_. Which means that the Job is the object you'll likely want to interface with, but it's values rely on the person, so that will be exposed as well.\n\nNB: It's important to note that you still _can_ interact with the person if you'd like, and you don't _have_ to expose the person via the job instance.\n\nIn this example, Yohan has made a digital business card. And, the he wants the business card to automatically change it's title when he gets older and graduates, and starts his career. The set-up follows:\n\n\n```dart\nclass Person with ChangeNotifier {\n Person({this.name, this.age});\n\n final String name;\n int age;\n\n void increaseAge() {\n this.age++;\n notifyListeners();\n }\n}\n\nclass Job with ChangeNotifier {\n Job(\n this.person, {\n this.career,\n });\n\n final Person person;\n String career;\n String get title {\n if (person.age >= 28) return 'Dr. ${person.name}, $career PhD';\n return '${person.name}, Student';\n }\n}\n\nvoid main() {\n runApp(\n MultiProvider(\n providers: [\n // you must first provider the object that will be passed to the proxy \n ChangeNotifierProvider(create: (_) => Person(name: 'Yohan', age: 25)),\n // Because the ChangeNotifierProxyProvider is being used,\n // each class used must be of ChangeNotifier type \n ChangeNotifierProxyProvider(\n // first, create the _proxy_ object, the one that you'll use in your UI\n // at this point, you will have access to the previously provided objects \n create: (BuildContext context) => Job(Provider.of(context, listen: false)),\n // next, define a function to be called on `update`. It will return the same type\n // as the create method. \n update: (BuildContext context, Person person, Job job) => Job(person, career: 'Vet'),\n ),\n ],\n child: MyApp(),\n ),\n );\n}\n``` \n\nAs you can see, the set up is a bit more involved, perhaps. But, it's still quite terse and easy to read. And, in the following example, you'll see how easily it's used.\n\n\n\nThe neat thing here to look for is that all three values that are _read_, are done via the provided `job` object, but the button calls the `Person.increaseAge` method when pressed. Yet, the UI still knows to rebuild when the `Job.title` value is different.","created_at":"2020-07-25T15:08:17.154Z","id":108,"slug":"proxy-provider","title":"ProxyProvider","tutorial":11,"updated_at":"2020-08-05T19:36:11.877Z"},{"author":1,"content":"[Provider](https://github.com/rrousselGit/provider) can be somewhat difficult to explain. The package author, [Remi](https://github.com/rrousselGit), has described it as a mix between State Management and Dependency Injection. At his talk at [Flutter Europe in 2019](https://www.youtube.com/watch?v=BulIREvHBWg), he quoted another Flutter community usual, [Scott Stoll](https://twitter.com/scottstoll2017), who called is 'Inherited Widgets for humans'. I think this is the most straight-forward explanation.\n\nI also find it difficult to find an explanation on the interwebs that includes an easy to grok example. If you want to use provider effectively, you're left to tinkering or reading the source code. I will attempt to fill that void here. \n\nIn a nutshell, Provider gives us an easy, low boiler-plate way to separate business logic from our widgets in apps. Because it's built on `InheritedWidget` classes, it also makes it easy to re-use and re-factor business logic. Separating state from your UI is one of the main problems that Provider solves.\n\n### What does Provider do for me? \n\nIt can be used in a variety of ways in your Flutter app. It can be used in-lieu of more robust state-management libraries, or along side them. It can be used with `InheritedWidgets` and `StatefulWidgets`, or again, in place of them. It \"does\" two jobs:\n\n- Separates your state from your UI\n- Manages rebuilding UI based on state changes\n\nWhich makes loads of things simpler, from reasoning about state, to testing to refactoring. It makes your codebase _scalable_.\n\nConsider this widget tree that uses no libraries at all:\n\n\nThis widget tree is an extremely crude version of the `Counter` app we all know and love. It passes a callback (`onPressed`) to a `FloatingActionButton` and a `counter` property down a text widget. When `onPressed` is fired, it updates the counter. \n\n\nThat's fine, but what happens when you need to refactor your code? What happens if state is shared between different widgets? And what about testing? Your logic is sprinkled throughout your app, and tied to your widgets. This makes writing tests a pain, verbose, and hard to refactor.\n\nImagine for a moment that you decided you no longer wanted a FloatingActionButton, and you wanted a button, as a child of the column, to trigger `onPressed`. That refactor would be a pain. \n\n(I know my drawing... err... leaves a lot to be desired. But the gist is that all of the pink text is what would have to be refactored.)\n\n\n\nBut there's a better way. (To be fair, this can be done with just plain ol InheritedWidgets as well, but provider has a nicer API and less boiler plate.) \n\n(Disclaimer! A provided widget _is_ in the widget tree, but I drew it separately because I feel it's helpful to think of them as different entities.)\n\n\n \n\nIf you're using this architecture, you can have any widget in the tree read the Counter and trigger counter methods. Refactor away, because it's much easier. And, you can test the logic of the counter with a simple unit test, no need to bring the the UI into it.\n\n### Is provider a State Management library?\n\nIn my opinion, no. But it can be. \n\nUnlike libraries like Redux and Bloc, Provider simply provides tools to 'wire up' our UI to business logic, and it is not opinionated in how you manage state. Because of this, it's almost easier to look at it as Flutter-specific dependency injection library (and that's what it was originally advertised as). In fact, the Bloc library is built on top of provider, because provider, again, doesn't _really_ manage state for you.\n\nProvider helps make your widgets as 'dumb' as possible by separating logic from the widgets, and injecting the important data to those widgets. If you're building an e-commerce app, you can build a _cart page_ that knows it should display some items in a cart. But, using provider, the widget has no concept of what those items are, nor is it responsible for keeping track of the cart contents. Rather, there would be a separate class elsewhere in your app, perhaps called `Cart`, that manages all the logic. And, whenever a new item is added the the cart, the widget that displays the cart item is told to re-render with the new items.\n\nIf this seems hand-wavy and obtuse, the examples on the following pages should help make this more concrete (as well as show you what you really want: _how_ to use provider with real life code). \n\nBut lastly, I need to point out a few important points to remember while using provider:\n\n* Provider is built using widgets. It literally creates new widget subclasses, allowing you to use all the objects in provider as if they're just part of Flutter. This also means that provider is _not_ cross platform. (By cross platform, I mean outside of a Flutter project. i.e. AngularDart)\n* Separating this business logic makes your code much easier to test and maintain.\n* Again, Provider is not opinionated about state management. It is not going to force consistency like Redux would.\n\n\nThe remainder of this tutorial will walk through the usage of Provider by walking through how you'd use most of the different classes in Provider.","created_at":"2020-07-25T15:01:45.156Z","id":99,"slug":"what-is-provider","title":"What is Provider?","tutorial":11,"updated_at":"2020-08-05T19:36:11.877Z"},{"author":1,"content":"The content of this lesson could be filed under \"extraneous\". You don't need to know this in order to use Provider. No more than you need to know how Skia works to build a Flutter app. But, you might learn something neat. I will also spend some time gushing about how cool Provider is, and how well designed it is. This was not my intention, but it happened.\n\nSome background: In order to learn Provider, I basically 'rebuilt it', using the original package as a guide. This is how I like to learn the ins and outs. While taking on that venture, I learned a lot of interesting things about both Flutter and Provider. Things that I have read before, and make sense logically, but really 'clicked' when I saw how they were implemented. \n\nSo, I've decided to do a short write up of how Provider works for the curious out there. \n\n\nThis is 100% information that I have deduced, without any confirmation from the real experts, such as the package author. So, take this all with a grain of salt.\n
\n\n### A Flutter detour\n\nBefore I get in the weeds, I want to take a little detour to and talk about how Flutter builds (and rebuilds) UI.\n\nAs you may know, you (the Flutter developer) can tell Flutter to rebuild your UI by calling `setState`. You can also manage when your UI updates with other methods on the `State` object, such as `didChangeDependencies`. But, it all comes down to the `State` object. (`StatelessWidget`, on the other hand, are rebuilt when they're changed by configuration changes passed into them.)\n\nWhat you may not know is that widgets are just \"configuration\" or blue-prints for different objects called `Elements`. And, when you call `setState`, your widget is interfacing with a singular Element, and not the Flutter or the widget tree itself. It's the Element's responsibility to tell Flutter that it has changed, and it needs to be repainted. This is done this via a method called `markNeedsBuild`, which is called internally.\n\nThis matters to us (provider users) because all objects in Provider are widgets (and elements). They know how to interface with Flutter. Which means you don't have to call `setState` if you're using Provider properly, because its toolbox of widgets are handling all of that for you. This is an important piece of Provider's design.\n\n### Providers are widgets\n\nIf you read any docs, you will surely understand that all classes in Provider are implementations of different widgets. I read this over and over again, but just kind of \"glossed over it\", and didn't really internalize the implications. But, I'll say it here anyway: Providers are widgets! And that's primarily what I want to talk about in this lesson. \n\nWhen I started reading Provider source code, I was immediately overwhelmed by the number of classes, mixins, extensions and interfaces that are in that library. There are typedefs abound, to boot. I wrapped my head around it by creating a chart of sorts that describes the class structure of Provider. It looks like this:\n\n(I don't expect you to be able to read this)\n\n\n\nKeep in mind that the only Provider that this document includes is the base `Provider` class. I haven't included FutureProvider, StreamProvider, Consumer, Selector, etc.\n\nThe big text that you _can_ read in this image is \"Element Tree\" and \"Widget Tree\". This seems like a good place to start. \n\n \nThe element tree:\n\n\nThe widget tree:\n\n\nAll these charts may only make sense to me, but let me point out some interesting insights:\n\n1. These classes aren't just Widget types, they're widgets built from the ground up. They include custom `Element` types. They are literally custom implementations of objects that Flutter can work with, and they don't rely on `InheritedWidget` or under the hood. This is impressive, _and_ powerful.\n2. Much of the classes are exposed to us, the developers. Specifically interesting is `InheritedProvider`, which all providers are subclasses of. (Again, my chart only shows `Provider`, but you'll have to trust me on this one.) This means that just like you can build your own widgets in Flutter, Provider is implemented in a way that you can build your `Providers`. Truly following the Flutter pattern that we all know and love.\n3. Provider even includes its own `BuildContext` sub class, which is why we can work with Provider so seamlessly in the widget tree.\n4. `InheritedProvider` classes do have a concept of `State` (via the `_Delegate` objects), which seems to be one of the reasons that we can use these inherited widget-esque objects with so little boiler plate. Previous to this package, using InheritedWidget's for responsive state management involved combining inherited widgets and stateful widgets, which of course means a ton of boiler plate.\n\n### final thoughts\n\nProvider is truth.","created_at":"2020-07-25T15:11:19.002Z","id":112,"slug":"for-the-curious-how-is-provider-implemented","title":"For the curious: How is provider implemented","tutorial":11,"updated_at":"2020-08-05T19:36:11.877Z"},{"author":1,"content":"In order to showcase the real, core value proposition of provider, I will show you the simplest example Flutter app I can build. To be sure, we will see some complex and \"real world\" examples through-out this section, but at it's core, Provider just tells Flutter apps how to interact with non-widget data classes. \n\nFirst, I want to show the example, and then I will walk through the code showing and explain what's going on.\n\n\n\nThat's it. It's just an app that displays some text on the screen. Now, let's walk through the code.\n\n```dart \n// This class is what Provider will work with.\n// It will _provide_ an instance of the class to any widget\n// in the tree that cares about it. \nclass Person {\n Person({this.name, this.age});\n\n final String name;\n final int age;\n}\n\n// Here, we are running an app as you'd expect with any Flutter app\n// But, we're also wrapping `MyApp` in a widget called 'Provider'\n// Importantly, `Provider` is itself a widget, so it can live in the widget tree.\n// This class uses a property called `create` to make an instance of `Person`\n// whenever it's needed by a widget in the tree.\n// The object returned by the function passed to `create` is what the rest of our app\n// has access to. \nvoid main() {\n runApp(\n Provider(\n create: (_) => Person(name: \"Yohan\", age: 25),\n child: MyApp(),\n ),\n );\n}\n\n\n// Just a plain ol' StatelessWidget\nclass MyApp extends StatelessWidget {\n @override\n Widget build(BuildContext context) {\n return const MaterialApp(\n home: MyHomePage(),\n );\n }\n}\n\n// Again, just a stateless widget\nclass MyHomePage extends StatelessWidget {\n const MyHomePage({Key key}) : super(key: key);\n\n @override\n Widget build(BuildContext context) {\n return Scaffold(\n appBar: AppBar(\n title: const Text('Provider Class'),\n ),\n body: Center(\n child: Text(\n // this string is where we use Provider to fetch the instance\n // of `Person` created above in the `create` property\n '''\n Hi ${Provider.of(context).name}!\n You are ${Provider.of(context).age} years old''',\n ),\n ),\n );\n }\n}\n```\n\nFor the most basic example, that's all you need. Provider simply exposes an instance of an object to all it's descendent widgets via 'Provider.of(context)'. \n\n\nIn Dart, it's convention to use `T` as a generic type. When you see `Provider.of(context)`, \"T\" is indicating that a type argument is required. For example, `Provider.of(context)` would be used to indicate you're referring to a `User` object. This is no different than defining collections. For example, a list of strings is defined by writing `List myList = []`.\n
\n\nIf you're familiar with [InheritedWidget](https://api.flutter.dev/flutter/widgets/InheritedWidget-class.html) objects, then this should look familiar. And that's because Provider is, in a nutshell, a widget that behaves exactly like the `InheritedWidget`, but with far less boiler plate. (If you aren't familiar, you may want to follow that link and learn a little bit.)\n\nIf you take anything from this lesson, I hope that it's this: Provider just... err... _provides_ classes to your widget tree that aren't widgets.\n\nThis example shows the most basic example, in which you can only read data. You can't update data. And even if you could, it wouldn't cause the widget tree to re-render, because there's nothing telling Flutter that the data has changed. Luckily, Provider includes a whole swath of classes that can help you with this which we'll explore in the following lessons.","created_at":"2020-07-25T15:02:34.380Z","id":100,"slug":"the-most-basic-example-using-provider","title":"The most basic example using Provider","tutorial":11,"updated_at":"2020-08-05T19:36:11.877Z"},{"author":1,"content":"There is no new information here, but rather an app that uses multiple providers, over multiple screens. That in mind, this lesson is broken down into two parts: the full app, running in DartPad, followed by some explanations for some of the parts that may be harder to grok.\n\n\n\n### Breaking down interesting parts\n\nThe app isn't all that interesting, but there are a few code examples that will help drive home the ideas of provider.\n\n- First, let's take a look at the models, so the rest of the code makes sense\n\n```dart\n// The product class does nothing fancy\nclass Product {\n final String name;\n final double cost;\n\n Product({this.name, this.cost});\n}\n\n// This class tracks the products that \n// the user wants to buy, and it's a [ChangeNotifier]\nclass Cart with ChangeNotifier {\n List products = [];\n\n double get total {\n return products.fold(0.0, (double currentTotal, Product nextProduct) {\n return currentTotal + nextProduct.cost;\n });\n }\n\n void addToCart(Product product) => products.add(product);\n void removeFromCart(Product product) {\n products.remove(product);\n notifyListeners();\n }\n}\n\n// The user class does nothing fancy.\nclass User {\n final String name;\n final Cart cart;\n\n User({this.name, this.cart});\n}\n\nclass Store {\n // Perhaps we're going to use a StreamProvider?\n StreamController> _streamController = StreamController>();\n Stream> get allProductsForSale => _streamController.stream;\n \n // rest of class\n}\n\n// This class is a singleton that mocks out two pieces of functionality:\n// Logging in a user\n// And fetching products from a realtime data base (like FireStore)\nclass MockDatabase {\n static final MockDatabase _instance = MockDatabase._internal();\n\n factory MockDatabase() {\n return _instance;\n }\n\n MockDatabase._internal();\n\n Future login() async {\n return await Future.delayed(Duration(seconds: 1), () {\n return User(name: 'Yohan', cart: Cart());\n });\n }\n\n // Imagine this is like calling Firestore.get('products').listen(...);\n // Anytime there are new products in the databse, they'll be pushed down\n // to the app.\n Stream> getProductsBatched() async* {\n List allProducts = [];\n\n var i = 0;\n while (i < 10) {\n await Future.delayed(Duration(seconds: 1), () {\n allProducts.add(_productsInDatabase[i]);\n });\n i++;\n yield allProducts;\n }\n }\n // rest of class...\n\n}\n\n```\n\n- The app starts with a `MultiProvider` to provide some models to the entire app.\n\n```dart\nvoid main() async {\n // creating a use right off the bat is \n // contrived so I can use a `.value` constructor.\n final user = await MockDatabase().login();\n\n runApp(\n MultiProvider(\n providers: [\n // The user provider uses a value constructor because the value\n // already exists, and we want to make sure we're using the same user\n Provider.value(value: user),\n\n // Store and Cart are both needed on the home page,\n // so they're provided right off the bat\n Provider(create: (_) => Store()),\n ChangeNotifierProvider(create: (_) => Cart()),\n ],\n child: MyApp(),\n ),\n );\n}\n```\n\nNothin' too fancy there. Let's move into the `Scaffold.body` property of the `build` method for the `ProductsPage`, where we're going to use a `StreamProvider`\n\n```dart\n// The StreamProvider is providing a single property from the Cart,\n// not the Cart itself. Thus, StreamProvider>\nbody: StreamProvider>(\n initialData: [],\n // using Provider to fetch a model and return a property from it? Fancy!\n create: (_) => Provider.of(context).allProductsForSale,\n catchError: (BuildContext context, error) => [],\n // List equality has nothing to do with the elements in the list\n // Therefor, in order to tell Flutter that list has changed, we need to compare a \n // property of the list that will be different when elements are added or removed.\n updateShouldNotify: (List last, List next) => last.length == next.length,\n builder: (BuildContext context, Widget child) {\n final items = context.watch>(); // context.watch rules\n return ListView.builder(\n itemCount: items.length,\n itemBuilder: (BuildContext context, int index) {\n if (items.isEmpty) {\n return Text('no products for sale, check back later');\n }\n final item = items[index];\n return ListTile(\n title: Text(item.name ?? ''),\n subtitle: Text('cost: ${item.cost.toString() ?? 'free'}'),\n trailing: Text('Add to Cart'),\n onTap: () {\n // notice that this calls a method on `Cart`, \n // but Cart isn't used anywhere else on this page.\n // This is an example of one model being shared across screens,\n // And I promise its far easier than passing values from one \n // screen to another during navigation\n context.read().addToCart(item);\n },\n );\n },\n );\n```\n\n- Lastly, let's peak at the other page:\n\n```dart\nclass CartPage extends StatelessWidget {\n @override\n Widget build(BuildContext context) {\n return Scaffold(\n appBar: AppBar(\n title: Text(context.watch().name + 's Cart'),\n ),\n // Consumer + a ChangeNotifier (cart) will ensure that \n // That this portion of the tree rebuilds when Cart.notifyListeners() is called.\n body: Consumer(\n builder: (BuildContext context, Cart cart, Widget child) {\n return Column(\n children: [\n Expanded(\n child: ListView.builder(\n itemCount: cart.products.length,\n itemBuilder: (BuildContext context, int index) {\n if (cart.products.isEmpty) {\n return Text('no products in cart');\n }\n final item = cart.products[index];\n return ListTile(\n title: Text(item.name ?? ''),\n subtitle: Text('cost: ${item.cost.toString() ?? 'free'}'),\n trailing: Text('tap to remove from cart'),\n onTap: () {\n // context.read is the easiest way to call \n // methods on a provided model\n context.read().removeFromCart(item);\n },\n );\n },\n ),\n ),\n Divider(),\n Align(\n alignment: Alignment.centerRight,\n child: Text(\n // remember, context.select allows you to \n // listen to specific properties, and ignore the rest of a class\n 'TOTAL: ${context.select((Cart c) => c.total)}',\n style: Theme.of(context).textTheme.headline3,\n ),\n )\n ],\n );\n },\n ),\n );\n }\n}\n```\n\nHopefully this slightly more robust example shows you how different classes from Provider all work along side each-other, even across pages. \n\nBut, that's it. You've solved my Provider puzzle! Checkout [Provider docs](https://pub.dev/packages/provider) for even more classes and updates to the package.","created_at":"2020-07-25T15:10:34.826Z","id":111,"slug":"the-final-example-a-shopping-cart-app","title":"The final example (A shopping cart app)","tutorial":11,"updated_at":"2020-08-05T19:36:11.877Z"},{"author":1,"content":"If you've used Provider at all in the past, then you may have noticed that all types of `Provider` classes have two constructors: the default constructor, and a `.value` named constructor.\n\nThese constructors, which I'll call _value constructors_, have specific use-cases. In the examples you've seen so far the `.value` constructors wouldn't be what you want. \n\nIn general, you want to use value constructors when you already have an instance of a class you'd like to provide. Say you're providing a `Person` instance that has already been created for some other reason. If you pass that variable into a provider, it's possible that the provider will dispose of that object while other pieces of code are still using it. \n\nFor example:\n\n```dart\nPerson person = Person();\n\nChangeNotifierProvider(\n create: (_) => person; // bad!\n)\n``` \n\nIf that person variable is used anywhere else, it may cause errors when this widget is removed from the tree. The reverse of this set-up is also a problem. Consider this example:\n\n```dart\n// this is bad! \n// everytime this widget is rebuilt, it will create a new instance of `Person`\n// and every new instance of Person will trigger a rebuild in _every_ widget reading this value.\nChangeNotifierProvider.value(\n value: Person(), \n child: ...\n)\n```\n\n\nSo again, value constructors are best used when you need to provide a specific value that is already created. Some use-case examples: \n \n- Perhaps you need to provide an instance of an object that already exists where it otherwise isn't available. \n- Maybe you have a reason to hide a provided class from certain widgets, but you want to expose a piece of the class. Suppose you have a `Person` object provided to a big chunk of your widget tree, and you further on down the tree you want to expose the persons name (as a String), but none of their other properties.\n\nRegardless of your reasoning, this is what using a value constructor looks like:\n\n```dart\nclass PersonsNameLabel extends StatelessWidget {\n @override\n Widget build(BuildContext context) {\n return Provider.value(\n value: Provider.of(context).name,\n builder: (BuildContext context, Widget child) {\n return Text(context.watch());\n },\n );\n }\n}\n```\n\n\nThere are a couple other examples in the
documentation that use value constructors, but they're extremely specific and outside the scope of this tutorial.\n
\n If you need a refresher on Streams, I recommend you
check out my code-cartoon of Dart Streams, or find a whole chapter about Streams in my book
Flutter in Action. Streams can be hard to grasp (and implement) if you aren't familiar, but they're wildly useful and popular in the Flutter ecosystem.\n
\nIf you really want to be impressed by the creator of Provider,
Remi, check out his package called
nested, which provides widgets that can take a list of children and nest them. This is what `MultiProvider` is built on top of. \n