-
-
Notifications
You must be signed in to change notification settings - Fork 55
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
## 馃摐 Description Added `target` field which represent a `viewTag` of focused `TextInput` field. ## 馃挕 Motivation and Context If we know tag of focused field we can apply advanced techniques and require additional information on demand (for example measure layout and calculate the scroll amount). I had a lot of designs on how to implement this feature. The main tradeoff was about whether this information should be provided as **separate hook** or should it be included as **part of keyboard event metadata**. For simplicity purpose I've decided to deliver this information as part of keyboard events (because there appears a lot of problems with synchronization values between various hooks - you'll need to assure that one variables are updated before other or run something in effects/reactions and it can make your code more difficult for understanding). So for now I'll deliver all information via already existing hooks 馃檪 Another important aspect is the fact, that information about focused field is deliver differently per different OS versions. On Android it's done via `addOnGlobalFocusChangeListener`, on iOS you can derive this information from keyboard lifecycles. And it appears to be a problem, because iOS uses kind of one channel for communication (keyboard events) - so even if you've changed focus and keyboard didn't change its size/position, it still will trigger a keyboard event (and in this keyboard event you can get a new info about focused field). Android works differently - it provides a callback which will be fired, when focus has changed (and this callback will be always called before any keyboard movement). So taking the information above into consideration I've decided to update internal variable in `addOnGlobalFocusChangeListener` since keyboard events will be fired later and tag values can be packed into event metadata. The only one excluding case is when keyboard is already shown and focus has been changed - in this case we dispatch the same events instantly, because we don't know in advance whether keyboard size will be changed (i. e. whether onStart/onMove/onEnd will be dispatched). So we dispatch them anyway and later, if keyboard size is changed, we will dispatch plain events. From my perspective it'll not introduce any breaking changes. Last but not least - on Paper architecture you can pass `() => tag` or use `UIManager.measure(tag, ...` to measure layout. But on Fabric architecture you only can measure layout by passing `ShadowNode` instead of `tag`. However you still can get `ShadowNode` and `tag` in Fabric from `ref`, so you can use mapping: ```ts { // paper [tag]: () => tag // fabric [tag]: () => ShadowNode } ``` I'll use this concept later in updated version of AwareScrollView example. Maybe after investigating more edge cases I'll come up with a different solution, but for now providing `target` opens new horizons and I'm going to explore them soon 馃槑 Closes #163 ## 馃摙 Changelog ### JS - added `target` field to plain and worklet events; ### iOS - added variable `KEYBOARD_CONTROLLER_NEW_ARCH_ENABLED` in Podfile to write architecture specific code in Swift files; - added `UIResponder` extension which allows to get focused TextInput on demand; - added extension for `reactViewTag` which returns tag of focused `TextInput`; - detect tag in keyboard lifecycles and reuse it in `KVO` and `DisplayLink` to improve performance. ### Android - added `addOnGlobalFocusChangeListener` to detect a focused `TextInput`; - dispatch instant (start/end) events only when keyboard is visible and focus has been changed; ## 馃 How Has This Been Tested? Tested both fabric/paper example apps on: - iPhone 14 Pro (iOS 16.5, simulator); - Pixel 7 Pro (Android 13, real device); ## 馃摳 Screenshots (if appropriate): <img width="570" alt="image" src="https://github.com/kirillzyusko/react-native-keyboard-controller/assets/22820318/5fd0af7f-b953-4c33-8a7a-f85e3e049f23"> ## 馃摑 Checklist - [x] CI successfully passed
- Loading branch information
1 parent
43ddde7
commit 0d6bd83
Showing
13 changed files
with
119 additions
and
27 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1 +1,2 @@ | ||
#import <React/RCTUITextField.h> | ||
#import <React/RCTViewManager.h> |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.