[0.71] Web Prop update caused unexpected breaking changes

[Titozzz]

Description

Following the work from #34424, there was some (unexpected?) breaking changes to <TextInput />.

Before there were 2 props:

• autoComplete => android (name-family, name-given, etc)
• textContentType => iOS (familyName, givenName, etc)

Now due to the changes, there is still 2 props:

• autoComplete => android & iOS
• textContentType => iOS

But the new implementation looks like this:

There is a new universal set of keys (some of them identical to the old one, some news)
When you set autoComplete:

• android: check if name is in the new set of keys, if so map to the android value, else pass it directly to android (compatibility with old keys)
• iOS: check if the name is in the set of keys, if so map to the iOS value, else if textContentType is defined, use it.

What's breaking is that for example if you used autoComplete = "A" and textContentType="B", on 0.71 it will be treated as textContentType="A" on 0.71

How we could have mitigated this:
-> Deprecate and set warnings on textContentType but still use it first in the implementation so that user migrate without breaking their apps

Version

0.71

Output of npx react-native info

/

Steps to reproduce

Use TextInput with autoComplete and textContentType

Snack, code example, screenshot, or link to a repository

/

[gabrieldonadel]

cc: @necolas

[necolas]

if you used autoComplete = "A" and textContentType="B", on 0.71 it will be treated as textContentType="A" on 0.71

If you use autoComplete = "A" it should be mapped to whatever the corresponding value of textContentType should be, which isn't necessarily "A". Hard to say anything more without a concrete example of the issue you're experiencing

[NickGerleman]

If both props were here before, and we repurposed one of them without documenting it as a breaking change, I think we messed up here.

I.e. the web prop precedence should only come into effect for someone using a newly introduced prop.

[NickGerleman]

It seems like this change effectively breaks any previous xplat usage of the prop, so we should patch this imo, and make the break later if we want to make it.

[necolas]

We added values to autoComplete and automatically map them to corresponding iOS values, if the autoComplete value is not recognized or not a web value, we use the provided iOS value. The OP needs to explain what specific values are causing issues.

[NickGerleman]

It seems like this is the scenario:

What's breaking is that for example if you used autoComplete = "A" and textContentType="B", on 0.71 it will be treated as textContentType="A" on 0.71

So, if Android and iOS disagreed before. Which is, more scoped, but still technically breaking.

[necolas]

Yes but A is not a specific value. In what scenarios does the same text input need to have completely different autocomplete values across platforms?

[Titozzz]

An example with cc-number, if we have an input that can take credit card information or bank account numbers.
On android, setting cc-number will only impact the suggestions but we do not want to use it on iOS and explicitly set it to none because if you use cc-number on iOS, the keyboard changes and restrains the user from using letters, only numbers.

There you have a regression that was unexpected!

[Titozzz]

While I understand this is niche and easily fixable dev side, I'm wondering why this approach was chosen, since the non-breaking alternative strategy (using the textContentType first and warn) seemed easier to me (and would also create discovery for the new capabilities)

[necolas]

the keyboard changes and restrains the user from using letter

When do you need to input letters for a credit card number?

I'm wondering why this approach was chosen

It's consistent with what we did for dozens of other props and styles.

[Titozzz]

When do you need to input letters for a credit card number?

if we have an input that can take credit card information or bank account numbers.

Bank account have letters in them!

[rickhanlonii]

@necolas interesting, can you list all the props we've done this for? I know about the props where the new one takes precedence over the old prop (only impacts new code), but I didn't follow close enough to see the props where we added support for an existing prop on one platform to both platforms (changing the behavior of existing code).

[necolas]

Bank account have letters in them!

Bank account should not use cc-number as that is designed only for credit card numbers, which is why the native keyboard limits it to only numbers.

There is an open HTML issue for adding an autocomplete type for bank accounts, but in the meantime you are expected to use free text entry. On web you can also pattern match to limit to numbers and letters, but React Native doesn't have support for declarative patterns.

whatwg/html#1448