Summary:
Changelog:
----------
[General] [Fixed] - After using React's `<StricMode>` it was discovered that a string ref was set, which is bad practice.
Pull Request resolved: https://github.com/facebook/react-native/pull/23146
Differential Revision: D13802397
Pulled By: cpojer
fbshipit-source-id: c2744877b25ad59eb1e4e9ce48a45e762f227b56
Summary:
PR Related to: #22990
Changelog:
[Android][Changed] - All the imports connected to requireNativeComponent in ActivityIndicator was moved to a seperate file.
Pull Request resolved: https://github.com/facebook/react-native/pull/23104
Differential Revision: D13781451
Pulled By: cpojer
fbshipit-source-id: 7204976d59a96abdaa81cdd7fd54fd001f7d1ee9
Summary:
His PR is related to #22990
Changelog:
----------
[IOS][Changed] - move the call to requireNativeComponent from TabBarIOS.ios.js to RCTTabBarNativeComponent.js
Pull Request resolved: https://github.com/facebook/react-native/pull/23118
Differential Revision: D13781428
Pulled By: cpojer
fbshipit-source-id: 3034c7db127a992c5757d70e22d98ee9acf4847b
Summary:
This PR exposes three static methods (`pushStackEntry`, `popStackEntry`, and `replaceStackEntry`) on StatusBar that enable imperative manipulation of the StatusBar style within the stack established by mounted StatusBar components.
Motivation:
----------
The StatusBar **component** provides a sensible API for manipulating that StatusBar style: every time a StatusBar component is mounted, its props are pushed onto a stack, and the props from the most recently mounted component are applied.
However, there are some scenarios where you may need to manipulate the StatusBar style from imperative code — particularly when invoking imperative third-party APIs that cause UI to appear. (For example, a user feedback utility or bug reporter that launches a full-screen modal.)
In modern iOS development, `UIViewControllerBasedStatusBarAppearance` is typically set to `YES`, which allows the third-party UIViewController to specify its preferred status bar style. However, as has been discussed at length in #11710, React Native has disabled this setting, which means that either the app's code or the third-party's React Native wrapper needs to manually manipulate React Native's StatusBar API to achieve the desired outcome.
The existing imperative StatusBar APIs are not a good fit for these needs because they simply overwrite the existing StatusBar styles, and provide no means of reverting StatusBar style changes when the third-party UI is dismissed.
To improve upon this situation, this PR makes it possible to call `StatusBar.pushStackEntry` before launching the third-party UI, wait for the UI to dismiss, and then call `StatusBar.popStackEntry` (supplying the token returned from the push call).
I've featured the new stack-based imperative methods in the documentation, but stopped short of explicitly deprecating the older imperative methods — though I can think of no reason not to deprecate them. Feedback is welcome on this point.
Release Notes:
--------------
[GENERAL] [ENHANCEMENT] [StatusBar] - Add static methods to manipulate StatusBar stack imperatively
Pull Request resolved: https://github.com/facebook/react-native/pull/21206
Differential Revision: D9945247
Pulled By: cpojer
fbshipit-source-id: ec118268cff5b47e87be81d0b9e1728ecc3a9b02
Summary:
[Android][Changed] - All the imports connected to `requireNativeComponent` in `ViewPager` was moved to a separate file.
Issue in focus: #22990
Pull Request resolved: https://github.com/facebook/react-native/pull/22995
Differential Revision: D13760459
Pulled By: cpojer
fbshipit-source-id: fca1633ce933ea4909ef81d7bbe8123d654e24fb
Summary:
Created a standalone JS file for the `RCTProgressView` native component.
This PR is part of #22990.
Changelog:
----------
[iOS] [Changed] - Created a standalone JS file for the `RCTProgressView` native component
Pull Request resolved: https://github.com/facebook/react-native/pull/23077
Differential Revision: D13760036
Pulled By: cpojer
fbshipit-source-id: 0f449528b28fde089d9c6b0eb9b752dee3a85af6
Summary:
his PR is related to #22990
Changelog:
----------
[Android][Changed] - move the call to requireNativeComponent from ProgressBarAndroid.android.js to ProgressBarAndroidNativeComponent.js
Pull Request resolved: https://github.com/facebook/react-native/pull/23068
Differential Revision: D13760445
Pulled By: cpojer
fbshipit-source-id: b74ff42c6f207803de70be549a13487d59125a66
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: Upgrades flow in xplat/js to 0.91. This diff also adds and removes suppressions.
Reviewed By: samwgoldman
Differential Revision: D13720697
fbshipit-source-id: 1bf8830ce286db92277476a2d2404cf0c0dddca2
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:
Removes unused suppressions before deploying 0.91. See D13708161 for more context on why these couldn't be removed before.
I will follow up with 2 more diffs:
1. A diff that bumps the flow version in xplat and removes unused suppressions
2. A diff that adds new suppressions for 0.91
Reviewed By: samwgoldman
Differential Revision: D13720219
fbshipit-source-id: b07dd163962fed7ff27ce3e0a4a73a71c51965d9
Summary:
Changelog:
----------
[Android] [Changed] - As mentioned in #22990, I have moved native components required by DrawerLayoutAndroid.android.js into separate files and added Flow Typing.
Question
----------
I have two questions.
It is not included in the files mentioned by #22990 [comment](https://github.com/facebook/react-native/issues/22990#issue-399165354). Perhaps we should be adding knowledge of that type to the codegen since it is quite complicated, what do you think TheSavior?
The `Props` type include `renderNavigationView: () => React.Element<any>,` and `children?: React.Node,`. Therefore I added `const React = require('React');` to the file, is it ok?
Pull Request resolved: https://github.com/facebook/react-native/pull/23036
Differential Revision: D13710035
Pulled By: cpojer
fbshipit-source-id: 671423b76c3b443d85e4b63d05d6253dbd33b29c
Summary:
Changelog:
----------
[iOS] [Changed] - moved RCTRefreshControl from RefreshControl as a separate component, as mentioned in #22990
[Android] [Changed] - moved AndroidSwipeRefreshLayout from RefreshControl as a separate component, as mentioned in #22990
Pull Request resolved: https://github.com/facebook/react-native/pull/23039
Reviewed By: rickhanlonii
Differential Revision: D13710076
Pulled By: cpojer
fbshipit-source-id: 332520b74d6fc73e50dbe511dae22f82015c2d3a
Summary:
Applies the `thumbTintColor` prop to Sliders on iOS (which has been supported since iOS 5.0). Updates other documentation so that it is not labeled as Android-only, including the RNTester app
Pull Request resolved: https://github.com/facebook/react-native/pull/22177
Differential Revision: D13695554
Pulled By: hramos
fbshipit-source-id: 250f6574b193a37b3cd237bcf42612c3e91bf813
Summary:
[Android] [Changed] - create standalone JS file for ToolbarAndroid, as part of #22990
I have a question.
`ToolbarAndroid` component use 2 types from other files.
They are not included files mentioned by https://github.com/facebook/react-native/issues/22990#issue-399165354.
One type `ColorValue` is very simple and I'll copy it.
But `ImageSource` type is a bit complicated I think it wolud be better to add to the codegen.
How do you think about it? TheSavior
Update: -> solved 👍
----------
- [x] yarn lint
- [x] yarn flow-check-android
- [x] yarn flow
- [x] yarn test
Pull Request resolved: https://github.com/facebook/react-native/pull/23009
Differential Revision: D13697524
Pulled By: TheSavior
fbshipit-source-id: 72ce43e1510be0986a3798d795f07ab176bd2a92
Summary:
Thank you for sending the PR! We appreciate you spending the time to work on these changes.
Help us understand your motivation by explaining why you decided to make this change:
Changelog:
----------
[iOS] [Changed] - As mentioned in #22990, I have moved native components required by DatePickerIOS.ios.js into separate files and added Flow Typing.
Pull Request resolved: https://github.com/facebook/react-native/pull/23013
Differential Revision: D13697591
Pulled By: TheSavior
fbshipit-source-id: 5aec5a2270cbfc708f3e3a67662abd8071f1333f
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 is related to #22990
Changelog:
----------
[Android][Changed] - move the call to requireNativeComponent from `Checkbox.android.js` to `AndroidCheckBoxNativeComponent.js`
Pull Request resolved: https://github.com/facebook/react-native/pull/23003
Reviewed By: TheSavior
Differential Revision: D13690827
Pulled By: rickhanlonii
fbshipit-source-id: 08bc83a7f097414b5c833a3b43715e5aec277d65
Summary:
Refactoring the codegen buck target from being used just for testing to a way that can be depended on for the real fabric target to replace the existing component code.
After this change, we can build a target for react native to use the codegen to create the native files for Switch. A follow up diff will be necessary to hook this up and actually replace the native files for switch.
Reviewed By: mdvacca
Differential Revision: D13662363
fbshipit-source-id: 599dd9ed9ca24ffb5c5784396f4bee7457d94d6d
Summary: I was reading through the ScrollView code and realized that the documentation was incomplete, and some of the flow types were wrong.
Reviewed By: yungsters
Differential Revision: D13583133
fbshipit-source-id: 11c495681e9671e078e4d2c9df76c25b04558696
Summary: On Android, the status bar color is not always black by default. The existing code causes the status bar to revert to black once the last `<StatusBar>` component is unmounted from the "stack". This diff reverts the bar background color to what it was before, instead of assuming black.
Reviewed By: yungsters
Differential Revision: D13368136
fbshipit-source-id: ef0154f776607b57bb9400b72d521f5f485b0075
Summary: This was added in [this PR](https://github.com/facebook/react-native/pull/22047) with a non strict type
Reviewed By: yungsters
Differential Revision: D13617894
fbshipit-source-id: 849f83203556e2830ac725570c9053503377f4be
Summary: In D13408886, I landed a PR that broke the `autoFocus` prop. This diff fixes this prop by partially reveting some of the changes in that diff.
Reviewed By: TheSavior
Differential Revision: D13611258
fbshipit-source-id: 225b9b59b2500cfac092f13c273685aaeb599ab0
Summary: In D13307775, ScrollView was changed into a `React.Component` subclass. The solution needed a few touchups, so I added them in this diff.
Reviewed By: TheSavior
Differential Revision: D13404191
fbshipit-source-id: cba2ddab1fb92a2cbb91b59ac9ae5b5d51d91eb8
Summary:
As a part of https://github.com/facebook/react-native/pull/22301 it turned out that we need to first convert `ScrollView` to class component. As a first step to do so, here's removal of using `mixins` API, in favor of populating `_scrollResponder` field with `ScrollResponder.Mixin` (still used) methods.
Pull Request resolved: https://github.com/facebook/react-native/pull/22374
Reviewed By: TheSavior
Differential Revision: D13307775
Pulled By: RSNara
fbshipit-source-id: 16be1df8a0bf9ccc5cc32f3a017a1279f99268ed
Summary:
This removes the use of the legacy context API in `TextInput`.
Nothing in OSS appears to make use of the `focusEmitter`.
Pull Request resolved: https://github.com/facebook/react-native/pull/22220
Reviewed By: TheSavior
Differential Revision: D13408886
Pulled By: RSNara
fbshipit-source-id: 9ae597507ccc26a9bc944a44c1f51b91e73cd637
Summary:
Similar to what was done here https://github.com/facebook/react-native/pull/22376
This allows using things like async functions with text input event props.
Changelog:
----------
[General] [Fixed] - Make TextInput event prop types less strict
Pull Request resolved: https://github.com/facebook/react-native/pull/22673
Reviewed By: TheSavior
Differential Revision: D13492029
Pulled By: hramos
fbshipit-source-id: 84e1a776a7ac1ae7567fbf4105b2be9be330610e
Summary:
This diff fixes a bug in Touchable and Pressability where a long delay setting would unwillingly trigger presses by the user.
The cause of this bug is that we were not calculating the responder region until _after_ the delay. If you were to lift up outside of the press rect _before_ we calculate the responder region, we wouldn't be able to calculate that you're outside of the region (i.e. never transitioned to an "out" state) and would register the press
The fix is to start the calculation as soon as you transition into the initial state, so the calculation is available by the time we need to check if you're in an out state
Reviewed By: TheSavior
Differential Revision: D13412934
fbshipit-source-id: 55d1c2a9e70d4e3ce268f92075d7d09dd842a81e
Summary:
This diff exposes a new prop for WebView in Android to disable HardwareAcceleration.
Disabling hardware acceleration is sometimes required to workaround chromium bugs: https://bugs.chromium.org/p/chromium/issues/detail?id=501901
Reviewed By: fkgozali
Differential Revision: D13425243
fbshipit-source-id: e3cd53c72d01f74624b60834496f3cc44076b6b5
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:
Experienced a `TouchableOpacity` releasing the `PanResponder` without invoking `onPress` due to a missing a direction key in the `hitSlop` prop; The missing key caused the corresponding pressExpand to become NaN which causes `isTouchWithinActive` to become falsey, when it should be truthy.
If defaulting to 0 is undesired behavior, I'm happy to take a different approach.
Pull Request resolved: https://github.com/facebook/react-native/pull/22281
Differential Revision: D13374335
Pulled By: cpojer
fbshipit-source-id: f9d28e51b9d9c45aed42bea2df3d844a799fa827
Summary:
Since #18470, the default focus behaviour of `TouchableHighlight` and `TouchableOpacity` has been missing on tvOS. This uses the new `touchableHandleFocus` and `touchableHandleBlur` functions to restore the behaviour. Fixes#21295.
Pull Request resolved: https://github.com/facebook/react-native/pull/21478
Differential Revision: D13372959
Pulled By: cpojer
fbshipit-source-id: a5fa9d45214ac48a14a6573ccf014bba1ee0a103
Summary:
Related to #22100
Enhance ViewPropTypes flow types.
- I had some troubles with a TODO left for `onResponderGrant` hence the return type.
- I wasn't able to properly type `nativeBackgroundAndroid` and `nativeForegroundAndroid` at the moment.
Pull Request resolved: https://github.com/facebook/react-native/pull/22504
Reviewed By: cpojer
Differential Revision: D13334024
Pulled By: TheSavior
fbshipit-source-id: cada236e0d716ae78cb663172e5315cf11c6406a
Summary:
Related to #22100
Enhance TouchableWithoutFeedback with press and target event types.
There are still work to do to update `UNSAFE_componentWillReceiveProps` and `touchableGetHitSlop` to make Flow not complain about `DeprecatedEdgeInsetsPropType` inexact type.
Pull Request resolved: https://github.com/facebook/react-native/pull/22479
Reviewed By: RSNara
Differential Revision: D13310764
Pulled By: TheSavior
fbshipit-source-id: 9002e542378491fb800c8e81c63f4fbe125b563c
Summary:
I think a common pattern is to use async functions with the onRefresh prop to reload data. I made the type `mixed` since we don't care about what the function returns. Could also be `void | Promise<void>` I haven't really seen a pattern for those in the codebase.
Pull Request resolved: https://github.com/facebook/react-native/pull/22376
Differential Revision: D13310372
Pulled By: TheSavior
fbshipit-source-id: 445f28cf2c37f9c937e72d76716002deaf9d9c94
Summary: This is one more step to remove `fbjs` from `react-native-github`. This changes both the internal and external code to use `invariant` from zertosh instead of the copy in fbjs.
Reviewed By: yungsters
Differential Revision: D13195941
fbshipit-source-id: 73564ca1715110e7da9c7ef56dc57374d61377e0
Rafael Melo
VisibleMarkov
Rafael Lincoln
James Reggio
RCiesielczuk
OdaDaisuke
Chi-AnTai
Jordan Brown
doniyor2109
Kudo Chien
Heinrich Tremblay
jesse
Jeff Held
John.Yang
Daiki Ihara
Nick Bell
Leko
Maxime Nory
nd-02110114
Eli White
Ramanpreet Nara
Arthur Lee
Luna Wei
Michał Pierzchała
empyrical
Janic Duplessis
glevi@fb.com
Rick Hanlon
David Vacca
Taylor123
gtebbutt
Doug Russell
Thomas BARRAS
Baldy Lukasz
Christoph Nakazawa