Assuming wasting peoples time is something you care about. To promote it as a replacement to Provider, and then spend 2 yrs constantly tinkering and changing the API, with no docs to back it up, wasting everyone's time who trusted your advice, is just bad decision making, no two ways about it. GetIt has been largely the same since it's inception, only really adding features.Īnd you're missing the point, when riverpod is _somewhat_ mature and docs are ready, then promote it. Even when provider changed, the changes were small. This idea that everything needs a new version every 3mths is an idea cooked up by marketing departments and sales people.Ĭase in point: Provider or GetIt. Things don't change endlessly until they are abandoned, GOOD things mature, and then go into a maintenance mode where they only require small updates and fixes. Part of the success of Flutter/Dart is its straight-forwardness and simple learning curve (IMHO.)Ĭonsidering I started programming in 1999, I don't think so :p When you try to decode its inner workings you are drown into a humongous rabbit hole which requires a very very good understanding in advanced Kotlin language features as well as coroutines.
I think this may be the OPs problem as well.Īs a more general note, evolving projects have to pay close attention to these iterative improvements which make a lot of sense for the insiders, but add abstraction which may make actual usage very hard.
#Riverpod v2 code#
I know why you do it, but "bare" riverpod is much easier to understand than the boiled down code where need to mentally expand the expressions to the actual provider etc. It was very enlightening, but I noticed that Craig had a hard time wrapping his head around it just like the OP, and I think for a large part it was due to the code generation thing.
This is a feature of Riverpod as all the providers in it are designed to be global and accessible from anywhere in the codebase.I just saw the session you did a while ago with Craig from Google. WidgetRef allows us to gain access to any provider within our codebase, provided that we have imported the corresponding file. ConsumerWidget is a good replacement StatelessWidget and gives us a convenient way of accessing providers with minimal code. ConsumerWidget takes a WidgetRef function as arguments. Use the ConsumerWidget widget to rebuild a part of your UI when the state changes. final counter = ref.watch(counterProvider) final counterProvider = StateProvider((ref) => 0) Īdd this line of code is used to read the current value of the counterProvider and make it available for use in the ref function of the ConsumerWidget. A Provider is a piece of state that can be read and updated by any part of your app. Here is a step-by-step guide to state management using riverpod.Ĭreate a Provider for the state you want to manage. Once again, we will use our good old friend, "The counter app" to understand riverpod in a very simple manner. If you want to know more about the Provider pattern, you can check out this article Project SetupĪdd the riverpod package as a dependency in your pubspec.yaml file. The library is designed to be simple yet powerful and compatible with both Dart 2 and 3. It uses the Provider pattern, which is similar to the Dependency Injection pattern, to manage the state of an application. Riverpod is a state management library for Flutter based on the concept of providers.
#Riverpod v2 how to#
In this tutorial, we will learn how to use Riverpod in a Flutter app to manage the application's state.
0 kommentar(er)
