The Right Way To Use Riverpod in Flutter
Hi folks. Today, we will talk about how to use Riverpod in the right way. I have seen so many implementations and they seem to struggle to achieve a result that can be done in a much better and easy way. I will show you how I use Riverpod and I hope it will help you to see it from a different perspective.
I will not teach you the basics. You can learn it from the official docs. I will only show you how to better use the same instruments.
Using Riverpod as a Presenter
Sometimes you don't want to return a widget when a state changes. Sometimes, Riverpod plays just a presenter role. You don't need to draw a user info card. Or, you don’t need to keep an empty string as a state just to use Riverpod to access your login network call. No worries, you will understand what I mean.
Imagine that you have a login screen and you need an authentication flow. Your first choice is to use Riverpod. Yey! But you don’t know what to put as an initial state. You only need to be sure that you are authorized so you can navigate to the home screen. Then, what the hell in the world Riverpod’s state will do anything? You might put a dummy UserModel and then replace it with the real one when you are authorized. Doing so, you might navigate to the home screen too.
It might sound right but there are two mistakes here.
- You use Riverpod just to access your network layer. Which can be done by directly using them in UI(it is not the right way either).
- You navigate inside Riverpod (with a global navigator key for example).
Then, what can be done?
- Create an enum to keep track of the current state of authentication.
- Listen to the state changes on the UI side and navigate if it is a success.
Let’s take a look at the below example.
You see? I let Riverpod do its job. I don’t rely on Riverpod to do the navigation. I only need to listen to the success state. It can be emitted by Riverpod, Bloc, or any other state management tool.
Do you feel like you pass too much data across your app?
Who doesn’t do that, does it? Well, It’s kind of a point why we use a state management tool. We don’t want to pass the state/data by hand. But even with Riverpod, you might do that. I will show you the wrong and right ways and explain why they are wrong or right.
Wrong way
I need to pass the current value ProductFilter every time I need to use GetProductsProvider. And if I am on the products page and change the filter, I need to call getProducts with the filter parameter. You can use another method to manually trigger the update. You might not show immediate effects on filter changes and let user decides when it will be applied. That’s alright. But, you still do not need to pass the filter value every time. When you feel that you are doing this. You need to rely on another provider to access ProductFilter .
Right way
You see? I don’t manually pass anything. getProductsProvider will fetch the product when the filter is changed. I know, in this version I cannot control when it should be fetched. Well, simply, I can do this though.
I read the filter and fetch the product. Any state changes in ProductFilterProvider will not have any effects on GetProductsProvider . If I want to fetch, I just invalidate GetProductsProvider and it will run the build again.
Do you see? I don't try to make things harder. This is much easier than passing the data all the way. But if you don’t have such recurring cases, you can use parameters. Getting product details by product ID for example. Like this.
Conclusion
Thank you for reading so far. I hope that I helped you to see things from a different perspective today.
Don’t forget to follow me, give claps, and share the article if you find it helpful.
Thank you for reading.
