React-native: [TextInput] Get keydown event to handle "Enter"

[JonasJonny]

Hello.
I tried to catch keydown/keypress events for several hours with no luck.
I can get whole .text string (onChange={}) but what if I need to do an action when "Enter/Backspace" are pressed?
Is there any solution how to know which keyboard character was just pressed in TextInput keyboard?

Thank you.

[chirag04]

Not sure if controlled={true} can help you here.

[JonasJonny]

No luck with controlled={true} but thank you @chirag04.
Attributes onKeyDown/Up/Pressed didn't work but I know they are not supported.
Event for onChange have just target, text, timestamp :(.

[brentvatne]

I would like to see onKey* implemented, @sahrens do you have any suggestions for where to get started on implementing this? Maybe @JonasJonny or another interested contributor would be able to take that and turn it into a PR

[JonasJonny]

Unfortunately I don't have enough skill to help.

[grabbou]

@brentvatne I think the way you emit events for your video component should work quite nicely in this case. The only thing is whether we want to wrap them like you and return event or return plain event.nativeEvent - not sure how it's handled in other cases as it should be consistent across the library.

[dsibiski]

@JonasJonny I have a working implementation of onKeyPress that successfully detects return and delete.

Right now it is returning the character of the key that was pressed and for return and delete, it's returning ASCII codes CR and DEL respectively.

Would this take care of your use case? @brentvatne any other ideas as to how the return and delete codes should be returned to JS? Would it be better to use ASCII code numbers?

I'd like to figure these things out before submitting a PR.

[dsibiski]

Ah, it looks like there really isn't a delete key in iOS, it's more like a backspace, so it should send back BS or 08

[JonasJonny]

Thank you @dsibiski for following. I really appreciate that.

In my opinion you should return "keyCode" http://www.cambiaresearch.com/articles/15/javascript-char-codes-key-codes

[brentvatne]

Agreed with @JonasJonny - I think we should emulate the modern browser version of this though, rather than keyCode: https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/key - so it would return {key: "Backspace"} and some other properties too (probably for now we can just do key and implement others on a per-use-case basis)

[dsibiski]

Thanks for the feedback guys! I pretty much have this ready for a PR, I'll make these changes and you guys can review it and see what you think...

[browniefed]

@brentvatne not sure how you want to handle issues w/ pending PRs.

[grabbou]

PR submitted label would've been handy when scrolling through the issues to pick one to work on.

[brentvatne]

@browniefed - yeah it's a little awkward, maybe PR submitted tag would be good but that might be hard to keep up to date unless it's added automatically

[ide]

GitHub should build this if there isn't already a way to write this query.

[browniefed]

@ide +1 ... oh wait they haven't built a voting system yet ... not holding my breath.

[GantMan]

Anything I can do to help this task along? Pretty essential to native apps I believe.

[dsibiski]

@brentvatne We can close this now as my PR for onKeyPress has been merged to master.

[brentvatne]

Awesome :smile:

[yfsx]

what about android? is onKeyPress worked on android version? because it's not possible to make 2 versions of code only for "enter clicked".

[brentvatne]

cc @dsibiski ^

[Abhay-Joshi-Git]

Does Android version has support for onKeyPress ? Documentation suggests otherwise also I just tried and it's not working with version 0.26.2, but I just wanted to get this confirmed.
Also, it would be great if anyone can estimate about when we would be able to see that if it's not already there.

[dsibiski]

@yfsx @Abhay-Joshi-Git: No, it hasn't yet been implemented for Android. If either of you want to give it a shot that would be awesome 👍

[semiautomatix]

Any further work on this? I am relying on a barcode scanner - that produces a return key value upon completion. If this isn't available for Android then it's a dealbreaker.

[santhosh77h]

Any update for android.OnKeyPress

[uncle-T0ny]

What the problem with https://github.com/facebook/react-native/issues/2082 ?

[joshjhargreaves]

Heads up: I'm taking a look at doing this on Android.

[joshjhargreaves]

Does anyone have any thoughts on the best way to approach this in terms of detecting the keypresses on ReactEditText? It seems that there might be a few approaches.

TextWatcher
The least desirable approach would be use the TextWatcher interface to determine the key press based on a the difference between the oldText and the newText, here for example. However this really doesn't seem feasible, due to numerous reasons; difficulty detecting backspaces on empty text views for one?

KeyListener
In ReactEditText we are using an internal KeyListener, which perhaps could be a place where we could capture the keypress here? However the relevant onKeyDown/onKeyUpMethods methods only seem to fire when the keyboard type is not of type TYPE_CLASS_TEXT; i.e. only when the keyboard is numeric, for example. Any ideas as to why this might be, I'm guessing there's no need internally to call the KeyListener if the set input type is of type text?

InputConnectionWrapper
Another approach seems to be extending the InputConnectionWrapper class and capturing the keypresses that way, for example as per here. I tried this out here, but experienced the same behaviour as the KeyListener; the events were only firing if the keyboard shown was not the default/not of class TEXT.

@janicduplessis I'm not sure if you can offer any insight :)?

edit: It's nothing to do with the keyboard type being shown, it's to do with the keys themselves. onKeyDown/onKeyUp are only firing if the characters being pressed themselves are numeric.
edit: The _KeyListener_ and _InputConnectionWrapper_ onKeyDown/onKeyUp events seem to fire 100% if the keypad is numeric & numeric values are typed, however intermittently when typing numeric values in other text fields in the UIExplorer app.
edit: Hardware keypresses from hardware mac keyboard cause the events to fire every time, but soft keys on the emulator do not.

edit: Looks like I was completely wrong and you actually do need to do this with TextWatcher and potentially have some special cases for Tab, Return etc. Backspace (detected by InternalInputWrapper).

[GuillaumeMunsch]

Hi !

Any news on this ?

[vance-liu]

Hi ! e~
Any news on this ~?

[andela-landia]

Hi, you can use onSubmitEditing prop on the TextInput to submit on Enter. This works for iOS and Android.

[hkung77]

onSubmitEditing works great for Enter but how about listening for other input events like backspace?

[joshjhargreaves]

Hey everyone,
I created a PR for onKeyPress on Android: thoughts and comments much appreciated :).
https://github.com/facebook/react-native/pull/14720

