React-native: [TextInput] Supply access to UITextView.inputAccessoryView attribute on <TextInput />

[rebeccahughes]

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 [email protected] 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 (https://github.com/facebook/react-native/issues/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" [email protected] 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
https://github.com/facebook/react-native/issues/371#issuecomment-139380634
.

[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 :+1:

[pfeiffer]

:+1:

[braunsquared]

+1

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

[lewisbarber]

Still not implemented?

[shaikhussian]

can any tell me that how to add done button for the keyboardType="number-pad". At the top of the keyboard

[danleveille]

+1

Any progress on this? :smile::+1:

[yuriyvl]

+1

[Obooman]

+1
@auser some progress notifications may be great.😄

[sowdri]

+1

[jacob-russo]

this would be amazing. really annoying not being able to close the keyboard on the numeric keypad.

[israelidanny]

@auser and @idibidiart - did either of you come up with a solution that is usable, however imperfectly?

[danleveille]

@israelidanny I ended up making my own custom one, though the implementation is pretty messy. Had trouble with the animations, though it's usable and it seems to be working fine in my live app.

[lewisbarber]

@danleveille - could you share your solution please?

[brentvatne]

Created a ProductPains issue for this here: https://productpains.com/post/react-native/make-ios-uitextviewinputaccessoryview-on-textinput-/ -- please upvote if this is important to you.

@danleveille - if you can share your implementation, messy or otherwise, that could be helpful as a starting point :)

[danleveille]

@brentvatne @lewisbarber @israelidanny So sorry for the late response!

Here's my current implementation: @danleveille/react-native-input-accessory-demo

Again, it's not perfect, and it's a little messy, but it works and I'm using it in my live app and never had any users complain. Feel free to contribute if you can make it any smoother.

[nazywamsiepawel]

+1

[EmilScherdin]

+1

[GantMan]

Would anyone be interested in a component that you could import and use? I've been considering writing one.

[latusaki]

+1

[thethanghn]

+1

[ammichael]

+1

[nazywamsiepawel]

@GantMan yes please!

[danleveille]

@GantMan If you find use in the implementation I shared above, please feel free to reuse any of that. Again, it's a bit amateur, but it works.

[nazywamsiepawel]

hey @danleveille - just tried your version. I'm trying to get a chat input box done. I reckon the general issue is that until we will be able to somehow get access to native inputAccessoryView the only way is a view chasing the keyboard. That solution usually goes visually out of sync. Closest attempt I have seen so far is contained in react-native-keyboard-space. Still, if even a couple frames are dropped during the animation the "accessory view" is going out of sync and doesn't follow the keyboard as nicely as a native would do. react-native-gifted-messenger has the same problem.

[melvinxie]

+1

[congnguyen91]

+1

[dcosson]

+1

[sahrens]

So internally we've mostly been using KeyboardAvoidingView and DockingScrollView (and similar one-off components). Have you guys been able to get those to do what you want?

If not, I would suggest using something from @GantMan or @danleveille

[chirag04]

@sahrens any plans to open source DockingScrollView?

This is what i'm currently using - keyboardAvoidingScrollView: https://gist.github.com/chirag04/d7a7d58f4afc9520a51f511ce7f67788

[sahrens]

Oh sorry, I thought it was OSS already :\

[chirag04]

not yet but now i know it's coming :D

[latusaki]

@sahrens had to add + android:windowSoftInputMode="adjustPan" on AndroidManifest for KeyboardAvoidingView to work properly on Android. Without it, it would bug after app going to inactive state (when pressing android multitask button)

[DeDuckProject]

+1

[knguyen2708]

+1

[yonkshi]

+1

[dcosson]

So it sounds like Facebook internally has this and it's called DockingScrollView? Is it possible to verify if that is true and get a decision/milestone if and when it can be open sourced?

This is a very important feature IMO, and the issue is approaching 2 years old. As far as I know a huge category of things involving keyboard input are impossible to build and make feel native in iOS without inputAccessoryView, including a basic chat or messages view, the done button on a number pad, previous & next buttons for navigating between form fields, etc. So I imagine this is a pretty big blocker for a lot of apps that might want to use React Native.

[nazywamsiepawel]

So I imagine this is a pretty big blocker for a lot of apps that might want to use React Native.

In my case, it was a blocker big enough to switch back to Swift. For anybody looking for a solid solution I recommend having a look SlackTextViewController

[logancarmody]

+1

[zkrige]

+1

[jgkim]

+1

[kumarpatel]

Same issue here. No return key to close onscreen numeric keyboard in iOS

[nezaidu]

+1

[appscaptain]

Yeah, the biggest issue in React Native IMHO. It really gives a bad user experience, when working with text-field heavy apps.

[oximer]

+1

[chih]

I wasn't satisfied with the other solutions presented (unsynced or non-native feeling animations, etc), so I just ended up just creating a modified version of react native with a showDoneButton attribute added to TextInput.

Basically, in RCTTextFieldManager.m, I added code to grab the showDoneButton attribute and create a inputAccessoryView if it is set

https://gist.github.com/chih/3aa8b3bbd490137a31f0b864eff1532e

And then I can do

<TextInput keyboardType={'numeric'} showDoneButton={true}

And get a native inputAccessoryView with the keyboard showing a Done button

I won't bother with a pull request since it seems like a more generic solution is in the works, but this might be an interim solution for those who just need a Done button above a number pad (like I do)

[evollu]

I'm using react-native-textinput-utils which provides 2 buttons for accessory as a temporary solution

[MattyK14]

@chih good stuff! Any way to change the colour to match the dark style keyboard? aka keyboardAppearance="dark"

[chih]

@MattyK14 You can just do

toolbar.barStyle = UIBarStyleBlack;

right below

UIToolbar* toolbar = [[UIToolbar alloc] init];

to get a dark toolbar. A better solution, of course, would be to do that based on reading the value of a prop

[aprct]

+1

[chumster]

+1

[milkers]

+1

[avogel3]

+1

[xicovarisco]

+1

[fdecampredon]

I ended up with this 'hackish' implementation: https://gist.github.com/fdecampredon/a94f47170a2921ac422ebca49eb3817a

You can use it like this (at your own risk):

class Component {

   getTextInputRef = () => this.refs.textInput,

   renderInputAccessoryView = () => {
     return <View>...</View>
   }

   render() {
     return (
       <FormScrollView>
         <TextInput ref="textInput" />
         <InputAccessoryView 
           render={this.renderInputAccessoryView}
           getTextInputRef={this.getTextInputRef}
           height={40} 
         />
       </FormScrollView>
     );
   }
}

[henrikra]

@chih Is your solution already in RN core? or do you have info that they are doing something to this?

[danleveille]

Here's the Product Pains link -- feel free to upvote: https://productpains.com/post/react-native/make-ios-uitextviewinputaccessoryview-on-textinput

(The previous link in this thread is broken.)

[stief510]

+1

[artald]

If anyone’s interested, you can try using a component I wrote a while back called react-native-keyboard-tracking-view.

Although it's not an actual inputAccessoryView, it behaves pretty much the same and allows you to have a view that “sticks” to the keyboard. Useful in case you need a text input or a toolbar that moves along with the keyboard.

[ericvicenti]

Lets keep track of this feature request on canny: https://react-native.canny.io/feature-requests/p/make-ios-uitextviewinputaccessoryview-on-textinput

[twvdb]

+1

[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 https://github.com/douglasjunior/react-native-keyboard-manager/issues/3 and https://github.com/facebook/react-native/issues/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 https://github.com/facebook/react-native/commit/38197c8230657d567170cdaf8ff4bbb4aee732b8 and added an example here https://github.com/facebook/react-native/commit/84ef7bc372ad870127b3e1fb8c13399fe09ecd4d

[loxtank]

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. #18997, doesn't work with multiline inputs.
2. #20157, doesn't work with a tab bar, ie. no way to customize bottom padding when keyboard is collapsed.
3. #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.