Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/28058
I'm taking the first step towards supporting iOS 13 UIScene APIs and modernizing React Native not to assume an app only has a single window. See discussion here: https://github.com/facebook/react-native/issues/25181#issuecomment-505612941
The approach I'm taking is to take advantage of `RootTagContext` and passing it to NativeModules so that they can identify correctly which window they refer to. Here I'm just laying groundwork.
- [x] `Alert` and `ActionSheetIOS` take an optional `rootTag` argument that will cause them to appear on the correct window
- [x] `StatusBar` methods also have `rootTag` argument added, but it's not fully hooked up on the native side — this turns out to require some more work, see: https://github.com/facebook/react-native/issues/25181#issuecomment-506690818
- [x] `setNetworkActivityIndicatorVisible` is deprecated in iOS 13
- [x] `RCTPerfMonitor`, `RCTProfile` no longer assume `UIApplicationDelegate` has a `window` property (no longer the best practice) — they now just render on the key window
Next steps: Add VC-based status bar management (if I get the OK on https://github.com/facebook/react-native/issues/25181#issuecomment-506690818 ), add multiple window demo to RNTester, deprecate Dimensions in favor of a layout context, consider adding hook-based APIs for native modules such as Alert that automatically know which rootTag to pass
## Changelog
[Internal] [Changed] - Modernize Modal to use RootTagContext
[iOS] [Changed] - `Alert`, `ActionSheetIOS`, `StatusBar` methods now take an optional `surface` argument (for future iPadOS 13 support)
[iOS] [Changed] - RCTPresentedViewController now takes a nullable `window` arg
[Internal] [Changed] - Do not assume `UIApplicationDelegate` has a `window` property
Pull Request resolved: https://github.com/facebook/react-native/pull/25425
Test Plan:
- Open RNTester and:
- go to Modal and check if it still works
- Alert → see if works
- ACtionSheetIOS → see if it works
- StatusBar → see if it works
- Share → see if it works
Reviewed By: PeteTheHeat
Differential Revision: D16957751
Pulled By: hramos
fbshipit-source-id: ae2a4478e2e7f8d2be3022c9c4861561ec244a26
Summary:
I propose this change because we (and a lot of other people, I'd guess) pass an `async` function as a parameter to `onRefresh`. Because the `async` function returns a `promise`, flow is reporting an error. I think the type checking here can be relaxed either all the way to `any` (because RN does not care here what we return) or to `void | Promise<void>` to account for async functions.
looking at https://github.com/facebook/react-native/commit/fb7b2d353356f67a3149c19ad733d46ec6842767#diff-a9c5687ae65236ba3e7f34bfdcdec81d seems like the second is preferred
## Changelog
[General] [changed] - relax RefreshControl's onRefresh flow typing
Pull Request resolved: https://github.com/facebook/react-native/pull/28167
Test Plan: * flow passes
Reviewed By: hramos
Differential Revision: D20196529
Pulled By: TheSavior
fbshipit-source-id: bb5a314bcfb5fb9c8ab71eccb449f1322aeebacb
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:
We will soon be enforcing that flow suppressions will only apply when on an error's primary location ([post](https://fb.workplace.com/groups/179614562644215/permalink/559286354677032/)). This diff uses the codemod created in D20008770 to move all suppression comments to their primary locations in the `xplat/js` flow root, and deletes suppression comments that are not on any primary locations.
This diff was generated with:
```
~/fbsource/fbcode/flow/packages/flow-dev-tools/bin/tool suppression-primary-locations --json-file ~/www/errors.json ~/fbsource/xplat/js
hg st -n | xargs grep -l -P '@(partially-)?generated' | xargs hg revert
hg st -n | xargs grep -l 'format' | xargs prettier --write
```
Changelog: [Internal]
bypass-lint
Reviewed By: dsainati1
Differential Revision: D20122544
fbshipit-source-id: d94e409aadb18bb399a1ddbf9f3f2494fe4fb54c
Summary:
Use codegen'd ViewCommands added in previous diff as a replacement for setNativeProps.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18619298
fbshipit-source-id: 08069e828e92ac3cca9813bbcdca99d99fb50883
Summary:
The migration from classy to functional component partially broke controlled TextInput selections. This fixes it.
The nuance is that even though we have "event counters" sent from native, "onChange" and "onChangeSelection" are separate events;
so even if you receive new text and a new native event counter, your selection may be out-of-date. Incrementing the event counter
when sending selection events breaks text updates; and adding another native event counter seems like overkill. Instead, in JS, we statefully
keep track of (1) the native event counter, (2) whether or not the selection has been updated for that event counter.
Changelog: [internal]
Reviewed By: mdvacca
Differential Revision: D18867152
fbshipit-source-id: c569ecd03ce0042d6feb5fa8af4c756588607a09
Summary:
We recently updated React Native's docs site to have its own domain reactnative.dev and needed to update the URLs in the source code
CHANGELOG:
[INTERNAL]
Reviewed By: hramos
Differential Revision: D20072842
fbshipit-source-id: 1970d9214c872a6e7abf697d99f8f5360b3b308e
Summary:
*Pressable* is a component which is intended to replace the Touchable* components such as *TouchableWithoutFeedback* and *TouchableOpacity*. The motivation is to make it easier to create custom visual touch feedback so that React Native apps are not easily identified by the “signature opacity fade” touch feedback.
We see this component as eventually deprecating all of the existing Touchable components.
Changelog:
[Added][General] New <Pressable> Component to make it easier to create touchable elements
Reviewed By: yungsters
Differential Revision: D19674480
fbshipit-source-id: 765d657f023caea459f02da25376e4d5a2efff8b
Summary:
motivation: there are cases where one'd like to control the radius of the ripple effect that's present on TouchableNativeFeedback - in my case, I want to make sure that both icons and text have the same ripple appearance, but that's currently not possible as far as I can tell.
Currently (afaik) the only way to set (upper) ripple limits is by specifying width, height and border radius ( + `overflow: hidden`), and this works well for icons which can usually be bounded by a square, but not for text which can have rectangular shape.
This PR adds `rippleRadius` parameter to `SelectableBackground()`, `SelectableBackgroundBorderless()` and `Ripple()` static functions present on `TouchableNativeFeedback`. It can make the ripple smaller but also larger. The result looks like this:
added to RNTester:
difference from the other ripples:
I'm ofc open to changing the api if needed, but I'm not sure there's much space for manoeuvring. While I was at it, I did a slight refactor of the class into several smaller, more focused methods.
It's possible that in some cases, this might help to work around this issue https://github.com/facebook/react-native/issues/6480.
## Changelog
[Android] [Added] - allow setting custom ripple radius on TouchableNativeFeedback
Pull Request resolved: https://github.com/facebook/react-native/pull/28009
Test Plan: I tested this locally using RNTester
Reviewed By: TheSavior
Differential Revision: D20004509
Pulled By: mdvacca
fbshipit-source-id: 10de1754d54c17878f36a3859705c1188f15c2a2
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:
Make iOS use Commands instead of UIManager.{focus,blur}. This makes these apis compatible with Fabric and paper at the same time.
Changelog:
[Internal] Switch iOS focus/blur calls to use new commands
Reviewed By: mdvacca
Differential Revision: D19458995
fbshipit-source-id: 8c4aacd41941f54a887aeec1a17d9ce0b6878ab1
Summary:
This makes Android dispatch focus/blur through the Fabric view manager when running in Fabric.
Changelog:
[Internal] Switch Android focus/blur calls to use new commands
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D19458362
fbshipit-source-id: 23e1d989ec55bc8abff4279e259f4b6c953ac0a3
Summary:
TextInput’s `InputAccessoryView` was using a [deprecated] prop-type as a Flow type, which TheSavior asked me to fix [here](https://github.com/alloy/rn2dts/commit/6ba4b28a22d8c0bd346996d78743016eaae707e1#r37343692).
## Changelog
[iOS] [Fixed] - Fixes the `InputAccessoryView.backgroundColor` prop’s typing to use `ColorValue`.
Pull Request resolved: https://github.com/facebook/react-native/pull/28105
Test Plan:
Passes:
```bash
yarn flow-check-ios
```
Differential Revision: D19956401
Pulled By: TheSavior
fbshipit-source-id: 0c16f292b0143e83235a23712a0a7a11b8317f4e
Summary:
This class is no longer used by the core and thus can be removed.
It isn't exposed as part of our public API so this is technically not a breaking change, although it may still cause people trouble if they are reaching into internals. It is expected that people will use forwardRef instead of this class.
I will follow up this diff with a removal from the ReactNativeRenderer as well.
Changelog:
[Internal] Remove ReactNative.NativeComponent from React Native
Reviewed By: JoshuaGross
Differential Revision: D19888400
fbshipit-source-id: 78da51e6c0edf9d8706395d376c3bfe75dabda03
Summary:
Right now, people are calling `getInnerViewNode` and `getInnerViewRef` to get the ref of the `View` within `ScrollView`. Instead, this change adds a prop to `ScrollView` to give people direct access to that `View` if they need it.
Previous usage:
```
const myRef = React.createRef<React.ElementRef<typeof ScrollView>>();
<ScrollView ref={myRef} />
const innerViewRef = myRef.current.getInnerViewRef();
innerViewRef.measure();
```
New usage:
```
const myRef = React.createRef<React.ElementRef<typeof View>>();
<ScrollView innerViewRef={myRef} />
// now, myRef.current can be used directly as the ref
myRef.current.measure();
```
Changelog:
[Changed][General] ScrollView: Deprecate getInnerViewNode and getInnerViewRef methods. Use innerViewRef={myRef} prop instead.
Reviewed By: TheSavior
Differential Revision: D19713191
fbshipit-source-id: 3304cb94a253dafb458ef49d6331e0e432693431
Summary:
Added description for rejectResponderTermination prop for the TextInput, which seemed to have been deleted.
Descriptions are taken from https://github.com/facebook/react-native/pull/16755/files
## Changelog
[Internal] [Added] - Add description for rejectResponderTermination prop for TextInput
Pull Request resolved: https://github.com/facebook/react-native/pull/28001
Test Plan: This PR only changes comment, which has no effect on actual function.
Differential Revision: D19820886
Pulled By: TheSavior
fbshipit-source-id: 5cbaafcbae0bdbf6932ef9c7c0c1a75cd6d8794e
Summary:
React is way better than it used to be...
Changelog: [Internal]
Reviewed By: zackargyle, lunaleaps
Differential Revision: D19421772
fbshipit-source-id: db82b68a0c2f31e9ef7e1875fd9e4bf27ef6295a
Summary:
All of our other JS view configs are gated by the `RN$Bridgeless` flag. This one has been behind a DEV flag instead. We've been using it in DEV for a long time now, so it's probably ok to be in prod, but I figured it's better to just be consistent with the rest of the native components, since we only need this for bridgeless.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D19669902
fbshipit-source-id: bd28cf84947bfe298efd95ae07e38c2bf4e45091
Summary: `requireNativeComponent` redboxes in bridgeless mode because there is no UIManager. This adds a handwritten view config to avoid using UIManager.
Reviewed By: ejanzer
Differential Revision: D19624044
fbshipit-source-id: 5ae68f63068a131a305754003154ee0cf0f1be46
Summary:
In case when Platform is different from Android or iOS, ScrollView initialised RCTScrollView two times, which caused a crash. It looks for me that default option is obsolete and can be united with iOS one to fix this issue.
## Changelog:
[Internal] [Fixed] - Fixed crash during ScrollView initialisation if Platform.OS is not iOS or Android
Reviewed By: ejanzer
Differential Revision: D19623046
fbshipit-source-id: 84f8a46ea24b463aa6aae761f4386ab7e4e95f9b
Summary:
When I was testing React Native 0.62-rc.1, I noticed that console was showing a warning for Require Cycle as shown in image below
This is because ScrollResponder was importing `ScrollView` to get the `typeof ScrollView`.
I've made an export for ScrollView type in `ScrollView` so that Require cycle warning will not show up.
## Changelog
[General] [Fixed] - Remove Require cycle warning.
Pull Request resolved: https://github.com/facebook/react-native/pull/27851
Differential Revision: D19577644
Pulled By: cpojer
fbshipit-source-id: 257b9421a91244d69394375102cfbe683326bba2
Summary:
Hand-writing a JS view config for AndroidTextInputNativeComponent.
This diff was generated by adding logging to `getNativeComponentAttributes`. Diff preview: https://our.intern.facebook.com/intern/diff/view-version/96875488/
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19456328
fbshipit-source-id: b2d5abd2fde380be182b95881c335d24481343f1
Summary: Changelog: [Fix] Fix status bar color not updating when navigating between two screens with the same status bar color.
Reviewed By: RSNara
Differential Revision: D19439424
fbshipit-source-id: 44388f1f94c87c12102471d72183bb6c152a46b6
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:
As a part of the migration from setNativeProps in Fabric and Paper, we are replacing it by view commands in the RefreshControl component on Android.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18475450
fbshipit-source-id: ad89547fada3444f725fd9b00e8482cfc8f4d7fc
Summary:
As a part of the migration from setNativeProps in Fabric and Paper, we are replacing it by view commands in the Checkbox component on Android.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18451749
fbshipit-source-id: 49d786ef3383df95b10260ba2b7f68489ad31789
Summary:
View should reset whether we are inside of a text or not. For example, inline images should only be rendered inside text, but if we have a view inside text, then it should render a regular image, not an inline image.
This logic *should* exist in native instead of in JS, but this is an easier change for now.
I'm sad to have to turn this back into a JS component instead of just being the string 'RCTView' as this will have performance implications on all surfaces, but this is how it always used to be so maybe it's fine.
This example previously crashed, and no longer does:
```
function PlaygroundContent(props: {}) {
return (
<View style={styles.container}>
<Text>
<View style={{width: 10, height: 10}}>
<Image source={fbicon.filled('chevron-down', 10)} />
</View>
</Text>
</View>
);
}
```
Changelog:
[General][Fixed] Fixes bug where <Text><View><Image> would crash.
Reviewed By: JoshuaGross
Differential Revision: D17564510
fbshipit-source-id: 0ecf49b3d466e7adf57a46a7a097dd3798c721a4
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:
Refactors `Pressability` so that updates to the configuration are now explicitly committed using `configure()`.
Previously, the configuration was updated implicitly because `Pressability` accepted a series of functions whose closures capture values (e.g. `this.props`). Although these changes typically happen when component instances are "atomically" updated by React, it is not a guarantee. For example, arbitrary instance variables could be used to configure `Pressability`, and they could be muted at any time.
This change makes updates to the configuration of `Pressability` more predictable.
Changelog:
[Internal]
Reviewed By: TheSavior
Differential Revision: D18742620
fbshipit-source-id: d2e96dd1e3643289daab2177199a29f80d17b0bc
Summary:
NativeComponent as a type isn't needed now that we have HostComponent
Changelog:
[Internal]
Reviewed By: zackargyle, rickhanlonii
Differential Revision: D18873494
fbshipit-source-id: 5ba3fa25537f8249c80c2303dcdb380e3b6b0ac5
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:
The flow team is rolling out exact-by-default object types to xplat/js. In order to do that, we need to take all inexact objects `{}` and turn them into explicitly inexact objects `{...}`.
This codemod does not change any type checking behavior. Prettier was run on all of the modified files with `format`.
drop-conflicts
Changelog: [Internal]
Reviewed By: zackargyle
Differential Revision: D18785076
fbshipit-source-id: c89c7fcc9eabe69859c8a488e03185fba5d06f80
Summary:
The former implementations of `TouchableHighlight` used `defaultProps` for `underlayColor`. However, the newly landed implementations use `??` which falls back to the default behavior if the prop is `null`.
This restores the former behavior so that, for example, supplying `underlayColor={null}` to `TouchableHighlight` will not fallback to black. (It probably should always have, but the intention of my rewrite was not to introduce a breaking change.)
Changelog:
[General] [Fixed] - Restore behavior for `underlayColor={null}` in `TouchableHighlight`.
Reviewed By: zackargyle
Differential Revision: D18806494
fbshipit-source-id: 4d33810e2f754f980385d76d81dc0f34006f4337
Summary:
Originally, normalizeColor.js was in Library/Color/ however, I noticed that its tests were in a completely different directly (Library/StyleSheet/__tests__) which was confusing. The other files such as processColor.js, setNormalizedAlphaColor.js had their tests in Library/StyleSheet/__tests__ as well.
## Changelog
[Internal] [Changed] - Moved normalizeColor.js to a more appropriate directory where its tests live.
Pull Request resolved: https://github.com/facebook/react-native/pull/27372
Test Plan: I simply moved a file and changed dependencies. The code should still function as is.
Reviewed By: rickhanlonii, mdvacca
Differential Revision: D18760210
Pulled By: yungsters
fbshipit-source-id: 4c2400acabab35ccbb2533faa5c1d6487c9bf48e
Summary:
Changelog:
[iOS] [Fixed] - Slider is now disabled properly on iOS if the disabled prop is set.
Reviewed By: yungsters
Differential Revision: D18758835
fbshipit-source-id: 4850ebf05380f241d49d40107de61fd840049779
Logan Daniels
radex
Vojtech Novak
Tom Underhill
Janic Duplessis
Hans Halverson
Joshua Gross
Kacie Bawiec
Rachel Nabors
Eli White
Eloy Durán
Jesse Katsumata
Spencer Ahrens
Emily Janzer
Peter Argany
Arthur Kushka
Mike Vitousek
Nikita Shanin
Samuel Susla
Rajat Gupta
Oleksandr Melnykov
Héctor Ramos
Kevin Gonzales
Tim Yung
Jordan Brown
Isabel B
Andy Huang
