InputAccessoryView like component, that's supports interactive dismissal beginning from the component, not the keyboard

[hannojg]

Is your feature request related to a problem? Please describe.

(I am not sure whether this is a bug, or rather a feature request, so sorry if I picked the wrong template).
I am using this library to get interactive keyboard dismissal working. I then have a component that I render on top of the keyboard, which creates a similar effect to the InputAccessoryView.
However, with the InputAccessoryView the dismissal starts as soon as your finger crosses the top/start of the view that's rendered above the keyboard.

Running the example app I can see that it only dismisses once you draw the keyboard down:

Screen.Recording.2023-09-28.at.12.16.20.mov

Describe the solution you'd like

In this example I used a ScrollView with an InputAccessoryView. You can see how it starts dismissing the keyboard as soon as you reach the start of the accessory view:

Screen.Recording.2023-09-28.at.12.25.32.mov

https://snack.expo.dev/@hannojg_margelo/vengeful-violet-strawberries?platform=ios

Describe alternatives you've considered

Not sure if this really needs a separate view, or maybe just some props that you can set to alternate the height from when it starts to pick up the dismiss gesture?

Additional context
/

[hannojg]

@kirillzyusko Do you have any idea how that could be implemented? Willing to contribute, but first wanted to double check with you 😊

[hannojg]

(A solution that would work equally on android would be dope)

[kirillzyusko]

Hello @hannojg

As I can understand such offset/additional space could be achieved only if real InputAccessoryView is attached.

I think me and @hirbod were trying to add InputAccessoryView with an empty View and were displaying TextInput over this InputAccessoryView but we were not able to achieve a desired effect (in our case InputAccessoryView wasn't sticky to the keyboard and was disappearing as soon as keyboard was getitng shown). But to be honest we didn't spend much time here - maybe a trick with invisible InputAccessoryView could work - just need more time to check 👀

In the past I did some experiments with attaching fake InputAccessoryView from a native side in 4164b60 (I thought about gathering coordinates from this FakeInputAccessoryView via KVO instead of gathering coordinates directly from keyboard view, but in the end decided to gather from keyboard view because user can attach its own InputAccessoryView from RN and we need to combine these views together and it makes code more complicated without any explicit benefits).

Regarding Android side - everything is much simpler there, because we have a full control over keyboard positioning. I think new prop like offset/verticalOffset to KeyboardGestureArea component and few modifications in native code in interpolators would make the trick.

Maybe you have any ideas about how iOS can be implemented?

BTW thank you for raising this issue 🙌 I also wanted to create/report it but didn't have time for that 😓

[hirbod]

Funny, we just had this conversation last week. We tried many things, but I couldn't achieve the desired behavior with a hidden InputAccessoryView. To be fair, I didn't test it for more than an hour.

[kirillzyusko]

I still didn't have time to work on this feature yet, but I found this interesting stuff: https://github.com/iAmrMohamed/AMKeyboardFrameTracker/blob/master/AMKeyboardFrameTracker/Classes/AMKeyboardFrameTracker.swift

Basically this project is using similar technique to what is used in RNKC (KVO observer), but it seems like it supports custom height. Need to check implementation more carefully and add something similar to RNKC 👀