[TextInput] Supply access to UITextView.inputAccessoryView attribute on <TextInput />

[ghost]

It would be cool to have this to make sticky text inputs.

(t21661353)

[sahrens]

Yes definitely - this is how we built parts of the comment input in the Groups app. Hopefully we'll be able to clean it up soon and release it to you guys.

[ide]

@sahrens do you have code you could throw over the wall that I could take a pass at cleaning up?

[brentvatne]

@sahrens - this would be great to see, this seems to be a highly requested feature

[sahrens]

I'll take a look at what we have.

On May 31, 2015, at 11:25 AM, Brent Vatne notifications@github.com wrote:

@sahrens - this would be great to see, this seems to be a highly requested feature

—
Reply to this email directly or view it on GitHub.

[irfaan]

Was there any luck with this? @sahrens , @auser (#1190)?

[tpisto]

+1 for solving this

[auser]

Not yet, but would be a good idea to get back on this...

[auser]

I have an initial implementation in progress that is not quite ready yet. When I get it working, I'll gist it. I'm currently working on it as a component (outside of the main repo), but will plan on making it a pull req when it is functional. Also... the API might need some help...

[LeoFidjeland]

+1

[OpakAlex]

+1

[alancmclean]

+1

[sahrens]

Sounds great, @auser - looking forward to that PR ;)

[sjmueller]

I've been playing around with tying an inputAccessoryView with RN. One thing I immediately noticed is that when using the navigator component, keyboard dismissal isn't as clean as with UINavigationController. An example of the regular behavior:

Notice how the keyboard slides away in tandem with the view as the controller is popped? Using the navigator component, there's no direct correlation and so the keyboard stays in place (or slides downward if you preemptively dismiss). The reason why I bring this up is because when using an InputAccessoryView, this difference becomes much more amplified, because the content of the view is usually much more scene-specific than the generic keyboard.

Any suggestions? I looked all over the groups app, and couldn't find a place where the navigation slides in a way that would reveal this issue.

[brentvatne]

cc @ericvicenti @hedgerwang @ide - interesting point raised above by @sjmueller

also cc @boourns - maybe your team could look at this too :)

[ide]

Great point and quite tricky I believe. Since we don't want to use UINavigationController and UIViewController we're going to need to move the keyboard ourselves. Should be possible by getting the UIWindow that contains the keyboard and applying a transform to it. Certainly yet another thing to consider for Navigator scenes.

[ericvicenti]

Agreed, this will be very tricky. Even if we have the ability to animate the keyboard from RN, the off-thread operation will cause the keyboard animation to lag.

@javache, any idea if we can add hooks to animate the keyboard from RN?

cc @sahrens for the main-thread animation concerns

[sahrens]

Yeah, messy. Native animations won't handle this any time soon. Might be
worth some custom native hook to link the keyboard to a view based on react
node handle?
On Sep 10, 2015 2:13 PM, "Eric Vicenti" notifications@github.com wrote:

Agreed, this will be very tricky. Even if we have the ability to animate
the keyboard from RN, the off-thread operation will cause the keyboard
animation to lag.

@javache https://github.com/javache, any idea if we can add hooks to
animate the keyboard from RN?

cc @sahrens https://github.com/sahrens for the main-thread animation
concerns

—
Reply to this email directly or view it on GitHub
#371 (comment)
.

[nicklockwood]

We have an inputAccessoryView prototype internally that would solve this problem, but there were some concerns about performance that have stopped us from shipping it. I'll see if we can revisit that.

[sjmueller]

@nicklockwood, curious what approach is used with the fb prototype? Like @ide says, there's no UINavigationController and UIViewController with the Navigator component, so it'd be interesting to learn about the way you're currently solving the challenge.

[idibidiart]

If it's easier to make it work with NavigatorIOS then let's have that first, please. It's a show stopper in apps that take numeric input for the user not to be able to signal "done" explicitly.

+1

Update:
I just finished adding a nice co-animated 'done' button above the numeric keypad, but it took me two days to perfect it and make it work across all screen resolutions. It's a big hole in React Native's functionality. It's such a basic must have feature.

[auser]

@idibidiart Can you share your solution? Is that a pure-JS solution or a UIInputAccessory?

Update to my work: lost my uncommitted code in a (unfortunate) reformat of a faulty OS.

