Summary:
Without `transform` in `OUTER_PROPS`, the refresh control component would not include `transform: {scaleY: -1}` in its style and so pulling down, rather than up, on a scroll view would trigger a refresh.
Fixes https://github.com/facebook/react-native/issues/26181
## Changelog
[Android] [Fixed] - Fixed issue with refresh control not working properly on an inverted ScrollView
Pull Request resolved: https://github.com/facebook/react-native/pull/26611
Test Plan: Updated unit test in splitLayoutProps-test.js.
Differential Revision: D17661079
Pulled By: cpojer
fbshipit-source-id: 747da27b11c3ca59b7f639f393ae5ac137f5490a
Summary:
I upstreamed the changes to this file from previous commits to React in this (unlanded) PR: https://github.com/facebook/react/pull/16898#issuecomment-535248721
I had to make some additional changes to be able to make Flow pass there. Bringing those changes back to FBSource as well. Having this change made here will make the next sync easier as we won't have to deal with conflicts then.
Changelog:
[Internal]
Reviewed By: cpojer
Differential Revision: D17586781
fbshipit-source-id: 4be8376d0af4fb5d63410afaaf5bb0005d992981
Summary:
`HostComponent` is built specifically to differentiate from `ReactNative.NativeComponent`. These tests should ensure that is the case, and help it stay that way.
I also expect these tests to be duplicated to DefinitelyTyped to help the team working on the TypeScript types ensure they have things modeled correctly.
Reviewed By: cpojer
Differential Revision: D17580120
fbshipit-source-id: c14eb18507cbee1b308beeff0092607e18706171
Summary:
MeasureLayout requires either a reactTag or a ref to a host component. Now that we have a type for Host Components we can be more differentiating here.
Also, because Object is treated as `any` in flow, the type was allowing the return from findNodeHandle or a ref itself be passed, even though both of those are nullable.
This change explicitly requires checking for null before calling the function which is consistent with the behavior of the implementation of measureLayout.
Changelog:
[Changed] Flowtype for measureLayout now disallows null as reactTag
Reviewed By: cpojer
Differential Revision: D17579300
fbshipit-source-id: af062fcd9dfc40eab42e5c5452af2ff653d0888e
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:
We found that many callsites existed that could be using the native driver, but weren't. In order to help people use it when appropriate and eventually switch the default, we are requiring that useNativeDriver is explicit, even when set to false.
This change adds a runtime warning if useNativeDriver is not specified, hopefully giving some light feedback to remember to use the native driver when you can. Without it being explicit it is very easy to forget setting this.
Reviewed By: JoshuaGross
Differential Revision: D17575918
fbshipit-source-id: e54612d87177e1821692b7de20fe673df0e890d2
Summary:
We need to migrate to HostComponent instead of the exported type from codegenNativeComponent which is the same type
Changelog:
[Internal] Migrate NativeComponentType from codegenNativeComponent to HostComponent
Reviewed By: rickhanlonii
Differential Revision: D17563307
fbshipit-source-id: 01c8fea8c67b33bed42ae28ffb8c132be87b9a7a
Summary:
We need to migrate to HostComponent, this is the first batch.
Changelog:
[Internal] Migrate NativeComponentType from codegenNativeComponent to HostComponent
Reviewed By: rickhanlonii
Differential Revision: D17562879
fbshipit-source-id: ce1993b64a79cede3598c89ddff0dadf07fde92f
Summary:
In React Native there are three types of "Native" components.
```
createReactClass with NativeMethodsMixin
```
```
class MyComponent extends ReactNative.NativeComponent
```
```
requireNativeComponent('RCTView')
```
The implementation for how to handle all three of these exists in the React Native Renderer. Refs attached to components created via these methods provide a set of functions such as
```
.measure
.measureInWindow
.measureLayout
.setNativeProps
```
These methods have been used for our core components in the repo to provide a consistent API. Many of the APIs in React Native require a `reactTag` to a host component. This is acquired by calling `findNodeHandle` with any component. `findNodeHandle` works with the first two approaches.
For a lot of our new Fabric APIs, we will require passing a ref to a HostComponent directly instead of relying on `findNodeHandle` to tunnel through the component tree as that behavior isn't safe with React concurrent mode.
The goal of this change is to enable us to differentiate between components created with `requireNativeComponent` and the other types. This will be needed to be able to safely type the new APIs.
For existing components that should support being a host component but need to use some JS behavior in a wrapper, they should use `forwardRef`. The majority of React Native's core components were migrated to use `forwardRef` last year. Components that can't use forwardRef will need to have a method like `getNativeRef()` to get access to the underlying host component ref.
Note, we will need follow up changes as well as changes to the React Renderer in the React repo to fully utilize this new type.
Changelog:
[Internal] Flow type to differentiate between HostComponent and NativeMethodsMixin and NativeComponent
Reviewed By: jbrown215
Differential Revision: D17551089
fbshipit-source-id: 7a30b4bb4323156c0b2465ca41fcd05f4315becf
Summary:
These types aren't robust to changes in the React component type. When we refactor requireNativeComponent these will error. This change is forwards compatible.
Changelog:
[Internal] Improve internal type in DrawerLayoutAndroid
Reviewed By: JoshuaGross
Differential Revision: D17561194
fbshipit-source-id: 470289449b4d5b3148692f1945fb720e1e3972eb
Summary:
This is used by Image.android.js and needs to be flow typed to be able to have confidence in the requireNativeComponent type change
Changelog:
[Internal] Flow type vendor/core/merge.js
Reviewed By: JoshuaGross
Differential Revision: D17561195
fbshipit-source-id: 2639f2628e15b2dd5469bb2ebfe935a444025a21
Summary:
It's possible that this crashes because the callback is non-null/non-undefined but isn't a function; if so, I would like to collect that information.
These changes have already been made in the React repo.
Reviewed By: TheSavior
Differential Revision: D17559022
fbshipit-source-id: a0538d533c3c482d27eef0ed3c8c980e2bc8e817
Summary:
@public
We're seeing crashes from multiple threads trying to call `[NSData appendData:]` at the same time. Usually the RCTURLRequestHandlers implementation avoids this but if you're using a background queue, it is pretty easy to reach this case.
Adding a lock to accessors of `_data` should prevent this.
Reviewed By: shergin
Differential Revision: D17552136
fbshipit-source-id: 3384d36221d0ada8cda638ad8e79e1bf3862f93f
Summary: Just need to validate the intended fix properly via simple gating mechanism.
Reviewed By: mmmulani
Differential Revision: D17536264
fbshipit-source-id: 92db4156beabd6dec2a71b6ea7c2d7bf708d44b1
Summary:
Due to an update to react-native on the android tv platform tapping the select button on a remote calls the onPress prop twice for `TouchableHighlight`, `TouchableOpacity`, and `TouchableWithoutFeedback`. This is happening because touchableHandlePress gets called from two places. First from the onClick prop in the touchable component and second from the TVEventHandler in the TouchableMixin.
## Changelog
[Android] [Fixed] - Adds a not android check to the select case of the TVEventHandler callback in the TouchableMixin.
Pull Request resolved: https://github.com/facebook/react-native/pull/26474
Test Plan:
Confirmed on Android Tv and Apple Tv
1) Add a TouchableOpacity to a screen with an onPress callback
2) Run app
3) Focus the TouchableOpacity
4) Press the Select Button on the Remote
**Expected Results**
onPress is called once
Differential Revision: D17530170
Pulled By: TheSavior
fbshipit-source-id: b776faba477c6231ad296abd21f072335dca5556
Summary:
I happened to hit this error a couple times and the issue is that if there are let's say 1000 pending callbacks the error would be triggered 500 times and pretty much crash the app. I think it is reasonable to use warn once here so it only happens once.
## Changelog
[General] [Fixed] - Use `warnOnce` for excessive number of callbacks error
Pull Request resolved: https://github.com/facebook/react-native/pull/26508
Test Plan: Tested by reducing the number of pending callbacks required to trigger the error.
Reviewed By: TheSavior
Differential Revision: D17512917
Pulled By: JoshuaGross
fbshipit-source-id: 5ce8e2a0a166805cc6f3fe6d78e2716d6792a80e
Summary:
The previous version of the code accessed `_animIdIsManagedByFabric` on the main thread (which is should be accessed on the UIManager thread) and called `flushOperationQueues` on the main thread as well (also must be called on UIManager thread because it modifies instance variables (e.g. `_operations`) which supposed to be accessed on UIManager thread).
The diff fixes that introducing an additional queue jump. That's should be fine because the overall architecture of RCTNativeAnimatedModule is appeared to be asynchronous and should be resilient to possible races.
Reviewed By: sammy-SC
Differential Revision: D17523958
fbshipit-source-id: c4b4ce38b68b009726b2f6c28c38b32b9f9d6921
Summary: This diff migrates `ReactSwtichManager` to use the generated `ReactSwtichManagerDelegate` for setting its properties.
Reviewed By: TheSavior
Differential Revision: D17395067
fbshipit-source-id: 1489c5d08cef860030ecbd23ef19bd8de1328d71
Summary: This diff migrates `ReactDrawerLayoutManager` to use the generated `AndroidDrawerLayoutManagerDelegate` for setting its properties.
Reviewed By: mdvacca
Differential Revision: D17343383
fbshipit-source-id: 85cd7ee3531b152da2601048f5e458f5dad73ad6
Summary: This diff migrates `ReactProgressBarViewManager` to use the generated `AndroidProgressBarManagerDelegate` for setting its properties.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D17315619
fbshipit-source-id: 6293c6fc18567a934b6f3dce9b77abcc408052d8
Summary: This diff migrates `SwipeRefreshLayoutManager` to use the generated `AndroidSwipeRefreshLayoutManagerDelegate`.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D17225894
fbshipit-source-id: e659d2a9cb5dba42c589559f61a0e98330e21612
Summary: This diff migrates `ReactSliderManager` to use the generated `SliderManagerDelegate` for setting its properties.
Reviewed By: mdvacca
Differential Revision: D17203078
fbshipit-source-id: 726736ef275074ecb799b334342ac64976153e2b
Summary:
## Motivation
The concept behind JSCallInvoker doesn't necessarily have to apply only to the JS thread. On Android, we need to re-use this abstraction to allow execution of async method calls on the NativeModules thread.
Reviewed By: PeteTheHeat
Differential Revision: D17377313
fbshipit-source-id: 3d9075cbfce0b908d800a366947cfd16a3013d1c
Summary:
We used to generate the documentation for the website but moved the docs to another repo.
There is some work on the docs to be able to ingest info from this repo in order to go back to generating API information. The current thinking is we will generate this JSON file and the website repo will pull it in to generate the docs.
I plan to make the script run on CI and fail if the generated file isn't updated, in a follow up PR.
Reviewed By: zackargyle
Differential Revision: D17183936
fbshipit-source-id: 99ce3fa5d7becc0ef20df5d439b175eedbe546f3
Summary:
We need to get rid of findNodeHandle calls so migrating scrollResponderScrollNativeHandleToKeyboard to take a ref to a host component.
I made this change with Flow, and tested by rendering UserJobApplicationForm
Reviewed By: mdvacca
Differential Revision: D17099280
fbshipit-source-id: 96af692006aace2c206f268f5416984b00f8a438
Summary:
In Windows, if you clicked on a Switch component to toggle it, you could see it "shimmy" back and forth once before settling. The native Switch ends up toggling three times every time it's invoked.
`Switch.js` prevents the native switch from toggling to the new value by explicitly setting the switch to `this.props.value` when it receives an `onChange` event. The re-setting of the value wasn't fast enough to prevent the `Switch` from starting to toggle, causing the visual shimmy.
The solution is taken from `TextInput`. `TextInput.js` stores `_lastNativeText` when it receives an `onChange` event. In `componentDidUpdate`, it puts `this.props.text` back on the native textbox if the value of `this.props.text` isn't the same as `_lastNativeText`, which is how it ensures that it is a controlled component. Porting this to the `Switch` results in only one toggle happening per invoke, removing the shimmy, while preserving the controlled component behavior.
This bug is not visible on Android or iOS, only Windows, however the code causing the bug was in `Switch.js` and it seems reasonable to avoid changing the value of the native switch excessively.
## Changelog
[General] [Fixed] - Fix excessive toggles on the Switch component
Pull Request resolved: https://github.com/facebook/react-native/pull/26496
Test Plan: Used RNTester on Android and iOS to test the Switch component and made sure that all scenarios behave as expected visually. Also ensured through the debugger that the value of the native switch is only being changed once, instead of three times.
Reviewed By: TheSavior
Differential Revision: D17468905
Pulled By: JoshuaGross
fbshipit-source-id: 92bf511510306968c3573ee4eed6df009850fd77
Summary: This was already deprecated, but without a message.
Reviewed By: zackargyle, ejanzer
Differential Revision: D17180347
fbshipit-source-id: 44aa5d1821e56f7600033e82062c4661fe663471
Summary:
React Native components need a mechanism to specify their value to assistive technologies. This PR adds the notion of accessibilityValueDescription-- a property which either contains a textual description of a component's value, or for range-based components, such as sliders and progress bars, it contains range information (minimum, current, and maximum).
On iOS, the range-based info if present is converted into a percentage and added to the accessibilityValue property of the UIView. If text is present as part of the accessibilityValueDescription, it is used instead of the range-based information.
On Android, any range-based information in accessibilityValueDescription is exposed in the AccessibilityNodeInfo's RangeInfo. Text which is part of accessibilityValueDescription is appended to the content description.
## Changelog
[GENERAL] [Change] - add accessibilityValuedescription property.
Pull Request resolved: https://github.com/facebook/react-native/pull/26169
Test Plan: Added two new accessibility examples to RNTester, one which uses text and another which uses range-based info in accessibilityValueDescription. Verified that they both behave correctly on both Android and iOS.
Differential Revision: D17444730
Pulled By: cpojer
fbshipit-source-id: 1fb3252a90f88f7cafe1cbf7db08c03f14cc2321
Summary: This function was deprecated in Dec 2016. It has no callsites at FB and should be deleted.
Reviewed By: zackargyle, ejanzer
Differential Revision: D17180174
fbshipit-source-id: de3ab78c469220b629ef7f6773d60507959f6db6
Summary:
This pull request makes properties of events' Flow types in `AndroidTextInputNativeComponent` be `$ReadOnly`.
This will make them more compatible with the callback types in `TextInput`.
## Changelog
[Internal] [Changed] - Made properties of events' Flow types in `AndroidTextInputNativeComponent` readonly
Pull Request resolved: https://github.com/facebook/react-native/pull/26469
Test Plan:
`yarn flow-check-ios` and `yarn flow-check-android` both pass.
No regressions to running `scripts/generate-rncore.sh` have been noted.
Differential Revision: D17435579
Pulled By: TheSavior
fbshipit-source-id: 92e6c0623c4dd3fe06ebfb22dc73916bf5917bcc
Summary:
This diff changes how we apply default text attributes to backed text input.
The original change in https://github.com/facebook/react-native/pull/23585 that introduced the `reactTextAttributes` field in for RCTBackedTextInputViewProtocol was great! Thank you Wu zhongwuzw !
However, there is one detail that needs to be changed.
RCTBackedTextInputViewProtocol is designed to only abstract complexity of iOS text input components (UITextView and UITextField); it intentionally does not have any React-specific fields or types. Adding a field `RCTTextAttributes *reactTextAttributes;` violates this principle and make it hard to reuse this functionality in the new Fabric-powered TextInput.
This diff changes the type of this prop from `RCTTextAttributes` to `NSDictionary<NSAttributedStringKey,id> *` (exact same type that UITextView and UITextField use).
Reviewed By: cpojer
Differential Revision: D17408501
fbshipit-source-id: 65f2bba119ccc30f22e87c28d0f8ea6f731cd365
Summary:
I wanted to configure the RN dev menu without having to write native code. This is pretty useful in a greenfield app since it avoids having to write a custom native module for both platforms (and might enable the feature for expo too).
This ended up a bit more involved than planned since callbacks can only be called once. I needed to convert the `DevSettings` module to a `NativeEventEmitter` and use events when buttons are clicked. This means creating a JS wrapper for it. Currently it does not export all methods, they can be added in follow ups as needed.
## Changelog
[General] [Added] - Export the DevSettings module, add `addMenuItem` method
Pull Request resolved: https://github.com/facebook/react-native/pull/25848
Test Plan:
Tested in an app using the following code.
```js
if (__DEV__) {
DevSettings.addMenuItem('Show Dev Screen', () => {
dispatchNavigationAction(
NavigationActions.navigate({
routeName: 'dev',
}),
);
});
}
```
Added an example in RN tester
Differential Revision: D17394916
Pulled By: cpojer
fbshipit-source-id: f9d2c548b09821c594189d1436a27b97cf5a5737
Summary:
Currently on iOS 13 the app will crash if you:
- Open the share sheet
- Tap something like messages or photos
- Cancel the dialog
- Perform any other action
This is because `shareController.completionWithItemsHandler` is called when the dialog box is canceled and currently `failureCallback` or `successCallback` will always be called. In the situation above, `activityError` is `nil` so `successCallback` will be called even though `completed` is false. This leaves us in a state where the callback has been invoked but the ShareSheet is still active, meaning the success or error callback will be invoked again, leading to the crash.
This PR adds a check to make sure `completed` is true before calling `successCallback`. This way `successCallback` will only be called when the user has successfully completed an action and the ShareSheet is closed.
## Changelog
[iOS] [Fixed] - Fix crash in RCTActionSheetManager.m on iOS 13
Pull Request resolved: https://github.com/facebook/react-native/pull/26429
Test Plan:
- Saved an image successfully
- Opened and dismissed the `Photos` dialog multiple times without crashing
Differential Revision: D17369712
Pulled By: PeteTheHeat
fbshipit-source-id: 228b696243cd39fad1fa134f4412d95d845b1bc5
Summary: This is part of Lean Core.
Reviewed By: rubennorte
Differential Revision: D17343246
fbshipit-source-id: 1185e6c1f75e8272048ce1a24c2f195728d436c4
Roshan Gautam
Pablo Espinosa
Miguel Alatzar
vasilich
Dulmandakh
Luna Wei
Eli White
Logan Daniels
Joshua Gross
Mehdi Mulani
Kevin Gozali
Daniel
Janic Duplessis
Valentin Shergin
Samuel Susla
Oleksandr Melnykov
Mike Vitousek
Ramanpreet Nara
Ruriko Araki
Alexander Kawrykow
Marc Mulcahy
empyrical
Tom Targosz
Christoph Nakazawa
