Summary:
This is a reopened version of https://github.com/facebook/react-native/issues/35224 by isidoro98 which was closed without explanation, updated to resolve new merge conflicts and now includes an example in the RN-Tester app. Aside from that it is unchanged. Here is isidoro98's description from their original PR:
This PR builds on top of https://github.com/facebook/react-native/issues/31402, which introduced the `automaticallyAdjustsScrollIndicatorInsets` functionality. It aims to fix one of RN's longstanding pain point regarding the keyboard.
The changes provide a better way of handling the `ScrollView` offset when a keyboard opens. Currently, when a keyboard opens we apply an **offset** to the `Scrollview` that matches the size of the keyboard. This approach is great if we are using an `InputAccessoryView` but if we have multiple `TextInputs` in a `ScrollView`; offsetting the content by the size of the keyboard doesn't yield the best user experience.
## Changelog:
[iOS] [Changed] - Scroll `ScrollView` text fields into view with `automaticallyAdjustsScrollIndicatorInsets`
Pull Request resolved: https://github.com/facebook/react-native/pull/37766
Test Plan:
The videos below compare the current and proposed behaviors for the following code:
```js
<ScrollView
automaticallyAdjustKeyboardInsets
keyboardDismissMode="interactive">
{[...Array(10).keys()].map(item => (
<CustomTextInput placeholder={item.toString()} key={item} />
))}
</ScrollView>
```
| Current behaviour | Proposal |
|-|-|
|  |  |
As can be seen in the video, the **current behavior** applies an offset to the `ScrollView` content regardless of where the `TextInput` sits on the screen.
The proposal checks if the `TextInput` will be covered by the keyboard, and only then applies an offset. The offset applied is not the full size of the keyboard but instead only the required amount so that the `TextInput` is a **specific** distance above the top of the keyboard (customizable using the new `bottomKeyboardOffset` prop). This achieves a less "jumpy" experience for the user.
The proposal doesn't change the behavior of the `ScrollView` offset when an `InputAccessory` view is used, since it checks if the `TextField` that triggered the keyboard is a **descendant** of the `ScrollView` or not.
## Why not use other existing solutions?
RN ecosystem offers other alternatives for dealing with a keyboard inside a ScrollView, such as a `KeyboardAvoidingView` or using third party libraries like `react-native-keyboard-aware-scroll-view`. But as shown in the recordings below, these solutions don't provide the smoothness or behavior that can be achieved with `automaticallyAdjustsScrollIndicatorInsets`.
| KeyboardAvoidingView | rn-keyboard-aware-scroll-view |
|-|-|
|  |  |
As shown in the videos, the `TextInput` is hidden by the keyboard for a split second before becoming visible.
Code for the videos above:
```js
// KeyboardAvoidingView
<KeyboardAvoidingView
style={{flex: 1, flexDirection: 'column', justifyContent: 'center'}}
behavior="padding"
enabled>
<ScrollView>
{[...Array(10).keys()].map(item => (
<CustomTextInput placeholder={item.toString()} key={item} />
))}
</ScrollView>
</KeyboardAvoidingView>
```
```js
// rn-keyboard-aware-scroll-view
<KeyboardAwareScrollView>
{[...Array(10).keys()].map(item => (
<CustomTextInput placeholder={item.toString()} key={item} />
))}
</KeyboardAwareScrollView>
```
Reviewed By: sammy-SC
Differential Revision: D49269426
Pulled By: javache
fbshipit-source-id: 6ec2e7b45f6854dd34b9dbb06ab77053b6419733
Moti Zilberman
Adam Averay