[sjmueller]

@auser not sure how far along you were from this gist: https://gist.github.com/auser/38d7484d986ab911152c#file-UIViewController+InputAccessory-m

[idibidiart]

@auser sorry didn't see your messsage. I'm just browsing this thread again. Mine is a simple JS based solution that is based on DeviceEmitter/KeyboardWillShow event and a simple ankmation of a "Done" button view that is initially hidden below the screen and is then animated up to coincide with the keyboards own animation. I just saw the native solution by @sjmeuller and I'm wondering if something like this can make it into the next version of React Native @nicklockwood @ide

[auser]

@sjmueller I forgot I posted that!

Thanks for the reminder. That was the beginning of my work. The issue with that code, as of then was that I wanted to design it with the native 'View' library. With that implementation, it doesn't quite work yet.

Was talking with @ide to understand that. Perhaps he has an idea with the release of 0.11.x. That was on 0.5.0.

Anyway, I can get back to work on it. Thanks for the reminder.

[GantMan]

+1 👍

[pfeiffer]

👍

[braunsquared]

+1

Is there any update on this? Maybe an updated gist that we could leverage locally in the meantime?

[simistern]

+1

[ahmadmuhsink]

+1

[douglasjunior]

UPDATE: 30/01/2018

Using Obj-c extensions I founded a way to make the react-native-keyboard-manager works again.

---

Any news on this?

Until version 0.46.4 was possible to access the inputAcessoryView and customize the keyboard toolbar externally. And I created a library that does it very well. But, after this commit that was released in version 0.47.0, access the inputAcessoryView is impossible.

We are discussing this on douglasjunior/react-native-keyboard-manager#3 and #16071, but it seems that there is no interest on the part of the RN team.

[iworkinprogress]

+1

[luco]

+1 on this.

[jnrepo]

why is this closed, there is no functionality for this on RN?

What's more is that Android provides a 'done' or 'next' button on the numeric keyboard and iOS doesn't and it always breaks parity.

[jpudysz]

+1

[hery]

One solution is to use a native UI component using this guide :)

I'll see if I can share some code or open source something.

[EmilScherdin]

This package works for getting that nice swipe to close with the keyboard (keyboardDismissMode =interactive) from what I've tested. Seems to work well with a lot of other things as well.

https://github.com/wix/react-native-keyboard-input

[sahrens]

@PeteTheHeat is going to have an RN Core solution on iOS pretty soon!

[hery]

Hello! Thanks @sahrens! Any idea how soon?

I've solved this by implementing a native textfield component and adding that functionality, but now I need to do that for a textarea as well so I'm wondering if I should just wait for a React Native solution.

Thanks!

[react-native-bot]

Thanks for posting this! It looks like you may not be using the latest version of React Native, v0.53.0, released on January 2018. Can you make sure this issue can still be reproduced in the latest version?

I am going to close this, but please feel free to open a new issue if you are able to confirm that this is still a problem in v0.53.0 or newer.

_{How to Contribute • What to Expect from Maintainers}

[PeteTheHeat]

I built this 38197c8 and added an example here 84ef7bc

[2ECC71]

Did this make it into 0.55?

[PeteTheHeat]

@loxtank yup https://github.com/react-native-community/react-native-releases/blob/master/CHANGELOG.md#055. I'm still fixing some things with it. Feel free to open any issues you find.

[Ashoat]

@PeteTheHeat thanks so much for working on this!

There are several serious issues with the implementation as it stands:

1. InputAccessoryView doesn't update its height when multiline TextInput grows in height #18997, doesn't work with multiline inputs.
2. [InputAccessoryView] Can't specify keyboard-conditional bottom padding #20157, doesn't work with a tab bar, ie. no way to customize bottom padding when keyboard is collapsed.
3. InputAccessoryView renders on top of YellowBox warnings #18987, impossible to close YellowBox warnings when InputAccessoryView is active.

Knowing FB culture around code ownership, I imagine you've probably moved on to something else. But if you have any spare cycles at all, would appreciate you looking into some of these issues. Any pointers on how to address them would be appreciated as well.

[LevelUp8]

I also think this issue is relevant:

#27440 -> React native IOS InputAccessoryView disappear from the screen after close modal.

Any help will be appreciated.