OS: iOS 13.3
Pre-release: v1.0.0-alpha.18
Peer dependencies:
The snapTo method always snaps to the highest snap point on first call. Calling it a second time with the same index does make the bottom sheet snap to the actual snap point defined at that index.
I divided a bit into the issue and it seems to be related to recent releases of react-native-reanimated (v1.5.0, v1.6.0 & v1.7.0) The issue doesn't occur on v1.4.0.
The headerPosition prop also seems to be affected...
I don't know if this is somehow connected, but (with 1.70) also after calling scrollTo, the onOpenEnd and onCloseStart callbacks won't fire ever again. I relay on these callbacks to set the scrollEnabled attribute of the contents ScrollViews and FlatLists. Just using 1.4.0 on the other hand leads to some other Typescript Errors I couldn't resolve.
I am not that familiar with reanimated, but it seems like some kind of race condition.
The animation seems to start before this.manuallySetValue has the correct value.
I worked around this by adding a timeout here https://github.com/osdnk/react-native-reanimated-bottom-sheet/blob/df2f054a8e4e738ccb4aa264fb8f6c07f819d433/src/index.tsx#L660
setTimeout(() => this.isManuallySetValue.setValue(1), 0);
Now this.manuallySetValue has the correct value when this.isManuallySetValue(1) is run.
@TheDuc This change does indeed fix the issue. Thanks for sharing it!
It feels a bit hacky though to use setTimeout. Maybe the issue could be fixed as well in the way react-native-reanimated is used in this library. On the other hand, it could also be that this setValue behaviour (first executing a setValue statement where the argument is a number and then a setValue statement where the argument is an Animated.Value) is as intended by the react-native-reanimated library. @osdnk Could you share your thoughts about this?
The overall compatibility with react-native-reanimated v1.7.0 isn't solved though. The headerPosition still misbehaves.
We started seeing similar behavior after updating react-native-reanimated from 1.3.0 to 1.7.0.
@TheDuc it helps, thx
@terribleben I also faced with this problem after updating reanimated from 1.3.0 to 1.7.0, did you find any solution for this ?
Possibly fixed by https://github.com/osdnk/react-native-reanimated-bottom-sheet/pull/206 which was included in the recent release 1.0.0-alpha.20.
I was experiencing this exact issue, using v1.0.0-alpha.22, with the following dependencies installed:
react-native-gesture-handler: v1.6.1
react-native-reanimated: v1.8.0
I updated both, and the issue was no more.
react-native-gesture-handler: v1.8.0
react-native-reanimated: v1.13.0
Hope this helps someone!
Most helpful comment
I am not that familiar with reanimated, but it seems like some kind of race condition.
The animation seems to start before
this.manuallySetValuehas the correct value.I worked around this by adding a timeout here https://github.com/osdnk/react-native-reanimated-bottom-sheet/blob/df2f054a8e4e738ccb4aa264fb8f6c07f819d433/src/index.tsx#L660
setTimeout(() => this.isManuallySetValue.setValue(1), 0);Now
this.manuallySetValuehas the correct value whenthis.isManuallySetValue(1)is run.