[$250] react-native-keyboard-controller migration plan

[kirillzyusko]

Problem statement

In Expensify app keyboard handling is not consistent across iOS/Android platforms:

• on Android we mostly rely on default keyboard avoiding mechanism adjustResize (it works great, but lacks of synchronous animations - which means the screen will be instantly resized, and there will be no animation at all. For chat-like apps this is quite important to have for good UX)
• since Android handles it automatically - it's very hard to add any customization to keyboard handling (for example to preserve elements position which are obscured by keyboard)
• on iOS we are using JS code mixture to handle keyboard avoidance (KeyboardAvoidingView, subscriptions to keyboard events)
  since iOS keyboard handling is done in JS code, on Android we use native keyboard avoidance provided by OS and we are writing cross-platform code -> we have a lot of Platform dependent code (like enabling KeyboardAvoidingView only on iOS), which eventually leads to UI inconsistency
• react-native offers a limited API for keyboard handling (especially on Android, where we can detect only Did events)
• react-native API is far behind from modern ways of keyboard handling

With react-native-keyboard-controller:

• we are getting cross-platform behavior:
  • edge-to-edge mode -> identical work with insets on both platforms
  • disabled default keyboard handling - all keyboard handling is delegated to developer providing basics primitives
• consistent API for working with the keyboard (all events are available on both platforms, including Will events which were not available prior to RN API)
• interactive keyboard support - an ability to dismiss keyboard via gesture (default RN implementation only works on iOS and has severe limitations, such as multiline TextInput can not grow)

Migration plan

I see next potential way for improving keyboard handling (aka migration plan):

• implement inline auto suggestions (Inline auto suggestion #42630)

• start to use it on a chat screen on iOS only (fix: messages content overlap when bottom sheet is shown #42143)

• start to use this library on chat screen on Android (this library also will give a smooth transition on chat screen when keyboard appears/disappears, so UI will look better & more pleasant for end user)

• search screen:

  • right now "footer" (invite a friend, get 250$) has an instant transition and doesn't follow keyboard movement - with this library transition will be smooth (KeyboardStickyFooter component)
  See it in action

  
  • on Android when keyboard appears -> at the bottom of the screen we have a different color (under keyboard) - that's how default keyboard avoidance works in Android - when we'll have a frame-level control we can fix it as well and we'll not see any blinks there
  See it in action

  

• on Chat screen we can add "interactive keyboard dismissal" (when keyboard can be closed via gesture)

• @roryabraham wanted to replace useKeyboardContext with this new library

• In Profile->Address screen: auto scroll is waiting for keyboardDidShow event and we have kind of two-fold animation -> potentially can be fixed by KeyboardAwareScrollView with fully synchronized animations

Additional resources

• Slack discussion: https://expensify.slack.com/archives/C01GTK53T8Q/p1707467001447909
• GH issue of library review: [New Lib] react-native-keyboard-controller #35270

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01360efa253e7a2c60
• Upwork Job ID: 1762155306344951808
• Last Price Increase: 2024-04-23

Issue Owner

Current Issue Owner: @kirillzyusko

[melvin-bot]

Triggered auto assignment to @JmillsExpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

[roryabraham]

this is kind of halfway between a new feature and a bug, but I'm going to treat it as a bug for the sake of accounting (no CAP SW project it fits with)

[roryabraham]

Marking this as Internal even though it will be almost 100% external. Doing so because I don't want to create an external Upwork job, but I do want a C+ to help review all the PR(s) for this. I think it will be a series of PRs, so I think we should compensate for the review of each.

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~01360efa253e7a2c60

[melvin-bot]

Triggered auto assignment to Contributor Plus for review of internal employee PR - @cubuspl42 (Internal)

[roryabraham]

welcome @cubuspl42! I encourage you to familiarize yourself with the context on this issue and decide whether you want to take it on or pass it off. Excited to have you help if you're interested!

[roryabraham]

moving this to weekly

[shubham1206agra]

@roryabraham I was already assigned #16356.

[roryabraham]

Fair enough. This is a broader migration than just that issue/PR though, basically we'll be refactoring keyboard handling across the whole app.

[roryabraham]

probably wouldn't hurt to get more than 1 C+ involved here either.

[shubham1206agra]

@roryabraham Can you assign me here also?

[cubuspl42]

Sounds interesting; I can get on board. This will be implemented by an expert agency, and C+ reviewed, right?

[shubham1206agra]

@cubuspl42 Please have a look at the #16356.

[cubuspl42]

@shubham1206agra I took a look. It's a PR with a 1-year-long post history. Let me know what exact aspect of that PR you'dl like me to focus on!

[shubham1206agra]

Take a look at the top description and go through code once.

[roryabraham]

This will be implemented by an expert agency, and C+ reviewed, right?

correct. 2 C+ in this case

[JmillsExpensify]

Are we still working on finishing native-stack ahead of this task, or is work resuming elsewhere via another issue?

[kirillzyusko]

@JmillsExpensify I'm working on this issue (and I updated issue description to mention that one PR link has been changed).

[melvin-bot]

This issue has not been updated in over 15 days. @JmillsExpensify, @rojiphil, @kirillzyusko, @roryabraham, @shubham1206agra eroding to Monthly issue.

P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!

[melvin-bot]

@JmillsExpensify, @rojiphil, @kirillzyusko, @roryabraham, @shubham1206agra, this Monthly task hasn't been acted upon in 6 weeks; closing.

If you disagree, feel encouraged to reopen it -- but pick your least important issue to close instead.

[roryabraham]

@kirillzyusko what's the plan here? Should we keep this open or revisit later?.

[kirillzyusko]

@roryabraham we are actively working on that!

@perunt already started to use the functionality of this library in #42630 and now he is actively working on #42143

Meanwhile I'm working on #47096 (this PR is kind of a preparation before #42143)

When we start to use more functionality of react-native-keyboard-controller we can try to spread the usage of this library across the codebase and start to use it on Android etc.

So I'd like to keep it open since the progress is moving!

[roryabraham]

Looks like #42630 and #47096 were merged, and #42143 is still WIP

[perunt]

It's in the review phase. Once testers confirm there's no jittering on their devices, we'll be good to go.
I asked about such testing because I was only able to test it on a few devices. On my oldest, least reliable device (an iPhone 7 with significant throttling and overheating issues), it shows jittering. However, the rest of the devices, such as the iPhone XR and 15, work well. So, the jittering might not be representative of typical user experiences

[roryabraham]

Need someone to hand this off to. @luacmartins not sure who's best, but going to reassign to you. Maybe you can handle or pass off to another Expensify engineer

[luacmartins]

@perunt are we still waiting for a review on #42143?

[kirillzyusko]

@luacmartins yes, review + we need to fix issues that were found 👀

[luacmartins]

Still working on the PR.