Menu
Am I wrong or if we just want to pass a value down the Widget tree, Provider is just an InheritedWidget with a dispose method?
273
If you use InheritedWidget in large application, build methods always rebuilds whole build method. But with Provider you have Consumer widget which is can be very specific to control specific blocks of build method, so you have more efficiency. Also listeners have less complexity than InheritedWidgets'(O(N) vs O(N²)).
InheritedWidget is a base class that allows classes that extend it to propagate information down the tree efficiently. Basically, it works by notifying registered build contexts if there is any change. Therefore, the descendant widgets that depend on it will only be rebuilt if necessary.
At an abstract level, we can think of the provider architecture as implementing both dependency injection and data binding. In this architecture, one object (the provider widget) supplies the dependencies (the values) on which another object (the dependent widget) relies, giving them to the other object.
One of the main reasons to prefer Provider over Statefulwidget s is that, using Provider , you will rebuild only the widgets that needs that value (the Consumers ) while the other will not be rebuilt. Instead when you call setState the whole build function of the widget will be called.
Yes. Provider is indeed mostly features based on Inheritedwidgets.
If you want to make your own, then that's fine. But you'll quickly realize that, without provider, you'll have hundreds of useless repetitive lines.
Provider basically takes the logic of InheritedWidgets, but reduce the boilerplate to the strict minimum.
114
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