The PR itself has a fairly extensive comment on implementation details.

@hkung77 : handles your backspace.

[semiautomatix]

@joshyhargreaves very excited for this PR - however I've changed my entire project to work around this shortcoming already.

[GuillaumeMunsch]

Looking forward to see this in RN next version as well ! :)

[joshjhargreaves]

So a bit of an update on the PR.

the tl:dr is that there are some limitations to the native APIs that stop us being able to have a completely 'flawless' onKeyPress API, but I reason that we don't need it to be a completely 'flawless ''onKeyPress' implementation, as implementing such a thing is something we cannot do natively. What we need to do is expose native functionality to JS that users currently don't have on Android, like detecting backspaces where no text changes, and distinguishing between text changes from keyboards and cut/paste. These are things we can do, and I'll update the PR to support these cases and bring the API functionality as close to the iOS API as possible.

https://github.com/facebook/react-native/pull/14720#issuecomment-311192996

[react-native-bot]

@facebook-github-bot icebox

[facebook-github-bot]

@react-native-bot tells me to close this issue because it has been inactive for a while. Maybe the issue has been fixed in a recent release, or perhaps it is not affecting a lot of people. Either way, we're automatically closing issues after a period of inactivity. Please do not take it personally!

If you think this issue should definitely remain open, please let us know. The following information is helpful when it comes to determining if the issue should be re-opened:

- Does the issue still reproduce on the latest release candidate? Post a comment with the version you tested.
- If so, is there any information missing from the bug report? Post a comment with all the information required by the issue template.
- Is there a pull request that addresses this issue? Post a comment with the PR number so we can follow up.

If you would like to work on a patch to fix the issue, contributions are very welcome! Read through the contribution guide, and feel free to hop into #react-native if you need help planning your contribution.

[bunnyc1986]

@joshyhargreaves, thanks for creating this PR. That's exact what I am looking for.
May I ask what is the status? Is it going to be merged soon? I look forward to seeing it on next RN version.

[gianpaj]

Same question to @joshyhargreaves on the status on https://github.com/facebook/react-native/pull/14720

[joshjhargreaves]

@gianpaj this landed a while ago! https://twitter.com/joshyhargreaves/status/949022712814555142

[gianpaj]

thanks great! I got confused because the docs mention it's only for iOS and the PR is closed, not merged.

I've opened a PR to update the docs:
https://github.com/facebook/react-native-website/pull/297