I'm getting confused since riverpod changed its syntax. Instead of 'watch(counterController.state)' it's gonna be 'ref.watch(counterController)' and instead of 'context.read(counterController).add();' will be 'ref.read(counterController.notifier).add();' Maybe you should make a STATEment (hehe) in the description that syntax in the video is a bit outdated. Anyway thanks for the tutorial, it was helpful!
@@congtoannguyen1940 You can pass ref.read as an argument to your provider's constructor final authRepository = ChangeNotifier((ref) => AuthRepository(ref.read)); class AuthRepository extends ChangeNotifier { AuthRepository(this.reader); final Reader reader; // the rest of your code }
So there are plenty of State management in flutter but till now I felt that getx is one of the easiest than any other but will follow you along to learn riverpod
GetX is the easiest in my opinion as well. It’s a great starting point, but as you saw there’s a lot of safety brought into your codebase with Riverpod. While it’s a little more complex I think it’s safer. End of the day though the solution that works well for you is the best one for you 😊
@@leoingson if you want to learn State management the getx is best to get started and easier to understand. But again it varies from people to people and what they need.
Really nice video, I tried using both Provider and flutter_bloc. Provider was very simple but lacked some features, Bloc is good, but has a lot of boilerplate code, for every small thing writing states and events. As of now, Riverpod seems to be right in between.
Your videos are very nice and informative. I have used many things that you have taught. Especially getx. But this was a little too fast. Please do a video comparing these two state management tools. 😘
After doing the async part, the buttons arent doing anything. Im pretty sure I followed exactly except for counterController and counterAsyncController because what you did wasnt working
This is a great tutorial, but for people who are watching this now, there are some slight changes. These are the ones that I found: In Consumer builder: 'builder: (BuildContext context, WidgetRef ref, Widget? child) { return ref.watch(userProvider).when( ...' 'StackTrace? stackTrace' StateNotifierProvider: 'final counterController = StateNotifierProvider((ref) => CounterNotifier());' 'return Text("Basic: ${ref.watch(counterController)}");' For the buttons, it’s changed to ‘ref.read(counterController.notifier).add();’, but you also have to change from ‘class Home extends StatelessWidget’ to ‘class Home extends ConsumerWidget’ change the build function to include ‘Widget build(BuildContext context, WidgetRef ref)’ Async: 'final counterAsyncController = StateNotifierProvider((ref) => CounterAsyncNotifier(ref.read));' I think that covers the changes I found, but I loved the tutorial! Thank you so much! And thanks to Richard Winter for pointing out some of these and helping me figure all this out.
I think there’s a little bit of learning curve at the beginning, but then you start picking up pieces here and there and it starts to really connect and make sense 😊
Hello when i'm following the tutorial the line "final counterController = StateNotifierProvider((ref) => CounterNotifier());" is giving me the error. " The type 'StateNotifierProvider' is declared with 2 type parameters, but 1 type arguments were given. Try adjusting the number of type arguments to match the number of type parameters."
I figured it out, do this instead in providers.dart: final counterController = StateNotifierProvider((ref) => CounterNotifier()); To get the count in main.dart: watch(counterController).toString()
I am a beginner so I am still stuck in making api fetch and post call with state management riverpod please make a video on Rest api services with riverpod. Thanks in advance.
Can you make one video on Firestore, riverpod, stream provider for fetch one time at login and use it every were including change detection. Thanks a lot in advance.
Awesome video! Say if you want to get a SharedPreferences string on init, how would you do this? Do you still use Stateful Widgets with flutter_riverpod and can call init?
Great tutorial, thanks. I have a list view displaying documents from a firestore collection. I would like to tap on a document to navigate to a details page with more information from the document that I tapped. Do you know how to do this with Riverpod? Maybe something to do with .family passing in the list view index?
Thank you for simplifying Riverpod, Tadas! I was overwhelmed by all the providers, but your video helped me understand how everything fits together. Do you have plans to make a video about using Riverpod with an API? That would be really helpful.
Thank you Tadas, great video and very good explanation to Riverpod management. I better understand that... very help me in riverpod dev. strongly other subjects on riverpod I hope ! good job
I have an example on my GitHub repos for patrons if that’s something you’re interested in. But also i have videos on Firebase with other state management and it’s a very similar concept
Coming from alot of GetX use, would it be possible to create a controller class and then provide that class instead of something specific like a counter class ? So, let's say i have a HomeScreenController for homescreen where i have a bunch of methods and variables , could i provide the whole class and use that for only home screen and then the same for different screens? Like If i have more than one state i want to "observe" in the controller ? Dunno if i make any Sense 😅
Yes, that is definitely possible. You can configure the controllers however you want. Personally I like do it by feature, but if you want to do it by page that’s definitely possible
Looks nice but after over a year of commercial flutter development, I see most of the methods in riverpod are a little overkill. What I mean is that I can't figure out where riverpod would be better than my current solution xD Usually, we are working with REST API which mostly fetches data once at the beginning(per view/tab/widget) and if you properly divide your widget tree, then you can maintain a good state o your app - Just follow the rule of moving the state up in a tree when it's needed. Your video is great! Sometimes I feel like we are creating state management solutions to solve problem that 90% of people doesn't have ;) Cheers!
I couldn't agree with this comment any more! I think setState is a looot more powerful and useful than people think. I would agree 90% of the time it is enough, but I think when you get to bigger apps with lots of state, then state management really makes sense. But it is also definitely not necessary, with a clean codebase and InheritedWidget, you can achieve all of this
And one more doubt can we use the data recived from futureprovider outside build method. I don't want the state to be rebuild just want to make an api call and fetch the data. How to implement that in riverpod.Should I use StateNotifier just the way you showed or is there another way ? Thank you
Good explainer, thanks. I'm sticking with GetX. I do appreciate the safety and other aspects of Riverpod, obviously Remy did a great job engineering it. I guess I've just gotten comfortable with GetX, and the the simplicity of a getbuilder passing in the "state" variable, then referencing it in your widget tree. If the controller changes the state, update the widget tree. Do you think it's a Imperative vs Declarative thing? After decades programming in other languages I think my mind is imperative biased lol
Yea, nothing wrong with sticking to the thing you are comfortable with. And to be honest, I am not really sure, I feel like there isn't a very clearly defined line for what is imperative vs declarative. Maybe I am wrong on this point though
@@tadaspetra I'm usually wrong about this, so I've spent a bit of time thinking it through, and I think that if you use getbuilder, manage your "state" in your controller, then call update when you want to update your widgets it would be imperative, if it changes, it doesn't change until the program tells you it changed. If you connect with listeners, or obs, streams... you are being more declarative. If it changes, it changes, things happen.
I've used StateProvider when you can use "==" for deciding a state is updated, and the value is simply dependent on a value for the initial state. You can do the same thing with StateNotifierProvider, but it's a bit more typing. :)
What Provider should I use if want to pass the data returned by the FutureProvider to other Provider, and how donI actually do it? This is where im stuck now :)
Depends what your end goal with the new provider is. But you can watch and read other providers within the providers. If you want some more in depth Riverpod tutorials check the Fun With Flutter channel, he has a really good series
I ended up reading my future provider inside my statenotifier just like what you did with Async one. And thank you very much simplifying Riverpod. your explanation is crystal clear!
Hey Tadas, can you make a new video for states_rebuilder? The author just released v4.0 (can be found in the null_safety branch). I think not too much changed but since v3.0 the way to inject states changed and made it much simpler, which is not covered in your previous video.
Yea I’ve gotten some other comments about it. I might take a look eventually. But i kind of want to make more non state management videos lol. The only reason I made this one is because I was currently working with it
Great tutorial but a small doubt accroding to riverpod documentation it is a bad idea to read another provider inside the body of Provider. Why is it so?
I don't think it is a bad idea. I think the documentation even says that you can do this. riverpod.dev/docs/concepts/reading#reading-a-provider-inside-another-provider
riverpod.dev/docs/concepts/combining_providers Here there's a red dialog indicating not to read inside the body of a provider. Can you explain it a bit. Thank You
@@SIDDARTHBHURA I think it is less a "error" type of dialog and more of a "it doesn't make sense to do it". Using read wouldn't really break the code, it just makes the provider not responsive, and defeats the purpose. I think people have a lot of issues when using read, so that's why it's emphasized
