Input-instance-specific KeyboardToolbar?

[danielcrk]

Hey, I'm looking into trying KeyboardToolbar but can't really wrap my head around how it works.

The examples show it as basically one toolbar per screen, but my usecase is a bit different. I have a custom TextInput wrapper with a bunch of props, some of them which should effect the toolbar. So my initial idea was to just add a KeyboardToolbar to the Input wrapper and handle all the logic locally. Then each input could have its own toolbar with content specific to that specific input.

But this seems to lead to very weird offset issues, as it seems the KeyboardToolbar component was meant to be placed OUTSIDE of the scrollview, not inside.

Am I thinking about this all wrong? Is it possible to have multiple KeyboardToolbars, and inside the ScrollView? I guess I would need to keep track of the Input isFocused state and conditionally render the toolbar? But then the toolbar would disappear before the keyboard animates away, and it would require additional listening to events and delaying unmount etc.

Another option would of course be to only use one KeyboardToolbar and introduce some sort of custom KeyboardToolbarContext, that the inputs, if they are focused, would write their toolbar requirements to. But that feels needlessly complex as well.

What are my options? One of the above or something more obvious that I am missing?

Thank you!

[kirillzyusko]

But this seems to lead to very weird offset issues, as it seems the KeyboardToolbar component was meant to be placed OUTSIDE of the scrollview, not inside.

Yes, but it caused some issues such as this #867

So I'm partially agree, that KeyboardToolbar should be attached directly to the keyboard (independently to its place in JSX-layout). And on iOS it's possible to do (for example KeyboardExtender attaches directly to the keyboard). But on Android you can't get a reference to keyboard view, because it's 3rd party app, so to use KeyboardToolbar you would anyway to place KeyboardToolbar outside of ScrollView/SafeAreaView.

Is it possible to have multiple KeyboardToolbars

Yes, you can render many instances of KeyboardToolbar. But the idea is that you can have only one KeyboardToolbar on screen.

and inside the ScrollView

No, it's not supposed usage. You'll deal with various offset issues and it will not work as expected.

I guess I would need to keep track of the Input isFocused state and conditionally render the toolbar? But then the toolbar would disappear before the keyboard animates away, and it would require additional listening to events and delaying unmount etc.

Yes, unfortunately it makes setup more complex. So if you want to make a management of KeyboardToolbar then you would need to use state management libs (redux/zustand) to conditionally show it. In example project I simply track onFocus event and modify content that is shown inside toolbar. You can apply the same trick and track only onFocus for specific fields that need to use "toolbar" (without onBlur, in this case when keyboard disappears it will not hide toolbar, because only onFocus decided whether toolbar should be shown or not). Then such inputs will dispatch an event to the store to "show toolbar". Show/hidden state can be managed via enabled prop on toolbar.

Another option would of course be to only use one KeyboardToolbar and introduce some sort of custom KeyboardToolbarContext, that the inputs, if they are focused, would write their toolbar requirements to. But that feels needlessly complex as well.

Yes, with current architecture I believe this is the only one option (but instead of context you can use state management lib that you use in your current app).

---

What would be the idea solution that you would like to have? Render multiple KeyboardToolbar (i. e. inside each TextInput), but this toolbar had to be shown only once on a screen?

[danielcrk]

Hey Kirill, sorry for the late reply, for some reason I didn't get a notification.

Thanks so much for your reply. I guess the best solution in my case would be to use a new context (which is what I use for the sparse global states) and let every input report it's toolbar options to it, and the have the single instance of the KeyboardToolbar update depending on that. I already have a Screen abstraction that contains a KeyboardAwareScrollView, so I guess that Screen component could also provide a local keyboard context that the inputs could talk to. It doesn't seem too bad.

I guess ideally, I'd like to be able to render a KeyboardToolbar inside each TextInput wrapper, and KeyboardController would show the right one based on focus. You already provide a KeyboardProvider context, what if the KeyboardToolbar component didn't actually render anything, but instead just talked to the global context. Then the KeyboardContext itself could render a single instance of the toolbar, and apply content to it depending on what input is focused?

Basically, KeyboardController would simply just abstract the context approach away.