[Bug] onIndexChanged doesn't get called on scrollToIndex

[clragon]

Bug report

When using scrollToIndex to change the scroll offset, it seems that onIndexChanged is not called.

Expected behaviour

onIndexChanged gets called regardless of how the index is changed

Actual behaviour

onIndexChanged is only called when manually scrolling

Setup

Version: anchor_scroll_controller: ^0.2.0
SDK constraints: sdk: ">=2.15.1 <3.0.0"
Flutter version: stable, 2.8.1
Platform: web
OS: windows

[lucian1024]

When calling scrollToIndex, the target index is already known so that it does not require calling onIndexChanged.
In my example, a TabView is used to indicate the index. When clicking some item of the TabView, the indicator of the TabView will scroll to the item and scrollToIndex is called. If onIndexChanged is called in this case, it will change the indicator of the TabView too. And this will lead to scroll conflict of TabView.
Can you detail in which case onIndexChanged should be called when using scrollToIndex?

[clragon]

I have a Text which changes depending on the current index.
The text works fine when normally scrolling, and it relies on onIndexChanged to rebuild.

I also have a navigation bar which uses scrollToIndex to scroll to certain parts.
This breaks, since onIndexChanged is not called, and my Text doesnt update.

the target index is already known

that is true, but only for the scope that is calling scrollToIndex.
if the Widget that wants index updates and the Widget scrolling to indexes are not related, this leads to a problem,
which is what happens in my case.

[lucian1024]

Well, I can add a param for onIndexChanged to indicate whether is scrolling by user. Like this
typedef IndexChanged = void Function(int index, bool userScroll);

But there is one thing must be noticed, that is onIndexChanged may not return the indexs of the last items when you call scrollToIndex to scroll to the last items. For example, if there are 100 items in the ListView and when calling scrollToIndex(99), the onIndexChanged may stop at index 91 or some other one, which deponds on the heights of the last items.

[clragon]

oh, because those items arent tall enough to reach the height
at which they are considered to be the "current" index? I see.

is it possible to fix that?
I assume the point at which it considers to current index to be would have to somehow contort at the very end of the list.
Then again, this entire idea might not be very feasible regardless, because views like GridView could never have a clearly defined current index.

[lucian1024]

oh, because those items arent tall enough to reach the height at which they are considered to be the "current" index? I see.

is it possible to fix that? I assume the point at which it considers to current index to be would have to somehow contort at the very end of the list. Then again, this entire idea might not be very feasible regardless, because views like GridView could never have a clearly defined current index.

I have no idea to fix it now. And I have added a param for onIndexChanged to indicate whether is scrolling by user. Not sure is it gonna to solve your problem?

[clragon]

When clicking some item of the TabView, the indicator of the TabView will scroll to the item and scrollToIndex is called. If onIndexChanged is called in this case, it will change the indicator of the TabView too. And this will lead to scroll conflict of TabView.

Speaking of this, I had an issue the other day where I linked a BottomBar or NavigationRail to a TabController and what would happen is that I could change the index of the currently selected item while the animation of the tab was ongoing, which wouldn't switch the tab back, but still change the index.

The fix to this is ignoring all index changes while indexIsChanging is true.

Maybe this would fix your issue?

[clragon]

I've seen that the AnchorScrollControllerHelper actually already has a _isScrollingToIndex variable.
maybe it could be made public, similar to the TabController one.

[clragon]

okay considering that the AnchorScrollControllerHelper allows arbitrary ScrollController to be used which is very good I actually think passing a boolean like that is better because it means we do not need access to the helper.
I will close this issue as completed, thank you.