Question as a new Commer

[JogoGakha]

Hi !
I have recently looked into several solutions for flutter state management.
Getx, states_rebuilder. and spent last 2 days for flutter_riverpod.

codes below are just simple for class with 1 member only.
==========
import 'package:flutter_riverpod/flutter_riverpod.dart';

class Watched {
int? count ;
Watched({ this.count});

Watched add(int value){
return Watched(count:value);
}
}

class Snotifier extends StateNotifier{
Snotifier():super(Watched(count: 0)) ;

void plus(){
print("here");
state= state.add(state.count!+1);
print(state.count);
}
}

final snProvider = StateNotifierProvider<Snotifier, Watched>((ref){
return Snotifier();
});

======================================

As you read, riverpod needs those code for 1 object with 1 member only.
and if that class have 1 more member, riverpod needs 2 times codes.
That is just my guessing at the third day of studying riverpod.
As those members increase, riverpod needs equatable, freezed,,, .

My guessing is correct ?

[TimWhiting]

It is recommended to use freezed or something similar with StateNotifier. Alternatively you can use ChangeNotifierProvider with a ChangeNotifier if you want to remember manually specifying notifyListeners() whenever you change a property the UI relies on. In a large project you will have fewer problems if you use immutable state with freezed + StateNotifier, but in a smaller project ChangeNotifier should work fine, just be aware that ChangeNotifier depends on the Flutter SDK and thus will not work if you want to reuse any notifiers in a backend application.

[JogoGakha]

Thanks a lot for your quick answer.
I fully understand what you mean.
Plus, could i question 1 more?

Have you ever experienced in "states_rebuilder" and "GetX" packages?
If yes, what do you think about their pros and cons ?

Thanks again.

[TimWhiting]

GetX tries to solve too many problems, and locks you into a microframework that is hard to replace or customize fully. Once you hit the limitations you will be more stuck. I've heard it can help you create apps fast, but locks you in and people regret it once they hit the limitations.

I haven't looked at states_rebuilder in a while. Just took a look again now. It seems very similar to riverpod but with less focus on immutability and more focus on providing a more comprehensive package that tries to solve more problems than state management and dependency injection. (It also has persistence, navigation, localization, theming - starting to get a little bloated like GetX). Personally I think that persistence, navigation, etc should be in separate packages (even if they depend on the same core state management system), since everyone's use cases will vary, and you might prefer the native flutter handling of that (theming) or not need persistence / localization in some areas. Riverpod is a bit more powerful in the state management and dependency injection areas, but I can't say for sure since I have not used states_rebuilder. Riverpod keeps you closer to native state management, and doesn't lock you in so much. It would likely be much easier to switch between one of (Provider - Riverpod - Bloc) to another in that group, than to switch from states_rebuilder / Getx to any other state management technique.

Again my opinion (riverpod > states_rebuilder > Getx), and not trying to insult the authors of those other approaches, since they definitely solve some issues with handling state natively in Flutter.

[JogoGakha]

Thanks a lot. Your answer was enough for my wondering.