Summary:
Switches `TextInput` from `setAndForwardRefs` to `useMergeRefs` (and `useCallback`).
Instead of creating a new `_setNativeRef` function on every render, this will now only create a new ref function when either `mostRecentEventCount` changes, `viewCommands` (i.e. `props.multiline` on iOS) changes, or when `props.forwardedRef` changes.
When a text input is being edited, `mostRecentEventCount` will probably change. But when an unfocused `TextInput` is being updated because a parent is being updated, we will now no longer unnecessarily create a new `ref`. The observable behavior of this is that any `ref` supplied onto `TextInput` will now be invoked less frequently.
Changelog:
[General][Changed] Any `ref` set on `TextInput` will now be updated less frequently (when the underlying `ref` has not changed).
Reviewed By: sammy-SC
Differential Revision: D41191439
fbshipit-source-id: c69a061317c51ad6c6ca8acd116539e0f24a1d08
Summary:
While refactoring `TextInput`, I noticed that we are allocating each of the exported imperative instance methods on every invocation of the component. This is wasteful because if the `ref` does not change, this just creates more garbage.
Instead, we only need to allocate them when we are actually going to assign them onto a `ref`.
Changelog:
[Internal]
Reviewed By: sammy-SC
Differential Revision: D41191440
fbshipit-source-id: 0120d67a9e29a3e0c3f42c3fa436381d6bec7619
Summary:
Straightforward refactor of how `TextInput` augments the exported `ref` with instance methods.
This change is in preparation for additional refactors to eliminate `setAndForwadRefs`.
Changelog:
[Internal]
Reviewed By: christophpurrer
Differential Revision: D41191441
fbshipit-source-id: 30560ce489c48409003a9f92875e5096d3f1130e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35169
This reorganizes typing structure a bit.
`Utilities.d.ts` was originally added for utilitiy types but I ended up leaving it a grab bag of types that didn't belong to any individual bit of code. Out of what is in it right now, `Insets` was actually public, and seems to have been imported.
We also run into files around the renderer which are [currently overwritten](https://github.com/facebook/react-native/commits/e286da25fc83324363486eb668806aca179f74b3/Libraries/Renderer/implementations/ReactNativeRenderer.d.ts) by the React sync script.
Finally, all of the top-level imports of `Utilities` were auto-generated by VS Code, but fail in real apps. I think this is because our tsconfig sets a `baseUrl` to allow resolution from the types folder, so the tooling in the RN repo will use that, but it breaks in real apps that don't have that mapping.
This splits all these up into a couple separate directories that are hopefully easier to reason about, and removes `Omit` which has been a builtin type for quite some time (we were actually already using built-in `Omit`).
Changelog:
[General][Fixed] - Fixup TS Organization
Reviewed By: cipolleschi
Differential Revision: D40932319
fbshipit-source-id: 0b6e3e3eda603885b4dc01dcb9f5233aa546d128
Summary:
In 2017, React published v15.5 which extracted the built-in `prop types` to a separate package to reflect the fact that not everybody uses them. In 2018, React Native started to remove `PropTypes` from React Native for the same reason. In 0.68 React Native introduced a deprecation warning which notified users that the change was coming, and in 0.69 we removed the PropTypes entirely.
The feedback we've received from the community is that there has not been enough time to migrate libraries off of PropTypes. This has resulted in users needing to patch the React Native package `index.js` file directly to add back the PropTypes, instead of migrating off of them. We can empathize with this fix short term (it unblocks the upgrade) but long term this patch will cause users to miss important changes to `index.js`, and add a maintenance cost for users.
Part of the reason there was not enough time is that we didn't do a good job surfacing libraries that were using PropTypes. This means, when you got a deprecation warning, it wasn't clear where the source of the usage was (either in your code or in a library). So even if you wanted to migrate, it was difficult to know where to actually make the change.
In the next release, we've made it easier to find call sites using deprecated types by [fixing the code frame in errors](https://github.com/react-native-community/cli/pull/1699) reporting in LogBox, and ensuring that [the app doesn't crash without a warning](https://github.com/facebook/react-native/pull/34650). This should make it easier to identify exactly where the deprecated usage is, so you can migrate it.
To help users get off of the patch, and allow more time to migrate, we're walking back the removal of PropTypes, and keeping it as a deprecation for a couple more versions. We ask that you either migrate off PropTypes to a type system like TypeScript, or migrate to the `deprecated-react-native-prop-types` package.
Once we feel more confident that the community has migrated and will not need to patch React Native in order to fix this issue, we'll remove the PropTypes again. **If you have any trouble finding the source of the PropType usage, please file an issue so we can help track it down with you.**
Changelog:
[General][Changed] - Add back deprecated PropTypes
Reviewed By: yungsters
Differential Revision: D40725705
fbshipit-source-id: 8ce61be30343827efd6dc89a012eeef0b6676deb
Summary:
iOS did not support the implementation of Korean word-wrap(line-break) before iOS14.
If the attribute applied, the word-wrap of Korean will works.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[iOS] [Added] - Line break strategy for Text and TextInput components
Pull Request resolved: https://github.com/facebook/react-native/pull/31272
Test Plan:
1. Test build and run on above iOS 14.
2. Test it does not affect existing text components when set default(none) strategy.
3. Test whether word-wrap works with Korean when set hangul-word strategy.
<img src="https://user-images.githubusercontent.com/26326015/112963967-d7f70c00-9182-11eb-9a34-8c758b80c219.png" width="300" height="" style="max-width:100%;">
Reviewed By: javache
Differential Revision: D39824809
Pulled By: lunaleaps
fbshipit-source-id: 42cb0385221a38c84e80d3494d1bfc1934ecf32b
Summary:
This adds support for the `verticalAlign` style attribute, mapping the already existing `textAlignVertical` attribute as requested on https://github.com/facebook/react-native/issues/34425. This PR also updates the TextExample.android on the RNTester in order to facilitate the manual QA of this.
## Changelog
[Android] [Added] - Add support for verticalAlign style
Pull Request resolved: https://github.com/facebook/react-native/pull/34567
Test Plan:
1. On Android open the RNTester app and navigate to the Text page
2. Check the text alignment through the `Text alignment` section
https://user-images.githubusercontent.com/11707729/188051914-bf15f7eb-e53f-4de5-8033-d1b572352935.mov
Reviewed By: jacdebug
Differential Revision: D39771237
Pulled By: cipolleschi
fbshipit-source-id: d2a81bec1edd8d49a0fcd36a42fea53734909739
Summary:
React Native's TS definitions are currently mostly stored in one monolithic file. This change splits the definitions up to correspond to the source files they came from, and are placed next to the source files. I think this should help inform, and make it easy to update the TS declarations when touching the Flow file.
I noticed as part of the change that the typings have not yet removed many APIs that were removed from RN. This is bad, since it means using the removed/non-functional API doesn't cause typechecker errors. Locating typings next to source should prevent that from being able to happen.
The organization here means individual TS declarations can declare what will be in the RN entrypoint, which is a little confusing. Seems like a good potential next refactor, beyond the literal translation I did.
Changelog:
[General][Changed] - Place TS Declarations Alongside Source Files
Reviewed By: lunaleaps, rshest
Differential Revision: D39796598
fbshipit-source-id: b36366466fd1976bdd2d4c8f7a4104a33c457a07
Summary:
This replaces all direct references to `ReactNative` within the `react-native` package to use `findNodeHandle` with a reference obtained from `RendererProxy`, which will allow us to select the correct renderer.
Changelog: [internal]
Reviewed By: javache
Differential Revision: D39270689
fbshipit-source-id: a39875281ba7b7b1b00128564124b6adcacebc4d
Summary:
This unifies the Android only `autoComplete` and the iOS only `textContentType` TextInput props with the web `autoComplete` values as requested on https://github.com/facebook/react-native/issues/34424. I left the `textContentType` prop and the current supported `autoComplete` values untouched in order to avoid having a breaking change. This also updates RNTester to include test cases using the new `autoComplete` values
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[General] [Changed] - Unify TextInput autoComplete and textContentType props
Pull Request resolved: https://github.com/facebook/react-native/pull/34523
Test Plan:
1. Open the RNTester app and navigate to the TextInput page
2. Test the `TextInput` component through the `Text Auto Complete` section
https://user-images.githubusercontent.com/11707729/187118267-3b509631-7b84-47b7-a580-567a7f5b483f.mov
Reviewed By: NickGerleman
Differential Revision: D39104545
Pulled By: cipolleschi
fbshipit-source-id: a0d4b1b9ab336854a741a9efe4a62c3da0b5c0f4
Summary:
This adds the `inputMode` prop to the TextInput component as requested on https://github.com/facebook/react-native/issues/34424, mapping web [inputMode types](https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/inputmode) to equivalent [keyboardType](https://reactnative.dev/docs/textinput#keyboardtype) values. This PR also updates RNTester TextInputExample in order to facilitate the manual QA.
### Caveats
~~This only adds support to `text`, `decimal`, `numeric`, `tel`, `search`, `email`, and `url` types.~~
#### `inputMode="none"`
**Currently mapped to `default` keyboard type.**
The main problem with this input mode is that it's not supported natively neither on Android or iOS. Android `TextView` does accept `none` as `android:inputType` but that makes the text not editable, which wouldn't really solve our problem. `UITextInput` on iOS on the other hand doesn't even have something similar to avoid displaying the virtual keyboard.
If we really want to add the support for `inputMode="none"` one interesting approach we could take is to do something similar to what WebKit has done (https://github.com/WebKit/WebKit/commit/3b5f0c8ecf9de23f79524ed02e290837ab8334cd). In order to achieve this behavior, they had to return a `UIView` with a bounds of `CGRectZero` as the inputView of the `WKContentView` when inputmode=none is present.
~~I guess the real question here should be, do we really want to add this? Or perhaps should we just map `inputMode="none"` to `keyboardType="default"`~~
Android docs: https://developer.android.com/reference/android/widget/TextView#attr_android:inputType
iOS docs: https://developer.apple.com/documentation/uikit/uikeyboardtype?language=objc
#### `inputMode="search"` on Android
**Currently mapped to `default` keyboard type.**
Android `TextView` does not offers any options like `UIKeyboardTypeWebSearch` on iOS to be used as `search` with `android:inputType` and that's probably the reason why `keyboardType="web-search"` is iOS only. I checked how this is handled on the browser on my Android device and it seems that Chrome just uses the default keyboard, maybe we should do the same?
### Open questions
- ~~What should be done about `inputMode="none"`?~~ Add it and map it to `default` keyboard type.
- ~~Which keyboard should we show on Android when `inputMode="search"`?~~ Use the `default` keyboard the same way Chrome does
## Changelog
[General] [Added] - Add inputMode prop to TextInput component
## Test Plan
1. Open the RNTester app and navigate to the TextInput page
2. Test the `TextInput` component through the `Input modes` section
https://user-images.githubusercontent.com/11707729/185691224-3042e828-a008-4bd0-bb3d-010a6a18dfd5.mov
Pull Request resolved: https://github.com/facebook/react-native/pull/34460
Reviewed By: necolas
Differential Revision: D38900724
Pulled By: cipolleschi
fbshipit-source-id: 60d405ccdbfad588b272fbb6b220b64ffdfc4b14
Summary:
This adds the Android only `rows` prop to TextInput as requested on https://github.com/facebook/react-native/issues/34424 mapping the existing `numberOfLines` prop to `rows`. This PR also updates the TextInputExample.android on the RNTester in order to facilitate the manual QA of this.
## Changelog
[Android] [Added] - Add rows prop to TextInput component
Pull Request resolved: https://github.com/facebook/react-native/pull/34488
Test Plan:
1. On Android open the RNTester app and navigate to the TextInput page
2. Test the `TextInput` component through the `Fixed number of lines` section
https://user-images.githubusercontent.com/11707729/186300173-7de79799-25b8-48af-99c0-8e3abeae334f.mov
Reviewed By: christophpurrer
Differential Revision: D38981953
Pulled By: cipolleschi
fbshipit-source-id: d4d84b3c0dac7342ba9a65e2491928fbc61ff4f1
Summary:
This adds the `readOnly` prop to TextInput as requested on https://github.com/facebook/react-native/issues/34424 mapping the existing `editable` prop to `readOnly` so that `readOnly={false}` maps to `editable={true}` and `readOnly={true}` represents ` editable={false}`. This PR also updates the TextInputExample on the RNTest in order to facilitate the manual QA of this.
## Changelog
[General] [Added] - Add readOnly prop to TextInput component
Pull Request resolved: https://github.com/facebook/react-native/pull/34444
Test Plan:
1. Open the RNTester app and navigate to the TextInput page
2. Test the `TextInput` component through the `Editable and Read only` section
https://user-images.githubusercontent.com/11707729/185295132-036443c8-1d5e-4567-a15e-5f1173cb0526.mov
Reviewed By: lunaleaps
Differential Revision: D38912786
Pulled By: necolas
fbshipit-source-id: faeb59ed8695732be682ec55406a2de0cb7e619a
Summary:
Now that [exact_empty_objects has been enabled](https://fb.workplace.com/groups/flowlang/posts/1092665251339137), we can codemod `{...null}` to `{}` - they are now equivalent.
1) Run my one-off jscodeshift codemod
2) `scripts/flow/tool update-suppressions .` (as some suppressions move around due to the change)
drop-conflicts
Reviewed By: bradzacher
Differential Revision: D37834078
fbshipit-source-id: 6bf4913910e5597e5dd9d5161cd35deece6a7581
Summary:
A layout-impacting style change will trigger a layout effect hook within `TextInput`. This hook fires a ViewManager command to set the text input based on the known JS value: https://github.com/facebook/react-native/blob/d82cd3cbce1597512bb2868fde49b5b3850892a0/Libraries/Components/TextInput/TextInput.js#L1009
The JS value is determined using `value` if set, falling back to `defaultValue`. If a component uses `TextInput` as an uncontrolled component, and does not set this value, the command wipes text input back to the default value. This does not happen on re-render of the JS side, despite setting text prop, since the underlying native property never changes/triggers a rerender.
This change alters the logic to prefer `lastNativeText` instead of `defaultValue` when available, to retain the updated `TextInput` content on relayout.
Reviewed By: javache
Differential Revision: D37801394
fbshipit-source-id: d56c719d56bebac64553c731ce9fca8efc7feae9
Summary:
`InputAccessoryView` works fine on iOS, but crashes on Android - you can see that by using an Android device on the [Expo Snack from the official doc](https://reactnative.dev/docs/inputaccessoryview).
It forces the developer not to render the component on Android, which is usually good, but other components have implemented other, safer ways to deal with incompatibility issues.
I am of course open to discussion about this change, as well as other implementation ideas.
## Changelog
[Android] [Fixed] - Fix InputAccessoryView crash on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/33803
Test Plan:
`yarn test` gives out the following output:
Reviewed By: cipolleschi
Differential Revision: D37215394
Pulled By: cortinico
fbshipit-source-id: 66c4401f7c61b745ea893969d69c8dde3e5afb03
Summary:
An issue that popped up working on:
D36140890
There is already behavior implemented to set the TextInput caret/cursor color independently from the selection box color in Android.
However this handy prop, was not documented or added as one of the available props for the TextInput component.
Associated behavior can be found here:
https://www.internalfb.com/code/fbsource/[f116d651b2e8]/xplat/js/react-native-github/ReactAndroid/src/main/java/com/facebook/react/views/textinput/ReactTextInputManager.java?lines=512
## **Changelog**
[Android] - Add android-only prop documentation at the TextInput js level.
Reviewed By: genkikondo
Differential Revision: D36208656
fbshipit-source-id: a54a2646351d897e0d598d5e1979f2a0c443e9d6
Summary:
We are working on making the empty object literal `{}` have the type `{}` - i.e. exact empty object - rather than being unsealed.
Some manual fixes, in particular to React Native code, which is used and can be synced to other repos (e.g. WWW).
With these changes, error diff in Xplat is down to ~1990 errors
Note that after I roll out `exact_empty_objects`, I'll codemod all the `{...null}` (the only way to get an exact empty object currently) back to `{}`
Changelog: [Internal]
Reviewed By: SamChou19815
Differential Revision: D36142838
fbshipit-source-id: 054caf370db230f42a4c5f5706c88979ef246537
Summary:
The static ViewConfig codegen generates the static ViewConfig inside the JavaScript module [under an exported constant](https://github.com/facebook/react-native/blob/a0a2958cdac767f50084c2d5bee6cf224ffb9db3/packages/react-native-codegen/src/generators/components/GenerateViewConfigJs.js#L127-L129):
```
export const __INTERNAL_VIEW_CONFIG = VIEW_CONFIG;
export default NativeComponentRegistry.get(nativeComponentName, () => __INTERNAL_VIEW_CONFIG);
```
This exported constant allows us to build a test page that requires all components, and compares their static ViewConfigs with their native ViewConfig.
This diff makes components with hand-written static ViewConfigs also export this __INTERNAL_VIEW_CONFIG const.
Changelog: [Internal]
Reviewed By: p-sun
Differential Revision: D34541868
fbshipit-source-id: f55dd3f1b161038baaf84cbbf75c1f4041c34647
Summary:
Removes the `propTypes` member from the `Image`, `Text`, and `TextInput` components.
They have been deprecated since React Native v0.66.
Changelog:
[General][Removed] - Removed `Image.propTypes`, `Text.propTypes`, and `TextInput.propTypes`.
Reviewed By: kacieb
Differential Revision: D33750298
fbshipit-source-id: 085f83ad838196bdd531b097b8ce5957270c3ad1
Summary:
Putting the static view config into its own file creates the uncertainty that n > 1 files import the static view config. This isn't true for AndroidTextViewConfig. So, let's just inline this static view config in the NativeComponent that uses it.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D33341776
fbshipit-source-id: 6fb710b8776d7b9276022c5226acefd7cf8395fb
Summary:
changelog: [internal]
Introduce a way to execute `onKeyPress` synchronously. This feature is experimental and will be changed in the future. It is not decided if marking native events as "sync" is going to be path forward with synchronous access.
NOTE: This is experimental API.
Reviewed By: ShikaSD
Differential Revision: D32882092
fbshipit-source-id: 68c66a9bb7c97758219e085c88a77f3c475c1eb3
XantreGodlike
Sam Zhou
Nicolas Gallagher
Tim Yung
Luna Wei
Mayank Sunil Pagar
Gabriel Donadel Dall'Agnol
Nick Gerleman
Rick Hanlon
bang9
Daksh Bhardwaj
Nick Gerleman
Luna Wei
Rujin Cao
Rubén Norte
ankit-tailor
Tony Du
Garrett Forbes Monroe
George Zahariev
hduprat
Hetan Thakkar
Christian Ruink
Rick Hanlon
Vojtech Novak
Ramanpreet Nara
Moti Zilberman
Tim Yung
Andres Suarez
Samuel Susla
Liron Yahdav
Marcel Lasaj
