Add callback to ScrollView scrollTo method after animation

[theodoregold]

This is just a suggestion. I am not a native developer, but it seems a good idea to add a callback for scrollTo method if it is possible.

For example, if a user presses on a "scroll me somewhere button" multiple times, it would be nice to disable this button until scroll animation finishes. It seems this might be a useful callback in some cases.

[theodoregold]

It also seems, that invoking multiple scrollTo with animation makes subsequent calls do it without animation.

[ptomasroos]

Give it a try to use onMomentumScrollEnd

[theodoregold]

@ptomasroos Couldn't find any documentatin about onMomentumScrollEnd. I tried it and it only works if user manually scrolls. Not when you call a scrollTo with animation.

[bd-arc]

Hi there! This one is also an issue for us. Let me give you a concrete use case.
We've created our own swiper plugin on top of the ScrollView component, but we aren't able to provide a reliable callback when swiping because scrollTo() doesn't offer one.

As suggested by @ptomasroos, we've tried using onMomentumScrollEnd. But, as stated by @teodors, the event is fired only when there is a user interaction (e.g. it won't work if we scroll programmatically). Moreover, as explained in ScrollView's source code, enabling momentum events on Android can be expensive.

Another lead was to specify a duration for the scroll animation, and then to defer the firing of the callback according to it, but scrollTo() doesn't accept a custom duration either. A PR was made, but it hasn't been active for a while.

That's why adding a callback to scrollTo() would be really helpful.

[sakulstra]

we've currently a usecase where we want to synchronize multiple scrollViews... a scrollView callback would be pretty neat to handle unbouncing

[ABleas]

I have a similar use case to make updates based on where a scrollView ends up, with or without gesture input. Can use setTimeout() to approximate, but it's not ideal.

[mfrachet]

Any new informations concerning this issue ?

[hramos]

Hi there! This issue is being closed because it has been inactive for a while. Maybe the issue has been fixed in a recent release, or perhaps it is not affecting a lot of people. Either way, we're automatically closing issues after a period of inactivity. Please do not take it personally!

If you think this issue should definitely remain open, please let us know. The following information is helpful when it comes to determining if the issue should be re-opened:

• Does the issue still reproduce on the latest release candidate? Post a comment with the version you tested.
• If so, is there any information missing from the bug report? Post a comment with all the information required by the issue template.
• Is there a pull request that addresses this issue? Post a comment with the PR number so we can follow up.

If you would like to work on a patch to fix the issue, contributions are very welcome! Read through the contribution guide, and feel free to hop into #react-native if you need help planning your contribution.

[ro-savage]

@hramos - This is still an issue, and I am running into the same thing. Would be a nice feature to have.

[hramos]

As it happens, we're using GitHub to track bugs in React Native. If you'd like to submit this as a feature request, please go ahead and create an entry on Canny. It has a voting system and if the feature gets a good amount of votes, it will have a greater chance of being implemented by the community.

[Jasbir23]

+1 Much needed

[askday]

+1