React-native-reanimated-bottom-sheet: snapTo method always snapping to the highest snap point

Created on 7 Feb 2020  路  9Comments  路  Source: osdnk/react-native-reanimated-bottom-sheet

OS: iOS 13.3
Pre-release: v1.0.0-alpha.18

Peer dependencies:

  • react: v16.8.6
  • react-native: v0.59.9
  • react-native-gesture-handler: v1.3.0
  • react-native-reanimated: v1.5.0 / v1.6.0 / v.1.7.0

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.

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.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.

All 9 comments

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!

Was this page helpful?
0 / 5 - 0 ratings