[TextInput] iOS Keyboard next/prev Buttons & tab Support

[erikthedeveloper]

I have been unable to find throughout the documentation, UIExplorer, or my own experiments a way to enable iOS keyboard navigation and submit elements. I feel like this is important and expected from users to be able to navigate between input elements and submit from the iOS keyboard.

This behavior is present/expected even on vanilla HTML forms accessed via iOS on the web.

If somebody already has a solution for this, please let me know 😄

Request

• Activate iOS next/prev buttons on the TextInput and other user input elements
• Enable grouping of input elements together as a "form"

Screen shot showing "next"/"prev" elements

[erikthedeveloper]

Update 😑 should have updated before submitting, but updating react-native from 0.3.1 -> 0.3.4 resolved the returnKeyType issue.

Before update: returnKeyType property had no effect on the iOS keyboard.
Now: it does 😄

          <TextInput
            // ...
            returnKeyType='go'
          />

[kevinkam]

How to focus on the second TextInput?
I have set the first TextInput with property returnKeyType="next"
and second TextInput with property returnKeyType="go"
But when I click the "next" button, it just hide the keyboard and unfocus the first TextInput
How can I focus on the second TextInput?
Thanks!

[auser]

bump

[brentvatne]

Discussed with @vjeux and @auser in irc, this is indeed an issue and if anyone is up for tackling it a PR would be very welcome. Just post in here if you are getting started on it. Otherwise I may look at it later this week.

[erikthedeveloper]

I would love to take a stab at it, but I'm not convinced I'm quite up to the task of a PR into react-native core 😅

I'll be very interested to check out your work if you get a PR submitted @brentvatne 😄

[ide]

For single-line text fields, the onSubmitEditing handler (or similar) should suffice. What is missing from it to let you solve this use case?

[nicklockwood]

The back/forward form navigation buttons are a iOS browser feature, not a native iOS app feature. These buttons will show up automatically if you display an HTML form inside a WebView, but there is no API for displaying these buttons in native iOS apps, and any app that you have seen using them is either using a WebView, or has re-created the same feature natively using custom code (presumably for the purpose of making their native form behave more like a web form - a somewhat dubious UX decision IMHO).

It would certainly be possible to implement a facsimile of this feature right now as a native module, and if the demand is high enough then I expect someone will build it (maybe even us), but for the record, if I was developing a native iOS app and the designer asked for this, I would push back and suggest that they try to implement forms using native iOS app design patterns rather than iOS mobile web patterns.

You'll notice that the iOS Settings app never once uses this pattern, despite having pages and pages of form fields.

That said, we are currently investigating the best way to implement inputAccessory views (the docked bar that appears above the keyboard that can be used for adding additional application-specific controls), and once that is in place, it should be relatively simple to implement this feature in JS code.

[dvdhsu]

Can the "return" key move to next text input field? Looking around the documentation, it seems like we can display the "return" key as a "next", but it won't actually move to the next input field -- it'll just dismiss the keyboard.

As @nicklockwood says, back/forward form navigation buttons aren't a native iOS app feature. Moving to the next field is, though. It'd probably be more important to implement that.

Edit: remove incomplete sentence.

[nicklockwood]

@dvdhsu unlike web forms, iOS has no natural concept of tabbing order, or the "next field", so we cannot easily replicate that automatically. If you register an event handler for onSubmitEditing, it should fire when the return key is pressed, and you can then call focus() on the next field in the form.

[nicklockwood]

@dvdhsu I've not actually tried building a form like this in practice, so if you find that it doesn't work, or if you have some ideas for how to make it simpler to implement, I'd be keen to hear them.

[brentvatne]

@nicklockwood - thank you the detailed response, your expertise is much appreciated.

@ide - you're right, that will work just fine for the most part. If you have a username and password field, you can just focus the password in the onSubmitEditing callback, easy. If you have several inputs, it seems preferable to have a more generalized focusNextField(currentField) function so that you don't have to hardcode the order of fields. This becomes a bit awkward because the event target is a node id number that refers to the node. So you have to set a ref on all of the inputs, then search through the refs until you find the one with the matching id, and then use the TextInput following that. Tabbing through inputs seems like a common enough use case that it would be worth simplifying a bit, can't say I have a good API in mind at the moment though.

[ide]

@dvdhsu - there are a good number of cases where you might want the Next button to do something other than go to the next text field. For example you might want to transition to the next screen, or focus the next text field that doesn't yet have valid input (ex: if the user filled them out out-of-order).

For the use case you mentioned: if I understand it correctly, to move to the next field you could get refs to all of the text fields and then call this.refs[desiredTextField].focus(). This is pretty lightweight and opens the opportunity for custom logic like skipping over certain fields, etc.