Summary:
Cleans up the Flow types for React Native ViewConfig. After this diff, we will have two new canonical types:
- `ViewConfig` which is what we get from native and what is registered in the `ReactNativeViewConfigRegistry`.
- `PartialViewConfig` which is what we generate statically and augment at runtime before registering with the `ReactNativeViewConfigRegistry`.
Changelog:
[Internal]
Reviewed By: JoshuaGross
Differential Revision: D25075299
fbshipit-source-id: 4b53927b2db437b615447b711e83db355d0cfa55
Summary: This completes the Picker stack. Use a handwritten view config to avoid calling `requireNativeComponent` in Bridgeless mode.
Differential Revision: D23663596
fbshipit-source-id: 5d0811014fd6f66956803a1db5fee8fd1119d5bc
Summary:
This builds on the last diff to remove type a type union from Picker. This diff focuses on Picker internals.
Changelog: [JS] Remove type union in PickeriOS/PickerNativeComponent
Reviewed By: sammy-SC
Differential Revision: D24254615
fbshipit-source-id: f788a2e123135c1e8b9909870c40f53b2dea0227
Summary:
Flow type unions don't play well with Fabric components. This diff removes a union in `Picker.js` and fixes all the flow errors.
Before this diff, all these surfaces would crash with the new Fabric Picker impl, because the impl asserts that this field is a string.
Reviewed By: sammy-SC
Differential Revision: D24236317
fbshipit-source-id: 6e646c84fcd16658aaabe5e93507f5f33b346a65
Summary:
telling native that `selected` is the new selection is basically ignoring the most recent user input and resetting it back to the previous value. the reason it flips back and forth is that by the next time `onSelect` is called, the above code has updated the value of `selected` (line 63)
Changelog:
[Android] [Fixed] Picker - fix usage of setNativeSelectedPosition in onSelect
Reviewed By: mdvacca
Differential Revision: D22022456
fbshipit-source-id: fe51f9cbd712b5578e9fd9ea2992bd12d48f4ec4
Summary:
This diff makes the ColorValue export "official" by exporting it from StyleSheet in order to encourage its use in product code.
Changelog: Moved ColorValue export from StyleSheetTypes to StyleSheet
Reviewed By: TheSavior
Differential Revision: D21076969
fbshipit-source-id: 972ef5a1b13bd9f6b7691a279a73168e7ce9d9ab
Summary:
This gets us on the latest Prettier 2.x:
https://prettier.io/blog/2020/03/21/2.0.0.html
Notably, this adds support for TypeScript 3.8,
which introduces new syntax, such as `import type`.
Reviewed By: zertosh
Differential Revision: D20636268
fbshipit-source-id: fca5833d003804333a05ba16325bbbe0e06d6c8a
Summary:
add support to the android implementation of the Picker component for setting the background color.
Changelog: [Android] [Added] - Support item background color in Dialog Picker
Differential Revision: D20566131
fbshipit-source-id: d693b40803fa1051ec955c5728994c820fecd9e9
Summary:
This Pull Request implements the PlatformColor proposal discussed at https://github.com/react-native-community/discussions-and-proposals/issues/126. The changes include implementations for iOS and Android as well as a PlatformColorExample page in RNTester.
Every native platform has the concept of system defined colors. Instead of specifying a concrete color value the app developer can choose a system color that varies in appearance depending on a system theme settings such Light or Dark mode, accessibility settings such as a High Contrast mode, and even its context within the app such as the traits of a containing view or window.
The proposal is to add true platform color support to react-native by extending the Flow type `ColorValue` with platform specific color type information for each platform and to provide a convenience function, `PlatformColor()`, for instantiating platform specific ColorValue objects.
`PlatformColor(name [, name ...])` where `name` is a system color name on a given platform. If `name` does not resolve to a color for any reason, the next `name` in the argument list will be resolved and so on. If none of the names resolve, a RedBox error occurs. This allows a latest platform color to be used, but if running on an older platform it will fallback to a previous version.
The function returns a `ColorValue`.
On iOS the values of `name` is one of the iOS [UI Element](https://developer.apple.com/documentation/uikit/uicolor/ui_element_colors) or [Standard Color](https://developer.apple.com/documentation/uikit/uicolor/standard_colors) names such as `labelColor` or `systemFillColor`.
On Android the `name` values are the same [app resource](https://developer.android.com/guide/topics/resources/providing-resources) path strings that can be expressed in XML:
XML Resource:
`@ [<package_name>:]<resource_type>/<resource_name>`
Style reference from current theme:
`?[<package_name>:][<resource_type>/]<resource_name>`
For example:
- `?android:colorError`
- `?android:attr/colorError`
- `?attr/colorPrimary`
- `?colorPrimaryDark`
- `android:color/holo_purple`
- `color/catalyst_redbox_background`
On iOS another type of system dynamic color can be created using the `IOSDynamicColor({dark: <color>, light:<color>})` method. The arguments are a tuple containing custom colors for light and dark themes. Such dynamic colors are useful for branding colors or other app specific colors that still respond automatically to system setting changes.
Example: `<View style={{ backgroundColor: IOSDynamicColor({light: 'black', dark: 'white'}) }}/>`
Other platforms could create platform specific functions similar to `IOSDynamicColor` per the needs of those platforms. For example, macOS has a similar dynamic color type that could be implemented via a `MacDynamicColor`. On Windows custom brushes that tint or otherwise modify a system brush could be created using a platform specific method.
## Changelog
[General] [Added] - Added PlatformColor implementations for iOS and Android
Pull Request resolved: https://github.com/facebook/react-native/pull/27908
Test Plan:
The changes have been tested using the RNTester test app for iOS and Android. On iOS a set of XCTestCase's were added to the Unit Tests.
<img width="924" alt="PlatformColor-ios-android" src="https://user-images.githubusercontent.com/30053638/73472497-ff183a80-433f-11ea-90d8-2b04338bbe79.png">
In addition `PlatformColor` support has been added to other out-of-tree platforms such as macOS and Windows has been implemented using these changes:
react-native for macOS branch: https://github.com/microsoft/react-native/compare/master...tom-un:tomun/platformcolors
react-native for Windows branch: https://github.com/microsoft/react-native-windows/compare/master...tom-un:tomun/platformcolors
iOS
|Light|Dark|
|{F229354502}|{F229354515}|
Android
|Light|Dark|
|{F230114392}|{F230114490}|
{F230122700}
Reviewed By: hramos
Differential Revision: D19837753
Pulled By: TheSavior
fbshipit-source-id: 82ca70d40802f3b24591bfd4b94b61f3c38ba829
Summary:
The [PlatformColor PR](https://github.com/facebook/react-native/pull/27908) is currently open to implement the [PlatformColor proposal](react-native-community/discussions-and-proposals#126). When that PR was imported into Facebooks internal builds it was found that the change to the `processColor()` function to return an opaque type or `number` instead of just `number` breaks internal components.
This PR is a simplification of the PlatformColor PR only changing the return type of `processColor()` from `?number` to `?number | NativeColorType` where `NativeColorType` is just an empty but opaque type. This will allow changes to be made to these internal components but with less risk than the larger PR.
## Changelog
[General] [Changed] - Add NativeColorType opaque type to normalizeColor() ahead of PlatformColor PR
Pull Request resolved: https://github.com/facebook/react-native/pull/28040
Test Plan: Flow checks, Jest test, iOS unit tests, iOS integration tests, and manual testing performed on RNTester for iOS and Android.
Differential Revision: D19860205
Pulled By: TheSavior
fbshipit-source-id: 799662c6621d3974158b375ccccfa136982c43b4
Summary:
Fabric doesn't support setNativeProps, so we are using view commands instead.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18044169
fbshipit-source-id: d5f199b930244d02f174ea8a7ef732e9a8ef2476
Summary:
With a Picker we would like to allow accessibility labels to be passed as a prop for situations where we want go give more detail. For example if we have a number picker that will be used for a timer instead of just saying 3, we might want to say 3 hours.
## Changelog
[General] [Added] - Picker test with an accessibility label prop
[General] [Added] - Support for accessibility Label prop to the Picker component
Pull Request resolved: https://github.com/facebook/react-native/pull/27342
Test Plan: Test plan is testing in RNTester making sure the examples work
Differential Revision: D18770184
Pulled By: hramos
fbshipit-source-id: e6f8ab4a9c50f3fb46342198441ecc71394913d3
Summary:
By depending on react-native, these files can't be flow strict until index.js is flow strict. By depending on the internals directly they can be flow strict as soon as their dependents are flow strict.
Changelog:
[Internal] Refactoring some core file imports to depend on internals directly
Reviewed By: zackargyle
Differential Revision: D18828324
fbshipit-source-id: 2a347c4e234a64edbb3e6f0ef6387ef1ce78badc
Summary:
Changelog: [Internal]
Fixing a red screen on the RN picker.
Looks like the picker gets confused when for unknown reasons a native value is undefined. In that case we stick to the JS value as it is specified in the comment.
https://fb.workplace.com/groups/rn.support/permalink/2997783536936908/
NOTE : Native fix was landed, this add an extra layer on the JS side
Reviewed By: mmmulani
Differential Revision: D18443005
fbshipit-source-id: 9511ac90f2d9e6186c6c0de3b673cc535cdb9fa6
Summary:
These tests need to be consistent with every test so a helper makes more sense.
Changelog: [Internal]
Reviewed By: rickhanlonii
Differential Revision: D18500439
fbshipit-source-id: de535156d370102bad88e556ad3d2a0d5443e4e2
Summary:
Fabric doesn't support setNativeProps, so we have to use commands instead to set the value of the native component.
Changelog: [Android] [Added] - Add setNativeSelectedPosition command to ReactPickerManager
Reviewed By: mdvacca
Differential Revision: D18007791
fbshipit-source-id: dfa26792205189a336ab43b1c51f43f8f57c8e72
Summary:
We are moving away from `setNativeProps` in favour of commands API.
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D17765031
fbshipit-source-id: fcfe3fe68abb3e49e2dd7a102db598ade749acde
Summary:
In previous implementation, `setNativeProps` was called before `render`. These two methods can change value of `selectedIndex` and it matters in which order they arrive in native.
This was fine in Paper because 1st selectedIndex is set from `setNativeProps` with wrong value and then correct value comes from props.
However in Fabric, 1st selectedIndex comes from props (this is the correct one), and 2nd comes from command which has the incorrect value.
changelog: [internal]
Reviewed By: TheSavior
Differential Revision: D18240118
fbshipit-source-id: dca897306d3e858b9175b2f81356c76f5a0f79e2
Summary:
These were being cast to a NativeComponent but that is no longer accurate. `requireNativeComponent` returns the type of `HostComponent` now which is more accurate. We don't need the cast through `any` anymore.
In order to know that I found all the callsites, I ran this command to find these:
```
grep -r "requireNativeComponent" react-native-github -C 5 | grep 'any'
```
Changelog:
[Internal]
Reviewed By: cpojer
Differential Revision: D17864165
fbshipit-source-id: 3774d6d47d7bb0d885cc1a1352f81fec7d3bca0d
Summary: Props are being ignored on native side, let's get rid of them.
Reviewed By: TheSavior
Differential Revision: D17765185
fbshipit-source-id: d3625dd25d2e41a49e701d54fe9a7b74cd47786c
Summary:
The stack of D17563110 was reverted because it triggered a failing OTA job that wasn't caught at land time.
Fixing the issue by reverting the change to `Route.js` and re-landing the rest of the diff.
Differential Revision: D17564219
fbshipit-source-id: 166b50a163ce8ae226de224882a98c40652e29ac
Summary:
`WithDefault` appears not to be required to be prefixed with `?` because it's option value per se.
Fixed tests, removed `?` where needed, updated snapshots and review them. Added mechanism fro throwing error when `?WithDefault` found. Add tests for it.
Reviewed By: rubennorte
Differential Revision: D16048463
fbshipit-source-id: f55ed7454aacf0b8c42944a9b5c1037ad1b360fe
Summary:
It's not needed to keep required providing default values even if they are not actually relevant.
Here I add a support for `null`, `0` of `false` instead by default and remove throwing errors if no other default value provided.
Reviewed By: rubennorte
Differential Revision: D16049047
fbshipit-source-id: bc4961af3873190568f2753fc4ec975354896df5
Summary:
It appears that `(e: BubblingEvent<T>) = mixed` exists only in given context and it's pointless to keep in this way. It could be simplified to `BubblingEventHandler<T>` without any negative consequences and that's the motivation of this diff.
The only tradeoff of this decision is leaving an opportunity to declare Bubbling/Direct event in the top of the file bc then analysing the code becomes much more difficult. However, it's not used anywhere so it's not a problem now and probably any time.
Also, changes the names to `DirectEventHandler` and `BubblingEventHandler` which are more related to current state. The names were updated in many places in code.
Reviewed By: rubennorte
Differential Revision: D16054571
fbshipit-source-id: 741d075eb46b80bac8eb73a6b30fc0b448cb3902
Summary:
Cleans up the implementation of `AndroidPicker` and the Flow types for the native components to almost work with `codegenNativeComponent`.
The remaining blocker is that the `items` prop is an array of objects: https://fburl.com/km8uj8x2
Reviewed By: rickhanlonii
Differential Revision: D15805611
fbshipit-source-id: 34bea83db8dbaaf6eb23b00e73e0c7ce292e8a32
Summary:
This is the next step in moving RN towards standard path-based requires. All the requires in `Libraries` have been rewritten to use relative requires with a few exceptions, namely, `vendor` and `Renderer/oss` since those need to be changed upstream. This commit uses relative requires instead of `react-native/...` so that if Facebook were to stop syncing out certain folders and therefore remove code from the react-native package, internal code at Facebook would not need to change.
See the umbrella issue at https://github.com/facebook/react-native/issues/24316 for more detail.
[General] [Changed] - Migrate "Libraries" from Haste to standard path-based requires
Pull Request resolved: https://github.com/facebook/react-native/pull/24749
Differential Revision: D15258017
Pulled By: cpojer
fbshipit-source-id: a1f480ea36c05c659b6f37c8f02f6f9216d5a323
Summary:
`OnValueChange` function of `Picker` is called when Picker is initialized.
[Android][fixed] - `OnValueChange` will be called only when the `selectedValue` changes.
Pull Request resolved: https://github.com/facebook/react-native/pull/24653
Differential Revision: D15146483
Pulled By: cpojer
fbshipit-source-id: e26f5aa4caa673015c50c853f00b99572e803755
Summary:
Per conversation with TheSavior, in #24538, this adds snapshot tests for more components. Shallow and deep snapshots are included.
[General] [Added] - Snapshots
Pull Request resolved: https://github.com/facebook/react-native/pull/24593
Differential Revision: D15082831
Pulled By: TheSavior
fbshipit-source-id: bc7f27317e2fd0bad133f4ba4d81996d08a12c44
Summary:
when conditional rendering is used then picker breaks when the child is null in iOS
This conditional rendering inside Picker fails when "someBooleanValue" variable is false
```
{
this.state.someBooleanValue && <Picker.Item label="value" value="value" />
}
```
[iOS] [Fixed] - null check on children by using filter
Pull Request resolved: https://github.com/facebook/react-native/pull/24057
Differential Revision: D14538337
Pulled By: cpojer
fbshipit-source-id: d9324671931b5f1dac65d8058d9aa957b650af25
Summary:
On conditional rendering if child is null then the PickerAndroid breaks.
when conditional rendering is used then picker breaks when the child is null.
This conditional rendering inside Picker fails when a is 1, because child will be null in PickerAndroid.android.js.
```
{
this.state.a === 2 && <Picker.Item label="value" value="value" />
}
```
[ANDROID] [FIXED] - Filter props.children.
Pull Request resolved: https://github.com/facebook/react-native/pull/23884
Differential Revision: D14436860
Pulled By: cpojer
fbshipit-source-id: 6a8fca604acf77c20729f26a53cd7f67e514deac
Summary:
when conditional rendering is used then picker breaks when the child is null.
This conditional rendering inside Picker fails when a is 1, because child will be null in PickerAndroid.android.js.
```
{
this.state.a === 2 && <Picker.Item label="value" value="value" />
}
```
[ANDROID] [FIXED] - When child is null it returns.
Pull Request resolved: https://github.com/facebook/react-native/pull/23748
Differential Revision: D14319140
Pulled By: cpojer
fbshipit-source-id: 07d48cd054a131e6984cfe3bdce7538ffbc50622
Summary:
[iOS] [Changed] - As #22990 said, move requireNativeComponent to a separate file.
I am not familiar with flow, I try to follow the https://pastebin.com/RFpdT76V example but I am not sure I have done it right.
Pull Request resolved: https://github.com/facebook/react-native/pull/22996
Differential Revision: D13697082
Pulled By: cpojer
fbshipit-source-id: c0c87a8e1a7f0553da994aba230f69b496140200
Summary:
Changelog:
----------
[Android] [Fixed] - Fix Picker.onValueChange sometimes not fired due to race condition. Fixes#15556
Root Cause:
------------
Please check my code snippet at https://snack.expo.io/kudochien/android-picker-issue
and try to select different items on Picker to see if console.log() hit.
If calling setState() with some latency, e.g. setTimeout() or changes from redux,
the second time changing picker item on UI, the onValueChange() will be not fired.
The root cause comes from the `forceUpdate` in PickerAndroid.android.js.
If user's setState() update comes after forceUpdate(), the flow will be:
1. First time select picker item
2. onValueChange + forceUpdate
3. user's setState() + componentDidUpdate + setNativeProps({ selected: ... })
4. mSuppressNextEvent = true
5. Second time select picker item
6. Since mSuppressNextEvent is true, the onValueChange will not be fired.
Solution:
---------
Like other controlled components, disable change listener during setup values from JS.
Android Spinner `setSelection(int position)` is asynchronous call, i.e. will fire onItemSelected in next run loop and is not suitable for us.
`setSelection(int position, boolean animate)`, however, is synchronous call which I used.
Some more references about setSelection:
https://stackoverflow.com/a/43512925/2590265http://androidxref.com/8.1.0_r33/xref/frameworks/base/core/java/android/widget/AbsSpinner.java#276
The two arguments version will use `setSelectionInt()` which set mBlockLayoutRequests as true to prevent onItemSelected call from next layout().
I also moved the setOnItemSelectedListener() call after onLayout to prevent onValueChange() during intialization.
Pull Request resolved: https://github.com/facebook/react-native/pull/22821
Differential Revision: D13731979
Pulled By: cpojer
fbshipit-source-id: e06bd9aa62463b66c8f3fd7214485898d5375054
Summary:
Changelog:
----------
[Android] [Changed] - As mentioned in #22990, I have moved native components required by PickerAndroid.android.js into separate files and added Flow Typing.
Pull Request resolved: https://github.com/facebook/react-native/pull/22999
Differential Revision: D13697130
Pulled By: TheSavior
fbshipit-source-id: 42da73d82cca45fefa066871eed5a637811643c8
Summary:
This PR adds e2e tests for the Picker and DatePicker components.
While writing these tests, I also found and fixed two bugs where we wern't passing the `testID` down to the native components, so detox couldn't look them up. This confirms what was mentioned by rotemmiz [here](https://github.com/wix/Detox/issues/798#issuecomment-401412276)
Pull Request resolved: https://github.com/facebook/react-native/pull/22537
Reviewed By: cpojer
Differential Revision: D13371307
Pulled By: rickhanlonii
fbshipit-source-id: a4dfcdb5913645bceca0c7353328eeb9ad0f6558
Summary:
There were approximately 350 unused suppressions in xplat/js when checking with .flowconfig.android
The flow team is partially responsible for this, since our release process hasn't changed since we added the flowconfig. In the diff beneath this one, I added the functionality necessary for us to not add any more unused suppressions. To test it, I made this diff. The steps were:
1. Start iOS server
2. Start android server
3. remove unused ios suppressions
4. remove unused android suppressions
5. add ios suppressions with site=react_native_ios_fb
6. add android suppressions with site=react_native_android_fb
7. remove unused ios suppressions. The ones that are unused are ones where an android comment was inserted as well, since the ios comment no longer is next to the error
8. add suppressions using ios flowconfig with site=react_native_fb
9. remove unused android suppressions. The unused ones are ones that were moved up when the cross-platform suppressions were inserted.
I'm going to make this into a script to make sure we don't contribute anymore unused suppressions from our side.
The controller you requested could not be found. nolint
Reviewed By: TheSavior
Differential Revision: D10053893
fbshipit-source-id: 7bee212062f8b2153c6ba906a30cf40df2224019
Summary: This change drops the year from the copyright headers and the LICENSE file.
Reviewed By: yungsters
Differential Revision: D9727774
fbshipit-source-id: df4fc1e4390733fe774b1a160dd41b4a3d83302a
Tim Yung
Peter Argany
Lulu Wu
Eddie Dugan
Zack Argyle
George Zahariev
Michael Bolin
Tom Underhill
Oleksandr Melnykov
Kevin Gonzales
Eli White
Lucy Beatriz Gomez
Samuel Susla
Andres Suarez
Logan Daniels
Joshua Gross
Michał Osadnik
Sam Goldman
James Ide
A C SREEDHAR REDDY
Brandon Carroll
Rahul kishan M
Chi-AnTai
Kudo Chien
jesse
Rick Hanlon
nd-02110114
Jordan Brown
empyrical
Héctor Ramos
