Provider - Selector rebuild when scrolling

Question

I am using the Selector widget as shown below

Nothing wrong with it's build method, only call it when the value changes. But when I use Devtools or android studio to track widget rebuild it's showing that the Selector it self rebuild when I am scrolling whether in a list or any other widget that support scrolling.

Yes the Selector didn't call the build method until the value changes but is this normal ?

Using Devtools:

As you can see the others (2) Selectors doesn't have to be triggers but yet they are.

sorry for my bad English, I can explain in another way in the comment section if you didn't understand me and thanks in advance.

edit:

I guess I know why the selector is rebuilding it's self, because I am using the provider class as listener to scroll controller direction with changenotifier. here the code in provider class:

bool isHideHomeScreenTabBar = false;

void hideShowTabBar(ScrollDirection scrollDirection) {
  isHideHomeScreenTabBar = scrollDirection == ScrollDirection.reverse;
  notifyListeners();
}

in my Home screen:

_scrollController.addListener(() {
 Provider.of<AppProvider>(context, listen: false).hideShowTabBar(
 _scrollController.position.userScrollDirection);
});

So basically the provider trigger changenotifier with every scroll I do and the selector get notified and rebuild it's self but if the value didn't change the selector won't trigger the build method (so it works fine for the child and the widget in the build method of the selector).

But even so is this normal ? and why, The other selectors aren't even listening to the scroll direction.

Anyway I found an alternative way to do this (with an animation controller) but it would be nice if someone could explain what is happening here, it's important for me at least because I might use another state management.

Answer 1

I know what was happing. I am using 1 class for the provider that contains all the values I need with many methods using notifyListeners, however I thought it's ok to use 1 provider class if I use Selector for every value I had so anything that need rebuild will only rebuild when it's need it.

The problem with this approach is that with every notifyListeners call every selector got notified and rebuild it self (in my case when any scrolling detected) but the selector doesn't call the builder if the value not changed.

The fix is to make some condition that check the old value and the new value before calling notifyListeners, that works prefect in my case, this decrease the rebuilding happing when I scroll to only 1 as it's intended to be, however the other selectors in the same class also rebuild (I guess because they are all in the same class so every notifyListeners call effect them).

At the end if you end up with similar issue it is better to use ProxyProvider or any way that let you use multiple providres, beside the benefit of a better project architecture and disposing it is way better to have more control over the state.

Thanks to Rémi Rousselet Riverpod it's way better than ProxyProvider and I am using it and it's awesome so consider Riverpod if you want to use ProxyProvider.