react-native: [0.71] Web Prop update caused unexpected breaking changes
Description
Following the work from https://github.com/facebook/react-native/issues/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
/
About this issue
- Original URL
- State: closed
- Created a year ago
- Comments: 18 (11 by maintainers)
Commits related to this issue
- Precedent textContentType when set Summary: Changelog: [iOS][Changed] - Give precedence to `textContentType` property for backwards compat as mentioned in https://github.com/facebook/react-native/iss... — committed to facebook/react-native by lunaleaps a year ago
- Precedent textContentType when set Summary: Changelog: [iOS][Changed] - Give precedence to `textContentType` property for backwards compat as mentioned in https://github.com/facebook/react-native/iss... — committed to facebook/react-native by lunaleaps a year ago
- Precedent textContentType when set Summary: Changelog: [iOS][Changed] - Give precedence to `textContentType` property for backwards compat as mentioned in https://github.com/facebook/react-native/iss... — committed to OlimpiaZurek/react-native by lunaleaps a year ago
Hey guys for an update, @rickhanlonii, @necolas and I met up to talk about this and the general strategy going forward.
For this case particularly, I am going to:
textContentTypetake precedence on iOS and make a patch for 0.71 and ensure its in 0.72textContentTypethat it’s just an alias forautoCompletebut not to use both.In our discussion we would like to address this one-off and don’t see this as a wide-spread issue (as-in, it likely isn’t an issue for other prop aliases we’ve added). In future efforts around conformance we’re going to be more intentional in making block changes behind gating flags so we don’t get these paper-cuts for un-intentional adoption.
cc @NickGerleman edit: also thanks @Titozzz for bringing this valuable point up!
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.
@necolas I know, but it was a shared input for two data types, that’s probably a bad idea but that’s what is was. And so have autocomplete for half the data was better than nothing I guess. 🙄
Once again this is just a silly example revealing something that happened. I don’t really want to slow down the effort to migrate to universal props nor argue about the pertinence of old code from our codebase.
The only goal was to show some this was a breaking behaviour while offering an alternative 😄
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)
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