#Flutter provider global state code
Which leads us to the third drawback.īy using Provider, you can have no assurances that your code will properly work. Changing the order of your providers, or trying to use one provider elsewhere can be troublesome. It also means that you should be confident in the fact that the dependencies have been properly initialized. While it can be limiting, it also forces you to wrap some simple values into more complex classes, helping sometimes with business naming.Ĭombining different providers can be really verbose especially if the number of dependencies grows.
It means that you can only have one provider of one given type at the same time in your widget tree. In order to get an instance of an object provided with Provider, you need to use its type. At its base, the InheritedWidget, a common widget included in the Flutter Framework that provides the ability to pass information down the widget tree without passing props.Įven if it's widely used, it comes with several drawbacks. Provider is a well known solution for state management. In this article I'm going to explain what are the differences between Provider (our default choice for some time now) and Riverpod, and what led us to choose Riverpod.
Developed by the well known Flutter developer Remi Rousselet, it seems to be the best choice. For the new flagship application of one of our clients, we needed to choose the best library for our use case and we ended up choosing Riverpod, one of the newcomers. But the Flutter ecosystem is moving at a fast pace, especially in State Management (which was and still is a hot topic in the Flutter community!). At Bam, we've been developing applications for a little while now.
0 kommentar(er)
