New API for focused TextInputs

[kirillzyusko]

Is your feature request related to a problem?

Right now you can access target property and detect layout of focused input using measure function from Reanimated.

However this approach has several downsides:

• on Fabric you need to have an access to ShadowNode and it adds more complexity to the code (and you need to use findNodeHandle which is deprecated in StrictMode);
• if view layout was changed - you are still not aware about it, because useKeyboardHandler is not reporting such cases (and obviously it shouldn't);
• it seems like measure on Fabric works differently and you need to take into consideration other UI elements (header height, etc.)

Describe the solution you'd like

I'd like to have two hooks:

• useFocusedInput
• useFocusedInputSharedValue/useFocusedInputReanimated;

They will return a value with next shape:

type FocusedInputChanged = {
  tag: number; // or `target` to be consistent with other APIs
  layout: {
    x: number;
    y: number;
    width: number;
    height: number;
    pageY: number; // or `absoluteY`
    pageX: number; // or `absoluteX`
  }
} | null;

These hooks should update its value before any keyboard lifecycle (onStart/onEnd), and should update when:

• keyboard changes its size (appears, disappears, changes size because of different input mode);
• when focused was changed from one TextInput to another;
• when layout of focused input was changed;

Describe alternatives you've considered

There is no known alternatives at the moment. You can use TextInputState and currentlyFocusedInput - but it's available only in JS (not reanimated), it's not reactive (i. e. you can not detect a moment when layout was changed, etc.) - so overall it's not an alternative 🙂

But everything above it's just rough idea. During the implementation it could be polish and adopted to real use cases.

Additional context

I think theoretically it shouldn't be too difficult to add such API. We can use the same approach as we used for onKeyboardMoveStart/onKeyboardMoveEnd etc.

But it would be good to move native implementation in separate files and don't mix it with current implementation.

Also we'll need to understand how to track layout changes on iOS. It seems like you can add KVO - but a lot of people don't recommend do that. Alternatively we can use the approach as used in IQKeyboardManager - we'll add a callback like KeyboardController.onFocusedInputLayout(e) and use this function in onLayout of TextInputs <- but it'll require additional setup. Also if we decide to release this functionality using KVO - maybe worth to consider to release it under feature flags (because Interactive keyboard brought a lot of issues 😅).

Overall I think suggested functionality can significantly enhance library capability and open new horizons 🚀

[kirillzyusko]

Closed as #257 was merged