4

There is setState and moreover Provider, using which you can manage your states easily and neatly, then why Riverpod?, I see different examples in enter link description here where riverpod is being used, I just find each example making simple things more complicated, when you use Riverpod, same things can be done more easily with Provider or just using setState and following some good techniques while managing states in codes.

there is a package named hooks_riverpod, I don't find the justification of this package just to support riverpod you hacked all the statndard widgets although there is another version flutter_riverpod but using hooks is not an intended approach maybe helpful for people coming from reactjs background but flutter engineers have not designed flutter this way, using these non-standard approaches you are just trapping yourself within the mercy of these few packages.

Inherited widgets is only standard approach given by flutter of managing states across the app, Provider and some other Packages like Redux they just follow the same approach.

If you may have used the Riverpod or related packages please share your experience.

IonicFireBaseApp
  • 925
  • 3
  • 10

2 Answers2

5

Well, there's a lot of debate on a good state management solution out there.

But in your context, I'd like to mention some points.

Why Riverpod over Provider?

Well, Riverpod was built to fix some issues of Provider which would have been impossible to fix in Provider. Like:

  1. Majorly, Riverpod is compile safe.
  2. Solves stuff like multiple providers, adding providers from anywhere.
  3. Removes Flutter dependence, there's no need of using contexts anymore like that were used in Provider.

and others... for more on that you can refer to the home page of Riverpod here

Also, Remi, the creator of Riverpod & Provider suggests using Riverpod over Provider.

Secondly, why not setState?

Well, you can't build a featured application just using setState with proper programming standards. You would have to pass up and down data in your application continuously with Prop Drilling. Imagine having 5 widgets under a parent widget and the parent widget needs the data in the 5th sub widget. This is just a normal case, it could go much worse in actual applications.

About hooks?

Well, yes, it's well easy for React devs to quickly jump on to Flutter. But that's just not the case it was developed for. Its main purpose is to use reusable functional widgets. So, a good example of this will always be, when you're using Animation Controller and you've to maintain its lifecycle every time you use it. I can't go in depth here, for that you can refer to the docs.

Sahil Sonawane
  • 1,144
  • 9
  • 18
  • 2
    Flutter Hooks are an easy way to abstract out the correlated responsibilities of State, initState, build, and dispose. In essence, they bring together the lifecycle states in a cross-function unification. – Randal Schwartz Aug 24 '22 at 08:04
  • "theres no need of using contexts anymore" lol, yeah, because there's a new one, WidgetRef, which you have to infact add alongside your context and use and also pass around like you did with context, so why add this extra ref when I can just do exactly the same with context – public static void Main Jul 05 '23 at 13:50
  • 1
    @publicstaticvoidMain It was an essential part of the design decision. Ref removed the dependency of context and thus using it in the widgets (or passing context around outside of widget if you like that way). So using context outside of widgets is a big thing that surely Context couldn't fix. Also not to mention, it helps access providers inside another provider, so no proxy provider, direct access just like any other inversion of control (ex. get it) – Sahil Sonawane Jul 31 '23 at 10:18
  • @SahilSonawane okay, makes sense now – public static void Main Aug 02 '23 at 00:28
3

It depends on the project and how you like to handle state. If you are ok with setState management/Inherited widgets, you don't need to use others.

I like share some reference here, On riverpod doc second section you can find

Provider, without its limitations Riverpod is inspired by Provider but solves some of it's key issues such as supporting multiple providers of the same type; awaiting asynchronous providers; adding providers from anywhere, ...

  • riverpod, Dart only (NO flutter)

  • flutter_riverpod, A basic way of using Riverpod with flutter. You mostly use it for state management.

  • If you are using hook widgets(flutter_hooks) that reduce the boilerplate code like dispose, you can use hooks_riverpod

Also, all these packages provided by same author Remi Rousselet

Md. Yeasin Sheikh
  • 54,221
  • 7
  • 29
  • 56