RiverPod globals drawback

[xOldeVx]

I'm using Provider for a while, i used bloc also, now in my new project i'm trying the RiverPod, but quickly i think to come back to other packages, why?

because it's really nice to little project or examples like counter project, but when the project is scale up, it's really hard to manage all this globals variables.

The global variables is out of the scope and live anywhere, it's the benefit and it's too they big drawback because if i want to add a little helper variable, it's can't be a part of the provider, unlike Provider package that using class, and you mange all of your repository in the same class, and can add variables to your class and manage all of them in the same scope, RiverPod is really less flexibility!

Before i give up this package, I would like to know if there is an example of using RiverPod in a medium / big project. OR if there's an example how using it in a class.

By the way, I'm using NotifierProvider but it's not enough for a class, because the class is limit only to one type (Notifier<T>), I'm looking for a Provider that listen to all of the class properties (with a selector of course).

Thanks!

[Trung15010802]

Why don't use use a custom class/model/state you created in your own in NotifierProvider ?

[sagnik-sanyal]

Provider package that using class, and you mange all of your repository in the same class, and can add variables to your class and manage all of them in the same s

well that's the reason folks use freezed sealed unions or equatable to customise the state classes and that should solve the issue of customisation that you are talking about