The onboarding process however seems to be a little bit harder as it introduces quite a lot of new Widgets and newcomers are unsure when to use a ConsumerWidget, a Consumer Widget or just a context.wach. There were still some limitations that I will describe here, but keep in mind that we are mostly happy with the solution! It allowed us to spend more time focusing on writing business logic than to make sure that all cases were properly handled. Our experience with Riverpod has been mostly great. Finally, the ability to map a FutureProvider to data, loading and error is something that helps make sure that all the cases are properly handled. The `.autodispose` helper is something that was really helpful in order to ensure that all the state was properly disposed of after we entered something in a form. The ability to group the providers with `.family` is something that makes a lot of sense during the development and helps keep each provider having a single responsibility. Riverpod is filled with a lot of dev helping features making the developer much faster and less error prone. You can create a provider that will return a boolean value without needing to encapsulate the data in an object with a specific type. It makes separating business logic in different file ways much easier. Since providers are just variables, you can import them easily from anywhere and they can return the same type. It means that if a Provider is called somewhere, the path to properly initialise it will always be available. It makes it easy to instantiate Providers (Riverpod's Provider) as global variables that don't depend on Flutter. It's promises seem to be way too compellent to miss.įirstly, Riverpod doesn't depend on the context to share information down the widget tree. Yet, despite its relative young existence, we decided to give it a try for our next project. Riverpod was first published in May 2020, and is currently (as of October 2021) undergoing the final refactorisation to go into the 1.0 version. It makes taking the codebase in hand harder than it should be for large scale projects.įor all these reasons, we wanted to consider another solution for our next project. If you move a Widget, you might also be moving a Provider and some dependencies in your widget tree will not properly receive its dependencies. 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 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |