Summary: LayoutAnimation is one source of flakiness in SSTs. Disable it globally in the SST apps.
Reviewed By: ejanzer
Differential Revision: D13791987
fbshipit-source-id: 0ebfd79fb31d235680c0d84f4b06d5a98c35260a
Summary:
This is a recreation of #13924, rebased on top of master, as the former PR wasn't re-reviewed and automatically closed by the bot.
iOS [Action Sheets docs](https://developer.apple.com/ios/human-interface-guidelines/ui-views/action-sheets/) say
> Make destructive choices prominent. Use red for buttons that perform destructive or dangerous actions, and display these buttons at the top of an action sheet.
Currently ActionSheetIOS's showActionSheetWithOptions only supports a single destructive button via the prop `destructiveButtonIndex`.
This PR maintains backwards compatibility with `destructiveButtonIndex` while simultaneously supporting `destructiveButtonIndexes` allowing developers to pass an array of destructive indexes
```js
ActionSheetIOS.showActionSheetWithOptions({
options: ['one', 'two', 'three'],
destructiveButtonIndexes: [0, 1],
}, () => {});
```
<img width="282" alt="actionsheet" src="https://cloud.githubusercontent.com/assets/3091143/25963211/1c211a16-3646-11e7-9b7c-c9a2dbea7832.png">
Some additional tests, all working as expected (item only red if it is a matching index).
```js
ActionSheetIOS.showActionSheetWithOptions({
options: ['one', 'two', 'three'],
destructiveButtonIndexes: [0, 19],
}, () => {});
```
```js
ActionSheetIOS.showActionSheetWithOptions({
options: ['one', 'two', 'three'],
destructiveButtonIndexes: [],
}, () => {});
```
```js
ActionSheetIOS.showActionSheetWithOptions({
options: ['one', 'two', 'three'],
destructiveButtonIndexes: undefined,
}, () => {});
```
```js
ActionSheetIOS.showActionSheetWithOptions({
options: ['one', 'two', 'three'],
}, () => {});
```
```js
ActionSheetIOS.showActionSheetWithOptions({
options: ['one', 'two', 'three'],
destructiveButtonIndexes: [0, 5, 0, 0],
}, () => {});
```
```js
ActionSheetIOS.showActionSheetWithOptions({
options: ['one', 'two', 'three'],
destructiveButtonIndexes: [0, 5, 0, 0, 'non numeric', 12.34],
}, () => {});
```
The following will crash the app but I believe this is expected
```js
ActionSheetIOS.showActionSheetWithOptions({
options: ['one', 'two', 'three'],
destructiveButtonIndexes: 'not an array',
}, () => {});
```
```js
ActionSheetIOS.showActionSheetWithOptions({
options: ['one', 'two', 'three'],
destructiveButtonIndexes: null,
}, () => {});
```
- [x] Explain the **motivation** for making this change.
- [x] Provide a **test plan** demonstrating that the code is solid.
- [x] Match the **code formatting** of the rest of the codebase.
- [x] Target the `master` branch, NOT a "stable" branch.
Pull Request resolved: https://github.com/facebook/react-native/pull/18254
Differential Revision: D13680516
Pulled By: hramos
fbshipit-source-id: ac183cdcf5e1daef8e3c584dcf6a921bbecad475
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:
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:
----------
Help reviewers and the release process by writing your own changelog entry. See http://facebook.github.io/react-native/docs/contributing#changelog for an example.
[General] [Fixed] - Same style was applied twice to SwipeableQuickActionButton in a recent commit causing problems with the buttons layout.
Pull Request resolved: https://github.com/facebook/react-native/pull/23113
Differential Revision: D13781896
Pulled By: cpojer
fbshipit-source-id: 659ddaed32b6a1e90080344ea3b0b42088fd9783
Summary:
Fix crash similar to #22410
react-native: 0.51.0
react: 16.0.0
Changelog:
----------
[iOS] [Changed] - Use onw serial queue to execute invalidate and send request action in RCTHTTPRequestHandler.mm.
Message:
--------
```
- (void)invalidate
{
[_session invalidateAndCancel];
_session = nil;
}
- (NSURLSessionDataTask *)sendRequest:(NSURLRequest *)request
withDelegate:(id<RCTURLRequestDelegate>)delegate
{
// Lazy setup
if (!_session && [self isValid]) {
NSOperationQueue *callbackQueue = [NSOperationQueue new];
callbackQueue.maxConcurrentOperationCount = 1;
callbackQueue.underlyingQueue = [[_bridge networking] methodQueue];
NSURLSessionConfiguration *configuration = [NSURLSessionConfiguration defaultSessionConfiguration];
[configuration setHTTPShouldSetCookies:YES];
[configuration setHTTPCookieAcceptPolicy:NSHTTPCookieAcceptPolicyAlways];
[configuration setHTTPCookieStorage:[NSHTTPCookieStorage sharedHTTPCookieStorage]];
_session = [NSURLSession sessionWithConfiguration:configuration
delegate:self
delegateQueue:callbackQueue];
std::lock_guard<std::mutex> lock(_mutex);
_delegates = [[NSMapTable alloc] initWithKeyOptions:NSPointerFunctionsStrongMemory
valueOptions:NSPointerFunctionsStrongMemory
capacity:0];
}
NSURLSessionDataTask *task = [_session dataTaskWithRequest:request];
{
std::lock_guard<std::mutex> lock(_mutex);
[_delegates setObject:delegate forKey:task];
}
[task resume];
return task;
}
```
now the invalidate function is called by the RCTBridge.invalidate->RCTCxxBridge.invalidate->[moduleData.instance invalidate] , this is on the "com.facebook.react.HTTPRequestHandlerQueue".
the sendRequest:withDelegate function is called by RCTImageLoader and is on the "com.facebook.react.imageLoaderURLRequestQueue".
when one thread step in invalidate and execute [_session invalidateAndCancel] and the another thread step in sendRequest:withDelegate and execute [_session dataTaskWithRequest:request], the _session is invalidate, so there will be a crash "Task created in a session that has been invalidated"
Pull Request resolved: https://github.com/facebook/react-native/pull/22746
Differential Revision: D13781512
Pulled By: cpojer
fbshipit-source-id: bd5fd1edf593e2bcdcc18596a29e906882bac8a4
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:
`groupCollapsed` is used to group logs but collapsed which is very useful when the console has many logs (e.g. when using `redux-logger`).
For developers who prefer to debug iOS apps using Safari JSC, the `groupCollapsed` was not polyfilled.
Fixes#21446
Pull Request resolved: https://github.com/facebook/react-native/pull/21457
Differential Revision: D13761796
Pulled By: cpojer
fbshipit-source-id: e7c4f1ff4728c6a7f6ffd6cc629f7fbc1aa67e87
Summary:
added protection for emit() because subscription.listener may have been removed during event loop
Changelog:
----------
[GENERAL][FIX] Avoid crash when subscription listener may have been removed during event loop
Pull Request resolved: https://github.com/facebook/react-native/pull/23047
Differential Revision: D13761725
Pulled By: cpojer
fbshipit-source-id: 0753b780067bd712cd43caf63020c3f0d6ea9f52
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:
When a list is updated to have fewer items and the user immediately
scrolls, the `ViewabilityHelper` `computeViewableItems` can be invoked
from the scroll and cause a crash.
This side effect *should* be relatively minor; the ViewabilityHelper shouldn't
cause a crash, as it generally would be used for analytics to see what users are viewing. I suggest changing this to a warning instead of a crash. Other react-native developers seem to [also be getting this occasionally](https://github.com/facebook/react-native/issues/20289).
Changelog:
----------
[General] [Fixed] - `Invalid render range` crash changed to warning when viewability helper detects an anomaly in list data.
Pull Request resolved: https://github.com/facebook/react-native/pull/22847
Differential Revision: D13750031
Pulled By: cpojer
fbshipit-source-id: 053d2baad208d1efe5b18b07ab10226032e665b8
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:
This PR is related to #22990
Changelog:
----------
[iOS] [Changed] - move the call to requireNativeComponent from Modal.js to RCTModalHostViewNativeComponent.js
Pull Request resolved: https://github.com/facebook/react-native/pull/23030
Differential Revision: D13710032
Pulled By: cpojer
fbshipit-source-id: 822284a639f38721442c67ceff98fc99495c31b9
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:
This expands functionality of URL minimally so Apollo Server can run in React Native contexts. Add explicit-fail getters so undefined values won't get generated from the otherwise missing implemenation.
Use of URL in apollo-server here: 458bc71ead/packages/apollo-datasource-rest/src/RESTDataSource.ts (L79)
Credit to my colleague dysonpro for debugging the issue and providing the initial working stub implementation.
Changelog:
----------
Help reviewers and the release process by writing your own changelog entry. See http://facebook.github.io/react-native/docs/contributing#changelog for an example.
[INTERNAL] [ENHANCEMENT] - Support construction, toString(), and href() of URL objects.
Pull Request resolved: https://github.com/facebook/react-native/pull/22901
Differential Revision: D13690954
Pulled By: cpojer
fbshipit-source-id: 7966bc17be8af9bf656bffea5d530b1e626acfb3
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:
Changelog:
----------
Help reviewers and the release process by writing your own changelog entry. See http://facebook.github.io/react-native/docs/contributing#changelog for an example.
[General] [Deprecated] - Deprecation warning for WebView as it has been extracted from core.
Pull Request resolved: https://github.com/facebook/react-native/pull/22980
Differential Revision: D13664505
Pulled By: hramos
fbshipit-source-id: 0cfc06015e77c52bed9eeebd97c8cbca6eacd8ce
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
TranLuongTuanAnh
Ben Newman
zhongwuzw
yushimatenjin
Peter Argany
Steven Goff
Rafael Melo
Varun Gupta
SHANKS
VisibleMarkov
jesse
Rafael Lincoln
Christoph Nakazawa
James Reggio
Mido
xianglinhe
RCiesielczuk
OdaDaisuke
Chi-AnTai
seansy
Jordan Brown
doniyor2109
Kudo Chien
Heinrich Tremblay
nd-02110114
Sam Goldman
Jeff Held
John.Yang
Daiki Ihara
Nick Bell
Leko
Maxime Nory
Julian Hundeloh
Matt Hargett
Alejandro
chrisnojima
Eli White
Thibault Malbranche
Alexander Vasyuk
Ramanpreet Nara
