feat(components-native): Replace react-native-keyboard-aware-scroll-view with react-native-keyboard-controller#2901
Conversation
Deploying atlantis with
|
| Latest commit: |
23c7863
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://ba62a055.atlantis.pages.dev |
| Branch Preview URL: | https://job-150289-find-and-replace.atlantis.pages.dev |
…9-find-and-replace-the-library-in-atlantis
There was a problem hiding this comment.
This was done manually to resolve issue with how Cloudflare installs packages. We've had to do something similar in 4c8f8f2
|
Published Pre-release for a97fab0 with versions: To install the new version(s) for Mobile run: |
| {...keyboardProps} | ||
| extraHeight={headerHeight} | ||
| extraScrollHeight={edgeToEdgeEnabled ? tokens["space-large"] : 0} | ||
| bottomOffset={headerHeight} |
There was a problem hiding this comment.
According to documentation, bottomOffset is equivalent to extraHeight prop from react-native-keyboard-aware-scroll-view and it's supposed to be The distance between the keyboard and the caret inside a focused TextInput when the keyboard is shown. However I'm seeing a bigger margin than before 🧐. But I'm also not sure why headerHeight was used as the bottom offset in the old implementation.
|
|
||
| const handleOfflineSubmit = useOfflineHandler(); | ||
|
|
||
| const keyboardProps = Platform.select({ |
There was a problem hiding this comment.
The old KeyboardAwareScrollView forwarded keyboard events directly as props.
The new KeyboardAwareScrollView does not expose keyboard event props. Instead, we use KeyboardEvents.addListener from react-native-keyboard-controller, which provides cross-platform keyboard lifecycle events.
The new library's KeyboardEventData only provides height — there is no endCoordinates.screenY. Since screenY is the Y coordinate of the top of the keyboard (measured from the top of the screen), it is derived as: keyboardScreenY = windowHeight - event.height
There was a problem hiding this comment.
With that said, I have not tested that this is still working. Still trying to figure out how to navigate to the components that need sticky form save button above the keyboard.
There was a problem hiding this comment.
I thought I had an update to this, not sure where it went.
I tried a few places in the consuming app with production atlantis where the Form is short, and the keyboard is open, saveButtonPosition becomes sticky, but the button does not render above the keyboard. This behavior may have changed over time even before we swap out the library. So although these handleKeyboard listeners are equivalent with the old implementation, it's not actually affecting the keyboard position.
| [windowHeight], | ||
| ); | ||
|
|
||
| const handleKeyboardHide = useCallback(() => { |
There was a problem hiding this comment.
This handler remains the same as the previous implementation.
…9-find-and-replace-the-library-in-atlantis
edison-cy-yang
deleted the
JOB-150289-find-and-replace-the-library-in-atlantis
branch
2 participants
Motivations
react-native-keyboard-aware-scroll-viewhas not been maintained nor updated in a long time, we are replacing it withreact-native-keyboard-controllerChanges
react-native-keyboard-aware-scrollp-viewis replaced withreact-native-keyboard-controllerinForminternal implementation. There should be no changes to existing functionality.Props
enableResetScrollToCoords={false}->disableScrollOnKeyboardHide={true}. Same behavior — prevent auto-reset of scroll position when keyboard hidesenableAutomaticScroll={!disableKeyboardAwareScroll}->enabled={!disableKeyboardAwareScroll}. Same behavior — toggles auto-scroll to focused inputsenableOnAndroid={edgeToEdgeEnabled}removed. Not needed; the new library handles Android by defaultkeyboardOpeningTime={...}removed New library handles animation timing internallykeyboardShouldPersistTaps={"handled"}unchanged Standard ScrollView prop, passed through as-isextraScrollHeight->extraKeyboardSpacebottomOffset — behavior difference
The old library's extraHeight (equivalent to bottomOffset ) was set to headerHeight, which is the navigation header height + a 20px constant (KEYBOARD_TOP_PADDING_AUTO_SCROLL) from useScreenInformation.
I am not sure how this was exactly working with the old library. However, the two libraries compute this offset differently internally.
Setting
bottomOffset={headerHeight}in the new library produced an oversized gap between the keyboard and the focused input. After testing,bottomOffset={KEYBOARD_TOP_PADDING_AUTO_SCROLL}(the 20px constant alone) gives the correct behavior — keeping the focused input just above the keyboard without the extra header height offset that is no longer needed.Keyboard event listeners
The old library forwarded keyboard events via props (onKeyboardWillShow, onKeyboardDidShow, etc.) directly on KeyboardAwareScrollView. The new library doesn't expose those props, so listeners are now registered using KeyboardEvents.addListener from react-native-keyboard-controller, which provides cross-platform keyboard events (keyboardWillShow/Hide on both iOS and Android).
The event payload changed: the old RN Keyboard event exposed endCoordinates.height and endCoordinates.screenY, while the new library's KeyboardEventData only provides height. screenY is now derived as windowHeight - height.
Scroll ref API
The old library's ref exposed scrollToPosition(x, y, animated). The new library's ref uses the standard RN ScrollView method scrollTo({ x, y, animated }).
Added
Changed
Deprecated
Removed
Fixed
Security
Testing
Changes can be
tested via Pre-release
In Atlantis we use Github's built in pull request reviews.