River_pod: ChangeNotifierProvider clarification

Created on 18 Jul 2020  Â·  15Comments  Â·  Source: rrousselGit/river_pod

I was reading the ChangeNotifierProvider documentation and I found out the following note:

Note: By using Riverpod, ChangeNotifier will no-longer be O(N^2) for dispatching notifications and O(N) for adding/removing listeners.

Could you maybe specify something more about that statement? Is it better by using Riverpod, worse, or?

documentation

Most helpful comment

Fair.

It's becoming O(N) for dispatching and O(1) for adding/removing listeners — which is better

All 15 comments

Fair.

It's becoming O(N) for dispatching and O(1) for adding/removing listeners — which is better

That makes me wonder if you are still using Flutter's ChangeNotifier when extending a model class or if Riverpod provides its own one that you should import instead.

I'm promoting the usage of StateNotifier instead.

Yeah, I was in fact reading the following article.

As I see it, Freezed is a perfect helper for StateNotifier, as you can now create proper events for the UI using unions. However, I haven't find myself more articles / tutorials about StateNotifier and its uses / advantages.

The problem I see for the migration is that StateNotifier logic differs from ChangeNotifier, as instead of declaring "complex" classes and handling the state there, you are now splitting the information into several pieces, as it based on the ValueNotifier idea.

Just as an example, I was taking a look at the StateProvider doxumentation code. If using a ChangeNotifier class, I would have declared both "selectedProductIdP" and "Products" directly there. However, as it now uses StateNotifier, it is split in two different providers now. I guess you could still create a class having these two elements and then override the equals method or use the equatable library, but I don't think that would be a good solution. What I mean is that it was not trivial for me how to handle these situations at first.

Furthermore, if you also include Freezed to the mix, using inmutable data is also a game-changer in how you think about the data and how you organize your code. I would really love to have more examples showing how to change your way of thinking when developing applications with these new solutions.

The examples in the example folder all uses StateNotifier.
Is there anything missing that you would like to be added?

I will take a deep look to them and open a new issue if I miss anything. Thanks!

I'm not clear how to use StateNotifier is supposed to work with the common use case of having a composite model and the filtering on specific properties. Is there an example that shows that?

@esDotDev The to-do example uses StateNotifer

Yes but it still seems to only support dispatching one type of payload. My models look more like this:

class CounterModel extends ChangeNotifier {
  int get count1 => _count1;
  int _count1;
  set count1(int count1) {
    _count1 = count1;
    notifyListeners();
  }

  bool get isLoggedIn => _isLoggedIn;
  bool _isLoggedIn;
  set isLoggedIn(bool isLoggedIn) {
    _isLoggedIn = isLoggedIn;
    notifyListeners();
  }
}

I know I could do it with ChangeNotifierProvider, trying to understand the State equivalent.

Simply make a class that holds both of your variables

class State {
  final int count;
  final bool isLoggedIn;
}

class MyNotifier extends StateNotifier<State> {
... 
} 

Oh my... that is pretty :D

For some reason StateNotifier class does not exist, so I don't know how to implement the code snippet shown here:
image

Just a comment on the docs in general is I find they just skip over the basics of how to use it, it presents an extremely simple use case (basic change notifier), and then jumps right into advanced use cases that start mixing hooks.

Would be nice to slow down a bit and just explain, here's how you watch, here's how you select, here's how you read. Here's a few flavors of each. Then go onto more complex stuff?

You need to import package:state_notifier
I may re-export it in Riverpod at some point. I'm not sure

Do you mind making a separate issue about the issues you found with the documentation?
I wrote both the package and the doc, so it's hard for me to know what people do not understand

Sure thing, will do, thanks for the quick response as always :)

Was this page helpful?
0 / 5 - 0 ratings