It would be great to have a completion callback to execute something after the ScrollView has finished scrolling from a scrollTo call.
This is already implemented if you check with the source code, although the lack of documentations in the RN's repo makes it hard for developers to use it. The props of ScrollView (or FlagList) is onScrollEndDrag.
@Hoang Pham: Thank you for your insight. onScrollEndDrag is well known and used, but it is not that reliable and doesn't answer the original request.
The only case where onScrollEndDrag is always triggered is when the user lifts his finger after dragging the ScrollView, while we need a reliable callback for a programmatic call to scrollTo().
This is a much needed feature for advanced ScrollView/VirtualizedList/FlatList.
It's possible to implement a workaround on the JS-side by tracking the Animated.event value during onScroll() (the Animated version being used to prevent missed scroll events), but a native implementation would be way better and more reliable.
Working on implementing this natively, I've PoC'd two approaches so far on Android which, as far as I can tell, work as expected.
The JS apis would either be:
1. ScrollView.scrollTo({x: foo, y: bar, animated: true, callback: () => {...});
2. ScrollView.onScrollToComplete={() => {...}};
The second approach fits closer to existing view APIs, but, in the case where there are multiple ways to trigger a scrollTo on the screen, it may require overwriting onScrollToComplete before each request to scrollTo. Otherwise, it would not be obvious which scrollTo had actually completed inside onScrollToComplete.
Before proceeding with iOS for either approach, I'm curious if there are any strong feelings either way for the APIs (or perhaps, something I hadn't thought of!).
@Luke Wilimitis: Wow, thank you very much for tackling this beast; I can't wait to see this feature finally come to life!
Regarding your question, I personally prefer the first API. It nicely complements the existing one and, as you've already stated, the other one might prove tricky to handle.
Do not hesitate to share the link to your PR as soon as you submit it so we can all upvote it ;-)
@Luke Wilimitis: +1 for first option
@Luke Wilimitis: Just checking in on this one. Did it make it to an approved PR in the end?
@Jonas Frid: Nope, in testing my Android PoC I encountered an issue with the non-animated scroll case where the callback would be invoked before the screen had visibly updated, and have yet to dig further into RN internals. I can post what I have so far if needed.