React-native-swiper: [Question] Should we keep ViewPagerAndroid or use only ScrollView for both Android and iOS
I wonder if it is necessary to keep ViewPagerAndroid for Android users.
Any opinion about that ?
arribbar
All 7 comments
It appears there are several bugs with ViewPagerAndroid component. Also, it is not possible to scroll vertically with it.
arribbar
on 11 Oct 2017
If doing that would add the vertical scrolling abillity to android then I say yes - use scrollview insteas of ViewPager
kadoshms
on 12 Oct 2017
And bugs like this one: https://github.com/leecade/react-native-swiper/issues/574
pencilcheck
on 25 Oct 2017
An attempt to fix the Android vertical swiper gets close to a fix, but with some problem: #643. It does appear that the ScrollView for android has some fixes that are almost merged into the most recent react-native (https://github.com/facebook/react-native/pull/10999, https://github.com/facebook/react-native/issues/16257).
I would wait until that happens and ScrollView fixes get incorporated into Expo before doing the unification. Meanwhile, move forward with #643 once some minor issues are cleaned up with it.
robblovell
on 3 Nov 2017
@arribbar
So I actually have a very specific use case where switching to ScrollView from ViewPagerAndroid fixed an issue for an app my team and I at work are developing.
It's a survey app where the survey component uses this package's Swiper component to render a dynamic number of SurveyQuestion components. The main issue is when one of these child components is a multiple choice question (renders a scrollView of choices, and tapping one of these choices may cause the data for the Survey swiper to include more or less questions, hence the dynamic aspect).
If in one of these child components you scroll to the bottom of the choices, select one that updates the swiper state (the data to render), for some reason when the number of views changes to reflect the new questions the entire subtree of child components is unmounted and re-mounted, like in reconciliation when the root element changes.
However, changing ViewPagerAndroid to ScrollView just like the iOS implementation fixed this behavior. I don't quite understand why ViewPagerAndroid caused this, but if anyone knows more about it please jump in 馃槃
P.S. I can provide code samples to illustrate what I mean, just let me know!
SSTPIERRE2
on 4 Jun 2018
hi @SSTPIERRE2 , can you provide the code samples you're mentioning? Thanks!
martabacc
on 5 Dec 2018
Hi, Is there any news about removing ViewPagerAndroid ? @arribbar
bichoymessiha
on 23 Jan 2019
Related issues
AndrewSouthpaw
路
3Comments
tokict
路
3Comments
nicolabortignon
路
3Comments
ghost
路
3Comments
kylehagler
路
3Comments
Most helpful comment
@arribbar
So I actually have a very specific use case where switching to ScrollView from ViewPagerAndroid fixed an issue for an app my team and I at work are developing.
It's a survey app where the survey component uses this package's Swiper component to render a dynamic number of SurveyQuestion components. The main issue is when one of these child components is a multiple choice question (renders a scrollView of choices, and tapping one of these choices may cause the data for the Survey swiper to include more or less questions, hence the dynamic aspect).
If in one of these child components you scroll to the bottom of the choices, select one that updates the swiper state (the data to render), for some reason when the number of views changes to reflect the new questions the entire subtree of child components is unmounted and re-mounted, like in reconciliation when the root element changes.
However, changing ViewPagerAndroid to ScrollView just like the iOS implementation fixed this behavior. I don't quite understand why ViewPagerAndroid caused this, but if anyone knows more about it please jump in 馃槃
P.S. I can provide code samples to illustrate what I mean, just let me know!