[v4] screen resize events triggering animatedIndex change

[jspizziri]

Bug

When a resize event occurs such as a screen rotation (in native) or a window resize (in web) the bottom sheet index can change suddenly. This seems to be due to animatedContainerHeight being used in the calculation of animatedIndex.

Environment info

Library	Version
@gorhom/bottom-sheet	4.4.7
react-native	0.71.6
react-native-reanimated	^2.6.0
react-native-gesture-handler	^2.4.2

Steps To Reproduce

Web

1. Open the bottom sheet.
2. Resize the window.

Mobile
I haven't tested this on mobile but theoretically it should happen there too.

1. Open the bottom sheet.
2. Rotate the device (triggering a change in the screen dimensions)

Describe what you expected to happen:

A window/screen resize should not result in a change in the animatedIndex

Reproducible sample code

N/A

Notes

I've done a little exploration on fixing this but I'm not super happy with any of my approaches or results. I've effectively tried to set a property in the component when a resize reaction takes place and then adding a conditional to check if a resize event is the responsible for triggering a recalc on the animatedIndex property.

If I could get some direction from someone who knows more about the library and the best path forward I'd happily do the implementation and submit a PR!

[gorhom]

i will look into this shortly

[gorhom]

I tried with rotating the device, and it seems working as expected

Simulator.Screen.Recording.-.iPhone.14.Pro.Max.-.2023-06-25.at.12.38.08.mp4

[gorhom]

tested on v5 web, and it works as expected too.

Screen.Recording.2023-06-25.at.12.40.52.mov

[jspizziri]

@gorhom thanks for your response! I'm going to upgrade to v5 and double check. If I'm still seeing an issue there I'll reopen.

[jspizziri]

@gorhom sadly this issue does still happen in v5. It's much better in v5 than in v4 (v4 even the slightest resize caused it).

I've created a repro example here and I also have a video of what I'm talking about here:

bottom-sheet-close.mov

You really have to quickly resize the window in order to see it now, however I think such resizes are fairly practical when considering things like entering and exiting fullscreen. Like I said before, it's definitely way better than before as before even a 1px nudge would cause a close.

I think the two conditions for a index changing are:

1. a fast resize.
2. two snap-points that are sufficiently close together.
   • in my case a closed snap point and a "near the bottom" snap point
   • I use bottom-sheet to provide a fullscreen and "mini" media player which is why it's so close to the bottom in my case.

EDIT: I can confirm that the most practical use-case for this is if a user has a window of a smaller size and has the bottom sheet open close to the bottom (like in the video) and then they enter and then exit fullscreen. Upon exit, the bottom sheet closes.

The second half of my video demonstrates that fast resizes can cause a closed bottom sheet to temporarily reveal itself. This definitely is a bit of a "nit", but it can be undesirable if the state of a closed player is "ugly" or "confusing" because it has no content loaded. This point I bring up as more food for thought. The thing I'm most concerned with is the closing behavior.

Let me know your thoughts! I'm happy to pitch in and write some code.

[jspizziri]

Another way to reproduce this on native Android is by opening the keyboard when the bottom-sheet is open (and sufficiently close to the bottom of the screen). The default configuration for android is android:windowSoftInputMode="adjustResize" which resizes the entire screen when the keyboard opens. As a result of the rapid decrease in size of the screen the bottom-sheet collapses. Despite the fixes that were put in place to handle android keyboard interactions this issue is present in v5.0.0-alpha.3.

[gorhom]

@jspizziri thanks for providing a repo with setup to reproduce the issue. I am just wondering if this issue also occurs on apps too ? cause resizing the container with the speed that you show is not realistic to me, and if that is the case then we need to have a solution only for web and not effect the apps.