Summary:
This diff formats the Java class files inside xplat/js/react-native-github. Since google-java-format was enabled in D16071401 we want to codemode the existing code so that users don't have to deal with formatter lint noise at diff-time.
```arc f --paths-cmd 'hg files -I "**/*.java"'```
drop-conflicts
Reviewed By: cpojer
Differential Revision: D16071725
fbshipit-source-id: fc6e3852e45742c109f0c5ac4065d64201c74204
Summary:
Similar to D15909582, this change makes the Android TextInput take strings for the value of autoCapitalize and not just numbers. As we are going to stop sending view configs from native and instead hardcode them in JS we can't do that anymore.
In this commit we are supporting the old style as well as the new style.
Changelog:
[Android] [Internal] - Supporting autoCapitalize as string to clean up internal TextInput.js file
Reviewed By: mdvacca
Differential Revision: D15911323
fbshipit-source-id: b236fdb314489cc1ef33f9214ff2d6b0e28b7310
Summary:
There's an issue with TextInput on Android where if you have TalkBack enabled, double tapping doesn't focus the text input. It turns out this is because we ignore all focus events that aren't from JS in ReactEditText. This diff makes an exception for the accessibility click event.
I think this should also fix https://github.com/facebook/react-native/issues/17624
Reviewed By: lunaleaps
Differential Revision: D15818103
fbshipit-source-id: 354728b58f1023c4d44edd48337c8daa8ea15c0c
Summary:
Add prop showSoftInputOnFocus to TextInput. This fixes#14045. This prop can be used to prevent the system keyboard from displaying at all when focusing an input text, for example if a custom keyboard component needs to be displayed instead.
On Android, currently TextInput always open the soft keyboard when focused. This is because `requestFocus` calls `showSoftKeyboard`, which in turn instructs `InputMethodManager` to show the soft keyboard.
Unfortunately even if we were to define a new input type that extends ReactEditText, there is no way to overcome this issue.
This is because `showSoftKeyboard` is a private method so it can't be overriden. And at the same time `requestFocus` needs to invoke `super.requestFocus` to properly instruct Android that the field has gained focused, so overriding `requestFocus` in a subclass of ReactEditText is also not an option, as when invoking `super.requestFocus` we would end up calling again the one defined in ReactEditText.
So currently the only way of doing this is to basically add a listener on the focus event that will close the soft keyboard immediately after. But for a split second it will still be displayed.
The code in the PR changes `requestFocus` to honor showSoftInputOnFocus as defined in Android TextView, displaying the soft keyboard unless instructed otherwise.
## Changelog
[Android] [Added] - Add showSoftInputOnFocus to TextInput
Pull Request resolved: https://github.com/facebook/react-native/pull/25028
Differential Revision: D15503070
Pulled By: mdvacca
fbshipit-source-id: db4616fa165643d6ef2b3185008c4d279ae08092
Summary:
We're working on a custom EditText that supports some rich text editing, and one of the places where our logic has to be different from the textinput provided by RN is the text setting logic:
https://github.com/facebook/react-native/blob/7abfd23b90db08b426c3c91b0cb6d01d161a9b9e/ReactAndroid/src/main/java/com/facebook/react/views/textinput/ReactEditText.java#L377
However, some of the important members are private and our subclass cannot access them (we work around this now with reflection). It would be nice if we could work with them directly, either using getters and setters or by changing the access. Let me know what you think about this. Thanks.
## Changelog
[Android] [Added] - allow custom maybeSetText logic for ReactEditText subclasses
Pull Request resolved: https://github.com/facebook/react-native/pull/24927
Differential Revision: D15431682
Pulled By: cpojer
fbshipit-source-id: 91860cadac0798a101ff7df6f6b868f3980ba9b1
Summary:
Resolve#24690
This is very simple unicode detecting. Should I improve this solution creating StringsUtils for detecting unicodes in whole react-native project ?
[Android][Fixed] onKeyPress method is calling, when user type emoji
Pull Request resolved: https://github.com/facebook/react-native/pull/24717
Differential Revision: D15238388
Pulled By: cpojer
fbshipit-source-id: 038b1040e1c44fd6f9401a3988a782f5778e1209
Summary: This is removing packages and libraries from the repo. Any modified buck files simply change the redirect targets to something more appropriate (no logic actually changed)
Differential Revision: D14950721
fbshipit-source-id: 6c14f827b76ca1dbaf83dcb983930f362c6a27d4
Summary:
Android API 26 and Android Support Library 26 added support for font resource type and native/downloadable fonts. It allows apps to easily download fonts from online providers, but also use of various font weights other than normal and bold, like medium. So it deprecated APIs for asset fonts, and should be removed in the future.
Advantages:
- Just copy font files in res/font and use it specifying filename (without extension) in fontFamily
- Define custom font-family using XML file (in res/font) and font files, it may have many weights and styles. See PR for example.
- Define configuration to download fonts from online font providers, and use it.
See https://developer.android.com/guide/topics/ui/look-and-feel/fonts-in-xml and https://developer.android.com/guide/topics/ui/look-and-feel/downloadable-fonts
[Android] [Changed] - add support for custom/downloadable fonts
Pull Request resolved: https://github.com/facebook/react-native/pull/23865
Differential Revision: D14506542
Pulled By: hramos
fbshipit-source-id: 67ba3148fb4b548cdbc779213cf6c1b2c3baffd2
Summary:
Since text and selection has dependency, handle text selection in
updateExtraData as well.
The root cause is due to setText is handled on extra data update but setSelection is handled on set property. And extra data update will be handled after all properties are handled. Since selection and text has dependency, move selection to extra data update as well.
Changelog:
----------
[Android] [Fixed] - Fix crash when set text and selection on textinput at the same time
Pull Request resolved: https://github.com/facebook/react-native/pull/22723
Differential Revision: D14783791
Pulled By: cpojer
fbshipit-source-id: a4065f3e151d23f4813d76e91d68362cfd4daaf4
Summary:
Try to prevent the crash described in https://github.com/facebook/react-native/issues/17530
There seems to be a bug in `Drawable.mutate()` in some devices/android os versions even after you check the constant state. This error is hard to reproduce and to fix, so just try to catch the exception to prevent crash.
[Android][Fixed] Prevent random crash when setting underlineColorAndroid
Pull Request resolved: https://github.com/facebook/react-native/pull/24183
Differential Revision: D14710484
Pulled By: cpojer
fbshipit-source-id: 3af20a5cb0ecd40839beaf85118c0f5aa6905414
Summary:
Potential breaking change: The signature of ReactShadowNode's onBeforeLayout method was changed
- Before: public void onBeforeLayout()
- After: public void onBeforeLayout(NativeViewHierarchyOptimizer nativeViewHierarchyOptimizer)
Implements same feature as this iOS PR: https://github.com/facebook/react-native/pull/7304
Previously, only Text and Image could be nested within Text. Now, any view can be nested within Text. One restriction of this feature is that developers must give inline views a width and a height via the style prop.
Previously, inline Images were supported via FrescoBasedReactTextInlineImageSpan. To get support for nesting views within Text, we create one special kind of span per inline view. This span is called TextInlineViewPlaceholderSpan. It is the same size as the inline view. Its job is just to occupy space -- it doesn't render any visual. After the text is rendered, we query the Android Layout object associated with the TextView to find out where it has positioned each TextInlineViewPlaceholderSpan. We then position the views to be at those locations.
One tricky aspect of the implementation is that the Text component needs to be able to render native children (the inline views) but the Android TextView cannot have children. This is solved by having the native parent of the ReactTextView also host the inline views. Implementation-wise, this was accomplished by extending the NativeViewHierarchyOptimizer to handle this case. The optimizer now handles these cases:
- Node is not in the native tree. An ancestor must host its children.
- Node is in the native tree and it can host its own children.
- (new) Node is in the native tree but it cannot host its own children. An ancestor must host both this node and its children.
I added the `onInlineViewLayout` event which is useful for writing tests for verifying that the inline views are positioned properly.
Limitation: Clipping
----------
If Text's height/width is small such that an inline view doesn't completely fit, the inline view may still be fully visible due to hoisting (the inline view isn't actually parented to the Text which has the limited size. It is parented to an ancestor which may have a different clipping rectangle.). Prior to this change, layout-only views had a similar limitation.
Pull Request resolved: https://github.com/facebook/react-native/pull/23195
Differential Revision: D14014668
Pulled By: shergin
fbshipit-source-id: d46130f3d19cc83ac7ddf423adcc9e23988245d3
Summary: This diff fixes an IllegalStateException that is thrown when the user click is on a edit text and tap 'Next' on the keyboard to focus on the next view, but the next view is hidden.
Reviewed By: lunaleaps, mmmulani
Differential Revision: D14598410
fbshipit-source-id: 2999cc468ed24bedff163eedcfaec50f6ee005d6
Summary:
Google recommends to use Gravity.START and Gravity.END instead of Gravity.LEFT and Gravity.RIGHT to support RTL better.
[Android] [Changed] - Improve RTL support
Pull Request resolved: https://github.com/facebook/react-native/pull/24069
Differential Revision: D14541569
Pulled By: cpojer
fbshipit-source-id: 5c104d8bd666e1270d5410216c7f2efa6152692a
Summary:
This diff migrates RN to AndroidX.
As part of this diff I disabled few tests in RNAndroid OSS that will be re-enabled this week. As part of the refactor of BUCK files in OSS
Reviewed By: shergin
Differential Revision: D14200097
fbshipit-source-id: 932fcae251d1553e672acd67ecd0e703dcb364aa
Summary:
Autofill Hints were added in [Android API 26](https://developer.android.com/reference/android/view/View.html#setAutofillHints(java.lang.String...)). Without this runtime check, pre-26 devices will crash.
[Android][Fixed] - Fixes crash on pre-26 Android devices when setting text content type
Reviewed By: lunaleaps
Differential Revision: D14479468
fbshipit-source-id: 238c1efd6aea682a93ecb45e1123aaed6bdcd9e3
Summary:
Clearing the android TextInput text programmatically (i.e. calling: this.textInputRef.clear()) does not clear the previously composing text, if enabled, causing inconveniences when such behaviour is desired (i.e. chat input box, where you constantly have to clear the input after sending a message). Instead, the currently observed behaviour is that, after a new text is entered (usually as soon as the first letter), the previously composing text reappears making the input unusable.
The effect is only observable on some devices, for example, we observed it on Samsung S6 devices using both Android 6 and 7, and several LG devices running Android 6.
This issue is only present when clearing the text; setting text to some other value does not produce the same effect.
<!--
Required: Write your motivation here.
If this PR fixes an issue, type "Fixes #issueNumber" to automatically close the issue when the PR is merged.
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/18859
Differential Revision: D14067144
Pulled By: hramos
fbshipit-source-id: 09f337edc026b83221f8a399749222cd75457ec7
Summary:
Native Android sets the EditText widget to multiline only if the InputType flags are set to Text (or its variants like textEmailAddress) and Multiline, which causes the React Native TextInput to not break the line when set to multiline={true} and keyboardType={'numeric'} as it only have the flags Multiline and Number set.
This fix forces the widget to enable multiline, by calling setSingleLine(false) everytime a state change needs to be commited and the multiline prop is set to true.
Pull Request resolved: https://github.com/facebook/react-native/pull/21884
Differential Revision: D14162701
Pulled By: cpojer
fbshipit-source-id: b7d3fc8c5a4444dcfd29ad74d515a8ae486c7ede
Summary:
In API 26, autofill framework was introduced in Android.
Read more about Autofill at https://developer.android.com/guide/topics/text/autofill.
Now, if in case for some text input if developer wants to disable
autofill then he can take help from this `importantForAutoFill` prop
and pass `no` to it.
Also important of auto fill can be configured with this prop, like:
* `auto`: Let the Android System use its heuristics to determine if the view is important for autofill.
* `no`: This view isn't important for autofill.
* `noExcludeDescendants`: This view and its children aren't important for autofill.
* `yes`: This view is important for autofill.
* `yesExcludeDescendants`: This view is important for autofill, but its children aren't important for autofill.
Default value if `auto`.
Read more at: https://developer.android.com/guide/topics/text/autofill-optimize
Changelog:
----------
[Android] [Added] - Add prop to configure `importantForAutofill` in `TextInput`.
Pull Request resolved: https://github.com/facebook/react-native/pull/22763
Differential Revision: D14121242
Pulled By: cpojer
fbshipit-source-id: aa4360480dd19f6dde66f0409d26a41a6a318c94
Summary:
TL;DR: Setting `autoComplete` will allow the system to suggest autofill options for the `<TextInput>` component.
Android Oreo introduced the AutoFill Framework, for secure communication between an app and autofill services (e.g. Password managers). When using `<TextInput>` on Android Oreo+, the system already tries to autofill (based on heuristics), but there is no way to set configuring options or disable.
The quick solution would be to just add the same Android attributes (`autofillHints` & `importantForAutofill`) in React Native TextInput, but that doesn't bond well with the cross-platform nature of the library.
Introduces an `autoComplete` prop based on HTML's `autocomplete` attribute, mapping to Android `autofillHints` & `importantForAutofill` and serving as a proper placeholder for autofill/autocomplete in other platforms:
Also gives you the ability to disable autofill by setting autocomplete="off".
Pull Request resolved: https://github.com/facebook/react-native/pull/21575
Differential Revision: D14102949
Pulled By: hramos
fbshipit-source-id: 7601aeaca0332a1f3ce8da8020dba037b700853a
Summary:
Basically I want my cursor to be the same color of the text. Which means obviously that selecting the text will make it invisibible (ie, red text on red selection rectangle)
Today, setting a selection color does set a cursor color, which may be a good default in some cases, but we don't always couple these 2 colors together.
See original commit of janicduplessis https://github.com/facebook/react-native/commit/ae57b25134c4db8be8539a0f0e6e52d46c850339
I'd like to be able to set different colors for selection and cursor.
Pull Request resolved: https://github.com/facebook/react-native/pull/20276
Differential Revision: D14102952
Pulled By: cpojer
fbshipit-source-id: 652ff782044277a0c8a821dd628f0373659a7850
Summary:
Fix lint errors and warning, which might be a cause of various crashes on older Android OS, using Android Support Library.
```bash
./gradlew :ReactAndroid:lint
```
[Android] [Changed] - fix lint error/warnings
Pull Request resolved: https://github.com/facebook/react-native/pull/23333
Differential Revision: D14019322
Pulled By: mdvacca
fbshipit-source-id: 74c98da269c318cf3b114c8d9c876186369f2b8c
Summary:
React Native's minSdkVersion is 16, or we support Android versions 16 (Jelly Bean) and above. But in the code we have many checks if Android is Jelly Bean or newer, which are unnecessary. This PR removes unnecessary Android version checks, also uses Android version names instead of numbers.
[Android] [Changes] - remove unnecessary Android version checks
Pull Request resolved: https://github.com/facebook/react-native/pull/23277
Differential Revision: D13955909
Pulled By: cpojer
fbshipit-source-id: 6b1caa5ef4fe42273d3c69a6617fff140a697b5c
Summary:
Equivalent of this iOS PR: https://github.com/facebook/react-native/pull/20915
Motivation:
----------
Whenever a user changes the system font size to its maximum allowable setting, React Native apps that allow font scaling can become unusable because the text gets too big. Experimenting with a native app like iMessage on iOS, the font size used for non-body text (e.g. header, navigational elements) is capped while the body text (e.g. text in the message bubbles) is allowed to grow.
This PR introduces a new prop on `<Text>` and `<TextInput>` called `maxFontSizeMultiplier`. This enables devs to set the maximum allowed text scale factor on a Text/TextInput. The default is 0 which means no limit.
Pull Request resolved: https://github.com/facebook/react-native/pull/23069
Differential Revision: D13748513
Pulled By: mdvacca
fbshipit-source-id: 8dd5d6d97bf79387d9a2236fa2e586ccb01afde9
Summary:
For certain style props, each time any style prop changed, the previous version of the style would remain. For example, if you passed `"underline"` for `textDecorationLine` on a `TextInput` and then later passed `undefined` for `textDecorationLine`, the underline would remain.
We solved this problem before in https://github.com/facebook/react-native/commit/de586bfa186289114974674bc2aece462f40393e. The fix was to use `manageSpans` to remove the old spans we added before adding the new spans. However, that fix hardcoded the list of spans to remove. Every span type that was introduced since that commit is affected by this bug:
- CustomLetterSpacingSpan
- CustomLineHeightSpan
- CustomTextTransformSpan
- ShadowStyleSpan
- StrikethroughSpan
- UnderlineSpan
- TextInlineImageSpan
The reason this bug was reintroduced is `ReactBaseTextShadowNode` is responsible for adding spans and `ReactEditText` is responsible for removing spans. These classes fell out of sync.
This fix attempts a more robust solution. Every span that React Native adds to text now implements the `ReactSpan` interface. `manageSpans` deletes all spans that React Native adds by targeting the ones that implement `ReactSpan`. `ReactBaseTextShadowNode.SetSpanOperation` has been updated so that it's a compiler error to add a span that doesn't implement `ReactSpan`.
Pull Request resolved: https://github.com/facebook/react-native/pull/22994
Differential Revision: D13727580
Pulled By: mdvacca
fbshipit-source-id: 07b2eb08832efafb6c2806aa3329f0e9466b09fb
Summary:
If you set `letterSpacing` on an outer text and then set `fontSize` on an inner text, the wrong `letterSpacing` will be rendered.
Here's an example:
```
<Text style={{ fontSize: 10, letterSpacing: 10 }}>
<Text style={{ fontSize: 20 }}>Some text</Text>
</Text>
```
`fontSize` affects letter spacing. In this case, the bug is that setting `fontSize` to `20` doesn't cause the letter spacing to be recalculated.
Notice that the logic for applying letter spacing only applies it if the node has a different value for `getEffectiveLetterSpacing()` than its parent. The problem is that `getEffectiveLetterSpacing()` doesn't represent the final letter spacing value -- it doesn't take `fontSize` into account. Consequently, it sometimes incorrectly skips applying letter spacing as illustrated above.
The fix is to ensure `getEffectiveLetterSpacing()` represents the final rendered letter spacing value. To do this, some of the letter spacing calculation code was moved from `CustomLetterSpacingSpan` to `getEffectiveLetterSpacing()`.
Pull Request resolved: https://github.com/facebook/react-native/pull/22993
Differential Revision: D13671505
Pulled By: cpojer
fbshipit-source-id: 400f36d3fd71ab7cb6cba8508baa71f2973f8f0e
Summary:
Currently, the `TextInput's` placeholder is always sized as though `allowFontScaling` is `true`.
Note that `allowFontScaling` works fine for the content of the `TextInput`. The reason is that we set the font size in two places: in the shadow node and in the Android view. The shadow node logic determines the size of the content and the Android view logic determines the size of the placeholder. The handler for the `allowFontScaling` prop is only present in the shadow node logic. Consequently, the Android view logic always uses the default value of `true` for the `allowFontScaling` prop.
The fix is to add logic for handling the `allowFontScaling` prop to the Android view.
It would be great if we could handle all text props in one spot instead of duplicating code between the shadow node and the Android view. That would eliminate this whole class of bugs. However, I don't have enough familiarity with the history of this code to know how hard that would be or if it's even possible.
Fixes#18827.
Pull Request resolved: https://github.com/facebook/react-native/pull/22992
Differential Revision: D13671400
Pulled By: cpojer
fbshipit-source-id: 40bae3cfb0ca6298e91a81c05211538935f5a0e8
Summary:
Purpose
----------
This commit fixes a bug and prepares us for adding support for the `maxContentSizeMultiplier` prop (it's currently only supported on iOS).
Details
----------
Today we don't explicitly track inheritance of text props. Instead we rely on `SpannableStringBuilder` to handle this for us. Consider this example:
```
<Text style={{fontSize: 10}}>
<Text style={{letterSpacing: 5}}>
...
</Text>
</Text>
```
In today's implementation, the inner text doesn't know about `fontSize` (i.e. its `mFontSize` instance variable is `Float.NaN`). But everything works properly because the outer `Text` told `SpannableStringBuilder` to apply the font size across the entire string of text.
However, today's approach breaks down when computing the value to apply to the `SpannableStringBuilder` depends on multiple props. Suppose that RN Android supported the `maxContentSizeMultiplier` prop. Then calculating the font size to apply to the `SpannableStringBuilder` would involve both the `fontSize` prop and the `maxContentSizeMultiplier` prop. If `fontSize` was set on an outer `Text` and `maxContentSizeMultiplier` was set on an inner `Text` then the inner `Text` wouldn't be able to calculate the font size to apply to the `SpannableStringBuilder` because the outer `Text's` `fontSize` prop isn't available to it.
The `TextAttributes` class solves this problem. Every `Text` has a `TextAttributes` instance which stores its text props. During rendering, a child's `TextAttributes` is combined with its parent's and handed down the tree. In this way, during rendering a `Text` has access to the relevant text props from itself and its ancestors.
This design is inspired by the [`RCTTextAttributes`](https://github.com/facebook/react-native/blob/7197aa026b6d262faa8f4dc6bb3e591f860cdc95/Libraries/Text/RCTTextAttributes.m) class from RN iOS.
Bug Fix
----------
This refactoring happens to fix a bug. Today, when setting `fontSize` on nested Text, `allowFontScaling` is always treated as though it is true regardless of the value on the root `Text`. For example, the following snippets should render "hello" identically, Instead, the bottom snippet renders "hello" as though `allowFontScaling` is true.
```
<Text allowFontScaling={false} style={{fontSize: 50}}>hello</Text>
<Text allowFontScaling={false}><Text style={{fontSize: 50}}>hello</Text></Text>
```
(The repro assumes you've increased your device's font setting so that the font size multiplier is not 1.0.)
Introducing the `TextAttributes` class fixed this. It forced us to think about how inheritance should work for `allowFontScaling`. In the new implementation, `Text` components use the value of `allowFontScaling` from the outermost `Text` component. This matches the behavior on iOS (the `allowFontScaling` prop gets ignored on virtual text nodes because it doesn't appear [in this list](https://github.com/facebook/react-native/blob/3749da13127cb7455d533cb2bc5f2cf37470c0c7/Libraries/Text/Text.js#L266-L269).)
Pull Request resolved: https://github.com/facebook/react-native/pull/22917
Reviewed By: mdvacca
Differential Revision: D13630235
Pulled By: shergin
fbshipit-source-id: e58f458de4fc3cdcbec49c8e0509da51966ef93c
Summary: Simplifying our OSS enums (remove private variables and methods) so that redex can more easily optimize them for us.
Reviewed By: achen1, Feng23
Differential Revision: D9812796
fbshipit-source-id: 11a8272db41ff04399d1cdf366e28ddf1b07b7be
Summary: This diff removes the Fabric Android implementation in favor of Fabric C++, as part of another diff I'm going to move the fabricxx package into fabric package
Reviewed By: shergin
Differential Revision: D9841240
fbshipit-source-id: c7922b7bfb9885f33b1f52237ec7cf00c1df96fb
Summary: This change drops the year from the copyright headers and the LICENSE file.
Reviewed By: yungsters
Differential Revision: D9727774
fbshipit-source-id: df4fc1e4390733fe774b1a160dd41b4a3d83302a
Summary:
Problem: The first ReactTextInputShadowNode layout calculation didn't consider the placeholder. When the layout with placeholder was actually being measured, its height was constraint by the previously calculated height, causing long placeholder content to be clipped.
Fix: Access the placeholder property in ReactTextInputShadowNode, set the dummyEditText's hint with placeholder before ReactTextInputShadowNode's first measurement.
Reviewed By: mdvacca
Differential Revision: D8903108
fbshipit-source-id: 8f3e518d0395ac875807f9ea989a0b5bbe4b2a26
Summary:
<!--
Required: Write your motivation here.
If this PR fixes an issue, type "Fixes #issueNumber" to automatically close the issue when the PR is merged.
-->
There are some bugs surrounding the use of unicode characters that are causing issues with `onKeyPress` on Android: see https://github.com/facebook/react-native/issues/18405#issuecomment-373624413.
We disable the creation and use of `ReactEditTextInputConnectionWrapper` unless the onKeyPress prop is specified, so that this code is 'opt-in' & not a general regression for every use of the TextInput.
N.B. it seems to introduce a lot of unnecessary code complexity to allow for enabling/disabling the onKeyPress events after a InputConnection has been created in `onCreateInputConnection` when the keyboard focusses (a new input connection is created whenever a TextInput gains focus) so I opted not to for simplicity's sake.
Build & debug RNTest app, verify ReactEditTextInputConnectionWrapper code not executed if onKeyPress function not specified.
<!--
Required: Write your test plan here. If you changed any code, please provide us with
clear instructions on how you verified your changes work. Bonus points for screenshots and videos!
-->
[ANDROID] [BUGFIX] [TextInput] - Disable TextInput onKeyPress event from being fired unless callback specified.
Closes https://github.com/facebook/react-native/pull/18443
Differential Revision: D8149625
Pulled By: hramos
fbshipit-source-id: cdf28141d71cdedd67a6ef350e3a3b955f97e340
Oleksandr Melnykov
Eli White
Emily Janzer
valerio.ponte
Vojtech Novak
Uilque Messias
Piotr Trocki
Kevin Gozali
Christoph Nakazawa
Rick Ratmansky
Dulmandakh
YuTeh Shen
Sunny Luo
Adam Comella
David Vacca
Héctor Ramos
Luna Wei
Vishwesh Jainkuniya
mannol
Murilo Araujo
Cassio Zen
Sébastien Lorber
Jonathan Kim
Jiaqi Wu
Noam Schachter
Jens Panneel
Andrew Chen (Eng)
Josh Hargreaves
