Summary:
Looks we forgot to add this file to publish list. By adding it, we can remove some code in CLI that special-cases `react-native` package, since it now announces itself as a proper platform.
cc kelset, we'd like to have this cherry-picked for 0.60.
## Changelog
[Internal] [Fixed] - Publish `react-native.config.js`
Pull Request resolved: https://github.com/facebook/react-native/pull/25436
Test Plan: `npm pack` shows `react-native.config.js`
Differential Revision: D16071113
Pulled By: cpojer
fbshipit-source-id: df18affbb9a0ad7f2cfdd1a4cc93191aa5ffadeb
Summary:
The current technique we use to draw text uses linear memory, which means that when text is too long the UIView layer is unable to draw it. This causes the issue described [here](https://github.com/facebook/react-native/issues/19453). On an iOS simulator the bug happens at around 500 lines which is quite annoying. It can also happen on a real device but requires a lot more text.
To be more specific the amount of text doesn't actually matter, it is the size of the UIView that we use to draw the text. When we use `[drawRect:]` the view creates a bitmap to send to the gpu to render, if that bitmap is too big it cannot render.
To fix this we can use `CATiledLayer` which will split drawing into smaller parts, that gets executed when the content is about to be visible. This drawing is also async which means the text can seem to appear during scroll. See https://developer.apple.com/documentation/quartzcore/calayer?language=objc.
`CATiledLayer` also adds some overhead that we don't want when rendering small amount of text. To fix this we can use either a regular `CALayer` or a `CATiledLayer` depending on the size of the view containing the text. I picked 1024 as the threshold which is about 1 screen and a half, and is still smaller than the height needed for the bug to occur when using a regular `CALayer` on a iOS simulator.
Also found this which addresses the problem in a similar manner and took some inspiration from the code linked there https://github.com/GitHawkApp/StyledTextKit/issues/14#issuecomment-395234885
Fixes https://github.com/facebook/react-native/issues/19453
## Changelog
[iOS] [Fixed] - Use CALayers to draw text, fixes rendering for long text
Pull Request resolved: https://github.com/facebook/react-native/pull/24387
Test Plan:
- Added the example I was using to verify the fix to RNTester.
- Made sure all other examples are still rendering properly.
- Tested text selection
Reviewed By: shergin
Differential Revision: D15918277
Pulled By: sammy-SC
fbshipit-source-id: c45409a8413e6e3ad272be39ba527a4e8d349e28
Summary:
Bump Fresco to 2.0.0, which supports AndroidX. We should cherry-pick to 0.60 release, to support brown field apps but also native components.
## Changelog
[Android] [Changed] - Bump Fresco to 2.0.0, supports AndroidX
Pull Request resolved: https://github.com/facebook/react-native/pull/25358
Test Plan: CI is green, and RNTester builds and runs as expected.
Differential Revision: D15959443
Pulled By: mdvacca
fbshipit-source-id: 58ba2c3e4d1342014d6ea632cd865b4f413548d9
Summary:
I found that on Android we only support 2 fontWeight options, either **normal** or **bold**, even developer can set any numeric value. But iOS supports all possible numeric values. This PR tries to add support for all possible numeric values on Android, even if it's supported only on Android P(28) and above.
This change might break texts where fontWeight use improperly, because this PR removes conversion of values above 500 to BOLD and below 500 to normal.
FYI, also moved **mCustomTypefaceCache** usage up because it was working after unnecessary mFontCache usage.
## Changelog
[Android] [Changed] - add custom font weight support to Text component on Android, only on P(API 28) and above versions.
Pull Request resolved: https://github.com/facebook/react-native/pull/25341
Test Plan: RNTester app's Text examples will show Rubik Regular, Rubik Light, Rubik Bold, Rubik Medium and Rubik Medium Italic texts in corresponding font family, style and weights.
Differential Revision: D15956350
Pulled By: mdvacca
fbshipit-source-id: 61079d953c65fb34ab4497d44c22317912a5a616
Summary:
Upgrading the CLI to the latest with a bunch of fixes and features included.
## Changelog
[General] [Changed] - Bump CLI to 2.0.0-rc.0
Pull Request resolved: https://github.com/facebook/react-native/pull/25175
Differential Revision: D15694764
Pulled By: cpojer
fbshipit-source-id: 25fbf1c275ed5379e1cdb372512b6bb6327dea92
# Conflicts:
# jest/hasteImpl.js
# package.json
# yarn.lock
Summary:
Fixes#22752
On line 1021 you are passing base style to props:
`style: [baseStyle, this.props.style],`
Explicitly passing base style to ScrollView just overrides this line and doesn't let developers to customise style of any inheritors of ScrollView (not only FlatList) with custom RefreshControl.
So this line (1113) seems to be removed.
## Changelog
[GENERAL] [Fixed] - fix of Android's bug that doesn't let override ScrollView's Style with custom RefreshControl.
Pull Request resolved: https://github.com/facebook/react-native/pull/24411
Differential Revision: D15713061
Pulled By: cpojer
fbshipit-source-id: 461259800f867af15e53e0743a5057ea4528ae69
Summary:
### Problem
According to https://github.com/facebook/react-native/issues/9145, the `--port` setting is not respected when executing `react-native run-android`. The templates that report things like what port the dev server runs on are hard coded as well.
### Solution
This commit replaces the hardcoded instances of port 8081 on Android with a build configuration property. This allows setting of the port React Native Android connects to for the local build server.
For this change to work, there must also be an update to the react native CLI to pass along this setting:
https://github.com/react-native-community/react-native-cli/compare/master...nhunzaker:9145-android-no-port-hardcode-cli
To avoid some noise on their end, I figured I wouldn't submit a PR until it's this approach is deemed workable.
## Changelog
[Android][fixed] - `react-native run-android --port <x>` correctly connects to dev server and related error messages display the correct port
Pull Request resolved: https://github.com/facebook/react-native/pull/23616
Differential Revision: D15645200
Pulled By: cpojer
fbshipit-source-id: 3bdfd458b8ac3ec78290736c9ed0db2e5776ed46
Summary:
Fixes build in Xcode 11 beta, the signature for `__unused` was changed. This adds a new check for the new style.
## Changelog
[iOS] [Fixed] - Xcode 11 beta build
Pull Request resolved: https://github.com/facebook/react-native/pull/25146
Differential Revision: D15628404
Pulled By: cpojer
fbshipit-source-id: 781a188a0e1562a3316fbe62920b12b03a44e4a7
Summary:
The accessibilityActions accessors in UIView+React.m are not aligned with the property declaration in the header file.
## Changelog
[General] [Fixed] - Fix accessibilityActions accessors
Pull Request resolved: https://github.com/facebook/react-native/pull/25134
Differential Revision: D15621848
Pulled By: cpojer
fbshipit-source-id: f344689292ae7988e46d0d4263980306d364366b
Summary:
Co-Authored: zamotany
With React Native 0.59.8 the app keeps crashing with indexed RAM bundle on Android with the following error:
```
2019-05-09 11:58:06.684 2793-2856/? E/AndroidRuntime: FATAL EXCEPTION: mqt_js
Process: com.ramtestapp, PID: 2793
com.facebook.jni.CppException: getPropertyAsObject: property '__fbRequireBatchedBridge' is not an Object
no stack
at com.facebook.react.bridge.queue.NativeRunnable.run(Native Method)
at android.os.Handler.handleCallback(Handler.java:873)
at android.os.Handler.dispatchMessage(Handler.java:99)
at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:29)
at android.os.Looper.loop(Looper.java:193)
at com.facebook.react.bridge.queue.MessageQueueThreadImpl$4.run(MessageQueueThreadImpl.java:232)
at java.lang.Thread.run(Thread.java:764)
```
After investigation we found that when using any bundle, let it be non-ram, FIle RAM bundle or Index RAM bundle, the `CatalystInstanceImpl.java` is always using `loadScriptsFromAsset`, which is calling `CatalystInstanceImpl::jniLoadScriptFromAssets` in C++. This method when checking if bundle is a RAM bundle, uses `JniJSModulesUnbundle::isUnbundle` which only check for js-modules/UNBUNDLE - file generated when building File RAM bundle. There is no other logic to handle Indexed RAM bundle, so it figures that the bundle is not RAM, cause there is no js-modules/UNBUNDLE file and tries to load as regular bundle and fails.
In this PR we added check if it is indexed RAM bundle in `jniLoadScriptFromAssets` and handle it if it is.
## Changelog
[Android] [Fixed] fix indexed RAM bundle
Solves https://github.com/facebook/react-native/issues/21282
Pull Request resolved: https://github.com/facebook/react-native/pull/24967
Differential Revision: D15575924
Pulled By: cpojer
fbshipit-source-id: 5ea428e0b793edd8242243f39f933d1092b35260
Summary:
The original reason for vendoring the fetch polyfill was to remove the default blob response type but this was reverted.
Here's a little history around the fetch polyfill and the blob issue:
- Original commit introducing the vendored polyfill: #19333, the goal was to fix a memory leak because our blob implementation doesn't release resources automatically. Not an ideal fix but since the issue was pretty severe and the infra for a proper fix was not in place.
- This introduced an issue when downloading images using `fetch` which was fixed by #22063 which re-added the default blob content type. However that re-introduced the original fetch memory leak.
- We have better infra now with jsi and I was able to get blob deallocation working, see #24405
Currently the vendored fetch polyfill is useless since it was changed back to the original version. We can just use the npm version again. I also updated to 3.0 which brings better spec compliance and support for cancellation via `AbortController`, https://github.com/github/fetch/releases/tag/v3.0.0.
## Changelog
[General] [Changed] - Remove vendored fetch polyfill, update to whatwg-fetch@3.0
Pull Request resolved: https://github.com/facebook/react-native/pull/24418
Differential Revision: D14932683
Pulled By: cpojer
fbshipit-source-id: 915e3d25978e8b9d7507ed807e7fba45aa88385a
Summary:
If you (try to) build React Native for Android without having the NDK properly installed and referenced, you get the following error:
>A problem occurred evaluating project ':ReactAndroid'.
\> Cannot get property 'absolutePath' on null object
This is not an overly helpful diagnostic. This PR results in this message instead:
>ndk-build binary cannot be found, check if you've set $ANDROID_NDK environment variable correctly or if ndk.dir is setup in local.properties
Fixes#25087
## Changelog
[Android] [Fixed] - Show proper error message instead of throwing a NullReferenceException if Gradle cannot find the NDK
Pull Request resolved: https://github.com/facebook/react-native/pull/25088
Differential Revision: D15559271
Pulled By: cpojer
fbshipit-source-id: 35c9a9321af4e4a34bf519144ada48884b48352d
Summary:
This PR solves bug https://github.com/facebook/react-native/issues/24393 for Android. Allows an app to be opened with an NFC tag and getting the url trough Linking.getInitialURL()
## Changelog
[Android] [Fixed] - This branch checks also for `ACTION_NDEF_DISCOVERED` intent matches to set the initialURL
Pull Request resolved: https://github.com/facebook/react-native/pull/25055
Differential Revision: D15516873
Pulled By: cpojer
fbshipit-source-id: e8803738d857a69e1063e926fc3858a416a0b25e
Summary:
Changelog: [Android] [FIXED] - Fix backgroundColor top level prop of TextInput
This diff fixes two issues with the `backgroundColor` top level property of TextInput on Android:
* Now it is possible to set a **string** value for the top-level `backgroundColor` property of TextInput (crashed the app previously):
```
<TextInput backgroundColor="#ffccbb">Hello, React Native</TextInput>
```
* Now it's possible to set an **integer** value for the top-level `backgroundColor` property of TextInput (had no effect previously):
```
<TextInput backgroundColor={0xffccbbff}>Hello, React Native</TextInput>
```
A `customType = "Color"` annotation parameter must be provided for `ReactBaseTextShadowNode.setBackgroundColor(...)` since the color value must be previously processed in JS before sending it over the bridge to the native code. The JS code will parse the color value and return the proper ARGB color integer to the native platforms (https://fburl.com/uqup52tn).
Without providing the custom type for the background color, if a string value is set for the top-level `backgroundColor` property in the JS code, the Android code will crash since it expects an integer value for the color in `ReactBaseTextShadowNode.setBackgroundColor(...)`, but a string will be passed from JS without any conversion and there will be a `ClassCastException` thrown. If an integer value without the alpha component (like `0xffccbb`) is set, the Android native view would get an integer color value with its alpha component set to `0x00`, which means a transparent color.
On a side note: the alpha component of a color must always be set when using an integer value for `backgroundColor` since the JS code, while processing the color type, shifts the rightmost 8 bytes (alpha component) to the leftmost position. If those 8 bytes are not the alpha component, you will get the wrong color in the end. It doesn't seem to be a problem for string values of `backgroundColor` though.
Reviewed By: mdvacca
Differential Revision: D15453980
fbshipit-source-id: f3f5d9c9877cdbce79a67f2ed93ad4589576d166
Summary:
This diff adds a new `--test` option to `js1 build viewconfigs` which will only check that the configs have not changed instead of writing the new/updated files. This will allow us to run sandcastle checks on the view configs
I also improved the output of the script to give better feedback during normal runs including an additional message and a summary of generated files
Reviewed By: TheSavior
Differential Revision: D15372843
fbshipit-source-id: 4988fc2405cc03137b540817e08d4365cb31fc34
Summary: Fixes a flow failure in the generated output and adds trailing commas to pass linting
Reviewed By: yungsters
Differential Revision: D15354725
fbshipit-source-id: 1eac27fa753af595a9a2787426b147e5f49a4e1d
Summary: After reading the native code, all bubbling and direct events need to start with "top", but we were only doing this for bubbling in the view config. Updated and added comments pointing to native behaviors
Reviewed By: TheSavior
Differential Revision: D15336080
fbshipit-source-id: d8f883f5fd41bb7856a334849dc7fce0c8922872
Summary: This removes the NetInfo import from RN and moves it to FB internal. Follow-up diffs will move the Android and iOS files as well.
Reviewed By: rubennorte
Differential Revision: D15392486
fbshipit-source-id: b868b671b8d91661bc7634b4662074ae953835be
Summary:
In case `RCTView` had no subviews, `RCTRecursiveAccessibilityLabel` was returning an empty string rather than nil.
I've noticed that https://fburl.com/i95iynxi returns empty string as well. Shall we change it there as well?
Reviewed By: shergin
Differential Revision: D15337865
fbshipit-source-id: 8e38a88321f3dcfdf35a38d43fdbe4f5118796f1
Summary:
The `Linking.openURL()` method is supposed to resolve to a `true` `Promise` when the URL was properly open. However, in iOS, the `Promise` was resolving to `nil`. So I fixed this issue by making it resolve to `YES` (`true`), just like on Android.
## Changelog
[iOS] [Fixed] - Fix return value of `Linking.openURL()`
Pull Request resolved: https://github.com/facebook/react-native/pull/24955
Differential Revision: D15411994
Pulled By: cpojer
fbshipit-source-id: 90bdd6cfae8d69d7a239a0b4c84d75859e293b32
Summary:
This is a reconstitution of #24190. It extends accessibility actions to include both a name and user facing label. These extensions support both standard and custom actions.
We've also added actions support on Android, and added examples to RNTester showing how both standard and custom accessibility actions are used.
## Changelog
[general] [changed] - Enhanced accessibility actions support
Pull Request resolved: https://github.com/facebook/react-native/pull/24695
Differential Revision: D15391408
Pulled By: cpojer
fbshipit-source-id: 5ed48004d46d9887da53baea7fdcd0e7e15c5739
Summary:
`scrollEventThrottle` is often a source of confusion, especially when using native animated since users expect that it doesn't affect `Animated.event` but it does. We added a default prop to Animated.ScrollView but not to `Animated.FlatList` and `Animated.SectionList` so this adds it for those.
## Changelog
[JavaScript] [Added] - Add default scrollEventThrottle to Animated{FlatList, SectionList}
Pull Request resolved: https://github.com/facebook/react-native/pull/24954
Differential Revision: D15411998
Pulled By: cpojer
fbshipit-source-id: 41589a96c0a8b75ae7cf3169ccef363ac5140ad3
Summary:
While working on https://github.com/facebook/react-native/pull/24893 I noticed the `WebSocket` module implementation on iOS was ignoring the code and reason arguments for the `close` method.
The Android implementation already handled those arguments properly.
So this PR brings iOS implementation on par with Android for the `WebSocket` module.
## Changelog
[iOS] [Fixed] - Fixed `code` and `reason` arguments ignored on iOS when calling `WebSocket.close`
Pull Request resolved: https://github.com/facebook/react-native/pull/24950
Differential Revision: D15411922
Pulled By: cpojer
fbshipit-source-id: f8a25598bd9c727313e24fea3801d5884d0723e4
Summary: Using Mutex lock_guard mechanism when writing to subscribers and when accessing them in publish to make a copy
Reviewed By: davidaurelio
Differential Revision: D15391679
fbshipit-source-id: 16713ff28ce1762a5ca4c48c152897a92417e80b
Summary:
Straightforward.
Rick, I rename some stuff, I hope you are cool with that.
Reviewed By: mdvacca
Differential Revision: D15403306
fbshipit-source-id: 1dbd34060052a9bd39ed4211010f14b76fffcde6
Summary: This is implementation of standard PullToRefresh component that uses standard iOS component and modern integration approach.
Reviewed By: mdvacca
Differential Revision: D15403308
fbshipit-source-id: 5c877f7c18af9f5ac40e15a4ba44118614ba80bc
Summary: This way we can reuse this code in other RCTScrollViewComponentView-satellite components, especially in standard pull-to-refresh component.
Reviewed By: mdvacca
Differential Revision: D15403307
fbshipit-source-id: 5999f851f22db0f358887e1a86d610e163adcb1d
Summary:
Fix Issue https://github.com/facebook/react-native/issues/24820
It's caused by `_labelsForTags` and `RCTPLTag` being out of sync, the crash might only be one of the issues that this bug was causing.
## Changelog
[iOS] [Fixed] - fix crash on performance logger
Pull Request resolved: https://github.com/facebook/react-native/pull/24821
Differential Revision: D15407291
Pulled By: PeteTheHeat
fbshipit-source-id: c8d2a047fceb9cec981c48fe5181d1b4cbf0976c
Summary:
This diff contains two changes:
* The actual UIScrollView is now mounted inside the component as `contentView` which mostly means that border-props will properly affect the layout of the scroll view (the scroll view will be laid out inside borders, not on top of those). And that also simplifies the code.
* Now the component view exposes the actual scroll view, its delegate splitter, and the container view defining a single interface for all possible integration that can be done with the Scroll View Component.
Reviewed By: mdvacca
Differential Revision: D15397283
fbshipit-source-id: 35e860b8bf55fbd4d0a5f4116f79e4507df79098
Summary:
There was a reason why it exists: on iOS if you want to implement a view with rounded corners with a non-transparent background you need to set `clipToBounds = YES` to enabling clipping because besides drawing borders we need to clip the background otherwise it will "stick out".
There were a bunch of problems with this implementation and approach:
* It's overshooting. It applies `clipToBounds` no matter which border-radius is and no matter is there a background or not. So, it's kinda heuristic implementation and it's totally unexpected behavior sometimes.
* The previous problems can lead to performance problems as well (clipping requires additional work to do for CoreGraphics/GPU).
* The border-radius that we assigned to contentView is incorrect because it does not take border-width into account.
* This functionality only applies to non-null `contentView` which is a rear and custom case in which that can always be done manually for components that require that for some reason.
Reviewed By: mdvacca
Differential Revision: D15397282
fbshipit-source-id: 1599882ca8e591a9c4edb4d2b845bbf3d147bfce
Summary: Make sure that `importKeys` doesn't choke on null `map_`, since ReadableNativeMap can have a null backing `map_`.
Reviewed By: mdvacca
Differential Revision: D15360094
fbshipit-source-id: b507bdd93c247153aa34e4f62ac6f93349c1faf5
Summary: Force `getConstants` in native modules to return an empty object when they're not defined in their native implementations.
Reviewed By: fkgozali
Differential Revision: D15393585
fbshipit-source-id: cdda9df0d0f0a98ba226340d3cee67fec63e106c
Summary:
1. Consistency with full stops (you can see screenshots in https://github.com/facebook/react-native/pull/24783 )
2. Improvements to the wording, describing what you're going to see
## Changelog
[Internal] [Fixed] - Improves the copy for the new app screen
Pull Request resolved: https://github.com/facebook/react-native/pull/24918
Differential Revision: D15391421
Pulled By: cpojer
fbshipit-source-id: 2ec6d2d5bd4845c5f4c699838ae865ab4217e49e
Summary:
Removes the hacks we had in place to help Fabric run in RNTester. Runs fine without them now, so let's remove em!
## Changelog
[Internal] [Removed] - RNTester Fabric hax
Pull Request resolved: https://github.com/facebook/react-native/pull/24924
Differential Revision: D15391418
Pulled By: cpojer
fbshipit-source-id: d800f4c2f68f5e68a20a03c65fdf0317072d2c5e
Summary:
This is already handled cleanly on the JS side of things in AnimatedInterpolation.js: https://github.com/facebook/react-native/blob/0ee5f68929610106ee6864baa04ea90be0fc5160/Libraries/Animated/src/nodes/AnimatedInterpolation.js#L133-L142
However, the native driver interpolation will try to divide by 0, produce NaN and then crash. This change just copies the logic from the JS version of the interpolation logic and adds it to the Java version.
Note that this bug only reproduces on Android Q. It seems that RenderNode::setCameraDistance now crashes when receiving NaN on Android Q.
Reviewed By: sahrens
Differential Revision: D15380844
fbshipit-source-id: cfa82d8f58574e1040a851aaa5b5af1e23c9daa8
Summary:
In D15367312, I deprecate `$Enum<...>` in favour of `$Keys<...>` (the functionality is identical). Codemod existing usages in xplat and fbcode.
bypass-lint
Reviewed By: samwgoldman
Differential Revision: D15378084
fbshipit-source-id: 251c6b9ac07cb50139a8f03e3a45a5fac0d91812
Summary:
Adds one byte of private storage to `YGNode`, intended to be used by Yoga itself.
This is in previously unused alignment space, and won’t cause more memory to be allocated.
Reviewed By: SidharthGuglani
Differential Revision: D15296732
fbshipit-source-id: 3caf0a3cd506e4e324e51c31869c69be5781d476
Summary: Style bits had overlap, because `dimensionBit` was set with an incorrect increment.
Reviewed By: SidharthGuglani
Differential Revision: D15335134
fbshipit-source-id: 370e1a73547d76b0e26bc6ab67acb96d33ddf180
Summary: `android.util.ArrayMap` ins't available on API < 19. Let's use the one that Android Support Library (aka AndroidX) provides.
Reviewed By: mdvacca
Differential Revision: D15372704
fbshipit-source-id: 5c2ea3c7ea7368bb75ff22c54af0b258558556b5
Summary: This diff adds the android specific View view config props that I missed in an earlier diff in this stack
Reviewed By: cpojer
Differential Revision: D15336076
fbshipit-source-id: 6d20462b2682e3ea80b0ffc95ef35aa7618d4cf2
Summary:
## Overview
This diff switches the RCTSlider onSlidingComplete event on iOS from a bubbling event to a direct (non-bubbling) event to match the non-bubbling type on android.
Note that in this case these seems like a bug. I will still explain the motivation and reasoning as this will come up in future diffs.
## Changelog
[Slider][BREAKING] Switch Slider onSlidingComplete event to a non-bubbling event on iOS to match Android
## Motivation:
The motivation here is that when we codgen the view configs, we'll need to unify all of the events and props across platforms for components that have the same name on iOS and Android.
In this case, the view configs (below) conflict for onSlidingComplete. On iOS this is under bubblingEventTypes, on Android this is under directEventTypes. We have code [here](https://fburl.com/3s1dahm2) in the react native renderer which ensures an event is not listed as both.
```
// iOS
const SliderViewConfig = {
bubblingEventTypes: {
onSlidingComplete: {
phasedRegistrationNames: {
captured: 'onChangeCapture',
bubbled: 'onChange'
}
}
},
directEventTypes: {
// None
},
validAttributes: {
// ...
}
};
```
```
// Android
const SliderViewConfig = {
bubblingEventTypes: {
// None
},
directEventTypes: {
onSlidingComplete: {
registrationName: 'onEventDirect'
}
},
validAttributes: {
// ...
}
};
```
## Solutions
There are three solutions to this issue:
1. Don't generate view configs
2. Rename the component on one platform
3. Make a breaking change in the event behavior on one platform to make it consistent across both platforms
Here we've chosen option #3
Reviewed By: TheSavior
Differential Revision: D15322304
fbshipit-source-id: ff1ab86efe9e2bc50fd3f7619e6760ab5c1c5090
Summary: We're going to be incrementally adding these view configs and enforcing that they're up to date in react-native-sanity-test so we need to limit them to what's supported (which is just Slider for now)
Reviewed By: TheSavior
Differential Revision: D15321950
fbshipit-source-id: 22b014db1d9b58553237f571b438c82948f19634
Summary:
In order to generate the view configs, we need to know the name of the component used in:
```
ReactNativeViewConfigRegistry.register(
'RCTNativeComponent', // <------- this name
() => BooleanPropNativeComponentViewConfig,
);
```
For this, we'll use `component.name` in the schema (see fixture updates). Doing this would break the native code we generate though, since that code has the RCT stripped.
So this diff adds support to mirror the native stripping of 'RCT' for generated native code
Reviewed By: TheSavior
Differential Revision: D15320422
fbshipit-source-id: be1ab9964078df2c7bc6e41462776f00b94b104f
Summary: This diff adds a line to the codegen'd view configs which will check that all of the properties in the native view config are also in the JS view config we generate (note that the JS view config may have more properties than one native platform because it includes a union of both platforms)
Reviewed By: TheSavior
Differential Revision: D15278478
fbshipit-source-id: 0fef20c12265b952c69aca4e4c070a7d036db05a
Summary: This diff inserts the differs for color/image/point inline into the generated viewconfigs
Reviewed By: TheSavior
Differential Revision: D15258752
fbshipit-source-id: 0e93dc6abc186851b411dfd6864d5b4ca005885b
Summary:
This diff adds a new `js1` script `js1 build viewconfigs` which will generate the view configs for generated components in xplat/js
Note that the view configs are not currently valid so I'm not checking them in or adding them to a test, that work will follow
Reviewed By: TheSavior
Differential Revision: D15239656
fbshipit-source-id: d15776f36a7d7684f50beafd783bccb02352afc0
Summary:
PR https://github.com/facebook/react-native/pull/24843 broke Android tests because of a regression we introduced in terms of passing `reporter` argument to Metro config. This was fixed in latest `alpha.20` release of CLI
## Changelog
[General] [Fix] - update CLI to alpha.20 to fix Android tests
Pull Request resolved: https://github.com/facebook/react-native/pull/24869
Reviewed By: rickhanlonii
Differential Revision: D15355144
Pulled By: cpojer
fbshipit-source-id: faafd8098c708845264b7164557076bce45ea332
Summary:
This is a TODO, we met crash if we don't call `retainArguments` when return type is like `NSDictionary`, the reason is `getReturnValue` don't retain the return value, so we need to using `__bridge` to transfer ownership to OC type.
Also add `resolveBlock` and `rejectBlock` to `retainedObjectsForInvocation`.
cc. cpojer
## Changelog
[iOS] [Fixed] - Remove retainArguments && do retain by us explicitly
Pull Request resolved: https://github.com/facebook/react-native/pull/24849
Differential Revision: D15369209
Pulled By: fkgozali
fbshipit-source-id: 8431d03705d8476f38c8b5d29630489a545d373a
Summary:
Some ObjC NativeModules conform to `RCTInvalidating` protocol and implements `invalidate` method. This is typically used to clean things up during bridge teardown or reload. In TurboModule system the invalidate method can be replaced by pure destructors, but for backward compatibility, we call existing invalidate method on each module during teardown.
This also cleans up all existing LongLivedObject's.
Reviewed By: mdvacca, RSNara
Differential Revision: D15365655
fbshipit-source-id: 802844b39b5b7adb54970ea541f4d744bbf9e480
Summary:
With the introduction of TurboModules, it would be beneficial to measure the setup time of these modules, as we currently have it in place for NativeModules.
The instantiation of the TMs occurs in the `RCTTurboModuleManager`. In order to successfully measure the time it took to setup the module, we need to ensure that we don't take into account cached modules. As such, we need to:
1. Check if module is in `_turboModuleCache`
a. Start mark for `RCTPLTurboModuleSetup` tag if not found
2. Get the TM via `[self provideTurboModule:]`
3. Check if module is in `_turboModuleCache`
a. Stop mark for `RCTPLTurboModuleSetup` if we did not find module in cache prior to **step 2** and if it's now present in the cache.
b. Notify about setup time if the above is true.
4. Return TM
## Changelog
[iOS] [Added] - Gain insights on the the turbo module setup times by observing `RCTDidSetupModuleNotification`. The userInfo dictionary will contain the module name and setup time in milliseconds. These values can be extracted via `RCTDidSetupModuleNotificationModuleNameKey` and `RCTDidSetupModuleNotificationSetupTimeKey`.
Pull Request resolved: https://github.com/facebook/react-native/pull/24732
Differential Revision: D15362088
Pulled By: RSNara
fbshipit-source-id: e6a8044e4aba5a12ae63e9c7dbf707a17ec00180
Summary: Future improvements in RCTScrollViewComponentView require ability to have multiple listeners of UIScrollViewDelegate (e.g. PullToRefresh component needs it), therefore we need a splitter to support it.
Reviewed By: JoshuaGross
Differential Revision: D15345301
fbshipit-source-id: 62bb50c4fdd4fa64ece5d7cc6ddc76367c84c4b3
Summary:
This is the final piece of change that makes measuring (`LayoutableShadowNode::getRelativeLayoutMetrics()`) take ScrollView content offset into account (on iOS).
It works pretty simply: at the end of scrolling (or zooming) action ScrollView updates the state which later can be used for computing `transform` which measuring uses to adjust values in LaoutMetrics.
Reviewed By: mdvacca
Differential Revision: D15323688
fbshipit-source-id: fdf86c6cd9bdfd56caddd4b39bdd1185760b9f94
Summary: Seems we need this now to enable future improvements in ScrollView such as correct measure, pull-to-refresh and so on.
Reviewed By: mdvacca
Differential Revision: D15323687
fbshipit-source-id: fae37431ccbbf2faec9c84752396153689b873ef
Summary: A couple of new methods in ConcreteShadowNode allows us to deal with State in more LocalData-like manner.
Reviewed By: mdvacca
Differential Revision: D15323686
fbshipit-source-id: ede4aa1f1d0ad6f876bd963e57a00a0ad470c1c0
Summary:
using shared_ptr for vector of subscribers
Further changes in commit stack support the mutiple subscribers in event system
Reviewed By: davidaurelio
Differential Revision: D15352512
fbshipit-source-id: fac7f4268abf9ca4277734aca2f21cd711eb7d6e
Summary:
Replaced global event subscriber with a vector of subscriber functions
Further changes in commit stack support the mutiple subscribers in event system
Reviewed By: davidaurelio
Differential Revision: D15352451
fbshipit-source-id: 7ca6f0943735bf1f76a906c23e15e14ae3c5f42c
Summary:
This PR fixes the content being shown behind the `StatusBar` in the new app template, was only happening in iOS.
## Changelog
[General] [Changed] - Fix content being shown behind `StatusBar` in the new app template.
Pull Request resolved: https://github.com/facebook/react-native/pull/24868
Differential Revision: D15353748
Pulled By: cpojer
fbshipit-source-id: 4c84a65d9f8e85e5558d447533e381126c971e38
Summary:
Revert Gradle download plugin import, because new way is causing some issues when building from source.
## Changelog
[Android] [Changed] - revert Gradle download plugin import
Pull Request resolved: https://github.com/facebook/react-native/pull/24863
Differential Revision: D15352002
Pulled By: cpojer
fbshipit-source-id: 5996ce8aeeca1fdd8b43fdc9087af705cf7f682d
Summary:
There has been push back to remove this module from React Native. Since it is contentious, let's revert the deprecation and table this conversation until later.
## Changelog
[General] [Changed] - Undeprecate StatusBar for now.
Pull Request resolved: https://github.com/facebook/react-native/pull/24860
Differential Revision: D15351835
Pulled By: cpojer
fbshipit-source-id: 2f40f3a8f17ab7631bf5441cd6528b04103e7821
Summary:
Adds YogaEventListener interface and it's implementation which will be used in flipper for events coming from Yoga
After this diff , we will start getting layout calculate events in flipper listener
Reviewed By: davidaurelio
Differential Revision: D15316928
fbshipit-source-id: da3a53374a52386037b553d460038d988b0162c2
Summary: We don't need it anymore because we don't use folly::Future.
Reviewed By: JoshuaGross
Differential Revision: D15344961
fbshipit-source-id: a368e600d69e6879f6a98b4a997de85c71186e92
Summary: This check isn't needed in prod as the bundle is served with the app. In dev mode it's possible to have native and JS out of sync.
Reviewed By: yungsters
Differential Revision: D15268485
fbshipit-source-id: 9aeeb6cf5ca91baa90b85e18c848c3b10d85b0f7
Summary:
The `measure` API receives LocalData and Props, it should also receive State.
This will also be used in future diffs.
Reviewed By: mdvacca
Differential Revision: D15325182
fbshipit-source-id: 6cb46dd603ce7d46673def16f0ddb517e2cf0c4f
Summary: In D15252375 I made JSCallInvoker an abstract class and extended it in BridgeJSCallInvoker, but I forgot to add the `override` keyword for overridden methods.
Reviewed By: fkgozali
Differential Revision: D15328292
fbshipit-source-id: 3e75faf1b4a968b80643b8a97071ab2e122fd643
Summary: If some stack frames in a trace fail to symbolicate (or are genuinely unmapped), their `frame` field will be null, and `ExceptionsManager.js` will currently crash. This diff lets it recover gracefully and show whatever information is available.
Reviewed By: dcaspi
Differential Revision: D15296220
fbshipit-source-id: 2b1006b1354295171b25bfc6230c5b3e0c57f67f
Summary:
Fixes redbox/yellowbox symbolication when the Java delta client is enabled. Previously the modules would get concatenated in a nondeterministic order (owing to Metro's parallelism) which differed from their order in the source map, where they're explicitly sorted by module ID.
This diff changes the data structure holding modules in memory from a `LinkedHashMap` (which iterates in insertion order) to a `TreeMap` (which iterates in key order).
NOTE: Similar to this change in the Chrome debugger's delta client: https://github.com/react-native-community/cli/pull/279
Reviewed By: dcaspi
Differential Revision: D15301927
fbshipit-source-id: 27bdecfb3d6963aa358e4d542c8b7663fd9eb437
Summary:
In ContextContainer, only in Debug mode, we store type information alongside with data to detect typemismatch in runtime. We used type hashes before, but seems they are not so stable and can cause some false negative crashes.
This diff changes that to store mangled typenames instead of hashes, so it should be much more reliable now.
Reviewed By: JoshuaGross
Differential Revision: D15325728
fbshipit-source-id: 3a0f1116e1336af79adb51f38ce83c37aee4cad1
Summary:
This PR is related to #24760 and adds the `openURLInBrowser` functionality introduced on react-native-community/cli#383.
[General] [Changed] - Open links from new app in computer's browser.
Pull Request resolved: https://github.com/facebook/react-native/pull/24843
Reviewed By: rickhanlonii
Differential Revision: D15334011
Pulled By: cpojer
fbshipit-source-id: 947ad1b113923989cf706e60851e02a87e1099e8
Summary:
first, I edited this post so that the comment below are NOT relevant any more
problem: `scrollToLocation` behavior in SectionList on master is inconsistent between platforms.
Recently, there have been two PRs changing this function: https://github.com/facebook/react-native/pull/21577 and https://github.com/facebook/react-native/pull/24034
let me just quote the [docs](https://facebook.github.io/react-native/docs/sectionlist#scrolltolocation) here
> Scrolls to the item at the specified sectionIndex and itemIndex (within the section)
originally, the code was `let index = params.itemIndex + 1;`
so if we call
```js
node.scrollToLocation({
animated: false,
itemIndex: 0,
sectionIndex: 0,
viewPosition: 0,
viewOffset: 0,
});
```
inside scrollToLocation, index is incremented and that results into the list scrolling to the first item (the first section heading is not visible - see the gif). If I specify `itemIndex = -1`, it will scroll all the way up. I was expecting `itemIndex = 0` to bring me all the way up, so that the first section heading is visible. Not sure which way this should work but at least this behavior is in line with the docs.
next, there was https://github.com/facebook/react-native/pull/21577 that changed it to
`let index = Platform.OS === 'ios' ? params.itemIndex: params.itemIndex - 1;`
so that https://github.com/facebook/react-native/issues/18098 is fixed. The PR had a bug and so next, there was https://github.com/facebook/react-native/pull/24034 that changed it to
`let index = Platform.OS === 'ios' ? params.itemIndex : params.itemIndex + 1;`
the reasoning was
> Note however, how the sign for non iOS changed from + to - causing a crash on Android when trying to scroll to index 0 as that will be evaluated to -1 instead of 1 and thus be out of bounds.
with this change, the list does not crash. However, the behavior is not consistent between platforms (see gifs):
So, this PR works under the assumption that
```js
node.scrollToLocation({
animated: false,
itemIndex: 0,
sectionIndex: 0,
viewPosition: 0,
viewOffset: 0,
});
```
should scroll all the way up, so that even the first section heading is visible. This should keep this bug https://github.com/facebook/react-native/issues/18098 fixed. However, this change means different behavior from how it used to be and from how it is documented, which should be pointed out in release notes and docs need to be updated.
Finally, if we agree this is the way to go, it'd be nice to have some automated tests.
cc melina7890 danilobuerger
[Android][Fixed] - fix scrollToLocation not consistent between platforms
Pull Request resolved: https://github.com/facebook/react-native/pull/24734
Differential Revision: D15334565
Pulled By: cpojer
fbshipit-source-id: f7122ef4a5c252fc3e0d2112861d1460742e9fa4
Summary:
This replaces the "new app screen" in the template with the new design from https://github.com/react-native-community/discussions-and-proposals/issues/122
This uses components that are shipped as part of the `react-native` module, but not necessarily as proper components exported by the main `react-native` module. To use these, we use absolute imports to those components.
Related to #24760
[General] [Changed] - Updated new app template design 💖
Pull Request resolved: https://github.com/facebook/react-native/pull/24805
Differential Revision: D15334459
Pulled By: cpojer
fbshipit-source-id: d0b67d08f936eeabd9e93d4e0ff78302b4d6429f
Summary:
When running Android app for the first time, the packager is requesting delta bundles from metro instead of a bundle (in dev settings delta bundles are disabled by default and marked as experimental). UI of dev settings is not consistent with the current state, to turn off delta bundles you have to enable them and then disable.
[Android] [Fixed] - Disable delta bundles on the first app run
Pull Request resolved: https://github.com/facebook/react-native/pull/24848
Differential Revision: D15334059
Pulled By: cpojer
fbshipit-source-id: 384a8abba64c54db3656a4d5d0e24acc825870c8
Summary:
The files in `ReactAndroid/src/androidTest/js` use Haste names; this commit migrates them to use path-based imports. This helps us move RN towards standard path-based requires. All the requires in `androidTest` have been rewritten to use relative requires.
[General] [Changed] - Migrate "androidTest" JS from Haste to path-based requires
Pull Request resolved: https://github.com/facebook/react-native/pull/24813
Differential Revision: D15318108
Pulled By: cpojer
fbshipit-source-id: dddc68f992b8dea48afb01fd4481bd5b846231ca
Summary:
We provided `ReactNetworkForceWifiOnly` in https://github.com/facebook/react-native/pull/24242, but it's a string type, actually the value only YES or NO, so let's change it to Boolean type, we can benefit from:
1. Users don't need to type string `YES`, just select bool YES or NO directly by click the button:
<img width="789" alt="image" src="https://user-images.githubusercontent.com/5061845/57634311-a8af7400-75d7-11e9-9f8a-ebf865d672e3.png">
2. Don't need to do string compare.
3. More looks what it should looks, Boolean is the Boolean. :)
cc. cpojer ericlewis .
[iOS] [Changed] - Change ReactNetworkForceWifiOnly from String to Boolean
Pull Request resolved: https://github.com/facebook/react-native/pull/24829
Differential Revision: D15323685
Pulled By: cpojer
fbshipit-source-id: c626d048d0cbea46d45f232906fd3ac32a412741
Summary:
Original commit changeset: f149721d6b4d (D15238379)
This commit was causing the following crash: Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'An instance 0x7fb3453eda00 of class RCTUITextField was deallocated while key value observers were still registered with it.
FB: See also P64445585 T44107377 T44169319
Reviewed By: mmmulani
Differential Revision: D15323255
fbshipit-source-id: 037c34ae387d912c5ea03eaa364b8c60367df357
Summary:
The bug description can see https://github.com/facebook/react-native/issues/24688, we add `contentView` size check before center the content, because in some cases, the contentView's size not yet be calculated, in those cases, we don't adjust the `contentOffset`.
cc. cpojer .
[iOS] [Fixed] - Fixes ScrollView centerContent not work in some cases
Pull Request resolved: https://github.com/facebook/react-native/pull/24817
Differential Revision: D15322502
Pulled By: sahrens
fbshipit-source-id: e2081f13e9f2e8597a379a9db1607451ea496909
Summary: The existing implementation of JSCallInvoker holds a reference to Instance (aka the bridge). This diff makes JSCallInvoker an abstract base class that's extended by BridgeJSCallInvoker, which is what's returned by CatalystInstance to initialize TurboModules. This will allow us to add another class that derives from JSCallInvoker that doesn't rely on the bridge.
Reviewed By: shergin
Differential Revision: D15252375
fbshipit-source-id: 75eee2ca149235a63e2a2cd8cdd361b163d1d1ab
Summary:
@public
RocksDB was originally available when RN open sourced but is no longer used, so removing it from AsyncStorage.js.
Changelog: [General] Removed RocksDB from AsyncStorage.js
Reviewed By: fkgozali
Differential Revision: D15218709
fbshipit-source-id: 82993f86bbb3f32e61d1e9895aafd67701351860
Summary:
We are getting errors where views are being dropped twice.
This is following from logic that viewManagers are only removed from `mTagsToViewManagers` from `dropView`.
This log will hopefully identify if we are getting improper operations because we shouldn't be re-using tags
Reviewed By: mdvacca
Differential Revision: D15152869
fbshipit-source-id: 914ee9c1772fa066adefde0753075ecba6377a0c
Summary:
Now that inline views are supported on iOS and Android, we can add some examples to RNTester. I brought back examples from https://github.com/facebook/react-native/commit/03663491c6e68409f73d5c9bbc1a2e3c02ee0966.
I also added some new inline view examples in TextInlineView.js. Note that some examples are only supported on iOS because they rely on the inline view being able to size to content. Android's implementation requires that a width and height be specified on the inline view.
Here are the known bugs illustrated by these examples:
- ClippedByText
- Expected: The image/view wraps to the next line (because it is too wide) and gets clipped vertically (because it is too tall).
- iOS bug: The image/view does not get wrapped to the next line
- Android bug: The view gets wrapped to the next line but doesn't get clipped vertically. The image appears to be positioned too low.
- ChangeImageSize/ChangeViewSize:
- Expected: The "Change Image/View Width" button causes the image/view to toggle between a width of 50 and 100.
- iOS bug: First update works. Subsequent updates don't get rendered.
- Android bug: No updates get rendered.
- ChangeInnerViewSize:
- Expected: The "Change Pink View Width" button causes the pink inner view to toggle between a width of 50 and 100.
- iOS bug: First update works but second update **CRASHES** the app.
- Android bug: No updates get rendered.
[Internal] [Added] - Added inline view examples to RNTester
Pull Request resolved: https://github.com/facebook/react-native/pull/24814
Differential Revision: D15318070
Pulled By: cpojer
fbshipit-source-id: 35a4aaab88e477d627456eeb4208c509c42927df
Summary:
Add link to ECOSYSTEM.md and clean up markdown formatting.
[Internal] [Added] - Edit to CONTRIBUTING.md, add link to ECOSYSTEM.md
Pull Request resolved: https://github.com/facebook/react-native/pull/24808
Differential Revision: D15316889
Pulled By: cpojer
fbshipit-source-id: 1805b957d7480ca5e3a8a36bf86b75d23193cd55
Summary:
Bugs like https://github.com/facebook/react-native/issues/24789, we don't apply tintColor to GIF. We fixes it by setting a poster image before add animation.
cc. cpojer .
[iOS] [Fixed] - Fixes renderingMode not applied to GIF images
Pull Request resolved: https://github.com/facebook/react-native/pull/24794
Differential Revision: D15316913
Pulled By: cpojer
fbshipit-source-id: 611a07ec17afc962d1eb6b8fc193f118fa623e73
Summary:
This adds in a link to the reactnative Twitter handle so our users can follow along with the latest and greatest of React Native!
Related to #24760
[General] [Added] - Added link to reactnative Twitter handle to Learn More section
Pull Request resolved: https://github.com/facebook/react-native/pull/24806
Differential Revision: D15316771
Pulled By: cpojer
fbshipit-source-id: cd45f005cfbcbd277fadb48be8943d60f4386767
Summary:
This is the next step in moving RN towards standard path-based requires. All the requires in `Libraries/vendor` have been rewritten to use relative requires. Talking to cpojer, the vendored code in RN can be modified directly.
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.
Closes#24769.
[General] [Changed] - Migrate vendored code from Haste to path-based imports
Pull Request resolved: https://github.com/facebook/react-native/pull/24807
Differential Revision: D15316831
Pulled By: cpojer
fbshipit-source-id: 19475823ce9f506600bd09b001156e306bff4db8
Summary:
Some users (me included) have projects located in quirky places, resulting whitespaces in the path.
An example, , I symlink into my iCloud drive which result in the following path
```
/Users/r/Library/Mobile Documents/com~apple~CloudDocs/_/work/{a_company}/repos.nosync/app
```
This commit quotes the variable to make sure it gets properly passed to the CLI.
For reference, similar issue that has been resolved: https://github.com/react-native/react-native/commit/7d4e94edccfc2f642fcbd1d6aa00756f02e3a525
Pull Request resolved: https://github.com/facebook/react-native/pull/24810
Differential Revision: D15316898
Pulled By: cpojer
fbshipit-source-id: 4ed2c8391d65d1680e836bfce8c51dfb5763caed
Summary:
On iOS in React Native, immediately after successfully connecting to a WiFi network, if 4G is also on, it is possible that network requests sent via fetch get sent over 4G instead of WiFi for several seconds (between 1 and 40+ seconds depending on the device and network in my experience). If the calls are meant to be communicating with a local Wireless Device (such as a wireless router, etc.), then API calls that get sent over 4G to the internet are lost. Note that Reachability/NetInfo are saying that we are connected to a WiFi network and are not sufficient to prevent this from happening. To prevent this, I would like to be able to set an instance property that iOS exposes for network requests allowsCellularAccess to NO to ensure a request is never sent over 4G.
This code needs to be able to accept a flag to allow the user to override the default value of YES, but only when they explicitly opt in to this decision. I am not sure the best place to set and pass in this value, so I created [this issue](https://github.com/react-native-community/discussions-and-proposals/issues/113), where it was recommended that I make a PR and discuss how best to do this here. Before this PR could be merged we would need to allow the NO to be configurable in some way.
Additional information about the [allowsCellularAccess](https://developer.apple.com/documentation/foundation/nsurlsessionconfiguration/1409406-allowscellularaccess?language=objc) property can be found in the [Apple documentation.](https://developer.apple.com/library/archive/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/Platform-SpecificNetworkingTechnologies/Platform-SpecificNetworkingTechnologies.html#//apple_ref/doc/uid/TP40010220-CH212-SW9)
[iOS] [Added] - Ability to force network requests to use WiFi using the allowsCellularAccess property. This can ensure that network requests are sent over WiFi if communicating with a local hardware device and is accomplished by setting a flag. Default behavior of allowing network connections over cellular networks when available is unchanged.
Pull Request resolved: https://github.com/facebook/react-native/pull/24242
Differential Revision: D15316760
Pulled By: cpojer
fbshipit-source-id: 96df43b4eff6b4301c853df6b2e5c6e1bb1abda0
Summary:
Adds `LayoutPassStart` and `LayoutPassEnd` events.
The existing `NodeLayout` event in isolation is not as useful as it could be. Having events that mark start and end of a layout pass are a useful addition.
Differential Revision: D15305467
fbshipit-source-id: 14af6f65e698fb1e3112eb2ffd87a74d31df4840
Summary:
This diff ensures the method scheduler.constraintSurfaceLayout is executed before the JS run application start.
This is necessary to properly set the pointScaleFactor for the Root before running JS.
This is a workaround to fix a bug when the pointScaleFactor changes over time for the rootShadowNode. The bug is easily reproducible when rendering the "fabric" indicator on Fabric screens. During the first render of a Fabric screen this method was called before "JS run application" starts, and the Fabric indicator was render correctly.
Beacuse of timing of measure APIS, the second time a Fabric screen is rendered the method is called after the "JS run application process started", as a consecuence the Fabric indicator is not rendered correctlly (the pointScaleFactor is incorrectly assigned into the layout metrics of the Fabric indicator text).
We still need to analyze why the pointScaleFactor is not correctly assigned when it is set after the "JS run application process started", but this will be part of another diff.
Reviewed By: shergin
Differential Revision: D15303554
fbshipit-source-id: 7d985cefee20fd40dbe04166c1a1358b3f3ddc85
Summary:
Previously the pointScaleFactor field was not being compared properly in LayoutMetrics equality method.
This diff fixes that
Reviewed By: shergin
Differential Revision: D15303555
fbshipit-source-id: 8863e9e1fbad15b43400afc32b97bf6d252cbe55
Summary: `YogaStylableProps.yogaStyle` is designed to be consumed by Yoga only. Making it `protected` allows us to avoid confusion and misuse of this props.
Reviewed By: JoshuaGross
Differential Revision: D15296474
fbshipit-source-id: cf9e416afee99fb426d72765557b34d303a63dbe
Summary: We needed that in the very beginning when diffing algorithm produces mount instructions for <Text> nodes which don't have ComponentView representation, so we simply silence those error here. That's not the case anymore, so we don't need those ugly checks.
Reviewed By: JoshuaGross
Differential Revision: D15296473
fbshipit-source-id: ea3717062056907e5395776fe95e3d581d3e9b09
Summary: RCTComponentViewRegistry is not a thread-safe class and must be accessed only from the main thread.
Reviewed By: JoshuaGross
Differential Revision: D15296475
fbshipit-source-id: 67192abd6290191f3b8119972efc41cec48a793a
Summary: self should be assigned to result of [super init]
Reviewed By: shergin
Differential Revision: D15295275
fbshipit-source-id: 722ae9ad3f9fb8ee3a86892bfb5b2a4cb7b8c708
Summary:
ReactNativeRenderer has `require('scheduler')` in it but we don't seem to declare a dependency. As a result, the latest sync broke `useEffect` in open source master:
```js
function Counter() {
const [count, setCount] = useState(0);
useEffect(() => {
const id = setInterval(() => {
setCount(c => c + 1);
}, 1000)
return () => clearInterval(id);
}, [])
return <View><Text>{count}</Text></View>
}
```
<img width="535" alt="Screen Shot 2019-05-10 at 3 26 05 PM" src="https://user-images.githubusercontent.com/810438/57535832-e04dc000-733a-11e9-8e3e-d685171ec55a.png">
This adds an explicit dependency on the same version we're currently using internally.
<img width="535" alt="Screen Shot 2019-05-10 at 3 47 42 PM" src="https://user-images.githubusercontent.com/810438/57535886-f65b8080-733a-11e9-82c3-78e6c3a3888b.png">
Pull Request resolved: https://github.com/facebook/react-native/pull/24802
Differential Revision: D15295252
Pulled By: hramos
fbshipit-source-id: cd897ac590de1b719f28234f7631b0dcc069d043
Summary:
Fixes#13351
Two root causes:
1. Android Spinner will reset selection to undefined after setAdapter()
which will trigger onValueChange().
The behavior is not expected for RN.
And the solution is to setSelection() explicitly
2. In original implementation, it setups `items` immediately,
but delays the `selected` setup after update transaction.
There will be some race condition and incosistency
if update `items` only.
The fix will do the setup all after update transaction.
[Android] [Fixed] - Fix#13351 PickerAndroid will reset selected value during items update.
Pull Request resolved: https://github.com/facebook/react-native/pull/24793
Differential Revision: D15293516
Pulled By: cpojer
fbshipit-source-id: 5a99a60015c7e1b2968252cdc0b2661d52a15b9d
Summary:
Fixes this issue:
https://github.com/facebook/react-native/issues/24468
It was incorrectly closed by a fix on react-native-community CameraRoll implementation. CameraRoll in react-native still crashes when finding a file with # sign
[Android] [Fix] - Fix Android Camera Roll crash on mime type guessing
Pull Request resolved: https://github.com/facebook/react-native/pull/24780
Reviewed By: mdvacca
Differential Revision: D15281062
Pulled By: lunaleaps
fbshipit-source-id: ca3364c8478d9bfc9a0a6657b531ffb384145d8c
Summary:
This is the first step in revamping the Contribution Guide at `/CONTRIBUTING.md`. This work will require changes to the React Native website repository, as well as the React Native GitHub wiki. For review purposes, changes to copy that exists outside of this repository will be included within a `.github/wiki` directory in this PR, but they are not intended to be part of the final PR that gets merged.
[General] [Changed] - Contribution Guide Revamp
Pull Request resolved: https://github.com/facebook/react-native/pull/24705
Differential Revision: D15290268
Pulled By: hramos
fbshipit-source-id: b09c86738e75143fbdf2fea97ccd860da79362d2
Summary: In the future we're planning to decouple ThemedReactContext from the bridge (CatalystInstance). For now, we just need to be able to create a ThemedReactContext with a ReactContext that has no Catalyst instance.
Reviewed By: mdvacca
Differential Revision: D15246442
fbshipit-source-id: 99ebda6521f4df72969011ea0e6ea41b046875c8
Summary: This diff replaces usage of abort() with assert() when a prop-value is not found during parsing of prop values
Reviewed By: shergin
Differential Revision: D14563338
fbshipit-source-id: c799420e6b49df35e1d7ccdbd4bc4845067d33cc
Summary: Refactoring ReactContext to move message queue initialization into its own function that can be called independently of initializeWithInstance. This allows you to create a ReactContext with message queue threads without a CatalystInstance.
Reviewed By: mdvacca
Differential Revision: D15246287
fbshipit-source-id: 4b8c53e68112af7eded47d8c31311500cc296dfe
Summary: Now it's implementled differently (see -[RCTComponentViewRegistry preallocateViewComponents]), so this code is not being used.
Reviewed By: mdvacca
Differential Revision: D15242045
fbshipit-source-id: c02eceb978cf1eae778f84a73456e7156ccf503b
Summary:
ImageLoader is an actual external dependency, not a ImageManager.
That change allows to remove dependency on ImageManager from SurfacePresenter and make some other code simpler.
Reviewed By: mdvacca
Differential Revision: D15242047
fbshipit-source-id: 8622d15b8fdb5c3a7e25091adf7be1108f87ecd5
Summary: The particular meaningful piece of code that diff removes was added as (successful) attempt to fix an issue which was lately fixed by D14868547.
Reviewed By: mdvacca
Differential Revision: D15242046
fbshipit-source-id: 88a3e3c629d7c5f84c402b03e45034644147fec4
Summary:
Related to #24760 and #24737
This simplifies some styling within the components used for the New App Screen to help advocate for best practices when styling with CSS-like styles in React Native, as well as using React Native's own unique components.
There's a bit more detail in each commit. Let me know if you'd like me to pull that info out into the PR description here!
[General] [Changed] - Polished up new app screen component styling
Pull Request resolved: https://github.com/facebook/react-native/pull/24783
Differential Revision: D15284851
Pulled By: cpojer
fbshipit-source-id: 954db00d39fc0082bbd4dc96afa7d38dfb7f67d5
Summary:
UITextView is accessible by default (some nested views are) and disabling that is not supported.
The problem happened because JS side sets `isAccessible` flag for UITextView and UITextField to `true` (with good intent!), which actually disables (surprise!) bult-in accessibility of TextInput on iOS.
On iOS accessible elements cannot be nested, so enabling accessibily for some container view (even in a case where this is view is a public API of TextInput on iOS) shadows some features implemented inside the component.
(Disabling accessibility of TextInput via `accessible=false` was never supported.)
Reviewed By: JoshuaGross
Differential Revision: D15280667
fbshipit-source-id: 72509b40383db6ef66c4263bd920f5ee56a42fc1
Summary: Right now TurboModuleManager gets the JSCallInvokerHolder from the bridge in its constructor; this diff changes the constructor to make the JSCallInvokerHolder a required argument so that TurboModuleManager doesn't directly depend on the bridge.
Reviewed By: axe-fb, RSNara
Differential Revision: D15227184
fbshipit-source-id: b16e6abaa727587986a132d0e124163acdf55408
Summary:
This diff changes the condition in `ViewShadowNode::isLayoutOnly()` removing checking for `onLayout` event listener.
We needed that before because the mechanism of emitting events was based on analyzing mutation instructures (we needed those to be generated for nodes with `onLayout`).
Recenly we changed that algorithm deeply integrating in layout infra, so we don't need this anymore.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D15273491
fbshipit-source-id: 2d43f00d1b87369d5993fe5ba70c2de36b8ce0c5
Summary: RCTBridge does not need to retain RCTSurfacePresenter, so we enforce that using `OBJC_ASSOCIATION_ASSIGN`.
Reviewed By: mdvacca
Differential Revision: D15273325
fbshipit-source-id: f223192ff5f781d9e905b004907739a36882bb63
Summary:
Fixes an issue introduced in https://github.com/facebook/react-native/pull/15894 that can cause events to be dispatched out of order.
Also reverted `viewTag` moved to optional property as it didn't actually work and makes code more complex.
[iOS] [Fixed] - Fix event ordering when combining coalescable and non-coalescable events
Pull Request resolved: https://github.com/facebook/react-native/pull/24693
Differential Revision: D15279513
Pulled By: shergin
fbshipit-source-id: 3c64aba6d644ea9564572e6de8330b59b51cf4a9
Summary:
If `$buildDir/generated/res/react/${flavorPathSegment}release/raw` contains files during `gradle assembleRelease` script will fail with `Error: Duplicate resources` error.
This patch is based on this issue [22234](https://github.com/facebook/react-native/issues/22234) and pull request [24518](https://github.com/facebook/react-native/pull/24518).
[Android] [Fixed] - Fix duplicate resource error for raw folder in Android build
[CC from Mike Hardy PR]
Reports of success on the linked issue via use of the patch + patch-package for a couple months, I personally use it full time with all gradle builds (./gradlew clean assembleRelease or if you have a 'staging' flavor, e.g. ./gradlew clean assembleStagingRelease)
Related reading, also cross-links with the linked issue here:
https://stackoverflow.com/questions/53239705/react-native-error-duplicate-resources-android
Pull Request resolved: https://github.com/facebook/react-native/pull/24778
Differential Revision: D15277766
Pulled By: cpojer
fbshipit-source-id: 0ccd76d2aa2e13f7c8bfac07d4ef23b74945807a
Summary:
Issue #22234 includes a number of people (myself included) suffering with duplicate resource errors while building in Android. We have been collectively using a patch there but I don't believe any attempt has been made to PR it upstream.
I am not excellent at gradle, so I may have approached this in completely the wrong way, but it works for me in the standard init templates, as well as my current work project which has a complicated 2 buildType + 4 productFlavor configuration. If there is a better way to achieve the result I am happy to learn
The approach here is to determine the generated path the resources land in, then move them into the main build output tree. If they remain in the generated path android merging fails with duplicate resource errors, so that move (vs copy) is important.
[Android] [Fixed] - Fix duplicate resource error in Android build
Pull Request resolved: https://github.com/facebook/react-native/pull/24518
Differential Revision: D15276981
Pulled By: cpojer
fbshipit-source-id: 3fe8c8556e4dcdac5f96a2d4658ac9b5d9b67379
Summary:
@public
`YGNodeGetInstanceCount` was only ever meant for tests, and caused data races in multi-threaded environments.
It was completely replaced with event-based counting for tests.
Here we remove public API around the counter, and the counter itself.
Reviewed By: SidharthGuglani
Differential Revision: D15174857
fbshipit-source-id: 228e85da565bac9e8485121e956a2e41910b11c8
Summary:
@public
Test utility on top of the new event system that maintains a counter of instantiated nodes. Meant to replace the global node counter.
Reviewed By: SidharthGuglani
Differential Revision: D15174855
fbshipit-source-id: 6998472f95a09b8da652257a26596164bdcf43d6
Summary:
@public
Publish two events, `NodeAllocation` and `NodeDeallocation`, in the same places where the global node counter is changed.
Reviewed By: SidharthGuglani
Differential Revision: D15174858
fbshipit-source-id: 6e4e9add88513b9e987189ca5035d76da2a1de55
Summary:
Eliminate the regression template, as it is hardly used and it is already served by the bug report template. Triagers can add the Regression label selectively, or we can do so through the bot.
Eliminate the discussion template, as it is not meant to be used and we can point people in the right direction using the existing questions template.
Rename the document bug template, and point people to the website repo.
Update the bug report template, and be less prescriptive about how an issue is reported. As long as the issue is well-described and the steps to repro can be reasonably followed by someone who is investigating the bug, we'll be happy.
[Internal] [Changed] - Consolidated issue templates.
Pull Request resolved: https://github.com/facebook/react-native/pull/24765
Differential Revision: D15276866
Pulled By: cpojer
fbshipit-source-id: d99a174982d2454d8cad3a195dfd627a07438611
Summary:
@public
Reduces measure cache size to a number that is enough for 95% of nodes, according to our (FB-internal) measurements.
Node size: 776b -> 584b
Reviewed By: SidharthGuglani
Differential Revision: D15183567
fbshipit-source-id: 9ae8cc78074271a015e7618b931ba0356de87a0c
Summary:
See e94b116d76 which broke RNTester in open source. Environment variables are always strings, so "0" is a truthy value. This fixes it.
[iOS] [fixed] - Fixed broken RNTester
Pull Request resolved: https://github.com/facebook/react-native/pull/24736
Reviewed By: fkgozali
Differential Revision: D15272951
Pulled By: hramos
fbshipit-source-id: aa78f229e05cb553f75cdf6fb4f926829e20a557
Summary: Apparently, Yoga has a "quirks mode" and we have to enable that for Fabric. Which is probably a mistake that we have to make one more time.
Reviewed By: davidaurelio
Differential Revision: D15267852
fbshipit-source-id: 88a910fafc9ff64fb19376f4b74a2f2fd5827eba
Summary:
See e94b116d76 which broke RNTester in open source. Environment variables are always strings, so "0" is a truthy value. This fixes it.
[iOS] [fixed] - Fixed broken RNTester
Pull Request resolved: https://github.com/facebook/react-native/pull/24736
Differential Revision: D15240810
Pulled By: hramos
fbshipit-source-id: 76f498222b6ac05131b3820d8356bfee696f46b8
Summary:
Continuation of #24687
> Issue: [Polish the "new app screen"](https://github.com/react-native-community/discussions-and-proposals/issues/122)
> This is the pull request for the new intro screen proposal in react native as directed by cpojer
This PR was created because the previous one could not be pushed to for some reason. I cleaned up a few small things and added the component as an example to RNTester so we can keep iterating. My plan is to land this, and then polish it and make it the default in a follow-up.
[General][Added] - New Intro screen, Icons
Removed Lottie Integration
100% React Native 💥
Pull Request resolved: https://github.com/facebook/react-native/pull/24737
Differential Revision: D15259092
Pulled By: cpojer
fbshipit-source-id: bc141fb1425cf354f29deffd907c37f83fd92c75
Summary:
Our Blob implementation was very problematic because it didn't release its underlying resource when the JS instance was dealocated. The main issue is that the fetch polyfill uses blobs by default if the module is available, which causes large memory leaks.
This fixes it by using the new jsi infra to attach a `jsi::HostObject` (`BlobCollector`) to `Blob` instances. This way when the `Blob` is collected, the `BlobCollector` also gets collected. Using the `jsi::HostObject` dtor we can schedule the cleanup of native resources. This is definitely not the ideal solution but otherwise it would require rewriting the whole module using TurboModules + jsi.
Fixes#23801, #20352, #21092
[General] [Fixed] - [Blob] Release underlying resources when JS instance in GC'ed
Pull Request resolved: https://github.com/facebook/react-native/pull/24745
Reviewed By: fkgozali
Differential Revision: D15248848
Pulled By: hramos
fbshipit-source-id: 1da835cc935dfbf4e7bb6fbf2aea29bfdc9bd6fa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/24764
The `test_android` CI build was failing:
```
./scripts/circleci/buck_fetch.sh
+ buck fetch ReactAndroid/src/test/java/com/facebook/react/modules
Not using buckd because watchman isn't installed.
Picked up _JAVA_OPTIONS: -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap
PARSING BUCK FILES: FINISHED IN 1.1s
No build file at ReactAndroid/src/main/libraries/fbjni/BUCK when resolving target //ReactAndroid/src/main/libraries/fbjni:java.
This error happened while trying to get dependency '//ReactAndroid/src/main/libraries/fbjni:java' of target '//ReactAndroid/src/main/java/com/facebook/react/turbomodule/core:jscallinvokerholder'
Exited with code 1
```
The problem was that I was using `react_native_dep("libraries/fbjni:java")` to access JNI classes like `HybridData`. In open source this target translates to the path `//ReactAndroid/src/main/libraries/fbjni`, which doesn't exist. Instead, the actual classes are available at the path `//ReactAndroid/src/main/java/com/facebook/jni`. Therefore, I changed the target to `react_native_dep("java/com/facebook/jni:jni")`. This is exactly how the bridge (i.e: `//ReactAndroid/src/main/java/com/facebook/react/bridge:bridge`) accesses JNI clases.
Reviewed By: hramos
Differential Revision: D15261218
fbshipit-source-id: 659a5627389bbca3603db7de347618cd400d4ffc
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:
This is another step in moving RN towards standard path-based requires. All the requires in Jest's setup script have been rewritten to use relative requires. 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.
[General] [Changed] - Migrate Jest setup scripts from Haste to path-based requires
Pull Request resolved: https://github.com/facebook/react-native/pull/24753
Differential Revision: D15258238
Pulled By: cpojer
fbshipit-source-id: aa05dc8ea2e4ba195226e8ec7ba6482b7de03240
Summary:
AccessibilityInfo.announceForAccessibility is currently only available on iOS. I've added the Android specific implementation, updated RNTester, and the documentation.
[Android] [Added] - Added AccessibilityInfo.announceForAccessibility for Android
[General] [Added] - RNTester example for AccessibilityInfo.announceForAccessibility
Pull Request resolved: https://github.com/facebook/react-native/pull/24746
Differential Revision: D15258054
Pulled By: cpojer
fbshipit-source-id: 3e057a5c32b28e30ea2ee74a18854b012cd2dbfd
Summary:
React Native Gesture Handler uses a `RCTViewManager` subclass to manage `UIControl` so the cast to set accessibility props is not safe. This moves the accessibility props we set to `UIView+React` so they can be used safely on any `UIView`.

[General] [Fixed] - Move accessibility props to UIView+React
Pull Request resolved: https://github.com/facebook/react-native/pull/24743
Differential Revision: D15258062
Pulled By: cpojer
fbshipit-source-id: 4a25b79407e5cb7b3b368c7506161e989794bb26
Summary:
So far we have only officially supported "iOS" and "Android" as categories, with a "General" catch all for everything else.
Let's add a "JavaScript" category for changes that only affect JavaScript, and an "Internal" category for things that do not make sense in a changelog (e.g. CI changes).
[Internal] [Added] - Added JavaScript and Internal categories to changelog regex
Pull Request resolved: https://github.com/facebook/react-native/pull/24744
Differential Revision: D15258061
Pulled By: cpojer
fbshipit-source-id: 8b6cb193adf602d3bd6639b550e04775b201fe59
Summary:
Fix crash in XMLHttpRequest example because `groupTypes` is not supported on android.
[Android] [Fixed] - Fix crash in XMLHttpRequest example on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/24747
Differential Revision: D15258037
Pulled By: cpojer
fbshipit-source-id: 73086dc92ceb065200e0faafaf100fa742b387bb
Summary:
This is another step in moving RN towards standard path-based requires. All the requires in `IntegrationTests` have been rewritten to use relative requires. This commit uses requires that are relative to `react-native/...` assuming that IntegrationTests are meant to try consuming RN rather than being part of it.
See the umbrella issue at https://github.com/facebook/react-native/issues/24316 for more detail.
[General] [Changed] - Migrate IntegrationTests from Haste to path-based requires
Pull Request resolved: https://github.com/facebook/react-native/pull/24750
Differential Revision: D15258019
Pulled By: cpojer
fbshipit-source-id: 01ac01ba4699f8ba424353f74e745b4057f79b59
Summary:
See #24316 for the motivation. This commit rewrites a couple more new imports in the RNTester project so they use path-based requires.
[General] [Changed] - Migrate TurboModule example in RNTester to use path-based requires
Pull Request resolved: https://github.com/facebook/react-native/pull/24754
Differential Revision: D15258015
Pulled By: cpojer
fbshipit-source-id: adb298cb3006ea0afcd3b813a2e2fe85017764d2
Summary:
There are 2 issues:
* RCTTurboModuleManager may be initialized too late, so the module lookup from native via `[bridge moduleForClass:]` may end up going to the old system incorrectly
* In the case where JS is asking for a nativemodule, we may be incorrectly registering modules that are marked as RCTTurboModule - they should be ignored instead
Reviewed By: mmmulani, RSNara
Differential Revision: D15247632
fbshipit-source-id: 4e0fae33923810c74966b38276b206ac00723012
Summary: I don't recall why the mutation function return rvalue reference, but it is totally incorrect (the function cannot own the object, so returning a reference introducing a dungling pointer and will crash).
Reviewed By: mdvacca
Differential Revision: D15156312
fbshipit-source-id: 497d10de22a41906efe71cd10139e3710ae11a79
Summary:
In https://github.com/facebook/react-native/pull/23865, RN introduced support for custom fonts the Android Way. But it introduced performance regression because it'll lookup for a font using getIdentifier() every time fontFamily changed. This PR fixes regression by requiring custom fonts to be listed in **fonts** array, and populating **mTypeCache** at first use using the list.
[Android] [Changed] - Require custom fonts to list in **fonts** array. Fixes performance regression.
Pull Request resolved: https://github.com/facebook/react-native/pull/24595
Reviewed By: mdvacca
Differential Revision: D15184590
Pulled By: fkgozali
fbshipit-source-id: e3feb2396609583ebc95101130186a1f5af931da
Summary:
When using `scrollToLocation` together with `stickySectionHeadersEnabled` in a `SectionList`, the length of the section header is not accounted for when scrolling to any item except the header.
[General] [Fixed] - Adjust scrollToLocation when using sticky section headers
Pull Request resolved: https://github.com/facebook/react-native/pull/24735
Differential Revision: D15240953
Pulled By: cpojer
fbshipit-source-id: fd7121d990c5b01533e456bdfa39bebf6245fa80
Summary:
packagingOptions.pickFirst is unreliable that we could not specify which library will be used.
If user have other third party libraries, the story is more complicated.
From the framework point of view, it is better to drop the pickFirst.
In jsc-android 241213.1.0, we did two things:
1. Remove libc++_shared.so in AAR to prevent the conflict with RN.
2. Build by NDK r17c, which aligned with current RN NDK version.
In this commit, I also revert the pickFirst for JSC.
pickFirst JSC also makes upgrade JSC unreliable.
Currently a lot of user report JSC crash issues, those crash issues may relate to JIT and hard to reproduce in-house.
My plan is to make sure user could choose another JSC build easier,
i.e. only to `yarn add 'jsc-android@latest'`.
We could then propose some experimented JSC build for user to check
if the build could help them to fix the crash issue.
[Android] [Fixed] - Remove unreliable packagingOptions.pickFirst for libc++_shared.so and libjsc.so
NOTE that this may not need to add the changelog, as RN 0.59 does not have pickFirst.
This will also reduce a breaking change for upgrade from RN 0.59 or before.
Pull Request resolved: https://github.com/facebook/react-native/pull/24672
Differential Revision: D15164536
Pulled By: cpojer
fbshipit-source-id: 9fc897a77409173a5841f325b38e2836bb07f599
Summary: Adds disabled kebab case modal props now that we can safely generate them to cpp
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D15218837
fbshipit-source-id: d712e53f53d91ae14bba9956321530907f67d2e8
Summary: This diff adds support for kebab-case enum properties by transforming them to KebabCase in cpp
Reviewed By: mdvacca
Differential Revision: D15218781
fbshipit-source-id: 0ec6d28f3ca0e5b8187fc7026e12a8d76be73a7c
Summary:
Resolve#24690
This is very simple unicode detecting. Should I improve this solution creating StringsUtils for detecting unicodes in whole react-native project ?
[Android][Fixed] onKeyPress method is calling, when user type emoji
Pull Request resolved: https://github.com/facebook/react-native/pull/24717
Differential Revision: D15238388
Pulled By: cpojer
fbshipit-source-id: 038b1040e1c44fd6f9401a3988a782f5778e1209
Summary:
`UITextField` don't have delegate to observe the selection changes of users(multiline text input `UITextView` have it), so we can add a KVO to observe selection changes.
cpojer shergin
[iOS] [Fixed] - Fixes selection of single line text input
Pull Request resolved: https://github.com/facebook/react-native/pull/24714
Differential Revision: D15238379
Pulled By: cpojer
fbshipit-source-id: f149721d6b4df28e90f5a9405c74e01fde7c7d10
Summary:
In #24095, we removed the code that changes the underlying Android view's enabled state to false when "disabled" is included in the accessibility states, which seems correct. The Android view's state shouldn't mirror the accessibility state, it should be the other way round-- the accessibility state should represent the state of the view.
It seems that the existing test is brokenly setting the disabled state in the Javascript object, and then querying the Android view's enabled state to confirm the change. If the Button implementation is actually the culprit, then IMHO, the correct fix would be to have the Button implementation manipulate the Android View's enabled state, not the accessibilityStates code.
[android] [fix] - Fix internal test case around disabled state of buttons
Pull Request resolved: https://github.com/facebook/react-native/pull/24678
Differential Revision: D15237590
Pulled By: cpojer
fbshipit-source-id: d7ebefbcba9d4d9425da4285175302e4b6435df7
Summary:
PR https://github.com/facebook/react-native/pull/24633 introduced some inconsistency in crash messaging, this PR fix it. Asked by mhorowitz
[General] [Added] - Consistent reporting native module name on crash on native side
Pull Request resolved: https://github.com/facebook/react-native/pull/24704
Differential Revision: D15237424
Pulled By: cpojer
fbshipit-source-id: ded8db45b2a2ec9998ff33fdbecef3f12c19578f
Summary:
Fixes https://github.com/facebook/react-native/issues/23712
Currently, It seems like `__nativeAnimatedValueListener` is not listening to the correct `onAnimatedValueUpdate` events if component was re-mounted. In this PR I'm attaching a new listener if the native view tag has changed.
[General] [Fixed] - Fixed Animated.Value value after animation if component was re-mounted
Pull Request resolved: https://github.com/facebook/react-native/pull/24571
Differential Revision: D15237431
Pulled By: cpojer
fbshipit-source-id: 1fe4e290ab45dfe6d1d364d8d7384aabf18d6610
Summary:
Our Blob implementation was very problematic because it didn't release its underlying resource when the JS instance was dealocated. The main issue is that the fetch polyfill uses blobs by default if the module is available, which causes large memory leaks.
This fixes it by using the new jsi infra to attach a `jsi::HostObject` (`BlobCollector`) to `Blob` instances. This way when the `Blob` is collected, the `BlobCollector` also gets collected. Using the `jsi::HostObject` dtor we can schedule the cleanup of native resources. This is definitely not the ideal solution but otherwise it would require rewriting the whole module using TurboModules + jsi.
Fixes#23801, #20352, #21092
[General] [Fixed] - [Blob] Release underlying resources when JS instance in GC'ed
Pull Request resolved: https://github.com/facebook/react-native/pull/24405
Differential Revision: D15237418
Pulled By: cpojer
fbshipit-source-id: 00a94a54b0b172fbc62324364b753d192ac7016a
Summary: Apparently it's not used anymore. And that a good this.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D15219258
fbshipit-source-id: e3258d851d1eec5955d86f99a0b0d8a1b0304cb4
Summary: I have noticed that `backfaceVisibility` example crashes (because actual value is a string/enum, not a boolean), so I fixed it.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D15219261
fbshipit-source-id: 27f76cd10903794d597adacb9da7300a42813f8e
Summary: After this change, all measuring operations based on `LayoutableShadowNode::getRelativeLayoutMetrics` will take into account the transformation matrices provided by shadow nodes. This will allow implementing scroll-offset-aware and custom-transform-aware measuring.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D15219259
fbshipit-source-id: 1d7cd8c0ee4406f4dd0002cd442dc0679391922b
Summary: The diff implements a function that applies given transformation to a point.
Reviewed By: JoshuaGross
Differential Revision: D15219263
fbshipit-source-id: 4cc0595b0dda38c1ede1f2885b800cbe57f54243
Summary:
`LayoutableShadowNode::getTransform` returns a transform object that represents transformations that will/should
be applied on top of regular layout metrics by mounting layer.
Reviewed By: mdvacca
Differential Revision: D15219262
fbshipit-source-id: e7aeb85b5f7e2fce3f8faf9dfcaee5dae3217d36
Summary:
Add support for a `CI_USE_BUNDLE_PREFIX` envvar in the RNTester Xcode scheme, as part of ongoing work to enable integration tests in Facebook's internal CI system.
[iOS] [Added] - Add new envvar to support internal iOS tests at Facebook
Reviewed By: cpojer
Differential Revision: D15163397
fbshipit-source-id: 1b75b1868b5f9721a69f6cba4d4052be47e5e5e2
Summary:
The jest HasteImpl's `pluginNameReducers` regex was not properly escaping a backslash, resulting in unintended behavior.
The intent of the code is to strip the `.${name}` from the end of a filepath, where `name` is a platform name. The correct regex for that would be `^(.*)\.(myPlat)$`, but because the regex is being constructed from a string, the `\.` is being interpreted as an escaped period, resulting in the regex `^(.*).(myPlat)$`. To correct this, the backslash needs to be escaped so it makes it into the regex.
[General] [Fixed] - Fix HasteImpl platform name regex
Pull Request resolved: https://github.com/facebook/react-native/pull/24628
Differential Revision: D15224468
Pulled By: hramos
fbshipit-source-id: 6eb507aa5410bdd7c247e6d301052d41995a2f11
Summary: I'm not sure if this is a good idea. Right now FabricUIManager creates a ThemedReactContext in addRootView() using the RAC you pass in. If you pass in an RAC without a Catalyst instance, this will throw; this diff makes it so it'll throw the next time you try to actually try to access the CatalystInstance, instead. I don't know if we're really relying on this right now, but we need to be able to create a ThemedReactContext without a CatalystInstance for Venice (for now, until we actually go through and get rid of TRC's dependency on the CatalystInstance entirely - but that'll be a lot more work)
Reviewed By: mdvacca
Differential Revision: D15194220
fbshipit-source-id: 64689cbe79c84ae33fe16e3dc396e3c69ec8e20f
Summary: Refactoring ReactContext to move message queue initialization into its own function that can be called independently of initializeWithInstance. This allows you to create a ReactContext with message queue threads without a CatalystInstance.
Reviewed By: mdvacca
Differential Revision: D14817741
fbshipit-source-id: f314a526c6534792714e5ba55dd873f1728c6b9f
Summary:
We currently have "Type: Bug Report", "Type: Bug Fix", and "Impact: Bug" in our list of labels. To simplify life for maintainers, lets use a single Bug label.
This PR makes it so new Bug Reports use the "Bug" label. The bot has been updated to accept "Bug" as a valid template label already.
[General] [Changed] - New issues use the Bug label
Pull Request resolved: https://github.com/facebook/react-native/pull/24707
Differential Revision: D15220772
Pulled By: hramos
fbshipit-source-id: e25f7180839d2e6aa7211b805dfbf5368b39d738
Summary:
[General] [Fix] - Reorder operations of native view hierarchy
When we update the native view hierarchy in `manageChildren` we:
1. iterate through all views we plan to remove and remove them from the native hierarchy
2. iterate through all views we plan to add and add them to the native hierarchy
3. iterate through all views we plan to delete and delete them (remove them from memory)
This covers these cases:
a. A view is moved from one place to another -- handled by steps 1 & 2
b. A view is added -- handled by step 2
c. A view is deleted -- handled by step 1 & 3
> Note the difference between remove and delete
Everything above sounds fine! But...
The important bit:
**A view that is going to be deleted asynchronously (by a layout animation) is NOT removed in step 1. It is removed and deleted all in step 3.** See: https://fburl.com/ryxp626i
If the reader may recall we solved a similar problem in D14529038 where we introduced the `pendingIndicesToDelete` data structure to keep track of views that were marked for deletion but had not yet been deleted. An example of an order of operations that we would've solved with D14529038 is:
* we "delete" the view asynchronously (view A) in one operation
* we add a view B that shares a parent with view A in subsequent operation
* view A finally calls its callback after the animation is complete and removes itself from the native view hierarchy
A case that D14529038 would not fix:
1. we add a view B in one operation
2. we delete a view A in the same operation asynchronously because it's in a layout animation
3. ... etc.
What we must remember is that the index we use to add view B in step 1 is based on the indices assuming that all deletions are synchronous as this [comment notes](https://fburl.com/j9uillje): removals (both deletions and moveFroms) use the indices of the current order of the views and are assumed independent of each other. Whereas additions are indexed on the updated order (after deletions!)
This diff re-arranges the order in how we act upon the operations to update the native view hierarchy -- similar to how UIImplementation does its operations on the shadow tree here: https://fburl.com/j9uillje
By doing the removals and deletions first, we know that the addAt indices will be correct because either the view is removed from the native view hierarchy or `pendingIndicesToDelete` should be tracking an async delete already so the addAt index will be normalized
Reviewed By: mdvacca
Differential Revision: D15112664
fbshipit-source-id: 85d4b21211ac802183ca2f0fd28fc4437d312100
Summary:
This diff adds generated c++ tests for all generated components
There is a test for every prop based on type, and in the case of enums every allowed value
Reviewed By: shergin
Differential Revision: D15147126
fbshipit-source-id: b4f88d2dab825e41754a880081d86b3cd12274ee
Summary:
This diff forces the eager initialization of some additional classes into FabricJSIModuleProvider.loadClasses().
This is a "hack" that will be removed in the near future
Reviewed By: JoshuaGross
Differential Revision: D15208977
fbshipit-source-id: 2e2c7856839b6c6888452800ef6da7f269e46735
Summary: When passing StateWrapper objects across the JNI, we were not ensuring that the Java objects would own the C++ state. This was initially done because I assumed that in Java, State would either be used immediately or discarded, so this wouldn't be unsafe. As it turns out, it makes sense in some cases to store the StateWrapper in Java and use it later, potentially even in other threads, so we need to make sure we maintain ownership of the C++ object from the Java object.
Reviewed By: shergin
Differential Revision: D15206194
fbshipit-source-id: a437d921ba00b194cf08bad80666bd99baf11d52
Summary: This diff implements encapsulating all time metrics in a single class for better extensibility and readability.
Reviewed By: JoshuaGross
Differential Revision: D15179835
fbshipit-source-id: 62bdf94435a0d37a87ad9bad613cc8e38043a235
Summary:
Rename test_detox_end_to_end to test_end_to_end, then move JavaScript and iOS end-to-end tests to this job.
Fixes an issue in the end-to-end tests, but does not yet bring them back fully to green.
[General] [Changed] - Collect e2e tests under test_end_to_end job
Pull Request resolved: https://github.com/facebook/react-native/pull/24689
Differential Revision: D15202242
Pulled By: hramos
fbshipit-source-id: e7a9627896d2990cb6ddd0d3a91b915781ac2417
Summary: iOS TurboModules work in OSS. I pulled out JSCallInvoker from `React-turbomodule-core`, as a part of D15055511. In this diff, I'm adding it back in.
Reviewed By: mdvacca
Differential Revision: D15195007
fbshipit-source-id: 64ee294a68c0a63ba400b8a829864c6619d3311a
Summary:
`CatalystInstanceImpl.cpp` now depends on `JSCallInvoker` and `JavaJSCallInvokerHolder`. Therefore, we need to correctly adjust the OSS builds to include these dependencies into the `libreactnativejni.so` file.
I made `ReactCommon/turbomodule/jscallinvoker` a static library `libjscallinvoker.a`. I then made `ReactAndroid/src/main/jni/react/jni`'s `libreactnativejni.so` depend on that static library. Also, because the Android NDK build system doesn't support header namespaces, I had to use the filesystem to simulate them. This is why all the `.cpp` and `.h` files for `JSCallInvoker` were moved to a `jsireact` folder.
Reviewed By: mdvacca
Differential Revision: D15194821
fbshipit-source-id: 0cee682e41db53d0619f56ad017d5882f6d554aa
Summary:
`TurboModuleManagerDelegate` is an abstract base class with the following API:
```
public TurboModule getModule(String name, ReactApplicationContext reactApplicationContext);
public CxxModuleWrapper getLegacyCxxModule(String name, ReactApplicationContext reactApplicationContext);
```
```
std::shared_ptr<TurboModule> getTurboModule(std::string name, jni::global_ref<JTurboModule> turboModule, std::shared_ptr<JSCallInvoker> jsInvoker) override;
std::shared_ptr<TurboModule> getTurboModule(std::string name, std::shared_ptr<JSCallInvoker> jsInvoker) override;
```
On the C++ side, when asked to provide a TurboModule with name `name`:
1. First, is this a CxxModule? If so:
1. Create the CxxModule and return
2. Otherwise:
1. Somehow get a Java instance of the TurboModule
2. If this Java object represents a CxxModule, like `FbReactLibSodiumModule`:
1. Grab the C++ part of this object, and wrap it in a `TurboCxxModule.cpp` and return.
3. Otherwise:
1. Wrap the Java object in a C++ HostObject and return.
This pseudocode demonstrates how we'd use `TurboModuleManagerDelegate` to implement `__turboModuleProxy`.
```
__turboModuleProxy(name, jsCallInvoker):
let cxxModule = TurboModuleManagerDelegate::getTurboModule(name, jsCallInvoker)
if (!cxxModule) {
return cxxModule;
}
// JNI Call that forwards to TurboModuleManagerDelegate.getLegacyCxxModule
let javaCxxModule : CxxModuleWrapper = TurboModuleManager.getLegacyCxxModule(name)
if (!javaCxxModule) {
return std::shared_ptr<react::TurboCxxModule>(javaCxxModule.getModule())
}
// JNI Call that forwards to TurboModuleManagerDelegate.getModule
let javaModule : TurboModule = TurboModuleManager.getModule(name)
if (!javaCxxModule) {
return TurboModuleManagerDelegate::getTurboModule(name, javaModule, jsCallInvoker)
}
return null
```
Reviewed By: mdvacca
Differential Revision: D15111335
fbshipit-source-id: c7b0aeda0e4565e3a2729e7f9604775782b6f893
Summary:
JSCallInvoker requires a `std::weak_ptr<Instance>` to create. In our C++, `CatalystInstance` is responsible for creating this `Instance` object. This `CatalystInstance` C++ initialization is separate from the `TurboModuleManager` C++ initialization. Therefore, in this diff, I made `CatalystInstance` responsible for creating the `JSCallInvoker`. It then exposes the `JSCallInvoker` using a hybrid class called `JSCallInvokerHolder`, which contains a `std::shared_ptr<JSCallInvoker>` member variable. Using `CatalystInstance.getJSCallInvokerHolder()` in TurboModuleManager.java, we get a handle to this hybrid container. Then, we pass it this hybrid object to `TurboModuleManager::initHybrid`, which retrieves the `std::shared_ptr<JSCallInvoker>` from the `JavaJSCallInvokerHandler`.
There were a few cyclic dependencies, so I had to break down the buck targets:
- `CatalystInstanceImpl.java` depends on `JSCallInvokerHolderImpl.java`, and `TurboModuleManager.java` depends on classes that are packaged with `CatalystInstanceImpl.java`. So, I had to put `JSCallInvokerHolderImpl.java` in its own buck target.
- `CatalystInstance.cpp` depends on `JavaJSCallInvokerHolder.cpp`, and `TurboModuleManager.cpp` depends on classes that are build with `CatalystInstance.cpp`. So, I had to put `JavaJSCallInvokerHolder.cpp` in its own buck target. To make things simpler, I also moved `JSCallInvoker.{cpp,h}` files into the same buck target as `JavaJSCallInvokerHolder.{cpp,h}`.
I think these steps should be enough to create the TurboModuleManager without needing a bridge:
1. Make `JSCallInvoker` an abstract base class.
2. On Android, create another derived class of `JSCallInvoker` that doesn't depend on Instance.
3. Create `JavaJSCallInvokerHolder` using an instance of this new class somewhere in C++.
4. Pass this instance of `JavaJSCallInvokerHolder` to Java and use it to create/instatiate `TurboModuleManager`.
Regarding steps 1 and 2, we can also make JSCallInvoker accept a lambda.
Reviewed By: mdvacca
Differential Revision: D15055511
fbshipit-source-id: 0ad72a86599819ec35d421dbee7e140959a26ab6
Summary: Diffing algorithm uses a small map for every layer of shadow tree; that's a lot of maps. Luckily, it does not need a complex feature-full map (which is not free to allocate and use), it needs a tiny map with a dozen values. Why do we need to pay for what we don't use? This diff introduces a trivial map optimized for constraints that we have here. (See more details in the code.)
Reviewed By: mdvacca
Differential Revision: D15200495
fbshipit-source-id: d859b68b9543253840b403e7430f945a0b76d87b
Summary:
This is a small micro-optimization in Diffing algorithm.
Seems we don't need to store full ShadowView objects in `insertedPairs` map, we can store only pointers to them. That can save memory and CPU cycles because we will not need to store full objects and copy shared pointers (which is somewhat expensive).
Reviewed By: mdvacca
Differential Revision: D15200498
fbshipit-source-id: 2a268c3ee80755555bff3317e10e679be1cf9830
Summary: Diffing is already pretty fast, but using move semantic should make it even faster. ShadowViews have shared pointers, so moving them can save us atomic counter bumps.
Reviewed By: mdvacca
Differential Revision: D15200496
fbshipit-source-id: 6fb0eb79e07cd6ae9b3100713497c634f306bc18
Summary: Convert FabricUIManager.measure params to floats. Currently we convert parameters to ints across the JNI boundary, and then back to floats several times in Java. This is unnecessary and actually makes measurements trickier. The new implementation uses floats across the JNI boundary and uses Float.POSITIVE_INFINITY to represent unconstrained values, which is consistent with Fabric C++ as well.
Reviewed By: shergin, mdvacca
Differential Revision: D15176108
fbshipit-source-id: cf849b3773007637f059279460163872f300a4aa
Summary: Workaround for bugs with originalConsole.assert firing when it shouldn't.
Reviewed By: Hypuk
Differential Revision: D15201459
fbshipit-source-id: d4cf648725cf42754561468b23ea8edd7c1b84b2
Summary:
On iOS, `RCTRedBox` will not update the displayed stack trace if the message string sent with the update differs from the original error message. As JS errors are shown in two stages - before and after symbolication - there was previously a case where the message would differ between the two `updateExceptionMessage` calls, blocking the update and leaving only the unsymbolicated trace visible. This diff fixes that.
Longer term, we should also change `RCTRedBox`'s logic to rely on the JS-provided `exceptionID` instead of the message string - similar to what we do on Android.
Changelog:
[iOS] [Fixed] - Fix redbox JS symbolication when adding JS engine tag to the message
Reviewed By: sahrens
Differential Revision: D15202524
fbshipit-source-id: 237fc090e88b0c609865e0aed842d6a609c1239a
Summary: Looks like FBJNI exports a C Macro that does exactly what `throwIfJNIReportsPendingException` does. Therefore, I'm replacing `throwIfJNIReportsPendingException` with calls to `FACEBOOK_JNI_THROW_PENDING_EXCEPTION()`.
Reviewed By: mdvacca
Differential Revision: D15174820
fbshipit-source-id: 9dfb519352cbd5f37527675323cbabad05e31d4a
Summary:
`jclass` in `JNI` is just a regular local reference. Therefore, it's unsafe to keep a static reference to it. Link: http://journals.ecs.soton.ac.uk/java/tutorial/native1.1/implementing/refs.html.
This bug made it so that when you clicked on `getConstants` twice in the TurboModule playground, the app would crash.
Reviewed By: mdvacca
Differential Revision: D15174821
fbshipit-source-id: 13b2b8726473acc9b07306558044d26bed0db92d
Summary: Previously, we'd override the `TurboModule::get` method inside the `JavaTurboModule` class to return a special `jsi::Function` in the case that the property being accessed was "getConstants". We really don't need to do this because we can simply special-case the invocation of the `getConstants` method inside the `JavaTurboModule::invokeJavaMethod` method.
Reviewed By: mdvacca
Differential Revision: D15174822
fbshipit-source-id: 0ee705be841757d3870c908da911c3872b977a9f
Summary: We conducted an experiment with different measure cache sizes. This has now been deallocatedi (D15183473). Remove the necessary APIs.
Reviewed By: SidharthGuglani
Differential Revision: D15183486
fbshipit-source-id: a38fa5a3ab0321c2521265f7d1cd6b495efd76cf
Summary:
@public
`YGConfig::YGConfig(YGConfig*)` was not initializing the same fields as the default constructors.
Here, we make the default constructor delegate to the more specialized one to remove duplication.
Reviewed By: SidharthGuglani
Differential Revision: D15164599
fbshipit-source-id: 27247709091b7664386057d09ac67d481877871f
Summary:
In fabric, the measureLayout method expects 'node ref' instead of 'node handle'.
Node refs are supported by the current production version of RN and for Fabric, no changes should be expected in the current production version of RN
Reviewed By: TheSavior
Differential Revision: D15103116
fbshipit-source-id: cde94f61eaf6aa52ae4bd6f89082d18141d0da28
Summary:
* invokeMethod() ends up not useful because each platform has its own way of invoking the platform methods
* invalidate() is not necessary because there's already the destructor of each C++ class
Reviewed By: mdvacca
Differential Revision: D15187833
fbshipit-source-id: 9478ed1e6288da30c67179e03a7bc7da6043280b
Summary: This new target provides dependencies for using folly futures
Reviewed By: willholen
Differential Revision: D15018282
fbshipit-source-id: c38ad4775102b9f0c10b3a52c5a18f00aa398322
Summary: This make iteration work better without needing to clean as much
Reviewed By: willholen
Differential Revision: D15018285
fbshipit-source-id: 034f5529e2e51711aeaa75360ad10bb1f85c7fb8
Summary:
The path to copy log_severity.h could refer to the
destination, which would result in an empty file being copied on some
rebuilds.
Reviewed By: willholen
Differential Revision: D15018283
fbshipit-source-id: 0081526a9686de8c74753738c165753de6dda18d
Summary:
@public
We want to enable tooling, instrumentation, and statistics within Yoga without coupling these functionalities to our core code.
This commit introduces the foundations of a simple, global event system.
For the time being, we will only support a single subscriber. Should we require more than one, we can add support for it later.
Reviewed By: SidharthGuglani
Differential Revision: D15153678
fbshipit-source-id: 7d96f4c8def646a6a1b3908f946e7f81a6dba9c3
Summary:
Previously we computed the list of nodes that need to be notified about layout changes using a list of mutation instructions. That was fine, but that's not really compatible with some other changes that I plan to make, so I decided to change it (make it better).
Besides the better design (debatable; fewer dependencies to unrelated moving pieces), here is why I believe the new way is more performant:
* The new approach has no `dynamic_casts`, whereas the previous has tons of them (two per a mutation). If a `dynamic_cast` takes 10 ns, for 500 nodes it can take up to 5ms only for casts. (Non-scientific assumption.)
* After removing dependency to mutation instruction, we can enable flattening for views which have `onLayout` event.
Reviewed By: mdvacca
Differential Revision: D15110725
fbshipit-source-id: 31a657ccfd02441734ad1d71a833653223163289
Summary:
It's easy to accidentally trigger this invariant when adding / moving around a component that relies on a FlatList.
There might be some unexpected behavior when this occurs, i.e. messed up virtualization / viewability logging. But to me, that is a better outcome than crashing the JS context.
Reviewed By: sahrens
Differential Revision: D14975295
fbshipit-source-id: 18015a780a153aae995723b120440be0e55d8e8b
Summary: Instrumentation tests are expensive and flaky. Luckly this one does not need to be instrumentation one.
Reviewed By: mdvacca
Differential Revision: D15158985
fbshipit-source-id: 3c88e5a0d82db2cd00f5866c3f9956409cc8fc7f
Summary:
Currently, every time a touchable is pressed on Android, a system sound is played. It was added in the PR #17183. There is no way to disable it, except disabling touch on sound on the system level. I am pretty sure there are cases when touches should be silent and there should be an option to disable it.
Related PRs - #17183, #11136
[Android][added] - Added a touchSoundDisabled prop to Touchable. If true, doesn't system sound on touch.
Pull Request resolved: https://github.com/facebook/react-native/pull/24666
Differential Revision: D15166582
Pulled By: cpojer
fbshipit-source-id: 48bfe88f03f791e3b9c7cbd0e2eed80a2cfba8ee
Summary:
@public
Makes bitfield getters/setters part of the bitfield ref template.
Since we introduced the tracking bit as template parameter in D14933022, every bitfield ref is an individual class anyway, and having function pointers doesn’t potentially lead to less code generation anyway.
Furthermore, this change can (in the absence of tracking bits) avoid less specialized templates dealing with refs, and to dynamic dispatch as a consequence.
Reviewed By: SidharthGuglani
Differential Revision: D15085495
fbshipit-source-id: 0dd70fa05e9d43a29e38a619cddb642c9ca3f7ab
Summary:
@public
In order to optimise property storage, we have to know how style properties are used in our apps.
Here, we add a bitmask that allows us to track which properties are set explicitely, and use that for our analysis.
Reviewed By: SidharthGuglani
Differential Revision: D14933022
fbshipit-source-id: 1ab8af562b14baba1d02057e527aa36d5c9a7823
Summary:
@public
The extra overload of `updateStyle` introduced in D15078961 can also handle `BitfieldRef`.
That means that we can remove the more specific implementation previously introduced for `BitfieldRef`
Reviewed By: SidharthGuglani
Differential Revision: D15081069
fbshipit-source-id: 98f1f3478627974c5273c85d268ca07350f303d7
Summary:
@public
Change style property accessors to return `Ref` instances instead of references to `CompactValue`.
This will allow to track assignments to properties later on, e.g. for instrumentation or dynamic property storage.
Reviewed By: SidharthGuglani
Differential Revision: D15078961
fbshipit-source-id: 259f05f7d30f093c04bf333c5bd4fb3601b8e933
Summary:
When acquiring the `PARTIAL_WAKE_LOCK`, Android requires a tag to identify the source, normally the class name. This tag will show on dumpsys call and Google Play developer console.
`getSimpleName` will work fine as long as not enable ProGuard, in my case, it transformed the class name to just `"c"`, and I take my half day to find where the `c` comes from.
`getCanonicalName` will add the package path, which is more friendly for developers.
Later we can even let the developer choose the tag name, but this will require API break changes.
[Android] [Changed] - Use class canonical name for PARTIAL_WAKE_LOCK tag
Pull Request resolved: https://github.com/facebook/react-native/pull/24673
Differential Revision: D15164306
Pulled By: cpojer
fbshipit-source-id: fd65f9e5250c180b0053940b17877fe36af5d48b
Summary:
Start a `HeadlessJsTaskService` on Android without registered is dangerous on apps because `HeadlessJsTaskService` will acquire a [`PARTIAL_WAKE_LOCK`](https://developer.android.com/topic/performance/vitals/wakelock), without calling `onHeadlessJsTaskFinish` this lock won't release until timeout(if exist). This lock will prevent the android device from sleeping.
Although on JS will throw an error if no headless tasks registered, but it's hard to notice while app in the background. No visual information is displayed.
This PR will log a warning instead of Error, and just mark the task to finished on native if nothing registered in order to release the wake lock.
[Android] [Fixed] - Fix unexpected PARTIAL_WAKE_LOCK when no headless tasks registered.
Pull Request resolved: https://github.com/facebook/react-native/pull/24671
Differential Revision: D15164310
Pulled By: cpojer
fbshipit-source-id: 05b62017ba094d0faabc2848dc8bb6c26101321b
Summary: This diff exposes the Legacy method UIManager.measureInWindow as part of Fabric
Reviewed By: shergin
Differential Revision: D15110795
fbshipit-source-id: 2b4bf47452f7272fd3edc4e580e65ae7ec2f2622
Summary:
Different frameworks use different kinds of floats, optional floats, and floats with assigned unit names. All those approaches use different ways to represent undefined and empty values. To deal with it we need to have some helper functions.
So, this diff changes some ways that we convert some corner values (like NaN and empty value). That change is motivated by recent personal discoveries in this field that shifted my vision on that. E.g. ComponentKit does not use `CGFloatMax` value as `Infinite` value. UIKit is also (surprisingly to me) okay with using `Infitite` instead of `CGFloatMax`. And, in general, seems using really conceptually appropriate values (instead of UIKit-inspired ones) it's the right thing to do.
Reviewed By: mdvacca
Differential Revision: D15155189
fbshipit-source-id: 33e15141f1ca3efb400a7160811224335de34ba1
Summary: `kFloatUndefined` means "no value here", but in this particular case, we have to have `Infinity` value that represents maximum available space.
Reviewed By: mdvacca
Differential Revision: D15155190
fbshipit-source-id: d2de20681ad04da7444331eff44b93d2bd0200e3
Summary:
We don't need to have those constants because this functionality is available in STL via `std::numeric_limits<YourParticularFloatType>::infinity()` (or `::min()` and `::max()`).
At the same time usage of `kFloatMax` was replaced with `Infinity` (which is a different value). Using `max` instead of `Infinity` was an attempt to mimic iOS/UIKit model where `Infinity` and `NaN` values usually are not being used. However, now this does not seem like a good idea. This concept is not used anywhere else (even in CK which is totally incompatible with it) and de-facto in RN we use it only in few places. So, let's use Infinity in places where it's logically appropriate.
Reviewed By: mdvacca
Differential Revision: D15155191
fbshipit-source-id: 4d24350c7540cec074a8b040d7c13f257aa812e7
Summary: This diff exposes the Legacy method UIManager.measureLayout as part of Fabric
Reviewed By: shergin
Differential Revision: D15103117
fbshipit-source-id: 4cf7ab3776f6a541cf0d6a00789420a0bb008fae
Summary: This diff migrates VirtualizedList to use ref.measureLayout instead of UIManager.measureLayout, this is a pre-req to make measureLayout to work in Fabric
Reviewed By: JoshuaGross, TheSavior
Differential Revision: D14865762
fbshipit-source-id: 45dd3374813370188c914acfc7e631075508f74a
Summary: The map of sComponentNames ONLY contains the names of components that are different between JS and Android. This diff adds a method to unify the way we use this map.
Reviewed By: shergin
Differential Revision: D15076549
fbshipit-source-id: 9df750dca305e55cb44037bc63f3ebb6476c8b81
Summary:
This diff changes the style of the Modal container style as a pre-requisite to implement Modal on Fabric.
In the current version of React Native the size of the View container is determined at runtime using the size of the screen. The size of this view is set overriding the Widht and Height of this Container View (using the screen size), in Fabric we can not update the size of that view, instead we set the size of the RCTModalHostView to take the size of the whole screen.
Since the RCTModalHostView has an absolute position and it has the size of the screen, making this change should be enough to keep backward compatibility and be able to implement Modal on Fabric
Reviewed By: JoshuaGross
Differential Revision: D15067616
fbshipit-source-id: d7302ef3afc503adfee10e12fb6d0ebd371fb7ed
Summary: This adds support for specifying the exact selector name for each exposed ObjC method. This allows us to avoid dynamic method lookup every time a method is called from JS.
Reviewed By: RSNara
Differential Revision: D15141611
fbshipit-source-id: ed2820782ab013369e4e1f22dbce31d9838a17bb
Summary:
RNTester currently has four third party dependencies that are fetched from the network at build time:
- glog
- double-conversion
- boost
- folly
These dependencies are cached to ~/.rncache by default. This location may not be ideal for use in CI, therefore the cache location is now made configurable via a RN_CACHE_DIR envvar.
Reviewed By: cpojer
Differential Revision: D15141391
fbshipit-source-id: b51d749412c49500a657bd18e4c9520ddb30ea2c
Summary:
The `testBundleURL` test was disabled in open source recently due to issues running it successfully in Facebook's internal CI. We're now skipping `RCTBundleURLProviderTests` tests internally, so it's safe to re-enable now and ensure it runs in Circle CI.
Changelog:
[iOS] [Changed] - Re-enable testBundleURL unit test.
Reviewed By: cpojer
Differential Revision: D15140192
fbshipit-source-id: 5f6a91f3ce8cea245be31dff3ffb86768deab0be
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:
Bump the `react-native-community/eslint-config` version so we can release it.
[General] [Changed] - Bumped react-native-community/eslint-config version
Pull Request resolved: https://github.com/facebook/react-native/pull/24650
Differential Revision: D15146456
Pulled By: cpojer
fbshipit-source-id: 9a6767f502f1b5dcd49cf55b4e35c0d851f33222
Summary: Trivial diff that adds extra logging information on Exceptions that are thrown by the FabricViewTest
Reviewed By: shergin
Differential Revision: D14817899
fbshipit-source-id: 32e1d1fcd1292715dfcf2750d3f14c668927c8b8
Summary:
This diff fixes a bug that is reproducible when a view is reordered in a different level of hierarchy in the react tree.
Even if this is not supported by react, this can still happen because of viewFlattening.
Reviewed By: shergin
Differential Revision: D14817452
fbshipit-source-id: 13425b0e6a280affe681e80b4a6daa17ee56251a
Summary: Apparently we can/should not have in RCTConversions because it creates unnecessary dependency to core iOS module.
Reviewed By: mdvacca
Differential Revision: D15055325
fbshipit-source-id: 507f5a40c03b5c261967de4504297d31ecd02783
Summary: Sometimes we don't know for sure if `ContextContainer` has a value or not (and that's perfectly legit use case). In those cases now we can use `findInstance` method that returns an optional intead of throwing an exeption.
Reviewed By: JoshuaGross
Differential Revision: D15039137
fbshipit-source-id: 95ba8cc7b76e37d1bd17e18c0098e56350ff3fef
Summary: It turns out that just only props is not enought to build an initial state value in some cases for some component. Seems we need at least `surfaceId` and `eventEmitter` in some cases (which seems totally reasonable). So, seems using the whole `ShadowNodeFragment` for that purpose is a good choise.
Reviewed By: mdvacca
Differential Revision: D15039135
fbshipit-source-id: d9a5f47f971ccf6cdb2f888bd31f7948b37b67ef
Summary:
`ShadowNodeFragment` is very cheap by design because it does not own stuff it contains, so it's great. But... sometimes we need to own the stuff (e.g. to pass it on the other thread), in those cases we can use `ShadowNodeFragment::Value` now.
`ShadowNodeFragment::Value` cannot be used alone, it needs to be constructed from `ShadowNodeFragment` and then used as opaque object and then it can be converted to ``ShadowNodeFragment`.
We will need it soon.
Reviewed By: mdvacca
Differential Revision: D15039136
fbshipit-source-id: d40875cac05f4088358d8d418007d17df9ff14f4
Summary:
Trivial.
We are replacing rootTag with surfaceId according to the plan describing here: https://fb.workplace.com/groups/rn.fabric/permalink/1374002366064519/
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D15039134
fbshipit-source-id: ec8c3044f9f3f23939488bc01c66e9b653e651dd
Summary: This diff refactors the way we synchronize in ReactChoreographer using a lock object
Reviewed By: ejanzer
Differential Revision: D14913056
fbshipit-source-id: e86c4395d5d3c3fd5b7330b72c14920b536f74ce
Summary: QE expired a while ago. Remove the experiment code.
Reviewed By: fkgozali
Differential Revision: D15133830
fbshipit-source-id: 562c3998cc7860497eefa9899dfb6bfcee4fe210
Summary: A Flow error suppression was hiding two errors: one is a real type incompatibility, another is a "kind" mismatch error where the type of a component was being cast to another component (rather than its type).
Reviewed By: nmote
Differential Revision: D15141749
fbshipit-source-id: a090c02c949eb6614b46f2691ad41cee0b0f3dbd
Summary:
@public
Right now when you pass a ph:// video asset, we only ever return the image thumbnail of it. This is useful if you're displaying the ph:// in an <Image> but bad if you're trying to upload it.
This change keeps the original behaviour of displaying a thumbnail in an Image but fixes the latter behaviour, so that ph:// videos are uploaded correctly.
NOTE: There is a terrible hack to accomplish this. It is detailed in the code but essentially, we change the URL scheme to ph-upload:// when trying to upload it so that the default image loader doesn't try to process it.
Reviewed By: JoshuaGross
Differential Revision: D15129454
fbshipit-source-id: 18f87bec18b7cfa5edc1d60a47f23ac5d00675e0
Summary:
When trying to load image using method "RCTImageFromLocalAssetURL", if URL's path in file system representation return null (in my case, imageUrl is base64 format returned from server so it's always null) then method "stringWithUTF8String" will raise an exception.
[iOS] [Fixed] - Fix exception when attempt to load image from file system
Pull Request resolved: https://github.com/facebook/react-native/pull/24457
Differential Revision: D15123680
Pulled By: shergin
fbshipit-source-id: bc34b3d7c79a8f9157729c4cf0486507c3c15ddf
Summary:
This fixes a regression on Android introduced by f3e5cce where JS errors thrown during bundle load were lost (shown only as UnknownCppException). It is especially tough to debug (custom) bundling errors without seeing the javascript error.
Root cause hypothesis: since switching to clang, `JSError`s thrown in ReactCommon's `JSCRuntime::checkException` were never matched as `std::exception` in ReactAndroid's `convertCppExceptionToJavaException` due to these missing flags.
I'm a bit shy on low-level details concerning how C++ rtti works exactly around catching exceptions thrown in other libraries. All I can say that with this change, a `bundle.android.js` that only contains `throw new Error("wtf");` now nicely outputs a message and stack trace in the logcat. Before (and since DanielZlotin's switch to clang) it just outputted:
```
2019-04-29 12:17:59.365 1162-1306/com.rntest E/unknown:ReactNative: Exception in native call
com.facebook.jni.UnknownCppException: Unknown
at com.facebook.react.bridge.queue.NativeRunnable.run(Native Method)
at android.os.Handler.handleCallback(Handler.java:873)
at android.os.Handler.dispatchMessage(Handler.java:99)
at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:29)
at android.os.Looper.loop(Looper.java:214)
at com.facebook.react.bridge.queue.MessageQueueThreadImpl$4.run(MessageQueueThreadImpl.java:232)
at java.lang.Thread.run(Thread.java:764)
```
[Android] [Fixed] - JS errors during bundle load were reported as UnknownCppException.
Pull Request resolved: https://github.com/facebook/react-native/pull/24648
Differential Revision: D15123525
Pulled By: mdvacca
fbshipit-source-id: 74b5ce9ebae38d172446b6e31739d795c601947b
Summary:
This fixes an issue where the Prettier config was set to the `fb` (Facebook) values for all users of the `react-native-community/eslint-config` package. This was due to [this line](https://github.com/facebook/react-native/blob/8f186b84aeeb2613bf6ae08f20a8547d40179007/packages/eslint-config-react-native-community/index.js#L219) in the config file.
It was causing issues like these:
* Errors when using newer versions of `eslint-plugin-prettier` (you had to use a version that was >1 year old): https://github.com/facebook/react-native/issues/24564
* Errors due to the Prettier parser being forced to be `flow` when using Typescript: https://github.com/typescript-eslint/typescript-eslint/issues/481
This PR:
* Changes that line to remove the explicit `fb` config so users can set their own.
* Moves the React Native Prettier config to `.prettierrc` so ESLint, Prettier, and code editors can all read from the same place.
* Upgrades both `prettier` and the `eslint-plugin-prettier` to the latest versions.
[General] [Fixed] - Stopped the Prettier config being set for all users of react-native-community/eslint-config
Pull Request resolved: https://github.com/facebook/react-native/pull/24635
Differential Revision: D15122200
Pulled By: cpojer
fbshipit-source-id: 56bae8a7f2d8e133b1d808091a6b73302b94d2ed
Summary:
Hello Everyone, this series of commits helps to fix problems related to ART on Android. The main problem in here is that the ART components would disappear if the user turns off the screen and then turn it on again. It's important to note that this behaviour only occurs after Android N (7.1 or higher).
Pull Request resolved: https://github.com/facebook/react-native/pull/22624
Differential Revision: D15122573
Pulled By: cpojer
fbshipit-source-id: e7fb8b9280b4c52562e3d0c1a89759d4d31cd53d
Summary:
@public
Adds `YGStyle::ValueRepr` to make code depending on the actual type easier to write.
So far, we have treated `yoga::detail::CompactValue` as an implementation detail, and that’s what it’s supposed to stay.
React Native Fabric has one value conversion overload that depends on that type, though, and used `decltype(YGStyle{}.margin()[0])` until now.
That’s problematic for two reasons:
- we want to constrain the parameter of `operator[](...)` to enum types, making the `0` unsuitable
- we want to return the non-const overload of the operator to return a custom `Ref` type, which is not the type needed by Fabric.
Making the storage type explicit allows to write more forward-compatible code.
Reviewed By: SidharthGuglani
Differential Revision: D15078960
fbshipit-source-id: 932c27ef2f2cdc6ce965b79894268170f0ccdce5
Summary:
@public
Some `YGNode*` passed as `const YGNode*`, some const refs to sub-objects introduced.
This helps selecting the desired methods in more places, i.e. `const` overloads of accessors on `YGStyle`.
Reviewed By: SidharthGuglani
Differential Revision: D15078963
fbshipit-source-id: 5013721d6edcc68f42f4504f5c331da647a294bd
Summary:
@public
Having binary operators as member functions has disadvantages:
- the left hand side cannot be converted to `YGFloatOptional` implicitly (which we need for `YGStyle` refs)
- Operators are not necessarily commutative.
By moving these operators into free functions, and adding overloads for both variants if one operand is `float`, we get these properties.
Reviewed By: SidharthGuglani
Differential Revision: D15078962
fbshipit-source-id: 2e228a2ef90a8083c91788caa9eedfd4d140677f
Summary:
After upgrading RN from 0.57 to 0.59.4 we've received a lot of crash reports like `Exception in HostObject::get: <unknown>` with no clue what native module caused the crash. This commit adds native module name on crash in this situations. Related to https://github.com/facebook/react-native/issues/24607.
[General] [Added] - Report native module name on crash when native module has failed to load
Pull Request resolved: https://github.com/facebook/react-native/pull/24633
Differential Revision: D15120225
Pulled By: cpojer
fbshipit-source-id: cf8e3e5953548a58f1d010eb70343da5ee946ae8
Summary:
On android when borderXColor is null it causes the app to crash with:
```
04-28 17:44:18.021 20114 20213 E unknown:ReactNative: com.facebook.react.bridge.NoSuchKeyException: borderBottomColor
04-28 17:44:18.021 20114 20213 E unknown:ReactNative: at com.facebook.react.bridge.ReadableNativeMap.getValue(ReadableNativeMap.java:111)
04-28 17:44:18.021 20114 20213 E unknown:ReactNative: at com.facebook.react.bridge.ReadableNativeMap.getValue(ReadableNativeMap.java:115)
04-28 17:44:18.021 20114 20213 E unknown:ReactNative: at com.facebook.react.bridge.ReadableNativeMap.getInt(ReadableNativeMap.java:158)
04-28 17:44:18.021 20114 20213 E unknown:ReactNative: at com.facebook.react.uimanager.ViewProps.isLayoutOnly(ViewProps.java:246)
04-28 17:44:18.021 20114 20213 E unknown:ReactNative: at com.facebook.react.uimanager.NativeViewHierarchyOptimizer.isLayoutOnlyAndCollapsable(NativeViewHierarchyOptimizer.java:482)
```
Basically it is missing a `isNull` check on the props map before trying to access the value.
Fixes#22727
[Android] [Fixed] - Fix a crash when borderXColor is null
Pull Request resolved: https://github.com/facebook/react-native/pull/24640
Differential Revision: D15120182
Pulled By: cpojer
fbshipit-source-id: bc41da572f04d8abf733b5a4e94a74a0f40acda1
Summary:
Convert root Gradle script to Kotlin DSL, and cleanup. Currently, there is not much benefit or advantage over Groovy scripts, except IDE support and it'll cache compiled KTS scripts on first run.
[Android] [Changed] - Convert root Gradle script to Kotlin DSL, and cleanup.
Pull Request resolved: https://github.com/facebook/react-native/pull/24631
Differential Revision: D15120190
Pulled By: cpojer
fbshipit-source-id: 86691db5c7746e71bb243ebc263c1a3075ee9a9e
Summary: [General] [Changed] - If `isInteraction` is not specified in the config, it would always default to `true` which would block interactions like VirtualizedList updates. This is generally not what you want with useNativeDriver since the animation won't be interrupted by JS. If something does end up interfering with an animation and causes frame drops, `isInteraction` can be set manually.
Reviewed By: yungsters
Differential Revision: D14988087
fbshipit-source-id: 791b5cc327ffef6d2720c647a228cf3134a27cda
Summary:
This PR bumps Android Gradle Plugin to 3.4.0, which enables R8 shrinker by default and improves build performance significantly.
Disabled R8 for ReactAndroid because it'll strip out AndroidX and other libraries bundled in ReactAndroid.
[Android] [Changed] - bump Android Gradle plugin to 3.4.0
Pull Request resolved: https://github.com/facebook/react-native/pull/24463
Differential Revision: D15107117
Pulled By: hramos
fbshipit-source-id: 35a03dc9955e889c9399faeaf9a862e0fc044fc4
Summary:
Now RN has only ReactActivity which extends AppCompatActivity, subclass of FragmentActivity, therefore no need to check if activity is FragmentActivity or not. This PR changes DialogModule to work only with FragmentActivity.
Also DialogFragment from Android is deprecated in API 28, and recommends to use DialogFragment from Support Library. Excerpt from DialogFragment documentation.
> **This class was deprecated in API level 28.**
> Use the Support Library DialogFragment for consistent behavior across all devices and access to Lifecycle.
**BREAKING CHANGE**: Brown field apps must extend FragmentActivity or its subclasses.
[Android] [Changed] - DialogModule supports only FragmentActivity
Pull Request resolved: https://github.com/facebook/react-native/pull/23365
Differential Revision: D14021986
Pulled By: cpojer
fbshipit-source-id: b0ede60ef19cec48111a12701659a8bc1f66c331
Summary:
@public
Takes a const reference to the style of the printed node once, instead of using repeated calls to `node->getStyle()`.
Makes the code a bit shorter, and ensures that we are operating on `const YGStyle&`, which helps selecting the correct methods further up the stack.
Reviewed By: SidharthGuglani
Differential Revision: D14999094
fbshipit-source-id: 814f06b7e3179ac8cfb43d79fbec48ee4115d6e3
Summary: These strings shouldn't be translated by FB system because each app has its own set of languages and/or translation outputs. We're keeping just values/strings.xml in the repo.
Reviewed By: cpojer
Differential Revision: D15087192
fbshipit-source-id: c4b6112f6dd010d317060ac6640b34e4b725c695
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:
Assistive technologies use the accessibility role of a component to tell the disabled user what the component is, and provide hints about how to use it. Many important roles do not have analog AccessibilityTraits on iOS. This PR adds many critical roles, such as editabletext, checkbox, menu, and switch to name a few.
Accessibility states are used to convey the current state of a component. This PR adds several critical states such as checked, unchecked, on and off.
[general] [change] - Adds critical accessibility roles and states.
Pull Request resolved: https://github.com/facebook/react-native/pull/24095
Differential Revision: D15079245
Pulled By: cpojer
fbshipit-source-id: 941b30eb8f5d565597e5ea3a04687d9809cbe372
Summary:
Since initialisation flow changed with default template, we need to adjust the script to make it work properly.
[General] [Fixed] - Adjust text manual e2e script to work with new init.
Pull Request resolved: https://github.com/facebook/react-native/pull/24583
Differential Revision: D15062374
Pulled By: cpojer
fbshipit-source-id: 8110597b27056570784439362f12963154460613
Summary: For some reason the scroll events are sometimes generated with highly irregular spacing, some coming less than a millisecond apart. For interactions that must track scrolling exactly, this can cause them to glitch. With a scroll throttle of less than 17 ms, the intention is clear that the UI should be updated in sync with the scroll view so we shouldn't drop any events.
Reviewed By: PeteTheHeat
Differential Revision: D15068841
fbshipit-source-id: 730e7cb29cc3ddae66f37cf7392e02e0cc9d7844
Summary:
This test was disabled in e106112202 to allow unit tests to run on Facebook's internal CI. The change was reverted in 1f6de88230 because another internal test was broken when it found that mainBundleURL() was not getting called.
In this commit, I've commented out the actual piece of code that would cause unit tests to fail in Facebook's internal CI, without removing the call to mainBundleURL(). The localhostBundleURL() method is called elsewhere in the file, so commenting it out here should not cause any issues.
Changelog:
[iOS] [Changed] - Disable testBundleURL test.
Reviewed By: cpojer
Differential Revision: D15049238
fbshipit-source-id: da3a393922f2190b423980cac5ab54df5e7e3e41
Summary:
This pull request removes the tests for out-of-tree platforms and the dependency on the package `react-native-dummy` from the React Native repo.
The logic that this was meant to test was moved to the React Native CLI repo, and [it is being tested there](https://github.com/react-native-community/cli/blob/827daa4c1687f8d17eb7df46e1a2ec25640c7797/packages/cli/src/tools/config/__tests__/index-test.js#L125-L152) as well making this a bit redundant at this point.
The dependency on `react-native-dummy` was also an issue, because when the file structure under `Libraries/` changes, bundler errors could crop up if there wasn't an update made to the file structure of `react-native-dummy/Libraries/`.
This was an issue when [`TabBarIOS` was removed](https://github.com/facebook/react-native/commit/02697291ff41ddfac5b85d886e9cafa0261c8b98#diff-b9cfc7f2cdf78a7f4b91a753d10865a2) - `react-native-dummy` was causing Haste errors and was stopping the commit from being able to land, and I needed to cut a new version just for it. With Lean Core, I expect more issues like this happening in the future.
[General] [Removed] - Removed Out-of-Tree platform tests (functionality is tested in the RN-CLI repo now)
Pull Request resolved: https://github.com/facebook/react-native/pull/24536
Differential Revision: D15063320
Pulled By: cpojer
fbshipit-source-id: 2a0467bed326b286623fa3cfa4e0bb6959b66b78
Summary:
We are seeing crash reports that the webview is missing. In this case
it should fail gracefully so that a missing webview does not block
from using an app built with React Native.
The contains could also be changed to check for "webview" in general
to catch all webview related exception. It's currently checking on
for the specific string that I'm seeing in our app's crashreporting tool.
<img width="1507" alt="Screen Shot 2019-04-19 at 11 26 19 AM" src="https://user-images.githubusercontent.com/741767/56438307-5e1c2f80-6297-11e9-970b-a5095d18e9d7.png">
<img width="935" alt="Screen Shot 2019-04-19 at 11 32 58 AM" src="https://user-images.githubusercontent.com/741767/56438213-fa920200-6296-11e9-8008-5eb344eca8a8.png">
[Android] [Fixed] - The ReactCookieJarContainer/ForwardingCookieHandler now handles the missing WebView gracefully.
Pull Request resolved: https://github.com/facebook/react-native/pull/24533
Differential Revision: D15062824
Pulled By: cpojer
fbshipit-source-id: 80805a47494f0d924b7ee029ce8ca0504eaeee57
Summary:
Per a conversation with TheSavior, in #24538, this adds snapshot tests for all components whose mocks will be addressed in that PR. Shallow and deep snapshots are included.
[General] [Added] - Snapshots
Pull Request resolved: https://github.com/facebook/react-native/pull/24554
Differential Revision: D15062197
Pulled By: cpojer
fbshipit-source-id: 70ddbaa5e6d1d2c0fd1130ab04c458d9c49d0ee8
Summary: At Facebook we do not install the cli or the packages around it. I added some workaround for that in D15044762 but failed to run Jest without cache to test it and it seems like it didn't run on sandcastle properly either (wtf?). Either way, this adds back the `ios` and `android` reducers for `hasteImpl` to run the tests properly again.
Reviewed By: rubennorte
Differential Revision: D15063152
fbshipit-source-id: 2f1fefe664f02d5f2f5e65b75ac1e0c5b813a343
Summary:
Updates React Native to use latest CLI.
Changes:
- No more `--reactNativePath`, define it once in the configuration file. This reverts the previous PR that added this flag
- Add `platforms` and `commands` - React Native now defines platform like any other package. There's no longer concept of "out-of-tree" platform. All are treated equally. If React Native works, any other platform will work too.
- Updates `jest/hasteImpl.js` to use public CLI interface (`loadConfig`) instead of `findPlugins` and removes a weird conditional that checks for CI presence.
[INTERNAL] - Update React Native CLI
Pull Request resolved: https://github.com/facebook/react-native/pull/24517
Differential Revision: D15044762
Pulled By: cpojer
fbshipit-source-id: 379b61e842e619312c542173219a7d326663cf24
Summary: In `ObjCTurboModule::getArgumentTypeName`, I replaced all instances of `':'` with `''` to transform the selector into a TurboModule methodName. This transformation works when the method has 0 or 1 argument, however, it breaks when the method has more than 1 argument. In all cases, we just want to get the substring until the first `':'`.
Reviewed By: fkgozali
Differential Revision: D15056937
fbshipit-source-id: 3a7dce1ce62ca9758e46c0af951b269166d68454
Summary: adding the flow types makes it impossible to forget to change them back.
Reviewed By: yungsters
Differential Revision: D14990037
fbshipit-source-id: d018e4cf6798d50bcfb44b55d3c68ca7f5beef72
Summary:
Trivial.
Apparently, `DEBUG` is non-standard feature and using `assert` with `DEBUG` is practically asking for bugs. So, if your `assert` relies on some variable which is only defined when `DEBUG` is set, it's easy to get invalid code because NDEBUG and DEBUG can be unsync.
So, we have to use clunky double negative `#ifndef NDEBUG` everywhere where we used DEBUG.
Reviewed By: JoshuaGross
Differential Revision: D15031328
fbshipit-source-id: 036f573e68925741ca46384261885766c87db1e3
Summary:
@public
RCTScrollView sometimes asserts with another contentView set. While this doesn't crash, it'd be good to know what's causing the assert. This will add a recursive description of the contentView.
Changelog: [iOS] [Changed] RCTScrollView: added debugging to help fix assert
Reviewed By: PeteTheHeat
Differential Revision: D15049869
fbshipit-source-id: 5431de7764881922327c6c0a3bdd392668396b58
Summary:
@public
Introduces `YGNodeConstRef` as `const YGNode*`, i.e. a pointer to a constant `YGNode`.
We also use it for all style getters, which will avoid casts to `const YGNode*` in diffs up the stack.
We should use this pointer type for all functions that do not modify the underlying node.
Reviewed By: SidharthGuglani
Differential Revision: D14999095
fbshipit-source-id: 61cc53bb35e787a12ae12e70438d84c0a4983752
Summary:
@public
In order to encapsulate property access on `YGStyle`, as a first measure we wrap all fields with accessors.
This will e.g. enable dynamic property storage and instrumentation in the future.
All accessors have a `const` version that allows direct access via `const&`. For mutation, bit fields are wrapped with a custom reference object.
This style allows for the least amount of changes in client code. Property access simply needs appended parens, eg `style.direction` becomes `style.direction`.
Reviewed By: shergin
Differential Revision: D14999096
fbshipit-source-id: fbf29f7ddab520513d4618f5e70094c4f6330b30
Summary:
@public
Remove unnecessary `const` and `extern` specifiers from `Yoga.h`.
- Function declarations are `extern` by default
- The removed `const` specifiers for pass-by-valye parameters are only meaningful for the *definition* of functions, not for the declaration.
In this specific case, I found `const YGNodeRef` particularly confusing, as it is a `typedef` for a pointer type. `const` does not refer to the pointed-to object, but to the parameter itself, i.e. `const YGNodeRef` is `YGNode * const`, and not `const YGNode *`.
Reviewed By: SidharthGuglani
Differential Revision: D14999097
fbshipit-source-id: 8350870cb67f4a34722f796c4f4a2fc7dde41b99
Summary:
Simplifies the code anyone on iOS using RN has _to see_. In this case, React Native knows that everyone probably wants all these imports (unless they're using dev mode) and so we can auto-import the pod specs for a user from inside the lib.
Basically auto-link for the React side.
[iOS] [Added] - Adds a ruby function which imports the Pods for RN, so that users only have to include this function and it can change per RN version.
Pull Request resolved: https://github.com/facebook/react-native/pull/24555
Differential Revision: D15044780
Pulled By: cpojer
fbshipit-source-id: c3702a52104706def51da6f1d11ab966d57d1edb
Summary:
React Native Environment Info:
System:
OS: Linux 4.15 Ubuntu 18.04.1 LTS (Bionic Beaver)
CPU: (4) x64 Intel(R) Core(TM) i5-7300U CPU @ 2.60GHz
Memory: 1.12 GB / 15.55 GB
Shell: 4.4.19 - /bin/bash
Binaries:
Node: 8.10.0 - /usr/bin/node
Yarn: 1.13.0 - /usr/local/bin/yarn
npm: 3.5.2 - /usr/bin/npm
SDKs:
Android SDK:
API Levels: 16, 19, 22, 23, 24, 25, 26, 27, 28
Build Tools: 23.0.1, 23.0.3, 25.0.0, 25.0.2, 25.0.3, 26.0.1, 26.0.3, 27.0.3, 28.0.2, 28.0.3
System Images: android-16 | Google APIs Intel x86 Atom, android-19 | Google APIs Intel x86 Atom, android-24 | Google Play Intel x86 Atom, android-27 | Google APIs Intel x86 Atom, android-28 | Intel x86 Atom_64, android-28 | Google APIs Intel x86 Atom, android-28 | Google Play Intel x86 Atom
npmPackages:
react: 16.8.6 => 16.8.6
react-native: git+https://github.com/facebook/react-native.git#v0.59.5 => 0.59.5
npmGlobalPackages:
react-native-cli: 2.0.1
react-native-git-upgrade: 0.2.7
The workaround implemented in https://github.com/facebook/react-native/pull/21117 tries to fix
https://issuetracker.google.com/issues/112385925 scroll direction (according to the latest comments, the scroll direction problem has been reverted in security patches so not sure if the workaround is still valid).
But... proposed solution in fling method is using signum which leads to zero computedVelocityY in case of zero mOnScrollDispatchHelper.getYFlingVelocity() on old devices(Samsung s4 mini) even when real velocityY is non zero
```
final int correctedVelocityY = (int)(Math.abs(velocityY) * Math.signum(mOnScrollDispatchHelper.getYFlingVelocity()));
```
Proposed solution is to take signum from original velocityY in case of zero
```
float signum = Math.signum(mOnScrollDispatchHelper.getYFlingVelocity());
if (signum == 0) {
signum = Math.signum(velocityY);
}
final int correctedVelocityY = (int)(Math.abs(velocityY) * signum);
```
The symptoms are the same as described in issue https://github.com/facebook/react-native/issues/22925, but proposed workaround doesn't work.
[Android][fixed] - Fix smooth scrolling on old devices (SDK >=16)
Pull Request resolved: https://github.com/facebook/react-native/pull/24545
Differential Revision: D15044834
Pulled By: cpojer
fbshipit-source-id: 3f523eb1a438df774e22387aecded433b9031ab9
Summary:
By default, the text color is `#000000` on iOS and different on Android, e.g. `#808080`, depending on the manufactorer.
This PR changes it so that newly created projects all have the text color `#000000` by default on both iOS and Android.
The argument for this is to make the app by default be more consistent between platforms.
Expo also does this: https://github.com/expo/expo/blob/master/android/expoview/src/main/res/values/styles.xml#L31
---
For context and for your consideration, I have started a discussion here with the topic of whether React Native should try to use OS defaults or be consistent between platforms:
https://github.com/react-native-community/discussions-and-proposals/issues/121
[Android] [Changed] - New projects have a `#000000` by default.
Pull Request resolved: https://github.com/facebook/react-native/pull/24540
Differential Revision: D15044898
Pulled By: cpojer
fbshipit-source-id: 3197266504e1061ac7027bec3100e39e39a4406a
Summary:
By default, an alert is `cancelable` on Android but not on iOS.
This PR changes the behavior so that the Alert is not dismissable on Android by default.
The motivation is that many developers develop on iOS and test on Android, and do forget to consider the case that the alert is dismissable.
Consistent behavior by default makes it easier to develop cross-platform apps in general.
---
For context and for your consideration, I have started a discussion here with the topic of whether React Native should try to use OS defaults or be consistent between platforms:
https://github.com/react-native-community/discussions-and-proposals/issues/121
---
If this PR gets merged, the docs should be updated as well:
https://github.com/facebook/react-native-website/blob/master/docs/alert.md#android
[Android] [Changed] - By default, alerts are not dismissable
Pull Request resolved: https://github.com/facebook/react-native/pull/24541
Differential Revision: D15044798
Pulled By: cpojer
fbshipit-source-id: 762b2ace69eb7ec79cd6ebec916e473348b9cafe
Summary:
Fixes a regression in https://github.com/facebook/react-native/commit/1f8b46a2fc191e2899735fbdcdbb535a91b63724. The internal subscription vendor uses a sparse array to track listeners, which makes listener removal fast. When querying listeners, the sparse entries need to be removed. `Array#filter` is a built-in way to do this -> linked to the JS spec, which explains this.
[General] [Fixed] - Fixed sparse array handling in `EventEmitter#listeners()`
Pull Request resolved: https://github.com/facebook/react-native/pull/24546
Differential Revision: D15044790
Pulled By: cpojer
fbshipit-source-id: 0f1301618739357b4a0f5378b9584efe74f0f09a
Summary:
If an app [builds from RN source](https://facebook.github.io/react-native/docs/building-from-source), there was an error for jsc-android not found.
It is a side effect of my previous [JSC as node dependency change](https://github.com/facebook/react-native/commit/8e375850de73d1b998a83279e6c4ba238867a453)
For building from RN source case, the jsc-android is located at `/path/to/app/node_modules/jsc-android`.
Original gradle task will try to find it at `/path/to/app/node_modules/react-native/ReactAndroid/../node_modules/jsc-android`, as ReactAndroid project path was being override inside node_modules.
The change fixes the building from source case.
N/A
This change does not need to publish into changelog, as it is a master branch building fix.
Pull Request resolved: https://github.com/facebook/react-native/pull/24547
Differential Revision: D15044703
Pulled By: cpojer
fbshipit-source-id: a7d824b1a14064d46c4a2ec9ea28255179174c83
Summary:
Bumps to Xcode 10.2.0 and uses the iOS 12.2 simulator when running tests.
The `testBundleURL` test is temporarily disabled to allow the iOS unit tests to run successfully in the internal Facebook CI system.
Changelog:
[iOS] [Changed] - iOS tests: Bump Xcode to 10.2.0, iOS to 12.2.
Reviewed By: TheSavior
Differential Revision: D14962710
fbshipit-source-id: 769cfb90aacce33903ab6e8dbcc5b5727deacf41
Summary: `jClassName_` is unnecessary because you can use `JNIEnv::GetObjectClass` to get the TurboModule's Java class.
Reviewed By: fkgozali
Differential Revision: D14937480
fbshipit-source-id: 2c1c9be53217331152270dbac3d13f372a2ed818
Summary:
libreactnativejni does not need to link against libjsc directly:
that library is only needed by libjscexecutor.
Reviewed By: mhorowitz
Differential Revision: D15017942
fbshipit-source-id: fb545c9127221dab28434321fe9c116fe72f7507
Summary:
UAs must adjust border radius values to fit a content box:
>>> Corner curves must not overlap: When the sum of any two adjacent border radii exceeds the size of the border box, UAs must proportionally reduce the used values of all border radii until none of them overlap.
This diff implements that.
Reviewed By: mdvacca
Differential Revision: D15028325
fbshipit-source-id: 368232ffa2fa0409d13759bbbe7fe10f8474c400
Summary: Additional check verifies that requested type matches the type of a stored value.
Reviewed By: mdvacca
Differential Revision: D14944336
fbshipit-source-id: 6d3a1654d9b9a64ced83f553236093f02f2c97c7
Summary:
ShadowTree commits happen concurrently with limited synchronization that only ensures the correctness of the commit from ShadowTree perspective.
At the same time artifacts of the commit () needs to be delivered (also concurrently) to the proper thread and executed in order (not-concurrently). To achieve this we need some synchronization mechanism on the receiving (mounting) side. This class implements this process.
Practically, this diff fixes a problem with glitching UI during the very first render of Fabric screen.
Reviewed By: JoshuaGross
Differential Revision: D15021794
fbshipit-source-id: 62982425300c515e92b91e1e660b45455a5446e9
Summary:
`MountingTransaction` encapsulates all artifacts of `ShadowTree` commit, particularly list of mutations and meta-data.
We will rely on this heavily in the coming diffs.
Reviewed By: JoshuaGross
Differential Revision: D15021795
fbshipit-source-id: 811da7afd7b929a34a81aa66566193d46bbc34f8
Summary: We have to figure out a different way to request for a fallback component in ComponentDescriptorRegistry and in general, in public APIs. But now, to stop crashing here the fix.
Reviewed By: JoshuaGross
Differential Revision: D15021796
fbshipit-source-id: a60c66838e76ace990f2eb764c86c29d24db2141
Summary: `getContextContainer` should be marked as const so that const instances can call it.
Reviewed By: shergin
Differential Revision: D14969981
fbshipit-source-id: 8812f24ecf0642a38496580689943fbd43cddad1
Summary:
Removes the top-level return used in `run-android-ci-instrumentation-tests.js`.
This prevents the file from being parsed as a module. The top-level return here doesn't serve any purpose because it doesn't block the execution of any code after it, as there is no more code to execute.
Reviewed By: cpojer
Differential Revision: D15000395
fbshipit-source-id: 7acf010bb25dec5048813d01517875bcb6eb5a15
Summary: It seems like ReactContext isn't actually needed in measure functions. Changing the signature of ViewManager.measure() to take a Context instead.
Reviewed By: lunaleaps
Differential Revision: D14940330
fbshipit-source-id: b29987fd1d7f9c191a5f26138151082ca61cb351
Summary:
Registries, providers, providers of registries, registres of providers. All that can be really confusing, but that represents best the constraints and desires that we have:
* We need to be able to register components on-the-fly (so we need a mechanism that will propagate changes);
* We don't want to register ComponentDescriptors separately from ComponentView classes;
* C++ not always gives us abstractions that we want (e.g. pointers to constructors).
After the change, we can remove the whole Buck target that has a bunch of handwritten boilerplate code.
There is a still room for polish and removing some concepts, types or classes but this diff is already huge.
Reviewed By: JoshuaGross
Differential Revision: D14983906
fbshipit-source-id: ce536ebea0c905059c7a4d644dc25233e2809761
Summary:
ComponentDescriptorProvider represents unified way to create a particular descriptor.
Now all ComponentViews (which support RCTComponentViewProtocol) expose a `ComponentDescriptorProvider` which will allow creating and registering ComponentDescriptor instances for all visual components automatically as a part of ComponentView registration process.
Don't panic, everything is still being as explicit as it always was, no magic involved; we just will have only one registration step instead of two parallel.
That also opens a way to register components on the fly.
Reviewed By: JoshuaGross
Differential Revision: D14963488
fbshipit-source-id: 9e9d9166fabaf7b30b35b8647faa6e3a19cd2435
Summary: The bridge was not properly isolating isInspectable onto the JS thread.
Reviewed By: fkgozali
Differential Revision: D14991970
fbshipit-source-id: 92a06c90bade8f92bfa81fa3b7dfb23b17db6117
Summary: This installs the sample module to the RNTester.xcodeproj without using any TurboModule infra. This is possible because SampleTurboModule is backward compatible with the existing NativeModules system. This also fixes CI test failure: https://circleci.com/gh/facebook/react-native/84752
Reviewed By: RSNara
Differential Revision: D14987572
fbshipit-source-id: f5f2c4330c7f6558c7d4beeb43198869090dee02
Summary:
Makes sure `onViewableItemsChanged` fires ASAP when `waitForInterations` is false.
This also works around another deeper bug where updates scheduled with `InteractionManager` aren't firing at all in some cases, and thus instead of just firing late, `onViewableItemsChanged` isn't firing until scroll which is not what we want with `waitForInterations: false`. That bug will require more digging.
Differential Revision: D14984333
fbshipit-source-id: 718b39670307c6bc16268759bdb513682745265d
Summary:
Yargs package is used only in test scripts and script for bumping version.
Based on this https://github.com/facebook/react-native/search?q=yargs&unscoped_q=yargs Yargs is not really required in production build and should be moved as development dependency.
[General] [Changed] - Moved Yargs to devDepencies
Pull Request resolved: https://github.com/facebook/react-native/pull/24496
Differential Revision: D14982834
Pulled By: cpojer
fbshipit-source-id: 81b6be413b2037e1b852cba91f4a2c04267ae930
Summary:
This diff fixes the reconnect logic with the metro websockets which is causing the app to not re-connect when metro crashes. To demonstrate the issue, consider the following video:
{F156029086}
On the left we have metro, on the right is the xcode console with some logging to show the reconnecting phase. When we kill the metro server you can see the app tries to reconnect once and that's it - when metro is started back up, you can see the notification that there are no apps running and can also see that cmd+opt+r doesn't work anymore
I updated the logic to optimistically start the connection and if it's still unavailable to retry again after the timeout
[iOS][Fixed] - Metro websocket reconnect logic
Reviewed By: shergin
Differential Revision: D14961433
fbshipit-source-id: 0569aa169dc9f538a7e4a8d04e99de39f2e9b3f9
Summary:
Motivation:
* We don't use them much, and we already have `at`-methods, which are better.
* We don't want to expose `ComponentDescriptor`s as shared pointers (because it's not clear, not so performant, and because we don't want to store them as shared pointer in the future);
* In idiomatic C++ `[]` operator has mutating semantic, that's not what we want to communicate via the interface of the class.
Reviewed By: sahrens
Differential Revision: D14963487
fbshipit-source-id: dbfddee2ba90d70c3bb8dcf1959d553571c47bab
Summary:
React Native has a `NativeModule` to manipulate programmatically the dev menu options (live reload, hot reload, remote debugging, etc), called [`DevSettings`](https://github.com/facebook/react-native/blob/master/React/Modules/RCTDevSettings.mm#L120). However this module is only available for iOS.
This PR brings the same `DevSettings` for Android, making it a cross-platform NativeModule.
Motivation: Right now if your app needs to programmatically reload RN, one option is to install [`react-native-restart`](https://www.npmjs.com/package/react-native-restart). It's a tiny dependency, but it's annoying to have to install it, while the code to do so is inside RN codebase. According to NPM, react-native-restart has ~12k weekly downloads, shows it's a recurring feature for many apps (my case).
Thus making `NativeModules.DevSettings` is a small increment in the codebase, just exposing the dev menu methods, to improve the Development Experience
[Android] [Added] - Add DevSetting native module (making it cross-platform)
With expection of `setIsShakeToShowDevMenuEnabled`, the following methods will be available for both platforms:
* reload
* setHotLoadingEnabled
* setIsDebuggingRemotely
* setIsShakeToShowDevMenuEnabled
* setLiveReloadEnabled
* setProfilingEnabled
* toggleElementInspector
Pull Request resolved: https://github.com/facebook/react-native/pull/24441
Differential Revision: D14932751
Pulled By: cpojer
fbshipit-source-id: 465e6a89c3beb5fd1ea22e80ea02e9438f596a09
Summary:
This updates `detox` from `12.1.1` to `12.2.0`.
It includes (amongst other things) the following fixes, as described on the [12.1.4 release page](https://github.com/wix/Detox/releases/tag/12.1.4):
- hotfix: redundant logs in the folder
- fix: stabilize simulator log recording
It also updates the detox test script and config in `packages.json` (which was previously missed when detox was updated to 12.1.x). It will remove the following deprecation warnings:
```
detox[6416] WARN: [test.js] Deprecation warning: "file" and "specs" support will be dropped in the next Detox version.
detox[6416] WARN: [test.js] Please edit your package.json according to the migration guide: https://wix.to/I0DOAK0
```
Instead of extra preprocessing the test folder by `detox`, it will now be passed straight to `jest`.
More information in the [migration guide](https://github.com/wix/Detox/blob/master/docs/Guide.Migration.md).
[General] [Changed] - Update detox to 12.2.0
Pull Request resolved: https://github.com/facebook/react-native/pull/24425
Differential Revision: D14973771
Pulled By: cpojer
fbshipit-source-id: 367ed1f75d2cc3b02349282e7a6201684ba130a7
Summary:
In order to meet our accessibility requirements we need to have full support for keyboard navigation. The Touchable components works with press/tap with a finger, but doesn't respond to 'enter' when using a keyboard. Navigation works fine. This PR adds an onClick listener to touchable views that have the onPress prop defined.
[Android] [Added] - Add View.OnClickListener to Touchable components when onPress is defined
Pull Request resolved: https://github.com/facebook/react-native/pull/24359
Differential Revision: D14971230
Pulled By: cpojer
fbshipit-source-id: ca5559ca1308ee6c338532a00dcea4d00fa57f42
Summary:
This change adds a document outlining the main stakeholders in React Native and their responsibilities: Partners, core contributors and community contributors
It serves as an overview for companies and individuals who are interested in contributing, to get a better understand of how the project is set up, who supports it, and what they do.
This is the first version and I am hoping to integrate it into more places in the future as well as I'd like to keep it up-to-date as things change. Hector is working on a detailed document outlining what it means to be a core contributor and we'll make a list of existing core contributors soon as well.
Pull Request resolved: https://github.com/facebook/react-native/pull/24493
Differential Revision: D14973910
Pulled By: cpojer
fbshipit-source-id: 3a722582be6bb3b953f10073682c5841cdae2c27
Summary:
To ensure greater type safety, we want to generate some cpp tests for the fromRawValue conversions
This diff adds support to generate Tests.cpp along with the `buck test` targets itegrated into the rn_codegen rule automatically. The tests just `assert(true, true)` as a starting point
Reviewed By: fkgozali
Differential Revision: D14739493
fbshipit-source-id: fc9dea64ea31e6af7d997aebc54cfd459d48bf4f
Summary: This is removing packages and libraries from the repo. Any modified buck files simply change the redirect targets to something more appropriate (no logic actually changed)
Differential Revision: D14950721
fbshipit-source-id: 6c14f827b76ca1dbaf83dcb983930f362c6a27d4
Summary:
Second attempt at adding border properties to `RCTImageView`.
Previous attempt can be found at D14875673 which was reverted.
1. `UIImageView` is no longer laid out in in `layoutSubviews`.
2. `updateWithImage` was not being called, I instead of calling `self.image = image` I was calling `_imageView.image = image` directly which skips calling `updateWithImage`. This meant that image's rendering mode was not changed to `template`.
Reviewed By: shergin
Differential Revision: D14934103
fbshipit-source-id: b74c692f9f8ad520ef1f9c70ec4b4aa68b868cd4
Summary:
If you call into a Java method (from C++ using JNI) that raises an exception, the JNI call won't actually raise a C++ error. Instead, the `JNIEnv` will record the pending Java exception and the C++ will continue executing as normal. This is bad because the next time you call into JNI, the app will actually crash, unless you explicitly cleared the exception using `JNIEnv::ExceptionClear()` before the JNI call.
With respect to TurboModules, we need to make sure that RedBoxes show up whenever a native methods raise an exception. We also don't want the app to crash when a JNI method call fails because of a raised exception. Therefore, in this diff, I raise a C++ exception if `JNIEnv::ExceptionCheck()` is true.
Reviewed By: mdvacca
Differential Revision: D14738540
fbshipit-source-id: 4c3063aa93ae7aef025bd2dab6b45059bb8fb409
Summary:
If the return type of a TurboModule method is `Promise`, the infra should create a `com.facebook.react.bridge.Promise` object and pass it as the final argument of the TurboModule Java method call. The Java TurboModule method can then do some work asynchronously and either resolve or reject the promise at some point in time.
**Note:** I stacked a diff for error handling on top of this one.
Reviewed By: mdvacca
Differential Revision: D13653156
fbshipit-source-id: 4c30c3223ad8f47c6ba7f1236527aaced01c8ae8
Summary: If some class or category override/implement one of those methods, it implies that subclasses must call super for them. `NS_REQUIRES_SUPER` allows to enforce this constraint.
Reviewed By: JoshuaGross
Differential Revision: D14896804
fbshipit-source-id: a481f16e1f7ab901d70deb6486f2ca1cf19dd8d7
Summary:
Previously we could call `invalidateLayer` twice during a mounting transaction (one for update-props, one for update-layout-metrics), that was sub-optimal.
Now, with `finalizeUpdates:` we can do it only once. That should save us some CPU cycles.
Reviewed By: JoshuaGross
Differential Revision: D14896802
fbshipit-source-id: b6572fb2a4fa48a12b1d1c29144cd7c67f6cff80
Summary: We use this pattern already and seems we use it more. Those two functions introduce a "semantical" wrappers for this context, so now there is no need to think which exact `__bridge ***` qualifier we should use, so it's much less error-prone.
Reviewed By: JoshuaGross
Differential Revision: D14896800
fbshipit-source-id: 85b86bfcefdad5aff0375e7172769df86c001506
Summary:
Turns out that storing and using ContextContainer in custom subclasses is a huge pain. At the same time seems that a lot of custom components need some DI instrument, so we need this instrument anyway.
Moving stuff from the template to the base class should also help with codesize a bit.
Reviewed By: JoshuaGross
Differential Revision: D14921356
fbshipit-source-id: 4dbb961fe32bd66c73513d7e053bbed229860a31
Summary:
The new method is being called right after all update methods were called for a particular component view.
It is useful for performing updates that require knowledge of several independent aspects of the compound mounting change (e.g. props *and* layout constraints).
Reviewed By: JoshuaGross
Differential Revision: D14896801
fbshipit-source-id: 485d8c97d81d7a2ad7a7afc209094c328da6ef3c
Summary:
@public
This allows short methods defined in class declarations to occupy a single line.
The change makes class declarations more readable.
Reviewed By: SidharthGuglani
Differential Revision: D14950012
fbshipit-source-id: 1321949475184181c6cceb86613f730e430763e2
Summary:
Would like feedback from the community as this may not be the best solution for all
I would like to restrict (or paginate) the fling of a horizontal ScrollView when `snapToInterval` is set. This is not currently possible with `pagingEnabled`, since the pagination works only when items are the entire width of the ScrollView.
This implementation simply restricts the predicted `targetOffset` found from the `x` velocity and replaces it with the offset when the pan gesture ended.
To get pagination working, I may paginate based on the interval by calculating the offset delta from the beginning of the gesture to current offset and restricting the scrolling behavior to the `snapToInterval`. If this is preferred, I can update this PR or make a new one, but wanted to start a discussion since it seems like there are many in the community that would like this feature #21302 .
[General] [Added] - add prop `disableIntervalMomentum` to disable the predictive scrolling behavior of horizontal ScrollViews
Pull Request resolved: https://github.com/facebook/react-native/pull/24045
Differential Revision: D14939754
Pulled By: sahrens
fbshipit-source-id: 26be19c47dfb8eed4d7e6035df53a77451e23081
Summary:
For a small subset of Android devices, the following line of code caused the device to crash
```
output.transferFrom(input, 0, Long.MAX_VALUE);
```
According to the [Java docs](https://docs.oracle.com/javase/1.5.0/docs/api/java/nio/channels/FileChannel.html), this is what the function does.
> Transfers bytes into this channel's file from the given readable byte channel.
An attempt is made to read up to count bytes from the source channel and write them to this channel's file starting at the given position. An invocation of this method may or may not transfer all of the requested bytes; whether or not it does so depends upon the natures and states of the channels. Fewer than the requested number of bytes will be transferred if the source channel has fewer than count bytes remaining, or if the source channel is non-blocking and has fewer than count bytes immediately available in its input buffer.
Hence, using `Long.MAX_VALUE` seemed to be the standard way to transfer all bytes from one channel to the other.
However, it appeared that for some reason on a subset of old Android devices, the device tries to allocate `count` bytes of memory before transferring the bytes. Obviously, this caused a crash because no device has that much memory. This was fixed transferring bytes using a 1MB buffer.
Differential Revision: D14921778
fbshipit-source-id: 7fa46e10c656e23ae7d5679c72b278188f09ad0a
Summary:
This showcases SampleTurboModule usage in RNTester. Notes:
* iOS only for now, and you must use cocoapods version.
* You cannot use Chrome debugger when loading this specific example.
As illustrated in the example, the callsite should access `NativeSampleTurboModule` to access the native side.
{F155901711}
Reviewed By: cpojer
Differential Revision: D14932537
fbshipit-source-id: a733e1cd3b642b9e572d5ac6347f4775d495578a
Summary: This sets up RCTSampleTurboModule (and other variants) in RNTester when built with cocoapods. There's no call site yet though. And RNTester.xcodeproj doesn't support it.
Reviewed By: cpojer
Differential Revision: D14932535
fbshipit-source-id: db8eafd6777cbec8f3592dafdccbdd7cf44e38bc
Summary:
This provides various versions of SampleTurboModule, that are:
* compatible with existing NativeModule
* TurboModule compliant
Variants:
* RCTSampleTurboModule (traditional objc module)
* RCTSampleTurboCxxModule (objc++ module using CxxModule)
* SampleTurboModule (pure C++ impl of a TurboModule, no ObjC)
As noted in some files, they need to be codegen'ed based on the `NativeSampleTurboModule.js` (Flow type). The codegen script is not yet usable in OSS (we'll work on it some time in H2 2019). For now, these files need to be manually synced with Flow type.
Reviewed By: cpojer
Differential Revision: D14932539
fbshipit-source-id: fb887192384e5e6e4dff4cac68b4e037a4783cd9
Summary:
For CocoaPods variant only: install TurboModule binding so that sample modules can start using it. This commit only installs `global.__turboModuleProxy` - no sample module is provided.
Note: RNTester.xcodeproj will NOT have TurboModule enabled, due to complication in the .xcodeproj setup (doable, but maybe for some other time...)
To test:
```
console.error(global.__turboModuleProxy == null ? 'BOO' : 'YAY!');
```
Saw `YAY!` in RNTester pod version.
Reviewed By: cpojer
Differential Revision: D14932536
fbshipit-source-id: 3dc083da9154ec320ce6789ec7f2cef5a08fd6a7
Summary: This is to prepare for custom JS runtime binding installation. Note: AppDelegate needs to become .mm
Reviewed By: cpojer
Differential Revision: D14932538
fbshipit-source-id: 30f32223cc405d0cace9e3076b5a2a1d8cc9e3b2
Summary:
This adds https://github.com/mysticatea/abort-controller to polyfill [AbortController](https://developer.mozilla.org/en-US/docs/Web/API/AbortController). This is used to cancel requests when using `fetch`.
This also updates `event-target-shim` to 5.0 to make sure we only have one version of this dependency. This updates required adding a polyfill for `console.assert` which is used by the new version. I made one based on https://github.com/gskinner/console-polyfill/blob/master/console.js#L74.
The polyfill is very small, especially since we already use `event-target-shim` so I think it makes sense to include in core.
Depends on #24418 so that the fetch polyfill supports the `signal` parameter.
Fixes#18115
[General] [Added] - Add support for cancelling fetch requests with AbortController
Pull Request resolved: https://github.com/facebook/react-native/pull/24419
Differential Revision: D14912858
Pulled By: cpojer
fbshipit-source-id: 8a6402910398db51e2f3e3262f07aabdf68fcf72
Summary:
Closes: https://github.com/facebook/react-native/issues/24016
React Native 0.57 introduced cross-platform `accessibilityRole` and `accessibilityStates` props in order to replace `accessibilityComponentType` (for android) and `accessibilityTraits` (for iOS). With #24095 `accessibilityRole` and `accessibilityStates` will increase, receiving more options, which seems to be a good moment to remove deprecated props.
Remove deprecated `accessibilityComponentType` and `accessibilityTraits` props.
[General] [Removed] - Remove accessibilityComponentType and accessibilityTraits props
Pull Request resolved: https://github.com/facebook/react-native/pull/24344
Reviewed By: rickhanlonii
Differential Revision: D14842214
Pulled By: cpojer
fbshipit-source-id: 279945e503d8a23bfee7a49d42f5db490c5f6069
Summary:
We were using four edges for margin, padding and border. This diff changes the array size in YGLayout for margin, padding, border to reduce YGNode size and corresponding changes while we are setting values in YGLayout.
Reduces the YGNode size by 24 bytes
Reviewed By: davidaurelio
Differential Revision: D14892666
fbshipit-source-id: 94013d5183ee869901267c4c9941fd94fa05d848
Summary:
This PR fixes#24229.
Seems currently `opacity` props for Text is being applied twice (one for text color and one for the whole view). This PR disables applying the prop to the text.
[CATEGORY] [TYPE] - Fixed double applying opacity prop for Text
Pull Request resolved: https://github.com/facebook/react-native/pull/24435
Differential Revision: D14932795
Pulled By: cpojer
fbshipit-source-id: f9280fc75f788424cb5f1e42d2e79efdb354d645
Summary: Create views with props in one call instead of two. Backwards-compatible.
Reviewed By: shergin
Differential Revision: D14846424
fbshipit-source-id: cb53225579089f7e51d4e9d1fc9fc2e331a994c1
Summary:
`[RCTBridge setUp]` and `[RCTBridge invalidate]` execute asynchronously and concurrently. Therefore, it's not safe to call one method after the other, as we do in `[RCTBridge reload]`.
In this test, we create a bridge, and immediately reload it. Initializing the bridge causes the JS bundle to execute. Invalidating the bridge causes the jsThread to be terminated. If circumstances are correct, we could end up trying to executing the JS bundle after the jsThread has been terminated, which can lead to these assertions being triggered:
1. `RCTAssert(_jsThread, @"This method must not be called before the JS thread is created");` in `ensureOnJavaScriptThread:`.
2. `RCTAssert(_jsMessageThread != nullptr, @"Cannot invoke completion without jsMessageThread");` in `enqueueApplicationScript:url:onComplete:`.
```
- (void)testUnderlyingBridgeIsDeallocated
{
RCTBridge *bridge;
__weak id batchedBridge;
autoreleasepool {
bridge = [[RCTBridge alloc] initWithBundleURL:_bundleURL moduleProvider:nil launchOptions:nil];
batchedBridge = bridge.batchedBridge;
XCTAssertTrue([batchedBridge isValid], @"RCTBridge impl should be valid");
[bridge reload];
}
RCT_RUN_RUNLOOP_WHILE(batchedBridge != nil)
XCTAssertNotNil(bridge, @"RCTBridge should not have been deallocated");
XCTAssertNil(batchedBridge, @"RCTBridge impl should have been deallocated");
// Wait to complete the test until the new bridge impl is also deallocated
autoreleasepool {
batchedBridge = bridge.batchedBridge;
[bridge invalidate];
bridge = nil;
}
RCT_RUN_RUNLOOP_WHILE(batchedBridge != nil);
XCTAssertNil(batchedBridge);
}
```
To verify that this race is real, patch: P62410422. This adds an artificial delay in the `[RCTCxxBridge start]` method, which makes it so that the bridge is invalidated and the js thread is destroyed before we start executing the jsBundle.
I think a proper solution to this problem would require some bit of restructuring of `[RCTCxxBridge invalidate]` and `[RCTCxxBridge start]` to either:
1. Force `[RCTCxxBridge invalidate]` to wait for `[RCTCxxBridge start]` to complete and vice versa.
2. Make it safe to interleave execution of `[RCTCxxBridge start]` and `[RCTCxxBridge invalidate]`.
I tried the first approach using two semaphores: `_startSem(1)` and `_invalidateSem(0)`. When you start executing the code inside `[RCTCxxBridge start]`, you `semWait(_startSem)`. When you stop executing the code inside `[RCTCxxBridge start]` (which could happen in another thread at some later point in time), you `semSignal(_invalidateSem)`. Likewise, when you start executing `[RCTCxxBridge invalidate]`, you `semWait(_invalidateSem)` and when you stop executing the code inside `[RCTCxxBridge invalidate]` you `semSignal(_startSem)`. This way, invalidates always wait for starts to finish, and starts always wait for invalidates to finish. But considering all the concurrency involved in these methods, this is hard to get right.
The second approach seems possible. You could keep locks for the shared data, and create critical sections whever you want to access that data. I didn't actually try to implement this approach though.
Given that we're going to elminate the Bridge anyway, and that this race condition practically only occurs when you reload imediately after initializing the bridge (which can only really be done programmatically), I think it's fine to just disable the test for now. One other thing I considered was making the current thread sleep for some time after we created the bridge in the test. The reason why I'm hesitant to implement this approach is that it would slow down the execution of the test suite and still wouldn't guarantee that we don't hit this race condition. Ultimately, our infra might end up disabling these tests again.
Reviewed By: shergin
Differential Revision: D14909121
fbshipit-source-id: d7d441c3e2f0ad59182c8c7e23740be4ac4cf83c
Summary:
There are cases where native modules will try to reference other native modules during startup, which can causes a deadlock on `RCTModuleData::_instanceLock`.
My system was in a state where the deadlock would repro 100% so I could actually debug it a bit, but really this whole system is very fragile and needs to die in a fire.
I tried a recursive lock and it was not sufficient - there are definitely issues with multiple threads invoking at the same time and then calling `RCTUnsafeExecuteOnMainQueueSync`...
Reviewed By: fkgozali
Differential Revision: D14863583
fbshipit-source-id: 8c0d062353595a4ed3871aa9135950bc57983907
Summary:
Consolidate JavaScript tests from open source into a single script that can be executed by both Circle CI and Sandcastle, the internal Facebook CI.
[General] [Changed] - Switch internal and external CI to use the same script when running JavaScript tests
Pull Request resolved: https://github.com/facebook/react-native/pull/24422
Reviewed By: cpojer
Differential Revision: D14895773
fbshipit-source-id: d428929cc4e5219e02f5920259e08e0b3d24874c
Summary:
This diff replaces all MountItem classes with a bunch of static C functions that do the same job as classes did.
Seems, originally we overestimated the complexity of MountItem classes and that they ended up being notably trivial. Now, maintaining that even longer would mean paying for abstractions and allocations that we don't really need and writing a lot of tedious code.
Besides that, the one particular change that will be introduced in the coming diffs is not particularly fit very well in the existing class-based model.
This change also should save us many hundreds of allocations and atomic counters bumps, so maybe we can get a millisecond-or-two win.
This diff does not introduce any practical behavioral/logical changes in the mounting layer.
Reviewed By: mdvacca
Differential Revision: D14893764
fbshipit-source-id: 6f1247923ae36f29c12a7d358e2d496cf6c3e298
Summary:
`RCTImageView` is now a subclass of `RCTView` and includes `UIImageView` as it's subview.
This enables the use of `borderRadius`, `borderWidth`, `borderColor` properties and all of their derivatives.
Possible problem:
Now `RCTImageView` is backed by two views (`RCTView` + `UIImageView`), not a single one. That's 4 `CALayers`. Possible workaround would be to insert the image directly into `self.layer.contents`.
Reviewed By: RSNara
Differential Revision: D14875673
fbshipit-source-id: 594b2cd1ddffc6627566e07983c6d8f0b37dc2bb
Summary: This fixes a minor bug where the original props (like for styling) got dropped when the system falls back to UnimplementedView.
Reviewed By: mdvacca
Differential Revision: D14898906
fbshipit-source-id: 4a07952ceac66e491a5c0bc1ffd99f21438cda31
Summary: Similar to iOS, here we provide the basic impl of unimplemented view.
Reviewed By: mdvacca
Differential Revision: D14895706
fbshipit-source-id: 9053edfb2175b370d9070b6921794dbcafa1f37a
Summary: The changes made in D14811733 introduced a regression in React Native's open source iOS tests.
Reviewed By: fkgozali
Differential Revision: D14895096
fbshipit-source-id: 4307b094e3bc94e9f703b0271a95a9b318bcd49a
Summary:
Currently, `RCTLocalAssetImageLoader` only support directory of `Library` and `App bundle`, actually, we need to support other directories like `tmp` or `Documents`. Otherwise, the local image load in `tmp` or `Documents` would be handled by `NSURLSession`, we don't need that.
<img width="405" alt="image" src="https://user-images.githubusercontent.com/5061845/54188126-0ba66100-44ea-11e9-9a7b-0f721100e9be.png">
[iOS] [Fixed] - Enhance search of directories when load local asset image
Pull Request resolved: https://github.com/facebook/react-native/pull/23857
Differential Revision: D14894136
Pulled By: shergin
fbshipit-source-id: 26361cd952a423467be9af9a84a80100d868776b
Summary:
Motivation is following - I'm sure many people encountered this because it has been like this for a long time.
1 . you're developing something on android, HMR and dev mode is enabled
2 . you go to dev settings, you disable dev mode because you want to see how something behaves
3 . you reload the app because that's what is required for the change to take effect
4 . you wait for the bundle to be compiled and served, and when that is done, you get an error message about HMR not being a registered callable module - because HMR is not available when `__DEV__ === false` (todo screenshot)
this fixes the described case by checking if HMR is enabled and dev mode disabled when reloading (step 3) and disables HMR in that case.
this also fixes the case when dev mode is disabled and without knowing it, you try to enable HRM (will enable both dev hmr and dev mode).
[Android] [Changed] - improve developer experience around Dev mode and HMR interop
Pull Request resolved: https://github.com/facebook/react-native/pull/24377
Differential Revision: D14890695
Pulled By: cpojer
fbshipit-source-id: 95b6ff4131c6d05a32aadd09a9d5ed11f602122c
Summary:
There is a problem rendering text shadows on iOS. If the offset of the text shadow is `{width:0,height:0}`, the shadow does not display. This prevents you from representing a light directly above the text. This occurs because a text shadow only renders if the offset is a non-zero CGRect `{width:0,height:0}`.
My change checks `textShadowRadius` instead. If `textShadowRadius` is not nan then the user is rendering a text shadow. There are no situations to render a shadow without `textShadowRadius` making it a good variable to check.
This PR fixes this stale issue: https://github.com/facebook/react-native/issues/17277
[iOS] [Fixed] - Text shadow now displays when the textShadowOffset is {width:0,height:0}
Pull Request resolved: https://github.com/facebook/react-native/pull/24398
Differential Revision: D14890768
Pulled By: cpojer
fbshipit-source-id: a43b96a4a04a5603eede466abacd95c010d053e5
Summary: Running animations sometimes fail in Android. we are ignoring those failures temporarly
Reviewed By: fkgozali
Differential Revision: D14884510
fbshipit-source-id: 66d6113e12b1bd67e8bcc564943b423825b4cea6
Summary: This diff adds extra debug information in the mounting manager
Reviewed By: shergin
Differential Revision: D14817456
fbshipit-source-id: 5619c94eb76cdc20f5d7767f1aa4263e63f8d021
Summary:
This diff changes the way views are inserted by the diffing algorithm.
Previously the diffing algorithm inserted views top-down, now it insert views bottom-up (same order as previous version of RN).
Let say we need to create the following tree:
```
A --> B --> C
|
| --> D
```
Before, the diffing algorithm created the following list of instructions:
```
insert(A, B, 0)
insert(B, C, 0)
insert(B, D, 1)
```
After this diff, the insert instructions are going to be:
```
insert(B, C, 0)
insert(B, D, 1)
insert(A, B, 0)
```
Reviewed By: shergin
Differential Revision: D14817454
fbshipit-source-id: 7aac1a1e1784c53bca2747aee80a5bc8ee788e7a
Summary: This diff ensure that only views created by RN are taken into consideration for recycling.
Reviewed By: fkgozali
Differential Revision: D14874678
fbshipit-source-id: ea7dd5a0f29f6acf0dce8573fc77b012395476bd
Summary: AppRegistry always hides the small fabric indicator. This allows it to be enabled.
Reviewed By: mdvacca
Differential Revision: D14877831
fbshipit-source-id: 4fe3aac13074641049a9298f5a616aea3138ce93
Summary:
Android API 26 and Android Support Library 26 added support for font resource type and native/downloadable fonts. It allows apps to easily download fonts from online providers, but also use of various font weights other than normal and bold, like medium. So it deprecated APIs for asset fonts, and should be removed in the future.
Advantages:
- Just copy font files in res/font and use it specifying filename (without extension) in fontFamily
- Define custom font-family using XML file (in res/font) and font files, it may have many weights and styles. See PR for example.
- Define configuration to download fonts from online font providers, and use it.
See https://developer.android.com/guide/topics/ui/look-and-feel/fonts-in-xml and https://developer.android.com/guide/topics/ui/look-and-feel/downloadable-fonts
[Android] [Changed] - add support for custom/downloadable fonts
Pull Request resolved: https://github.com/facebook/react-native/pull/23865
Differential Revision: D14506542
Pulled By: hramos
fbshipit-source-id: 67ba3148fb4b548cdbc779213cf6c1b2c3baffd2
Summary:
This diff removes the copyToClipBoardMiddleware. This was exposing the /copy-to-clipboard endpoint that allowed unauthenticated access to writing to a developers clipboard.
This was only used in a single place, the Android red box dialog, so I've removed it from there.
Reviewed By: cpojer
Differential Revision: D14790813
fbshipit-source-id: 80e044eefd9658b8c5885643cdadf7947c00d34a
Summary: Remove dependency on ReactRootView in ReactInstanceManager by creating a rough interface (ReactRoot) so that either a Surface or ReactRootView can be attached to ReactInstanceManager.
Reviewed By: ejanzer, mdvacca
Differential Revision: D14158890
fbshipit-source-id: b7ab4654b1e0ef8343230a3c15023653a7f23a4b
Summary:
This allows an unsupported component to be rendered as a "unimplemented view" for better visualization of which component is missing. It is off by default, but configurable in the component factory.
For now, the layout simply follows regular <View />, which means the width/height etc is based on the react component styling. The side effect is that components with 0 height/width won't show up at all.
Reviewed By: mdvacca
Differential Revision: D14869656
fbshipit-source-id: f31e012fb7dc1c64fcc431ea5aa45079a23a618e
Summary:
For props that expects a struct/object value, like scrollView's contentInset, not all keys may be present. For example:
```
<ScrollView ... contentInset={{top: 10}} />
```
In this example, `left`, `bottom`, and `right` should just default to 0 (or whatever the default is in the platform). Before this fix, an exception occured when calling `fromRawValue()` because it is assuming all 4 keys are present in the prop bag. However, only `top` key was present in this example.
To fix this, we have to loop through the available keys in the prop bag, then assign the values accordingly.
Reviewed By: JoshuaGross
Differential Revision: D14868549
fbshipit-source-id: e25208eb31f6d4061338e9cac48a93fe71859859
Summary:
In the case where the first rootView we load enables Fabric, the UIManagerBinding ended up calling AppRegistry (JS) too early, before the bridge was fully ready. This means AppRegistry wasn't set up yet, causing redbox.
To fix this, RuntimeExecutor impl should ask the bridge to queue the callback instead of asking the MessageQueueThread directly. MessageQueueThread only works well IFF the bridge is alive, but it has no knowledge about whether the bridge is alive or not. To support this, we add `invokeAsync` impl to the RCTCxxBridge.
Reviewed By: JoshuaGross
Differential Revision: D14868547
fbshipit-source-id: 3b3f2b9150e930b4a2c71012242305241fc6dbed
Summary:
See https://github.com/facebook/react-native/issues/24316 for the motivation. This commit rewrites the imports in the RNTester project.
[General] [Changed] - Replaced Haste-style imports with standard path-style imports for RNTester
Pull Request resolved: https://github.com/facebook/react-native/pull/24317
Differential Revision: D14870504
Pulled By: cpojer
fbshipit-source-id: b14f22e7ce559efc332ced032617ca581196d90f
Summary:
Fixes#22511
I understand the motivation of adding extraRadiusForOutline to corner radius: without it there can be an empty space between border and view's background color.
So I add simple check: if corner radius is more than zero we still add extraRadiusForOutline. And if not, we don't add it to prevent all the corners to become slightly curved.
[GENERAL] [Fixed] - fix of Android's bug that causes all the corners to become slightly curved if only specific corners' radius should be more than zero.
Pull Request resolved: https://github.com/facebook/react-native/pull/24390
Differential Revision: D14870476
Pulled By: cpojer
fbshipit-source-id: df40fc584a2f8badc499413cb3c4e4d96b9e18cf
Summary:
The root cause comes down to the fact that historically `-DFOO=0` and `-DFOO=1` patterns have been used when it comes to preprocessor definitions and various engineers use `#ifdef FOO` and `#if FOO` interchangeably. That results in an incorrect pattern because the real evaluation is following:
- `FOO` not defined: `#if FOO` = `FALSE`, `#ifdef FOO` = `FALSE`.
- `-DFOO=0`: `#if FOO` = `FALSE`, `#ifdef FOO` = `TRUE`.
- `-DFOO=1`: `#if FOO` = `TRUE`, `#ifdef FOO` = `TRUE`.
Reviewed By: aditya7fb
Differential Revision: D14811733
fbshipit-source-id: a7fedc56ab0ce8eedcb48bda783739a4c1eecf81
Summary:
Following 6df2edeb2a, the template for a new app no longer refers to a specific version of React Native, as the React Native CLI will set the correct version when `react-native init` is run. As it happens, the CLI cannot find a local react-native@1000 version when run as part of the JavaScript e2e tests. Therefore, I am working around using the CLI directly, and instead we're copying the contents of `template/` into a temporary directory for e2e tests. This is not dissimilar to what we already test internally at Facebook.
[General] [Fixed] - Fixed JavaScript e2e tests
Pull Request resolved: https://github.com/facebook/react-native/pull/24381
Differential Revision: D14865627
Pulled By: hramos
fbshipit-source-id: b036da7479200f3efe41b81b6b336333d5558182
Summary: This change synchronizes the JSI API with its upstream, aiming to make this easier to automate in the future.
Reviewed By: mhorowitz
Differential Revision: D14783311
fbshipit-source-id: c180d0f728afbeb87a3e8e7331a39c06e73b907e
Summary: This will simplify updating the JSI API from upstream in the future.
Reviewed By: mhorowitz
Differential Revision: D14762674
fbshipit-source-id: fa4a86f08425943e301da4ef3df9893ebaa1493e
Summary:
Changelog:
----------
[Changed][General] Move callback-related logic to `AnimatedNode` class in order to make it possible to add the listener for other animated nodes than `AnimatedValue`.
I observed that native code appears to be fully prepared for listening not only to animated value but animated nodes generally. Therefore I managed to modify js code for exposing `addListener` method from `AnimatedNode` class instead of `AnimatedValue`. It called for some minor changes, which are not breaking.
If you're fine with these changes, I could add proper docs if needed.
Pull Request resolved: https://github.com/facebook/react-native/pull/22883
Differential Revision: D14041747
Pulled By: cpojer
fbshipit-source-id: 94c68024ceaa259d9bb145bf4b3107af0b15db88
Summary:
@public
compiler flags were pushed to C++14, but we don’t currently have any code that requires it. Setting to `-std=c++11` in order to fix the OSS build.
Reviewed By: SidharthGuglani
Differential Revision: D14833737
fbshipit-source-id: df2cd7da8c7124e89863c90d7b77bcf86c495618
Summary: Need to force the double thing in more places.
Reviewed By: cpojer
Differential Revision: D14835792
fbshipit-source-id: fb7a5435675b322d5fbbe9858e08804e9abe65db
Summary:
[Fixes an issue where the Docker Android tests container cannot be built.](https://github.com/facebook/react-native/pull/24276#issuecomment-480915232) The JSC is now pulled from the npm registry, so we need to run `yarn` prior to pulling the Gradle dependencies.
[Android] [Fixed] - Fixed React Native Android tests Docker container issue related to the JSC
Pull Request resolved: https://github.com/facebook/react-native/pull/24360
Differential Revision: D14842534
Pulled By: hramos
fbshipit-source-id: 3a1a714879e9c52a812b1077dce449470c30bddd
Summary: Adding JNativeRunnable to exported headers in react/jni/BUCK so I can use it outside of CatalystInstance.
Reviewed By: axe-fb
Differential Revision: D14817655
fbshipit-source-id: 15aa794e50f273778da337956c887c235a5aec3d
Summary:
See https://github.com/facebook/react-native/issues/24316 for the motivation.
By adding the .android.js and .ios.js extensions to the respective .flowconfig files, Flow is able to find files that either:
- Are required using Haste
- Are required using standard paths and have a .js extension
- Are required using standard paths and have a .platform.js subextension
[General] [Changed] - Adjusted .flowconfig to support both Haste and standard path-based requires
Pull Request resolved: https://github.com/facebook/react-native/pull/24318
Differential Revision: D14822356
Pulled By: cpojer
fbshipit-source-id: dde0c83692d6170f4a44cd3fb8ede162054157e9
Summary:
Flow typing can be annoying because the `renderItem` prop for FlatList always has to specifically be of type `React.Element`.
Since really we just want to return something renderable, it should be fine to type this as `React.Node` instead.
I'm not sure if this is valid, but it seems like since we just need to implant the `key` property, we should be able to accomplish this with a `React.Fragment` wrapper instead of needing to call `cloneElement`. Looking for feedback on if this is a sensible fix.
Changelog:
[General][Changed] Updated FlatList's renderItem Flow type from React.Element<any> to React.Node
Reviewed By: sahrens
Differential Revision: D14814805
fbshipit-source-id: ce6793dea5a92619babe048dcfddee0e4519979c
Summary:
In #20288, we solved `com.facebook.react.uimanager.NativeViewHierarchyManager.dropView (NativeViewHierarchyManager.java:536)` by adding codes that prevent to run method on `view` object when `view.getId()` is null.
But if `view` is null, `view.getId()` can make error about NullPointerException. So, I think `dropView` method needs to check if `view` is null.
If you need more information, Please read #24346.
[Android] [Fixed] - Ignore dropView method when view is null.
Pull Request resolved: https://github.com/facebook/react-native/pull/24347
Differential Revision: D14833822
Pulled By: cpojer
fbshipit-source-id: 88b6a05090ea8e8d6737c1f10b40e93649fab151
Summary:
Main change is to the property diffing - we now use the last known props set on the view rather than the default props to compute the diff. This requires exposing a `getProps` method on all view components which should be fine I think.
I also realized that in more complex animations with multiple nodes, the node that the animation starts on might not be connected to a view, so we don't know if it's fabric just based on that, so we have to do a recursive search through the children to find if there are any that are associated with a fabric view to decide we should start the animation immediately. Unfortunately there can still be a timing gap here since the animated API is async and the uimanager API is sync - I'll need to change the animated API to be sync to completely fix this.
Reviewed By: shergin
Differential Revision: D14732028
fbshipit-source-id: 882c056b0b63aa576f8e42439be405cf7fb3147a
Summary: Just a little more rigorous
Reviewed By: shergin
Differential Revision: D14790912
fbshipit-source-id: 0a4c9b6ea68466efb060c9c90572ff8987fdbd26
Summary:
We need to move animated native module calls to synchronous so we can properly thread them in with mounting instructions in Fabric. Some of them take callbacks so we need to add support for that when switching to synchronous.
A side benefit is that we can unify codepaths a little more with async callbacks.
Reviewed By: shergin
Differential Revision: D14790898
fbshipit-source-id: dc222b9e74375e046e8a9b1b19d72f652dc6722c
Summary:
@public
Regenerating the “golden master” tests with chrome surfaced different bugs around `align-content`:
- a misunderstanding that values in `align-content` only applied *if there is only one line.* In fact, it applies *every time* a container is set to `flex-wrap: wrap`. Chrome had this wrong, and as such our tests were generated with incorrect parameters.
- empty children growing to the cross axis size of the container, even when `align-content` is different from `stretch`. This was implemented incorrectly in Chrome as well. Here, we fix it with an extra check.
Reviewed By: SidharthGuglani
Differential Revision: D14725402
fbshipit-source-id: a45bebdadb9c694dc0eb7e27cb52b3d247f81c50
Summary:
Currently calling native methods on internal react native components throw a warning. I believe this is problematic because _users_ aren't calling native methods on internal components, the _component_ is making the call.
So for instance, if I unmount a component that has a form with a few uses of `TextInput`, which is a perfectly valid test case, my test output will be full of warnings that I can't call `.blur()` in the test renderer environment. That's very misleading, because I didn't, the internal component did. In fact, as far as I can tell, there's not really even anything I can do to stop that call or use the output from it, its all internal. `TextInput` is a black box, and 99% of users writing tests probably won't even know it calls `.blur()` under the hood on unmount.
I want to change these to `jest.fn()` because I think this eliminates a lot of chatter in test output, but also doesn't send users down a rabbit hole of trying to find workarounds that may involve filtering console output, which could potentially lead them to inadvertently filter out real warnings that they should see.
So I'm willing to change the implementation of how I did this, but I don't think its right to warn users that they called a native method when they didn't. If they build a component that calls these methods, I believe it's on them to do something similar to this, and maybe we can make this exposed as a helper that can be used for third party component mocks?
[General] [Changes] - Changed MockNativeMethods for core components to `jest.fn()` instead of function that warns about calling native methods.
Pull Request resolved: https://github.com/facebook/react-native/pull/24337
Differential Revision: D14822126
Pulled By: cpojer
fbshipit-source-id: 2199b8c8da8e289d38823bdcd2c43c82f3f635c9
Summary:
"Built from source" is past tense - if anything, it should be "Build from source". However, all other heading end with "ing" so it makes sense here too.
Pull Request resolved: https://github.com/facebook/react-native/pull/24343
Differential Revision: D14822098
Pulled By: cpojer
fbshipit-source-id: 3d07f2e6f8ed4a21e0311ef4f675f2d41553b619
Summary:
Previously, all placeholders methods have return type `SomeType &` which is not correct because it allows the called to modify enclosed `static` value of the placeholders; the type should be `SomeType const &`.
Besides that this diff migrates some type aliases to the new style (which makes evething much prettier and readable).
Reviewed By: mdvacca
Differential Revision: D14819076
fbshipit-source-id: 87e68d546f16d7a9ad1fb65e1b238859f9381eb7
Summary: Android plumbing for State and LocalData update mount items. See other commits in stack for usage
Reviewed By: mdvacca
Differential Revision: D14663522
fbshipit-source-id: 5604a6a9af292805e9ce46c68e5ce7472eef0218
Summary: Update Jest to 24.7.1, which has performance improvements I've built over the last few weeks.
Reviewed By: rubennorte
Differential Revision: D14766905
fbshipit-source-id: 9ebb3b6f2a9ed656ca0a41a27099fe1ea6e92710
Summary: Makes things a little more clear.
Reviewed By: TheSavior, yungsters
Differential Revision: D14790256
fbshipit-source-id: 42e47487adfd48b8de5e987ac0e73a128a200824
Summary:
Setting the scroll throttle for every animated scrollview is a pain, and if you forget it's super janky and can be confusing and frustrating.
Enables setting default props in createAnimatedComponent and uses it for scrollview.
Reviewed By: TheSavior
Differential Revision: D14790093
fbshipit-source-id: dd8f6f6540813245e87d696351f09ebb2e6ed5f2
Summary: Add experimental support for reordering the pages of a file that is mmap:ed by JSBigFileString. The wrapper is auto-detected (by checking file size and magic header) and transparently reorders the pages.
Reviewed By: ridiculousfish
Differential Revision: D14721397
fbshipit-source-id: 34e095350a9eeb9b07105bed6f3379f2fe472ae6
Summary: Fix duplicate definition Flow error in HMRLoadingView, and match latest changes made to Facebook's internal .flowconfig
Reviewed By: cpojer
Differential Revision: D13110965
fbshipit-source-id: 8c22cab8232e1f539e77014b21e258de8b08d2b3
Summary:
Fix#23755 - Which is to remove the warning:
```
Module RCTImagePickerManager requires main queue setup since it overrides `init` but doesn't implement `requiresMainQueueSetup`. In a future release React Native will default to initializing all native modules on a background thread unless explicitly opted-out of.
```
General Fixed - Warning "RCTImagePickerManager requires main queue setup
Pull Request resolved: https://github.com/facebook/react-native/pull/24314
Differential Revision: D14788772
Pulled By: cpojer
fbshipit-source-id: e2017136008367d36468debb258afa698b5402bc
Summary: This moves the iOS WebView files to be fb internal which completes the removal of WebView from React Native open source as part of the Lean Core effort.
Reviewed By: TheSavior
Differential Revision: D14630076
fbshipit-source-id: 7bc11d6c1470bb748c823c86cbb8b5ee94b508ff
Summary:
We don't need these polyfills in RN Open Source any longer because JSC supports these features natively.
We also don't need these internally at FB, but I want the removal to be a step by step process and separate from the open source work.
Reviewed By: rickhanlonii
Differential Revision: D14762827
fbshipit-source-id: 114626bd18516c42ced43c3f7aa29d42d1d95335
Summary:
It seems (I used git history to confirm) that FlatList/VirtualizedList have ([since the begining](https://github.com/facebook/react-native/blame/c13f5d48cfe3e7c0f6c6d0b745b50a089d6993ef/Libraries/Lists/VirtualizedList.js#L79)) a `disableVirtualization` prop.
SectionList ([since it's begining](https://github.com/facebook/react-native/blame/abe737fe746406533798f9670e8e243cb18d5634/Libraries/Lists/VirtualizedSectionList.js#L98)) have a `enableVirtualization` prop, but since SectionList is VirtualizedSectionList which use VirtualizedList, this prop probably never did something. This fix just rename the prop properly so it can have an effect on the underlying VirtualizedList when you use a SectionList.
Since props are spread it's kind of working already, but the flow annotation are wrong (so it tells you it won't work/ you can't use it) which sucks.
(NB: I am doing this since I was trying to use a SectionList with react-native-web & server side rendering to get the all list, you can laugh).
[General] [Fixed] - VirtualizedSectionList/SectionList: replace enableVirtualization prop annotation by correct underlying disableVirtualisation of VirtualizedList
Pull Request resolved: https://github.com/facebook/react-native/pull/24312
Differential Revision: D14779449
Pulled By: cpojer
fbshipit-source-id: e51e1d639d2bb265b5b286786010d01ffd9d90e0
Summary:
In origin approach, we packed libjsc.so inside react-native.aar and it is difficult for user to choose different JSC variants. E.g., [the Intl supported version](https://github.com/react-native-community/jsc-android-buildscripts#international-variant).
This change list allows application to determine JSC versions or variants by npm/yarn package.
There is a |useIntlJsc| flag in build.gradle, it will use the same JSC version but with Intl support.
`yarn add jsc-android@canary`
[Android] [Changed] - Allow application to select different JSC variants
**MIGRATION**
Note that there are some changes in build.gradle.
Existing application needs to change their android/build.gradle and android/app/build.gradle.
Hopefully, the rn-diff-purge should handle the case well.
Pull Request resolved: https://github.com/facebook/react-native/pull/24276
Differential Revision: D14752359
Pulled By: cpojer
fbshipit-source-id: a4bfb135ad8e328f404a2d1a062412f40ebf4622
Summary:
Since text and selection has dependency, handle text selection in
updateExtraData as well.
The root cause is due to setText is handled on extra data update but setSelection is handled on set property. And extra data update will be handled after all properties are handled. Since selection and text has dependency, move selection to extra data update as well.
Changelog:
----------
[Android] [Fixed] - Fix crash when set text and selection on textinput at the same time
Pull Request resolved: https://github.com/facebook/react-native/pull/22723
Differential Revision: D14783791
Pulled By: cpojer
fbshipit-source-id: a4065f3e151d23f4813d76e91d68362cfd4daaf4
Summary:
Trivial.
Now we can print actual list of mutations in case of some failure in the diffing algorithm.
Reviewed By: mdvacca
Differential Revision: D14715079
fbshipit-source-id: d0af7c756287643892d7120c199bc8028a6b3431
Summary:
Informal `DebugStringConvertible` interface serves the same purpose as `DebugStringConvertible` abstract class (providing universal pretty-printing interface) but relies on C++ static overloading instead of virtual dispatch.
This approach has some advantages and disadvantages:
Pros:
* It's more clear and scoped. It's simpler to implement debug-printing functionality aside of normal production code.
* It's more composable.
* It allows print types that are not classes.
* For some classes using `DebugStringConvertible` means that we have to use virtual inheritance (which might be undesirable and affect *production* performance (if a compiler isn't smart enough to remove empty base class).
* For some highly lean classes (that designed to be as small as possible) adding base (even empty-in-prod) classes kinda... smells.
Cons:
The particular implementations cannot rely on dynamic dispatch which can complicate printing classes with meaningful differences between sampling classes (e.g. ShadowNode subclasses). That's why we don't remove `DebugStringConvertible` class yet.
Reviewed By: mdvacca
Differential Revision: D14715081
fbshipit-source-id: 1d397dbf81dc6d1dff0cc3f64ad09f10afe0085d
Summary:
They need to be in DebugStringConvertible because it depends on they (and because `debugStringConvertibleUtils` depends on `DebugStringConvertible`).
We also moved they implementation to cpp file to avoid leaking Folly's features to consumer namespace.
Reviewed By: mdvacca
Differential Revision: D14715080
fbshipit-source-id: 7277e17b39a14a2d7ba7e5a9b44a70178feb1045
Summary:
* Small improvements in pretty-printing algorirhm (adding spaces and new-line caracters). Now it's even more pretty.
* The `depth` parameter was integrated into `DebugStringConvertibleOptions` which simplifies evething a bit and reduce amount of arguments that `getDebugDescription` requires.
Reviewed By: sahrens
Differential Revision: D14715082
fbshipit-source-id: 3ea0b8db3c1816c5cb43f40ccec9cdc1943f33a5
Summary: These are the same types as the existing measure calls on Paper's UIManager except ReactTag has been replaced with Node
Reviewed By: fkgozali
Differential Revision: D14732142
fbshipit-source-id: b757e0d1f8d168232d8ba58938cdcd3b30e006ff
Summary: Now that React Native ships with a newer version of JSC, we do not need this code to wrap `Object.freeze` any longer.
Reviewed By: mmmulani
Differential Revision: D14779239
fbshipit-source-id: 1a6e1a9c7f4312572bd08ba604fa8c9d6b1927e1
Summary: We've identified a couple of remaining issues that need to be re-tested before we can ship this more broadly.
Reviewed By: fred2028
Differential Revision: D14775730
fbshipit-source-id: 22402149066c5fbe72c36fcf7f547d63feaf5241
Summary:
React Native on Android has currently been focused and targeted at using an [Activity](https://developer.android.com/reference/android/app/Activity.html) for its main form of instantiation.
While this has probably worked for most companies and developers, you lose some of the modularity of a more cohesive application when working in a "brown-field" project that is currently native. This hurts more companies that are looking to adopt React Native and slowly implement it in a fully native application.
A lot of developers follow Android's guidelines of using Fragments in their projects, even if it is a debated subject in the Android community, and this addition will allow others to embrace React Native more freely. (I even assume it could help with managing navigation state in applications that contain a decent amount of Native code and would be appreciated in those projects. Such as sharing the Toolbar, TabBar, ViewPager, etc in Native Android)
Even with this addition, a developer will still need to host the fragment in an activity, but now that activity can contain native logic like a Drawer, Tabs, ViewPager, etc.
**Test plan (required)**
* We have been using this class at Hudl for over a couple of months and have found it valuable.
* If the community agrees on the addition, I can add documentation to the Android sections to include notes about the potential of this Fragment.
* If the community agrees on the addition, I can update one or more of the examples in the `/Examples` folder and make use of the Fragment, or even create a new example that uses a native layout manager like Drawer, Tabs, Viewpager, etc)
Make sure tests pass on both Travis and Circle CI.
_To Note:_
* There is also talk of using React Native inside Android Fragment's without any legit documentation, this could help remedy some of that with more documentation included in this PR https://facebook.github.io/react-native/releases/0.26/docs/embedded-app-android.html#sharing-a-reactinstance-across-multiple-activities-fragments-in-your-app
* Others have also requested something similar and have a half-baked solution as well http://stackoverflow.com/questions/35221447/react-native-inside-a-fragment
[ANDROID][FEATURE][ReactAndroid/src/main/java/com/facebook/react/ReactFragment.java] - Adds support for Android's Fragment system. This allows for a more hybrid application.
<!--
Help reviewers and the release process by writing your own release notes
**INTERNAL and MINOR tagged notes will not be included in the next version's final release notes.**
CATEGORY
[----------] TYPE
[ CLI ] [-------------] LOCATION
[ DOCS ] [ BREAKING ] [-------------]
[ GENERAL ] [ BUGFIX ] [-{Component}-]
[ INTERNAL ] [ ENHANCEMENT ] [ {File} ]
[ IOS ] [ FEATURE ] [ {Directory} ] |-----------|
[ ANDROID ] [ MINOR ] [ {Framework} ] - | {Message} |
[----------] [-------------] [-------------] |-----------|
[CATEGORY] [TYPE] [LOCATION] - MESSAGE
EXAMPLES:
[IOS] [BREAKING] [FlatList] - Change a thing that breaks other things
[ANDROID] [BUGFIX] [TextInput] - Did a thing to TextInput
[CLI] [FEATURE] [local-cli/info/info.js] - CLI easier to do things with
[DOCS] [BUGFIX] [GettingStarted.md] - Accidentally a thing/word
[GENERAL] [ENHANCEMENT] [Yoga] - Added new yoga thing/position
[INTERNAL] [FEATURE] [./scripts] - Added thing to script that nobody will see
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/12199
Differential Revision: D14590665
Pulled By: mdvacca
fbshipit-source-id: b50b708cde458f9634e0c14b3952fa32f9d82048
Summary: Before D14297477, the pre-allocation of views was ONLY necessary when react was running in the JS Thread, this is because the batch of mount items used to contain mount items for creation of views. After D14297477, views are only created during pre-allocation, that means that pre-allocation of views need to be trated the same way independently the thread where it is running.
Reviewed By: shergin
Differential Revision: D14714933
fbshipit-source-id: 7bd19cd33b624a5b0daaafabb476bb06707eea17
Summary:
ScrollView's scrollTo behavior on iOS was recently changed to limit the offset to the content size plus any content inset (see #23427). This departure from the old behavior created UI issues for anyone that is using the over-scroll ability for the purpose of positioning elements at specific coordinates on the screen. Examples include using this behavior to position TextInputs above the virtual keyboard programmatically when focused or moving drop down elements positioned near the bottom of the content toward the top of the screen when selected to show a larger absolutely positioned item list. Default behavior does not change and this is an "opt-in" type of prop to re-enable the old behavior.
[iOS] [Added] - Added scrollToOverflowEnabled prop to ScrollView
Pull Request resolved: https://github.com/facebook/react-native/pull/24296
Differential Revision: D14762619
Pulled By: cpojer
fbshipit-source-id: d2a552b5cb321d52e8ea4116327bf9ec647a3aae
Summary: A previous commit changed the signature of the Instance (the arg to JSCallInvoker) to be a weak ref, so this callsite needs updating.
Reviewed By: mmmulani
Differential Revision: D14757188
fbshipit-source-id: 1a8663e56a42b26c6202881c57a7caafa71da2ab
Summary:
This diff fixes a bug in TouchableNativeFeedback where a long press is not registered.
cause of the bug is _touchableHandleResponderMove_ being invoked **regardless** of a moving gesture ( even when movedDistance is 0) in some devices ( including OnePlus5t ), which was eventually clearing out the long-press timeout.
fix is to prevent _touchableHandleResponderMove_ from Implementing if the state of touchable is RESPONDER_INACTIVE_PRESS_IN.
[General] [Fixed] - Touchable onLongPress fix.
Pull Request resolved: https://github.com/facebook/react-native/pull/24238
Reviewed By: cpojer
Differential Revision: D14712986
Pulled By: rickhanlonii
fbshipit-source-id: e85a66a7e8b61e0a33146b2472e2e055726a0e93
Summary:
Fixes an issue where `scripts/objc-test-ios.sh` would fail if `xcpretty` is not installed. As this tool is not bundled with macOS, and it's not explicitly called out in our docs on testing, the script should not fail if it's not present.
In a related change, JUnit reports are written to a more sensible location when the script is run outside of Circle CI.
[iOS] [Fixed] - Fixed test script failure when xcpretty is not present
Pull Request resolved: https://github.com/facebook/react-native/pull/24173
Differential Revision: D14726101
Pulled By: hramos
fbshipit-source-id: 9f3081a75a4a262f55aef8498241fe7d1e04b931
Summary:
With new `init` implementation we replace all occurrences of the project name (`HelloWorld`) inside `ios` and `android` directories. For some reason, a product name field in `ios` was named wrongly. This shouldn't impact initialization using `global-cli`
[iOS] [Fixed] - Change productName in iOS in new init.
Pull Request resolved: https://github.com/facebook/react-native/pull/24292
Differential Revision: D14749249
Pulled By: cpojer
fbshipit-source-id: aaf4294ab23180770aac3075789d3ffb4d5a4f3f
Summary:
Currently, `react-native` Jest preset will not automatically transpile extracted Lean Core modules (all under `react-native-community` org), so maintainers will likely need to update their docs on how to do that (it's a common pain in RN testing story).
We can make it easier for users and maintainers by adding RNC modules to the `transformIgnorePatterns` whitelist we have in Jest preset. Some of them are not necessary to transpile, but I'd say it's a small sacrifice to make (having first test run possibly slower) for having less friction around migrating to extracted modules.
[General] [Added] - make Jest transform react-native-community/ packages by default
Pull Request resolved: https://github.com/facebook/react-native/pull/24294
Differential Revision: D14748962
Pulled By: cpojer
fbshipit-source-id: 36300ee021f03b8c13275a6e0cf28d988ee5beba
Summary:
@public
In order to get out of pre-releases again, we move `YGSetUsedCachedEntries` from `Yoga.h` to `Yoga-internal.h`.
This way, it’s obvious that the function is not public, and we can remove it from future versions without breaking semver contracts.
Reviewed By: SidharthGuglani
Differential Revision: D14726029
fbshipit-source-id: 8d7e747e843bf5c4b5e1d4cfbfa37ca9d240dffb
Summary: All animations are scheduled by the UIManager while it processes a batch of changes, so we can just wait to see what the longest animation is and cancel+reschedule the callback.
Reviewed By: mdvacca
Differential Revision: D14656733
fbshipit-source-id: 4cbbb7e741219cd43f511f2ce750c53c30e2b2ca
Summary: This code was shipped as part of the initial open-source release but was never used.
Reviewed By: sahrens
Differential Revision: D14649389
fbshipit-source-id: 0c068ca69b91d275008f4a7af77a23a4f1470c18
Summary: Add additional logging around the exception to figure out what kind of uris are causing the exception for `getContentTypeForFileName`
Reviewed By: PeteTheHeat
Differential Revision: D14715917
fbshipit-source-id: 46299d2ff3f1f06991d7800784a025a85815ae8c
Summary:
It seems that the content view can sometimes be null when onOverScrolled is called (presumably when the scrollview gets unmounted while it's in the middle of scrolling?).
Changelog: [Android][fixed] - Guard against content view being null in onOverScrolled.
Reviewed By: mdvacca
Differential Revision: D14737534
fbshipit-source-id: e88ec6f585e50517b734a8809fc3843c0b22df10
Summary:
There is a timing issue when reloading the bridge (in dev mode) and the tear down of the TurboModules. This causes `Instance` to never get freed, hence the "bridge" isn't cleaning up properly. The side effect can be bogus error saying that it's unable to find a module.
To address this, JSCallInvoker should just take in weak_ptr<Instance>.
Reviewed By: RSNara
Differential Revision: D14739181
fbshipit-source-id: f9f2a55486debaeb28d3d293df3cf1d3f6b9a031
Summary: Add a target for JSBigString tests that can be run with a normal `buck test` invocation. Also fix an issue in the test when `getenv` returns null by defaulting to `/tmp`.
Reviewed By: ridiculousfish
Differential Revision: D14716270
fbshipit-source-id: f2eb6d3aab93c32a4b41f5786aedd04a70468d75
Summary:
@public
This resolves the iOS side of #20879.
Reviewed By: natestedman, cpojer
Differential Revision: D14712066
fbshipit-source-id: 88dd0ff80d3467b314cacb9349029dadca4ddf19
Summary: This moves the Java files to FB internal and updates all the buck files
Reviewed By: TheSavior
Differential Revision: D14622521
fbshipit-source-id: a8d293e9f9e08868cca3ed2986a08d0db16dec15
Summary:
Try to prevent the crash described in https://github.com/facebook/react-native/issues/17530
There seems to be a bug in `Drawable.mutate()` in some devices/android os versions even after you check the constant state. This error is hard to reproduce and to fix, so just try to catch the exception to prevent crash.
[Android][Fixed] Prevent random crash when setting underlineColorAndroid
Pull Request resolved: https://github.com/facebook/react-native/pull/24183
Differential Revision: D14710484
Pulled By: cpojer
fbshipit-source-id: 3af20a5cb0ecd40839beaf85118c0f5aa6905414
Summary:
Since template has a fixed version in `template/package.json`, we want to automate this process.
[General] [Added] - Bump react-native in `template/package.json`
Pull Request resolved: https://github.com/facebook/react-native/pull/24262
Differential Revision: D14724831
Pulled By: cpojer
fbshipit-source-id: 164d13001a889941398f3db3b9b96eb9d5114cc3
Summary:
Potential breaking change: The signature of ReactShadowNode's onBeforeLayout method was changed
- Before: public void onBeforeLayout()
- After: public void onBeforeLayout(NativeViewHierarchyOptimizer nativeViewHierarchyOptimizer)
Implements same feature as this iOS PR: https://github.com/facebook/react-native/pull/7304
Previously, only Text and Image could be nested within Text. Now, any view can be nested within Text. One restriction of this feature is that developers must give inline views a width and a height via the style prop.
Previously, inline Images were supported via FrescoBasedReactTextInlineImageSpan. To get support for nesting views within Text, we create one special kind of span per inline view. This span is called TextInlineViewPlaceholderSpan. It is the same size as the inline view. Its job is just to occupy space -- it doesn't render any visual. After the text is rendered, we query the Android Layout object associated with the TextView to find out where it has positioned each TextInlineViewPlaceholderSpan. We then position the views to be at those locations.
One tricky aspect of the implementation is that the Text component needs to be able to render native children (the inline views) but the Android TextView cannot have children. This is solved by having the native parent of the ReactTextView also host the inline views. Implementation-wise, this was accomplished by extending the NativeViewHierarchyOptimizer to handle this case. The optimizer now handles these cases:
- Node is not in the native tree. An ancestor must host its children.
- Node is in the native tree and it can host its own children.
- (new) Node is in the native tree but it cannot host its own children. An ancestor must host both this node and its children.
I added the `onInlineViewLayout` event which is useful for writing tests for verifying that the inline views are positioned properly.
Limitation: Clipping
----------
If Text's height/width is small such that an inline view doesn't completely fit, the inline view may still be fully visible due to hoisting (the inline view isn't actually parented to the Text which has the limited size. It is parented to an ancestor which may have a different clipping rectangle.). Prior to this change, layout-only views had a similar limitation.
Pull Request resolved: https://github.com/facebook/react-native/pull/23195
Differential Revision: D14014668
Pulled By: shergin
fbshipit-source-id: d46130f3d19cc83ac7ddf423adcc9e23988245d3
Summary: This removes the JS parts of Geolocation from React Native open source.
Reviewed By: yungsters
Differential Revision: D14693179
fbshipit-source-id: 1da5b7ec0e3e9d21d2019b7ee43e5f85661795b4
Summary: A retain-cycle regression was added by D14162776 and detected here: T41208740. Fix should be trivial.
Reviewed By: shergin
Differential Revision: D14709784
fbshipit-source-id: bad6ab31a5170e9320c4432cbd20d02ec6164f38
Summary:
D14423742 introduced a regression on OSS test_android due to androidx.core.os not being available. I spent some time investigating a fix forward this morning, with no success. Reverting.
Changelog:
[Android] [Changed] - Revert 92f019c666
Reviewed By: cpojer
Differential Revision: D14668728
fbshipit-source-id: c7542992805551dc4302626e1536759794efaa82
Summary:
It closes#24170.
I opened the issue yesterday, and I think I found the way how to resolve it. So, I'm opening this PR directly without any comment on the issue.
In the `endRefreshProgrammatically` of `RCTRefreshControl.m`, the comment says that " The contentOffset of the scrollview MUST be greater than 0". However, if the `contentInset` prop is set for the `FlatList`, I think `contentOffset` can be a negative value after refreshing and should be greater than `-contentInset.top`.
As I reported the bug in that issue, If I am using `contentInset` prop to the `FlatList`, making `contentOffset` value be always 0 when refreshing ends causes something wrong situation.
[iOS] [Fixed] - Fix setting the contnetOffset when refreshing ends
Pull Request resolved: https://github.com/facebook/react-native/pull/24191
Differential Revision: D14710987
Pulled By: sahrens
fbshipit-source-id: 03f06df9a93a2a46a7cc0b56269091778805917e
Summary:
Harmonizes the spacing after colons to have a more consistent coding style.
Pull Request resolved: https://github.com/facebook/react-native/pull/24186
Differential Revision: D14668167
Pulled By: cpojer
fbshipit-source-id: 8f1ba71eec186b3a2221d1f4fac851e51afc52cc
Summary:
Add the ability to set a custom handler on ReactWebViewManager to handle client certificate challenges during TLS authentication.
[Android][Added] - Public method setCustomClientCertRequestHandler to the native com.facebook.react.views.webview.ReactWebViewManager, that allows using a custom response for client certificate challenges.
Reviewed By: mjhu
Differential Revision: D14609697
fbshipit-source-id: 567c95458af638d1f8233fc3ca0d9cefc061c2bf
Summary:
We suspect that we have some error in diffing algorithm that cause some crashes in mounting layer, so we decided to write a comprehensive unit tests for that.
Writing them we realized that it would be cool to also enable that for normal app run in the debug more, so we can catch the problem in real environment when/if it happens.
Reviewed By: mdvacca
Differential Revision: D14587123
fbshipit-source-id: 6dcdf451b39489dec751cd6787de33f3b8ffb3fd
Summary: Because it's kinda more logical and we will rely on this in comming diffs.
Reviewed By: mdvacca
Differential Revision: D14587124
fbshipit-source-id: 94ae9410b4ffeffd0fcb4da4a0518f0bb0d2ba63
Summary: This is the first diff in an effort to remove Geolocation from React Native. This diff removes the globally injected navigator.geolocation feature and instead requires explicit importing of `Geolocation`. When using Web APIs, people will need to patch `navigator.geolocation` on their own from now on.
Reviewed By: sahrens
Differential Revision: D14692386
fbshipit-source-id: c57b290b49728101250d726d67b1956ff23a9a92
Summary: Looks like there are already a bunch of issues in the codebase because this wasn't on.
Reviewed By: cpojer
Differential Revision: D14701084
fbshipit-source-id: 09ff8e0d905b81fbe08c41d4f58758479b38187b
Summary:
Using a config flag to switch between different implementations of transferring layout outputs
- YogaNodeJNI uses multiple access of java fields to pass all properties like width, height, margin etc...
- YogaNodeJNIBatching uses a float array to pass all the data in one java field access
Reviewed By: davidaurelio
Differential Revision: D14378301
fbshipit-source-id: 0da5b28e6a67ad8fd60eb7efe622d9b2deaf177f
Summary: This diff adds the logic to transfer layout outputs using a float array
Reviewed By: davidaurelio
Differential Revision: D14368120
fbshipit-source-id: d1f22283bcea051d15657f42c15b90edaa0a8a7a
Summary: This diff adds a test for reset method in YogaNodeJNI to verify all layout outputs are reset properly
Reviewed By: davidaurelio
Differential Revision: D14643926
fbshipit-source-id: fffbcd07ccb6d2df83fc0bf187d992ef194f3bd0
Summary:
Moved layout outputs transfer logic from YogaNodeJNIBase to YogaNodeJNI.
This change set is for adding experiment for layout outputs batching using a float array
Reviewed By: davidaurelio
Differential Revision: D14642995
fbshipit-source-id: 5d0bc7fa18c1985be7e216d7351f5eab2e03861d
Summary:
Xcode 10.2 forbids creating categories for swift class that uses `+load` method. In react-native categories like this are used to register swift classes as modules (macro `RCT_EXTERN_MODULE`) This PR changes it to use `__attribute__((constructor))` instead of objc `+load` method.
I introduced new macro for this purpose, `RCT_EXPORT_MODULE_NO_LOAD`, it expands in something like:
```
void RCTRegisterModule(Class);
+ (NSString *)moduleName {
return @"jsNameFoo";
}
__attribute__((constructor)) static void initialize_ObjcClassFoo{
RCTRegisterModule([ObjcClassFoo class]);
}
```
Functions marked with `__attribute__((constructor))` are run before main and after all `+load` methods, so it seems like correct thing to do.
Fixes https://github.com/facebook/react-native/issues/24139
Doc about loading order https://developer.apple.com/documentation/objectivec/nsobject/1418815-load?language=objc
[iOS] [Fixed] - Fix runtime crash in xcode 10.2 when using RCT_EXTERN_MODULE for swift classes.
Pull Request resolved: https://github.com/facebook/react-native/pull/24155
Reviewed By: javache
Differential Revision: D14668235
Pulled By: shergin
fbshipit-source-id: 0c19e69ce2a68327387809773848d4ecd36d7461
Summary:
If a NativeModule method requires an optional boolean argument, our codegen translates those optional booleans into `NSNumber*` instead of `BOOL`. The reason why is probably because this is the closest object analogue to `BOOL` in Objective C. The same boxing occurs with numbers. If the type of a number argument in JavaScript is optional, we'll map it to the `NSNumber*` Objective C type instead of `double`. Our existing TurboModules argument conversion code would not take this behaviour into account. Therefore, we'd try to insert a `BOOL` where the `NSInvocation` would expect a `NSNumber*`. This, in turn, would cause the app to crash. (Why would it crash at the point of NSInvocation retainArguments, I'm still not sure).
Our flow typechecking ensures that if the type of a method argument is a boolean, we pass in a boolean. Therefore, on the Native side, if we detect a boolean, we can check the type of the Native argument to see whether we should box the primitive. If the native argument type is an object, then we know it has to be an `NSNumber*` in both cases, so we simply wrap the `BOOL` or `double` in a `NSNumber*`.
Reviewed By: shergin
Differential Revision: D14679590
fbshipit-source-id: c394a878492aab8e98c71d74ec8740a94fc3a6c5
Summary:
Temporarily disable View Pooling in Fabric
Naming of classes will change in the near future
Reviewed By: JoshuaGross
Differential Revision: D14685009
fbshipit-source-id: 83573dd09af0202a67d0d0aa11e37c1660c3991f
Summary: Before the fix, the algorithm compares ShadowViews to make a decision should it recursively call itself or not; that didn't work properly because a ShadowView doesn't fully represent the state of the subtree tree (e.g. they don't have information about children nodes). After the fix, we compare pointers to ShadowNodes (by comparing pairs).
Reviewed By: mdvacca
Differential Revision: D14696996
fbshipit-source-id: 560d623b15a272f13b08a11745dec6be39a5dbdd
Summary: Moves a number of requireNativeComponent calls to standalone files to support codegen
Reviewed By: TheSavior
Differential Revision: D14654018
fbshipit-source-id: 349b975cd3a99a9373b2b9b1a19aa311d7c36399
Summary: This moves all the JS files and updates the BUCK files. The next step is to move the Android and iOS native files.
Reviewed By: TheSavior
Differential Revision: D14618890
fbshipit-source-id: 42984acdf5920e712f272d5742c778943be37ac5
Summary: With the recent change, JSCallInvoker now expects `Instance` to be passed in, not just the `MessageQueueThread`. There needs to be more plumbing to get the instance of `Instance` from the Java side, but this commit is just to unbreak the build temporarily.
Reviewed By: JoshuaGross
Differential Revision: D14687622
fbshipit-source-id: 42e0173ee8336fc5660fe8188a1e1f8517611521
Summary:
Otherwise reloading from metro deadlocks like this:
`[RCTSurfaceRegistry _stopAllSurfaces]` is calling `[RCTSurfaceRegistry enumerateWithBlock]` which locks `_mutex` and then we call `surfaceForRootTag` which then deadlocks on the same mutex:
https://pxl.cl/tmm1
Reviewed By: shergin
Differential Revision: D14679843
fbshipit-source-id: 9f4ecdfa7a79fcf7f3fc2ce437d4399b00910f26
Summary:
If size is zero, the `CGContext` would invalid, so we need to filter zero things.
cc. shergin
[iOS] [Fixed] - Fix invalid CGContext when invalidate layer
Pull Request resolved: https://github.com/facebook/react-native/pull/24195
Differential Revision: D14683396
Pulled By: shergin
fbshipit-source-id: b5b45fb86ca3158284281460cf1d95d1b22eab0d
Summary: When calling into JS (e.g. promise resolve/reject, callback) in TurboModule, we bypass the bridge's message queue. At times this causes race condition, where there are a bunch of pending UI operations (in RCTUImanager) waiting to be flushed, but nothing adds calls to the message queue. Usually tapping the screen will trigger the flush because we're sending down touch events to JS.
Reviewed By: JoshuaGross
Differential Revision: D14656466
fbshipit-source-id: cb3a174e97542bf80f0a37b4170b6a8e6780fa35
Summary: Small changes to State objects to support Android. See following diffs.
Reviewed By: mdvacca
Differential Revision: D14663470
fbshipit-source-id: 878f4dc39265991a7b8ff54ca80bdb862f1dd3de
Summary:
This diff fixes the scrolling of Android Horizontal Scroll View, the root cause was that Binding was mounting a ScrollView instead of an AndroidHorizontalScrollView component.
This will be automatically fixed when all the View components are autogenerated.
Reviewed By: shergin
Differential Revision: D14594622
fbshipit-source-id: 7c477ca167188ea9c473f61145461d3cf1696e17
Summary: Simple diff that refactors the usage of the sComponentNames to not require components to be part of the mapping when the name in JS is the same as the name in Native side.
Reviewed By: shergin
Differential Revision: D14594659
fbshipit-source-id: d1948b27e04686fefbf9b6e2b06d4f9317b97062
Summary: Adds debug logging in FabricUIManager and the mounting layer of Fabric.
Reviewed By: shergin
Differential Revision: D14594521
fbshipit-source-id: a5c0ee39e1bac8a340849ca3e044694cbee5427e
Summary: This diff exposes the collapsable prop as part of LayoutShadowNode, fixing the bug of the collapsable prop being filtered by JS in Fabric
Reviewed By: shergin
Differential Revision: D14594522
fbshipit-source-id: a892ba8228e76f11232acc6fe5c8d75e991d8fc6
Summary:
This diff removes the `WebView` export from React Native. Internally, we are requiring `WebView` directly now and externally people will have to use the community maintained module. This diff does not yet move the WebView files from the repo, this will happen in a follow-up.
Note that I had to remove a test for Cookies that displayed data in a WebView. I don't think there is an easy way to retain this (debugging) information that likely very few people ever take a look at so I think it is fine.
Reviewed By: TheSavior
Differential Revision: D14613077
fbshipit-source-id: b1d412f970d09d7d70ecac2c23e62cfdd09d7c8e
Summary:
Add `bin` field to `package.json`. It will be required for initializing `react-native` with `npx`:
```sh
npx react-native init ProjectName
```
[General] [Added] - Added bin to package.json
cc thymikee cpojer
Pull Request resolved: https://github.com/facebook/react-native/pull/24187
Differential Revision: D14672211
Pulled By: hramos
fbshipit-source-id: 9e8633213bba4b3f02d20b54391a04d0a1a19376
Summary:
Add the ability to build on top of the OkHttpClient.Builder by defining a lambda that gets called on network requests
[Android][Added] - Public method `setCustomClientBuilder` to the native `com.facebook.react.modules.network.NetworkingModule`, that allows customizing the OkHttpClient per-request for greater control over HTTP requests.
Reviewed By: hramos
Differential Revision: D14288613
fbshipit-source-id: 34df0ff3e18eeea1d565ccfcf97408379900120b
Summary: See https://github.com/facebook/fbjs/pull/293 for an explanation.
Reviewed By: yungsters
Differential Revision: D14658680
fbshipit-source-id: aad8808b8514817314bf67b9a43b01d52e850e36
Summary: According to TheSavior this was an experimental module that "accidentally" got added to RN open source. In fact, we only use it in two places internally. This diff moves these files to FB internal and removes them from RN completely. I skipped the deprecation message because it was always an experimental feature and I don't expect anyone out there using it.
Reviewed By: TheSavior
Differential Revision: D14631749
fbshipit-source-id: 87878fcbb901e1e7fa4a3ff3205e09886ff3ed43
Summary:
This lint setting makes deprecated $call syntax a warning instead of an error,
which is the default. This feature has been deprecated since Flow v0.75.0, and
I'm working to finally remove it, which will also remove this lint setting.
Reviewed By: dsainati1
Differential Revision: D14650366
fbshipit-source-id: 779df61be88996278ea63355517c17ec721cea7f
Summary:
I was working to use more Android Support Library in RN core, but wasn't able to finish it. So this PR is for only Systrace and TraceCompat only.
[Android] [Changed] - Use TraceCompat in Systrace
Pull Request resolved: https://github.com/facebook/react-native/pull/23780
Differential Revision: D14423742
Pulled By: hramos
fbshipit-source-id: e3c3e2dfd95eac3d2484313f9be69df1c85904cf
Summary:
This makes the RCTEvent protocol more generic to make it easier to use the event coalescing feature for type of events other than components. This does a few other improvements that will be useful in follow up PRs.
- Add `RCTComponentEvent` which is used instead of deprecated `[sendInputEventWithName:body:]` and remove that method completely (was only used at 2 places).
- Make `coalescingKey` optional for events that return NO from `canCoalesce`.
- Make `viewTag` optional for events that are not related to views.
- Fast path for events that return NO from `canCoalesce`.
- Add a missing test for event coalescing with different view tags.
Ended up making only one PR for all this since the changes are related and hard to separate.
**Migration**
Use a custom RCTEvent subclass with `[sendEvent:]` (preferred way to allow type safe events) or `RCTComponentEvent`.
**Test plan**
- Ran RCTEventDispatcher unit tests
- Tested manually in RNTester
Changelog:
[iOS] [Changed] - Remove deprecated RCTEvent method, sendInputEventWithName:body:
Pull Request resolved: https://github.com/facebook/react-native/pull/15894
Reviewed By: shergin
Differential Revision: D13726194
Pulled By: hramos
fbshipit-source-id: 11f63a99e08f46ec6b4f16f8d9949cdbf5c3fe13
Summary:
In D14571128, we made it so that when a JS object's property was `undefined`, we wouldn't insert that property into the corresponding NSDictionary. Here are two important observations about that diff:
1. ALL JS `null`s were now being converted to `NSNull`, and JS `undefined`s were now being converted to `nil`.
2. If a JS object's property was explicitly `null`, then we'd insert `NSNull` into the corresponding dictionary.
Considering that when a property doesn't exist in a `NSDictionary`, property access returns `nil`, I've made it so that if a JS object's property is either `null` or `undefined`, then we simply do not insert it in the corresponding `NSDictionary`. Also, I've reverted #1 and made it so that `undefined` and `null` always map to the ObjC `nil`.
This shouldn't unfix the problem that D14571128 was trying to fix.
Here's my understanding of the problem that D14571128 was trying to fix (to make sure I'm not breaking something by this diff).
This method was invoked from JS.
```
RCT_EXPORT_METHOD(logEvents:(NSDictionary *)events)
{
RCTAssert(events, @"You should provide events for logger");
[[NSNotificationCenter defaultCenter] postNotificationName:@"FBReactPerfLoggerDidReceiveEventsNotification"
object:nil
userInfo:@{@"FBReactPerfLoggerUserInfoPerfEventsKey" : [events copy]}];
}
```
The above dispatch calls into this method, which appends `events` into `_pendingJSPerfEvents`.
```
- (void)reactPerfLoggerDidReceiveEvents:(NSNotification *)notification
{
NSDictionary *events = notification.userInfo[@"FBReactPerfLoggerUserInfoPerfEventsKey"];
if (events) {
dispatch_async(_eventQueue, ^{
if (self->_sessionData.perfLoggerFlagId != nil) {
if ([self processJSPerfEvents:events]) {
[self reportMetricsIfFinished];
}
} else {
[self->_pendingJSPerfEvents addObject:events];
}
});
}
}
```
Then, in `_processJSPerfEvents`, we do the following (link: https://fburl.com/tr4wr2a7):
```
NSNumber *actionId = events[@"actionId"];
if (actionId) {
self->_sessionData.actionId = actionId;
}
```
So, if `undefined` or `null` was passed in as the `actionId` property of the `events` JS object in `FBReactPerformanceLogger logEvents:`, then we'd default the `NSDictionary` to have `NSNull` in the corresponding property. This is bad because we had this line in FBReactWildePerfLogger (link: https://fburl.com/2nsywl2n): `actionId ? [actionId shortValue] : PerfLoggerActions.SUCCESS`. Essentially, this is the same problem that my diff is trying to fix.
Reviewed By: fkgozali
Differential Revision: D14625287
fbshipit-source-id: c701d4b6172484cee62494256175e8b205b23c73
Summary:
We want the ability to use Linkify on android text elements. This only adds this property to Text and not TextInput since there are some functional differences with how the types could be used between iOS and android - iOS allows one or many types while Linkify restricted us to providing only one option (using the masks).
Performance is affected ONLY FOR TEXT ELEMENTS USING THIS FEATURE since Linkify is searching for patterns.
Pull Request resolved: https://github.com/facebook/react-native/pull/19216
Differential Revision: D14621883
Pulled By: cpojer
fbshipit-source-id: cb692021d314140b9a92b29e23384afd7fd1b09e
Summary:
This PR is a follow-up to #21211 by request of hramos to incorporate some additional crash fixes / synchronization edge cases found in our production testing. What follows is largely a copy of the original PR description from #21211 - see that PR for original discussion thread as well as context on why this replacement PR was needed.
This PR is a minimalistic change to RCTTiming that causes it to switch exclusively to NSTimer (i.e., the 'sleep timer') in order to continue triggering timers when the app has moved to the background.
Many people have expressed a desire for background timer support on iOS. (See #1282, #167, and #16493). In our app — a podcast/audio player — we use background timers to ensure that we never lose track of the user's playback position, should the app crash or be terminated by the OS.
The RCTTimer module uses a RN-managed CADisplayLink if the next requested timer is less than a second away; otherwise, it switches to an NSTimer (which is refers to as a 'sleep timer' in source). The RN-managed CADisplayLink is always disabled when the app goes to the background (and thus cannot be used); however, the NSTimer will still issue its callbacks in the background.
This PR adds a flag to track whether the app is in the background, and if so, all timers are routed through NSTimer until the app returns to the foreground. vishnevskiy at Discord opened a similar PR (#16493) that implements a drop-in for CADisplayLink which falls back to NSTimer, but I decided to incorporate the background-NSTimer logic directly into RCTTimer, since NSTimer is already in use.
It's worth noting that the background NSTimer may not fire as often as requested — it may give the appearance of lagging depending upon your app's priority in the background. For our audio app, NSTimer fires exactly on schedule if there's an open AVAudioSession and audio is playing; if audio is not playing, it fires about half as often as requested, which is still adequate for networking polling and other tasks.
It's worth noting that background timers only function as long as an app is actually running in the background. Apple offers a variety of Background Modes (which can be toggled in the Capabilities section of the target inspector in Xcode), and the app will need to be legitimately using one of these modes in order for this change to provide any value — otherwise it will be terminated within a couple of seconds of moving to the background.
The good thing about this change is that for apps that do perform essential computation in support of their Background Mode, they can now use `setTimeout` and `setInterval` without problem — whereas in the past, neither would ever trigger their callback until the app returns to the foreground.
Pull Request resolved: https://github.com/facebook/react-native/pull/23674
Differential Revision: D14621326
Pulled By: shergin
fbshipit-source-id: c76e060ad2c662c140d7d2f4fb5aaa7094032515
Summary: This diff fixes a NoSuchElementException that was being thrown at ReactChoreographerDispatcher.doFrame(). The root cause was a lack of syncronization in removeFrameCallback().
Reviewed By: shergin
Differential Revision: D14619386
fbshipit-source-id: 80bc9e44866218d2a8703b3186f6958c145f260b
Summary:
[Android] [Fixed] - LayoutAnimations cause invalid view operations
The dating team has found a consistent repro where following an order of steps will get you the following exception:
https://lookaside.facebook.com/intern/pixelcloudnew/asset/?id=2113362972287761
The exception is due to the fact that the following operation
`delete child tag 17 from parent tag 481 which is located at index 2`
cannot be performed because parent tag 481 only has 2 children.. and they also happen to not have the tag 17 as a child. Somehow the operations and the tree they act upon are out of sync.
RN receives operations from React via the native module `UIManagerModule`. The operations use tags (an identifier for a view) and indices to determine what view is updated. These operations (grouped together as a batch) are then passed to the UI thread where we perform them on the platform views.
LayoutAnimations are implemented per batch in RN. When LayoutAnimations are on, qualified view updates are animated. Because the delete operation is animated, RN doesn't remove the view from the platform view hierarchy immediately but asynchronously -- after the animation is complete. This is problematic for other view operations that rely on an index on where to insert or delete a view because during the creation of those operations, it was assumed all prior operations were performed synchronously.
This is what was occurring in the repro and there were silent view errors occurring before the exception was thrown.
This diff proposes a solution to track all pending delete operations across operations.
We introduce a map that is keyed on view tags and has a value of a sparse array that represents child index -> count of views that are pending deletion.
`{11: [0=1], 481: [2=1]}` where this would be interpreted as for index 0 under view tag 11, there is one async view deletion that has not completed and under tag 481 there is one async view deletion at index 2.
We use the map to adjust indices on add / delete operations. We also update the count when the deletion animation is complete and remove the tag from the map when it is deleted.
Regarding worst case sizing of the map => O(# of platform views rendered)
Reviewed By: mdvacca
Differential Revision: D14529038
fbshipit-source-id: 86d8982845e25a2b23d6d89ce27852fd77dbb060
Summary:
Allow interpolation of strings with useNativeDriver. This allows animating much more of react-native-svg. This PR adds support for native animation of lengths with units, path data, colors etc. Plus, fixing the redundantly created nodes and (and thus, previously incorrect) connection of native animated nodes, improving performance.
Docs will need to change, specifying that string interpolation works with the native driver as well.
[GENERAL] [Added] Add support for native driven string interpolation in Animated
[GENERAL] Fix exception: Expected node to be marked as "native"
[GENERAL] Fix connection of AnimatedNodes and creation of redundant AnimatedNodes
Pull Request resolved: https://github.com/facebook/react-native/pull/18187
Differential Revision: D14597147
Pulled By: cpojer
fbshipit-source-id: 82a948a95419236be7931a8cc4ff72f41e477e9c
Summary: This is the first diff part of moving WebView internally to Facebook. It will be available under the same name `WebView` but won't be required from `react-native` any longer.
Reviewed By: TheSavior
Differential Revision: D14598043
fbshipit-source-id: f870d3f58e1d304071405344de09598dd22cdcc2
Summary:
Moved layout outputs transfer logic from YogaNodeJNIBase to YogaNodeJNI.
This change set is for adding experiment for layout outputs batching using a float array
Reviewed By: davidaurelio
Differential Revision: D14368107
fbshipit-source-id: 75ca330c1e7f07adc0ab8e7a5927d93977088918
Summary:
@public
I would like to get rid of implicit conversions between `YGValue` and `CompactValue`, because they don’t come for free.
That’s why I am adding `CompactValue` specific overrides for `YGResolveValue` and `YGValueEqual`, that do explicit casts. Up the commit stack, we will be able mark both `CompactValue(const YGValue&)` and `CompactValue::operator YGValue()` as `explicit`.
Reviewed By: SidharthGuglani
Differential Revision: D14598447
fbshipit-source-id: 75dc15cefb2dddcf8def891c5fb37893cacd9d46
Summary:
This adds TypeScript support to the community ESLint config. Our babel preset supports TypeScript by default, so it's nice to have TypeScript support pre-configured in the ESLint config too.
Note: Users need to install `typescript` in their project for linting to work for TypeScript files.
[General] [Added] - Add TypeScript support to the ESLint config
Pull Request resolved: https://github.com/facebook/react-native/pull/24100
Differential Revision: D14597127
Pulled By: cpojer
fbshipit-source-id: dfbf1b97061ed6e8c46aa49adb21630f5acdb5d1
Summary:
setNativeProps ends up calling UIManager.updateView which fails to find the view tag in the Paper UIManager and crashes.
This diff simply checks if the tag is managed by fabric, and calls `fabricUIManager.synchronouslyUpdateViewOnUIThread` if it is.
Not the ideal fix, but it generally works (js-driven animations work as well as in Paper) and it's better than crashing or not working at all.
Reviewed By: JoshuaGross
Differential Revision: D14414523
fbshipit-source-id: 0acd404f55094f8ce8eda39cb87ab58c727fb068
Summary: Removes useArrayNativeAccessor and everything needed to support it, similar to D14486283
Reviewed By: mdvacca
Differential Revision: D14487244
fbshipit-source-id: 7cfa91f7cf322c648c82be5951f3622cd6468961
Summary:
This was quite a rabit hole of remove deps -> delete dead code -> repeat.
Waaay simpler now with less duplicate lookups, redundant type verification, and extra function calls.
Reviewed By: mdvacca
Differential Revision: D14486283
fbshipit-source-id: 035db30181755d046a1ae99760468b954b2449df
Summary:
Changes our property access pattern to iterate through props once and pass the Object value directly rather than looking the value up in the map with the key.
Note some ViewManagers methods (especially yoga related ones on shadow nodes) expect a `Dyanamic`, so this diff also creates Dynamic's only when needed by the hand-written code, and introduces a new `DynamicWithObject` to create them that simply wraps the underlying object (as opposed to `DynamicWithMap` which wraps the map and does a lookup any time the `Dynamic` is accessed.
Reviewed By: mdvacca
Differential Revision: D14453300
fbshipit-source-id: df98567b6eff1e6b7c611f179eb11e413fb94e5d
Summary:
We will use it inside `core` module, so we have to decouple it from `view`.
As part of this, I added some comments, changed `const Float &` to just `Float` and put the implementation into `.cpp` file.
Reviewed By: mdvacca
Differential Revision: D14593952
fbshipit-source-id: 80f7746f4fc5b95febc8df9f5a9c0386a6425c88
Summary: This diff fixes an IllegalStateException that is thrown when the user click is on a edit text and tap 'Next' on the keyboard to focus on the next view, but the next view is hidden.
Reviewed By: lunaleaps, mmmulani
Differential Revision: D14598410
fbshipit-source-id: 2999cc468ed24bedff163eedcfaec50f6ee005d6
Summary: This is based on the work done in D8686586. Removed the logger instance from JSIExecutor constructor and installed it into the runtimeInstaller at all call sites.
Reviewed By: mhorowitz
Differential Revision: D14444120
fbshipit-source-id: 0476fda4230c467573ea04102a12101bcdf36c53
Summary:
`launchPackager.bat` starts metro server but does not pass projectRoot to it. So metro server starts in the wrong directory, It is because `startServerInNewWindow` pass `react-native` directory instead of `projectRoot` in the third argument of `spawn()` in `runAndroid.js`
Its working for people
See https://github.com/facebook/react-native/issues/23908#issuecomment-475889443
[Android] [Fixed] - projectRoot in launchPackager.bat
Pull Request resolved: https://github.com/facebook/react-native/pull/24115
Differential Revision: D14597101
Pulled By: cpojer
fbshipit-source-id: fb4155b72e35062cfb41fe1b3ecca0e2b4e849ce
Summary: This diff replaces usage of abort() with LOG(FATAL) when a prop-value is not found during parsing of prop values
Reviewed By: fkgozali
Differential Revision: D14591210
fbshipit-source-id: 4a8484ea6bdfec5534122ded43cc24ef80c13c1d
Summary: This diff replaces usage of abort() with LOG(FATAL) when a prop-value is not found during parsing of prop values
Reviewed By: sahrens
Differential Revision: D14570713
fbshipit-source-id: 57b0f993ba264a4949baf4022d807c55cdfe03b1
Summary: This diff removes BatchedExecutionTime from the metrics that are measured in Fabric. This does not add much value and it is not easy to compare against current version of RN
Reviewed By: shergin
Differential Revision: D14541976
fbshipit-source-id: c488e0951815306a978dd7a4246ec8a16d663218
Summary:
With our current infra, we support automatic conversion of method arguments using `RCTConvert`.
```
RCT_EXPORT_METHOD(foo:(RCTSound*) sound)
{
//...
}
```
```
interface RCTConvert (RCTSound)
+ (RCTSound *) RCTSound: (NSDictionary *) dict;
end
implementation RCTConvert (RCTSound)
+ (RCTSound *) RCTSound: (NSDictionary *) dict
{
//...
}
end
```
```
export interface Spec extends TurboModule {
+foo: (dict: Object) => void,
}
```
With this setup, when we call the foo method on the TurboModule in JS, we'd first convert `dict` from a JS Object to an `NSDictionary`. Then, because the `foo` method has an argument of type`RCTSound*`, and because `RCTConvert` has a method called `RCTSound`, before we invoke the `foo` NativeModule native method, we first convert the `NSDictionary` to `RCTSound` using `[RCTConvert RCTSound:obj]`. Essentially, if an argument type of a TurboModule method is neither a primitive type nor a struct (i.e: is an identifier), and it corresponds to a selector on `RCTConvert`, we call `[RCTConvert argumentType:obj]` to convert `obj` to the type `argumentType` before passing in `obj` as an argument to the NativeModule method call.
**Note:** I originally planned on using `NSMethodSignature` to get the argument types. Unfortunately, while the Objective C Runtime lets us know that the type is an identifier, it doesn't inform us which identifier it is. In other words, at runtime, we can't determine whether identifier represents `RCTSound *` or some other Objective C class. I figure this also the reason why the old code relies on the `RCT_EXPORT_METHOD` macros to implement this very same feature: https://git.io/fjJsC. It uses `NSMethodSignature` to switch on the argument type, and then uses the `RCTMethodInfo` struct to parse the argument type name, from which it constructs the RCTConvert selector.
One caveat of the current solution is that it won't work work unless we decorate our TurboModule methods with `RCT_EXPORT_METHOD`.
Reviewed By: fkgozali
Differential Revision: D14582661
fbshipit-source-id: 3c7dfb2059f031dba7495f12cbdf406b14f0b5b4
Summary:
<!--
Required: Write your motivation here.
If this PR fixes an issue, type "Fixes #issueNumber" to automatically close the issue when the PR is merged.
-->
Fixes#13754
Pull Request resolved: https://github.com/facebook/react-native/pull/18889
Differential Revision: D14486115
Pulled By: PeteTheHeat
fbshipit-source-id: 7b8b4fa9d2c99fc5d6145fed4681afdc4bb14fb8
Summary:
The `RCTBridge` contains numerous definitions of notification names, which we can observe in order to get insights into the React Native performance.
The Android implementation is a little different, such that you can listen for any of the [following](https://github.com/facebook/react-native/blob/master/ReactAndroid/src/main/java/com/facebook/react/bridge/ReactMarkerConstants.java) marker constants, simply by including the following code:
```java
ReactMarker.addListener(new ReactMarker.MarkerListener() {
Override
public void logMarker(ReactMarkerConstants name, Nullable String tag, int instanceKey) {
Log.d("ReactNativeEvent", "name: "+ name.name() + " tag: " + tag);
}
});
```
This will allow you to perform the necessary processing, calculations as required.
---
This PR enables observing for the module setup event (`RCTDidSetupModuleNotification`) by including the respective module's name & setup time in milliseconds.
[iOS] [Added] - Gain insights on the module setup times by observing `RCTDidSetupModuleNotification`. The `userInfo` dictionary will contain the module name and setup time in milliseconds. These values can be extracted via `RCTDidSetupModuleNotificationModuleNameKey ` and `RCTDidSetupModuleNotificationSetupTimeKey`.
Pull Request resolved: https://github.com/facebook/react-native/pull/23859
Differential Revision: D14579066
Pulled By: PeteTheHeat
fbshipit-source-id: 52645127c3fc6aa5bd73e3bd471fccd79cb05c14
Summary:
@public
After changing native methods to return `long` rather than `YogaValue`, we switch them to JNI fast calls, as there is no more interaction with the Java GC.
Reviewed By: pasqualeanatriello
Differential Revision: D14576815
fbshipit-source-id: b5a33caef7343ba1de3d9634a50dc82ab3148cc7
Summary:
@public
Passing primitive data via JNI is more efficient than passing objects.
Here, we avoid creating `YogaValue` (Java) instances via JNI, and rather pass a `long` back to Java. The instance is then created by extracting the necessary bytes on the Java side.
Reviewed By: foghina
Differential Revision: D14576755
fbshipit-source-id: 22d09ad50c3ac6c49b0a797a0dad639ea4829df9
Summary:
@public
Moving all native methods in a single class provides the benefit of not having to load native bindings eagerly when just creating config objects in the startup paths, or setting Java-only values on them.
Loading native bindings triggers additional class loads (`YogaConfig` / `YogaNode`), and can lead to problems in multi-dex scenarions.
Reviewed By: pasqualeanatriello
Differential Revision: D14560658
fbshipit-source-id: 14e31e3c3b560675b5a752a38ae75ab80a565ea1
Summary:
Bug comes from #23545, if `allowedLength < 0`, it would crash if `text.length > 1`.
cc. cpojer
[iOS] [Fixed] - Fixed crash when textinput's default value exceeds maxLength
Pull Request resolved: https://github.com/facebook/react-native/pull/24084
Differential Revision: D14562719
Pulled By: cpojer
fbshipit-source-id: 87ed930e35b8fa889d8b04829795fa46b7787b07
Summary:
CocoaPods makes it easier to add new iOS dependencies to a project without having to manually edit Xcode projects. Editing Xcode projects is time consuming and merging changes to them difficult. Automating the changes to Xcode project `react-native link` is error prone. CocoaPods is a de-facto standard way to manage iOS dependencies and a central part of unimodules and upcoming improvements to `react-native link`.
This PR adds a `Podfile` to the default project template of React Native. To use a project with CocoaPods, after creating it, run `cd ios; pod install` and use the created `<projectname>.xcworkspace` file instead of the `.xcodeproj` file. (We could make this a part of `react-native init` so you only need to run one command when creating a project.)
[iOS] [Added] - Add CocoaPods Podfile to the project template
Pull Request resolved: https://github.com/facebook/react-native/pull/23563
Differential Revision: D14576505
Pulled By: cpojer
fbshipit-source-id: f6c9e93d61a52ad445d2931ccc4933d559a6ec1a
Summary:
Before invoking TurboModule ObjC methods, we loop through all the arguments and transform them from `jsi::Value` to ObjC data structures. `jsi::Value`s that represent JS Objects get converted to `NSDictionary`s in ObjC. This isn't good enough because `NSDictionary` isn't typed. What we really need is a C/C++ struct that represents the type of the JS Object.
Therefore, for every argument of a TurboModule method that is a JS Object, this diff allows you to specify a method on `RCTCxxConvert` (which you have to declare and implement) that transforms that type of JS Object into something else. Basically, with the changes in this diff, we'll be able to transform JS Objects into C++ struct instances, which gives us type safety for JS Object method argumetns to TurboModule functions.
I modified the codegen to also create a mapping from NativeModule method name => argument num => `RCTCxxModule` conversion selector. This way, the FB codegen that generates the `RCTCxxConversion` function also informs our TurboModule system which conversion function to use before we call the method requiring complex argument. I just had to extend the `ObjCTurboModule` class to accomplish this.
The old system relies on the additional method generated by `RCT_EXPORT_METHOD` macro. It takes the written code, does string processing on it to parse the type of the struct arguments, and then replaces all instances of `::` with `_`. Super hacky. I didn't take this approach because it seemed unnecessarily hacky brittle.
The other approach I considered was to try to use reflection to infer the type of the struct at runtime. We'd have to do a bit of string processing and concat the TurboModule class name with the struct type. The solution would be simpler because it'd only modify the objective C and it wouldn't touch the Codegen system. **Edit:** I implemented it here: D14513078. The one downside of this design is that the name of the conversion function is individually constructed in two different locations in the code (i.e: no source of truth for this name). The other downside is that we have to rely on `RCTBridgeModuleNameForClass`, which we want to eliminate. This also computationally more expensive since it requires string processing/regex parsing and additional reflection. Therefore, we decided to move on with the current solution.
Reviewed By: fkgozali
Differential Revision: D14513429
fbshipit-source-id: 3d1b87e02ee908a19305686ff82b2ed624d8ac67
Summary: [iOS] [Fixed] - The existing logic defaults `undefined` & `null` in JS to be `[NSNull null]` when converting JS object to `NSDictionary`. Let's not insert the prop to the dictionary if it's `undefined`.
Reviewed By: blairvanderhoof
Differential Revision: D14571128
fbshipit-source-id: e03c713b055672b0a001d3305d694912ee36ab36
Summary:
JSBigString was inadvertently changed to a shared mapping. This means
that any changes to the string will be written back to the file. Ensure
we have a private (COW) mapping.
Reviewed By: kodafb
Differential Revision: D14532757
fbshipit-source-id: 6afb9635493496c90904f1432847c2f0da882c58
Summary:
It crashes with IllegalStateException in case you pass a wrong URL.
It crashes if it meets unexpected symbols in the header name and value,
while standard says it is not recommended to use those symbols not that
they are prohibited.
The headers handing is a special use case as a client might have an auth token in the header. In this case, we want to get 401 error response
from the server to find out that token is wrong. In case of the onerror
client will continue to retry with an existing token.
[ANDROID][Fixed] - Networking: Passing invalid URL not crashes the app instead onerror callback of HttpClient is called. Invalid symbols are stripped from the headers to allow HTTP query to fail with 401 error code in case of the broken token.
Pull Request resolved: https://github.com/facebook/react-native/pull/21231
Reviewed By: axe-fb
Differential Revision: D10222129
Pulled By: hramos
fbshipit-source-id: b23340692d0fb059a90e338fa85ad4d9612275f2
Summary:
Fixes#23342.
Since Metro [v0.47](https://github.com/facebook/metro/releases/tag/v0.47.0), some babel plugins such as [babel-plugin-module-resolver](https://github.com/tleunen/babel-plugin-module-resolver) or [babel-plugin-import-graphql](https://github.com/detrohutt/babel-plugin-import-graphql) fail to resolve files if the packager is started through Xcode. They receive wrong filenames from Babel such as `${projectRoot}/node_modules/react-native/src/index.js` instead of `${projectRoot}/src/index.js`.
It happens because the start command of the local-cli is not executed in the projectRoot directory. In this case, the cwd will be `${projectRoot}/node_modules/react-native`.
This issue doesn't occur if you start the packager yourself using `node node_modules/react-native/local-cli/cli.js start` from your project root.
It comes from this [line](https://github.com/facebook/react-native/blob/b640b6faf77f7af955e64bd03ae630ce2fb09627/scripts/packager.sh#L11). This script changed the working directory to `${projectRoot}/node_modules/react-native` and started Metro from there.
Starting Metro from the project root fixes this issue.
[iOS] [Fixed] - Start Metro packager from project root
Pull Request resolved: https://github.com/facebook/react-native/pull/24070
Differential Revision: D14563996
Pulled By: cpojer
fbshipit-source-id: cdeff34610f1ebb5fb7bc82a96f4ac9eec750d16
Summary: This diff changes `js1 upgrade jest` to add a caret when upgrading so that the open source version of RN is not locked to a concrete version of Jest which doesn't really make much sense. I also added `pretty-format` to the packages that get updated because it is part of Jest's repo.
Reviewed By: rubennorte
Differential Revision: D14503180
fbshipit-source-id: 683c9a6ac768baa578771b9ad677e02df4912baa
Summary:
With recent activity to extract out non-core things into separate repos, I did an audit of the package.json to see what can be removed, and what packages remain that have newer versions that result in less/smaller javascript code. The goal is to:
1. make developer experience better by removing unneeded dependencies, and
2. eliminate things the app bundler needs to process to make the production app bundle smaller.
[internal] [chore] - Remove unneeded packages, bump package versions who now have smaller size
Pull Request resolved: https://github.com/facebook/react-native/pull/23968
Differential Revision: D14519070
Pulled By: cpojer
fbshipit-source-id: 579f035f925668a34d07293810e3d35a7d0ae076
Summary:
Existing glob might not work very well with `spec.js` and `test.js` files unless they're placed in `__tests__` directory. This PR aims to bring back the support of `jest` globals in these files, even if they're outside of `__tests__` directory.
[General] [Fixed] - Fixed globs for `spec.js` and `test.js` files.
Pull Request resolved: https://github.com/facebook/react-native/pull/24088
Differential Revision: D14562085
Pulled By: cpojer
fbshipit-source-id: 543d67e3f8a154256f454b34ccc68bb070197a75
Summary:
The goal of this PR is to enable eslint checks in the projects generated by `react-native init` command. I added `template/_eslintrc` file, that would be replaced in an initialized project with `.eslintrc` file. This PR comes in parallel with https://github.com/react-native-community/react-native-cli/pull/229
[General] [Added] - Added `.eslintrc` file to generated template.
Pull Request resolved: https://github.com/facebook/react-native/pull/23901
Differential Revision: D14561084
Pulled By: cpojer
fbshipit-source-id: 6eb717bf03c45d83ae8a393e6a0abb79e1e2f915
Summary:
@public
Yoga's Java license headers were not in the correct format.
Reviewed By: muraziz
Differential Revision: D14541087
fbshipit-source-id: 5b3cff398875bd59dadeaddbb43020700ef027e2
Summary:
Fix for this issue I rasied: https://github.com/facebook/react-native/issues/24024
When I toggle `Show Perf Monitor` and reload JS `CMD+R` the Perf Monitor will be hidden, but settings in dev menu will persist. So to fix this state and need to `Hide Perf Monitor` and `Show Perf Monitor` again to see it.
[iOS] [Fixed] - Show Perf Monitor, after reloading JS
Pull Request resolved: https://github.com/facebook/react-native/pull/24073
Differential Revision: D14560025
Pulled By: cpojer
fbshipit-source-id: cd5602bd6ee041b8b3e61d163d10bd8bc47237b9
Summary: Conceptually, this assert is correct, however, sometimes a new node got allocated by same address as old parent node (which does not exist already) which makes the assert fires.
Reviewed By: mdvacca
Differential Revision: D14533070
fbshipit-source-id: 3fcc71c25e7d724180dc85aaf2457227d22ddba0
Summary:
Google recommends to use Gravity.START and Gravity.END instead of Gravity.LEFT and Gravity.RIGHT to support RTL better.
[Android] [Changed] - Improve RTL support
Pull Request resolved: https://github.com/facebook/react-native/pull/24069
Differential Revision: D14541569
Pulled By: cpojer
fbshipit-source-id: 5c104d8bd666e1270d5410216c7f2efa6152692a
Summary:
For the use-case where iOSdebug builds prefer to use static bundles over bundles served dynamically by metro. There's currently a bug caused by the packager client repeatedly attempting to connect to metro. This leads to endless log statements in xcode as well as other side effects:
https://github.com/facebook/react-native/issues/21030. Fix is based off of https://github.com/facebook/react-native/issues/21030 which fixes the behavior for the inspector.
Stops endless logging by packager client for debug builds that use static bundles.
[CATEGORY] [TYPE] - Message
Pull Request resolved: https://github.com/facebook/react-native/pull/24050
Differential Revision: D14541574
Pulled By: cpojer
fbshipit-source-id: 09c2c82eb2d4aeb0e7ba322fd81b0dd7bf9e683c
Summary:
Custom containers are only enabled in release mode.
Using custom stuff complicates debugging process because it breaks embedded into IDE introspections mechanisms.
Reviewed By: mdvacca
Differential Revision: D14508299
fbshipit-source-id: d2dbe87764b17d75ccd544c0a4baf03dd9e0cd0b
Summary:
Added a child class of YogaNodeJNIBase which will be used to separate layout outputs transfer logic.
This change set is for adding experiment for layout outputs batching using a float array
Reviewed By: davidaurelio
Differential Revision: D14368098
fbshipit-source-id: e0f10fb61cd09ee47cf9ce41fb400f4cfb3dd795
Summary:
It allows HTTP connections in debug builds, and requires no configuration compared to previous/current solution where you need to edit config file to test on device.
Consulted with Salakar about this.
[Android] [Changed] - Allow HTTP in debug builds
Pull Request resolved: https://github.com/facebook/react-native/pull/24066
Differential Revision: D14540255
Pulled By: cpojer
fbshipit-source-id: f1239154c27c36c21c9b080a826f8b1d0eb0fc7d
Summary:
@public
Contexts of nodes only hold a bit mask after we got rid of weak JNI refs.
We can simply store that data in a pointer-sized unsigned int.
Here, we replace all context heap allocations with usage of the node context (`void *`) as bitmask. We also add a couple of utility operators in order to keep the code comprehensible.
Reviewed By: fabiomassimo
Differential Revision: D14425742
fbshipit-source-id: f32c2184a1f09268c39dbb8cd09ac96517339674
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:
Renamed class from YogaNodeJNI to YogaNodeJNIBase.
This change set is for adding experiment for layout outputs batching using a float array where we will have two separate classes which will override how layout outputs are transferred to java YogaNode object.
We needed two separate classes because having everything in one class was causing memory issues as both the individual fields for width, height etc. and float array for batching needs to be present in code.
Reviewed By: davidaurelio
Differential Revision: D14368069
fbshipit-source-id: 0e98e28c8c7a9788345ccb92b2cd0f2cd4a53525
Summary:
This module was merged with `Alert`. Landing the removal now will mean that it is gone from 0.61 which means the deprecation warning will have been there for two full versions.
It will also make it easier to ship D14538298.
Reviewed By: rubennorte
Differential Revision: D14539026
fbshipit-source-id: fb36482324866c277811756cc7461451a1482b23
Summary:
Change the function called when an error is returned from the completionHandler of the `RCTJavaScriptLoader(loadBundleAtURL:onProgress:onComplete:)`.
* AS-IS
- `RCTLogError()`
- This error method does not post any notification for users. So users cannot receive notification when `RCTJavaScriptLoader(loadBundleAtURL:onProgress:onComplete:)` complete with error.(i.e. bundleURL is is invalid but not nil, `http://1`, `http://localho:8081/index.bundle`)
* TO-BE
- `handleError(error:)`
- Call this method will post notification for users when `completionHandler` fails with error.
[iOS] [Fixed] - Change the function called when an error is returned from the completionHandler of the `RCTJavaScriptLoader(loadBundleAtURL:onProgress:onComplete:)`.
Pull Request resolved: https://github.com/facebook/react-native/pull/23837
Differential Revision: D14538790
Pulled By: cpojer
fbshipit-source-id: da3306904c0d8113d204edfaa0f9e2a23793981a
Summary:
This PR fixes the case where the content a VirtualizedList loads with a contentLength of 0, causing a crash in the `renderDebugOverlay` function. The result of that crash is a red screen when turning on debug on FlatList and other VirtualizedList components as described in #24053.
[LIST] [FIX] - Fix VirtualizedList debug mode crash
Pull Request resolved: https://github.com/facebook/react-native/pull/24058
Differential Revision: D14538317
Pulled By: cpojer
fbshipit-source-id: 7b17bf51c388561c517bab1f775a31200abdc5a9
Summary:
Put `prepareForRecycle` to last before enqueue to recycle pool, ensure only call it when count lower than RCTComponentViewRegistryRecyclePoolMaxSize.
cc. shergin .
[General] [Changed] - Reorder prepareForRecycle before adding recycle pool
Pull Request resolved: https://github.com/facebook/react-native/pull/24025
Differential Revision: D14536843
Pulled By: shergin
fbshipit-source-id: 82a816e2c0afb5a6bb72637d7d55d6a4fda708af
Summary:
I was annoyed by warnings from yarn/npm about eslint peer dependencies not being met, so I dived in to try and get rid of some of them. Sometimes it meant bumping a plugin, but then that plugin needed a newer babel-eslint, so it was a dance.
Some we can't easily update to latest (eslint-plugin-prettier) because the rule format has changed a bit. Happy to do that in this PR if folks think its a good idea. eslint-config-fbjs itself needs to be updated and republished to eliminate the last few warnings.
There are a few new warnings (the repo wasn't linting cleanly for me from the start). I can fix those in this PR, or a separate one, based on people's preferences.
[internal] [chore] - Eliminate some peer dependency warnings and bump some eslint packages to latest.
Pull Request resolved: https://github.com/facebook/react-native/pull/23969
Differential Revision: D14519076
Pulled By: cpojer
fbshipit-source-id: aa44cfd05814d7b79069414aa78d089e448c2235
Summary:
The copyright headers in the Wrapper example referenced a license file that doesn't exist anymore. This PR updates the copyright header to match other example files in the repo
Fixes https://github.com/facebook/react-native/issues/23215
[General] [Changed] Updated the license of RCTWrapperExample to match the rest of the Examples
Pull Request resolved: https://github.com/facebook/react-native/pull/24037
Differential Revision: D14521327
Pulled By: cpojer
fbshipit-source-id: 983741d4d93178cd90b532ad5f8ff0717670aff4
Summary:
Fixes#22873. Given that this code is meant to only work on macOS, we should be fine not using a portable hash. In the packages for which this matters at the bottom of this file, it produces the same hashes so it should be fine.
[General] [Fixed] - Don't use `-p` when invoking shasum.
Pull Request resolved: https://github.com/facebook/react-native/pull/24036
Differential Revision: D14521134
Pulled By: cpojer
fbshipit-source-id: 882e762b7817d9d46bdd405c9e2e9e8b4d7cfaf4
Summary:
It was not possible to run RNTester in Android P and connect to the packager.
[Android][RNTester] add react_native_config to RNTester for the packager to be able to connect with Android P devices
Pull Request resolved: https://github.com/facebook/react-native/pull/24033
Differential Revision: D14520803
Pulled By: cpojer
fbshipit-source-id: 567a0461d14d880cd78e9fa551ba25fe60af798d
Summary: Currently we can't access navigationOptions from measureAppRequire and that breaks fetchRelayQuery logs.
Reviewed By: fkgozali
Differential Revision: D14505525
fbshipit-source-id: 97ae4461ebb0e703633f782323b13b4e4f7c5cb7
Summary:
```
let index = params.itemIndex + 1;
```
to
```
let index = Platform.OS === 'ios' ? params.itemIndex : params.itemIndex - 1;
```
to fix an issue on iOS. Note however, how the sign for non iOS changed from `+` to `-` causing a crash on Android when trying to scroll to index 0 as that will be evaluated to -1 instead of 1 and thus be out of bounds.
[Android] [Fixed] - Fixed regression in SectionList caused by #21577 not being able to scroll to top on android
Pull Request resolved: https://github.com/facebook/react-native/pull/24034
Differential Revision: D14520796
Pulled By: cpojer
fbshipit-source-id: bb49619f49752fd3f343ef3b7bf1b86ac48af7f8
Summary: Adds support for the native type Point to the rn codegen
Reviewed By: TheSavior
Differential Revision: D14462164
fbshipit-source-id: 942b5697d616c6aa6289d01bb56382fd7adac203
Summary: Same algorithm using a new API.
Reviewed By: JoshuaGross
Differential Revision: D14423509
fbshipit-source-id: c40f61fdd001f68785512c304941f523585d641c
Summary: The basic idea of the implementation is the same, but it uses the new method for finding parenting chain and it does not use `shared_from_this()` anymore.
Reviewed By: JoshuaGross
Differential Revision: D14416949
fbshipit-source-id: 13ef928505a60280e2a6c30c76ac87d91cee326e
Summary:
The algorithm is quite simply:
1. Get family objects of the two nodes (inner and outer).
2. Traverse the list of family objects starting from the inner one and form a reversed list of them.
3. tarting from the inner node, traverse the tree layer-by-layer choosing a next element of the path by comparing the family object of each node on the level and an object from the list.
Reviewed By: JoshuaGross
Differential Revision: D14416950
fbshipit-source-id: 23c659a9e01690f90174193650a2b0ef09eadb4d
Summary:
One of the core feature of ShadowNodeFamily is having a pointer to a parent family. This diff implements it.
I don't think there is a hard retain cycle there, but for more lean memory usage we use weak_ptr here.
Reviewed By: JoshuaGross
Differential Revision: D14416948
fbshipit-source-id: 05fd2c4833146f007228363b1d958776b4a2a9cf
Summary:
ShadowNodeFamily is a new concept that allows us to implement an efficient way to solve the problem of finding a path to some ancestor node (practically reimplement ShadowNode::constructAncestorPath() in some efficient way).
This diff is the first one in the series. It introduces a new class and moves some data into it.
Reviewed By: JoshuaGross
Differential Revision: D14416947
fbshipit-source-id: c93865a8929a2128498e34d3589487696aac6283
Summary: This is a leftover from the ealy days of Fabric. The mehtod does not have implementation counterpart and any usage.
Reviewed By: JoshuaGross
Differential Revision: D14402636
fbshipit-source-id: aa2e919084ae7382d3a62af761e1f6eac334fc75
Summary: The removed code does nothing because we are replacing the oldChild with newChild several lines above.
Reviewed By: JoshuaGross
Differential Revision: D14402637
fbshipit-source-id: 731a950f373e20f7d5bae3cbf6470335d3694ccc
Summary: In React, things like changing `tag`, `eventTarget` or reparenting are impossible by design. Which seems like a strange limitation actually allows us to do tremendous performance optimizations (stay tuned!).
Reviewed By: JoshuaGross
Differential Revision: D14402638
fbshipit-source-id: 3b7b7edaff0d55a3ca94e2ac4c753d630d07101d
Summary:
We need to remove adding png file extension when path has not extension. Two reasons:
1. `imageWithContentsOfFile` or other `UIKit` methods can load png image correctly, even if path has not `png` file extension.
2. Sometimes, people may have file that actually not have file extension, it's the designated behavior for user. Like #23844 .
CC. sahrens cpojer .
[iOS] [Fixed] - Remove explicitly add png file extension when load local image
Pull Request resolved: https://github.com/facebook/react-native/pull/23864
Reviewed By: shergin
Differential Revision: D14425373
Pulled By: hramos
fbshipit-source-id: 3cc06c9a3d68cadf652c1de742f3cce26258c874
Summary:
With recent changes, simple cloning a component does not mean that underlying Yoga node will be dirtied. Autodirtying is only performed if the child nodes were dirtied and/or if the YGStyles were changed.
That's not the case for Text component which does not have direct layotable children, so we have to call `dirtyLayout` explicitly.
Reviewed By: JoshuaGross
Differential Revision: D14508277
fbshipit-source-id: 2c52d7d40da963a976c7d28a13781cc1755ef591
Summary: In methods which implement move semantic we have to check the source object because it's (also) being mutated.
Reviewed By: JoshuaGross
Differential Revision: D14496937
fbshipit-source-id: f3f2299d14e41c8b269f1647336dbd5b45c235f4
Summary: More `assert`s and `ensureUnsealed` calls were added to YogaLayoutableShadowNode for simpler debugging and early failing.
Reviewed By: JoshuaGross
Differential Revision: D14496936
fbshipit-source-id: 898c6a0665aeac5d0b1995bd53046f58cec37007
Summary:
If the `HasNewLayout` flag is `false`, we should not copy the data from YGStyle/YGLayout to ShadowNode because the node can be already sealed and because it's unnecessary. Previously we workaround this case with a special check in `setLayoutMetrics` method, but that can be unreliable because of some side-effects related to pixel rounding and comparing floats.
The new approach is much more robust and explicit.
Reviewed By: JoshuaGross
Differential Revision: D14496939
fbshipit-source-id: deddb14d2206c5bd3f22154d0ea682e3c5888901
Summary: These default implementations are never being used. Removing them allowing to ensure that flags inside YGNode have same values as flags in YogaLayoutableShadowNode. That also saves a couple of bytes in size of ShadowNode.
Reviewed By: JoshuaGross
Differential Revision: D14496938
fbshipit-source-id: c43f9c8a2eec054f728ff54a6573668eccda55fb
Summary:
As a comment above changed lines states, RootShadowNode is a special one because it layouts itself. In normal case some parent node layouts its children, and it also checks getHasNewLayout flag. So, in the case of RootShadowNode it has to check its own flag by itself.
That fix should save some resources and generally correct.
After the change, changing a state of some node does not cause relayout process. If dirtying is required, the component should call `dirtyLayout()` explicitly in the constructor or in `adopt` method.
Reviewed By: JoshuaGross
Differential Revision: D14472751
fbshipit-source-id: 75bf62ac28991a39e5664aa71c08bd0e64fa275b
Summary: That diff fixes an obvious bug that prevents internal data of LayoutableShadowNode being cloned during cloning of YogaLayoutableShadowNode.
Reviewed By: JoshuaGross
Differential Revision: D14472753
fbshipit-source-id: d07be3bf36708690dfe10de7898e2b48648aa0f4
Summary: In addition to the previous change, now we handle a situation where some node receives a new set of children and all those children have the same styles. (See the previous diff for more details.)
Reviewed By: JoshuaGross
Differential Revision: D14472754
fbshipit-source-id: 16411036e14f18e730e064e33948440b05ff51c8
Summary:
After the change, YogaLayoutableShadowNode will preserve dirty flag (being false) in cases where:
* a node was cloned with same children;
* changes in props don't affect layout.
Motivation:
In Fabric we always were aggressive about dirting yoga nodes: when we clone the node, we always dirty underlying Yoga node. I think that was the case because we don't deeply understand how the system works and we always had more severe problems to fix. Now, we faced an issue that forces us to think about that problem carefully (more about that later).
(I don't expect that will improve TTI performance, but that's possible if we do a lot of changes in the hierarchy during initial load process.)
I see two main use cases where we have to be smart about dirtied yoga nodes:
Case 1. Native local commits which do *not* modify yoga styles.E.g. in a case where ScrollView updates the internal state (which has offset info) really really frequently. (It will be implemented later.) That `contentOffset` info does not or might not affect layout, so we should not pay for this.
Case 2. Legit React commits which do *not* modify yoga styles. E.g. in a case where only the background color of some view changes, we don't need to relayout anything. Unfortunately, we do this in Fabric because of two major reasons:
* We don't make a difference between any changes in Props.
* React constructs new children of cloned node iteratively, calling `appendChild`. That makes implementing optimization really challenging because we don't know when the process ends. And when it ends we have very few pieces of information about how the state looked before.
This diff stack will handle the problems of the first kind. The main motivation is: we want to have state updates to be as lean as possible.
Reviewed By: JoshuaGross
Differential Revision: D14472752
fbshipit-source-id: 68374f60cb07de9ab65bf1f6d94c828985359fa5
Summary:
There is a small gap in the SynchronizedWeakHashSet implementation - the containsKey method of the WeakHashMap is modifying hence calling it during the iteration might cause ConcurrentModificationException. Added a command DO_IF_CONTAINS to safely handle this case.
[Android] [Bugfix] - Should fix a ConcurrentModificationException in onResume.
Pull Request resolved: https://github.com/facebook/react-native/pull/24015
Reviewed By: mdvacca
Differential Revision: D14507342
Pulled By: fkgozali
fbshipit-source-id: 2998bffb06e2cbacd8df1780964355842b1cc4a0
Summary:
Use AndroidX in ReactAndroid/build.gradle, and remove androidx dependency from template and RNTester app because it's already exposed/exported from ReactAndroid.
[Android] [Changed] - Land AndroidX in gradle
Pull Request resolved: https://github.com/facebook/react-native/pull/24014
Differential Revision: D14508774
Pulled By: mdvacca
fbshipit-source-id: c96b97876571a5a7f2b400dd29188cfdf1f84a4c
Summary:
Before I was looking at the animation nodeTag rather than the view reactTag to determine if it was Fabric, so sometimes we would do an early fabric flush on non-fabric views, or miss it on fabric ones.
This fixes it by associating animations with fabric based on the reactTag of the view that is associated with the animation nodeTag.
Reviewed By: shergin
Differential Revision: D14504446
fbshipit-source-id: 75a1394b34436556daf9c33dc63743df33c2fb19
Summary:
This gets completely rid of this flow ignore. The flow team is using the version
aware `$FlowFixMe` now and the only instance of this used was on www dating back
to 2016: D3235864
My intention here was to slightly simplify the flowconfigs.
Reviewed By: gabelevi
Differential Revision: D14494167
fbshipit-source-id: 0fab176ce326007ac45b47691378812c74a523e6
Summary:
Currently, the behavior of saving in the `CameraRoll` module varies depending on the platform.
On iOS, remote URIs are supported and will save a remote image to the local storage. However, on Android it can only be used for local images, making this function much less useful.
This change allows the Android version of the `CameraRoll` module to have the same behavior, at least for http and https scheme URIs, which will probably cover the vast majority of the use cases.
Reviewed By: sahrens
Differential Revision: D14483943
fbshipit-source-id: e63ca786240e6657c8c8e0292be9fb08efa40ef1
Summary:
This PR adds support to use Conscrypt as Security Provider if available runtime. Consscrypt supports TLS 1.2 on Android 4.x and TLS 1.3 on all Android versions. Fixes issues (ex https://github.com/facebook/react-native/issues/23151) with HTTPS connections on Android 4.x.
Just add below to your project build.gradle and it'll use it.
```gradle
implementation('org.conscrypt:conscrypt-android:2.0.0')
```
[Android] [Changed] - Add TLS 1.3 support to all Android versions using Conscrypt.
Pull Request resolved: https://github.com/facebook/react-native/pull/23984
Differential Revision: D14506000
Pulled By: cpojer
fbshipit-source-id: 58bf18f7203d20519fb4451bae83f01e2f020a44
Summary:
This fixes#23816, which states that `getSize()` does not function correctly on Android. The original PR for this is now outdated as there have been merges into master that would create merge conflicts.
[Android] [Fixed] - Added correct handling for `getSize()` to avoid warnings being thrown.import
Pull Request resolved: https://github.com/facebook/react-native/pull/23961
Differential Revision: D14505183
Pulled By: cpojer
fbshipit-source-id: 3d8976fd518de0903d7736a8cbd8371987eb1b2d
Summary:
Child props were being overridden by `<Touchable>` props even when the `<Touchable>` props were undefined.
[General] [Fixed] - Prevent prop override by TouchableWithoutFeedback when undefined
Pull Request resolved: https://github.com/facebook/react-native/pull/23966
Differential Revision: D14502918
Pulled By: cpojer
fbshipit-source-id: 614ee43bbb6f062a98bd9318693807320979a016
Summary:
I encountered invalid bridge error when I develop (reload high frequency) some times, and if it happened, I only can restart the app, because we would always show error invalid message if we trigger reload command. So I recommend Change invalid bridge log level from error to warn, I think it's enough.
cc. cpojer .
<img width="375" alt="892C97F4-E910-4E3B-935A-65C899916E6E" src="https://user-images.githubusercontent.com/5061845/54538344-0d32c600-49cf-11e9-818c-0e4cb5a0a518.png">
[iOS] [Fixed] - Change invalid bridge log level from error to warn
Pull Request resolved: https://github.com/facebook/react-native/pull/24005
Differential Revision: D14504820
Pulled By: cpojer
fbshipit-source-id: f24c4876fdb3e64183c09c5ddc598a8c87e405a7
Summary:
**Summary**
This PR introduces validation for the new `metro-config`. For now I'm keen on only validating new config, because I can see there's yet unused `convertConfig` which, I guess, defeats the purpose. Let me know otherwise.
This is still work in progress, as I need to fix some stuff upstream (e.g. recursive object validation and pretty-printing). Just letting you know I'm working on it :)
**Test plan**
Added a test.
cc CompuIves cpojer
Pull Request resolved: https://github.com/facebook/metro/pull/205
Differential Revision: D14501222
Pulled By: cpojer
fbshipit-source-id: 0ab8f3ad14d6f33690d5f57fd1e7487f3a4a8c71
Summary:
This will create a cross-platform and safe way to programmatically open the app's settings into the iOS /Android Settings app.
Right now it's possible to open the app's settings, but _**only for iOS**_ via `Linking.openURL("app-settings:")`
To do the same for Android, you need to either create NodeModule or install a dependency such as [react-native-open-settings](https://github.com/lunarmayor/react-native-open-settings).
Why this new method is useful: since Android 6, app permissions work similar to iOS. It's granular and it's requested in the app runtime.
https://developer.android.com/guide/topics/permissions/overview#runtime_requests_android_60_and_higher
> If the device is running Android 6.0 (API level 23) or higher, and the app's targetSdkVersion is 23 or higher, the user isn't notified of any app permissions at install time. Your app must ask the user to grant the dangerous permissions at runtime. When your app requests permission, the user sees a system dialog telling the user which permission group your app is trying to access. The dialog includes a Deny and Allow button.
Thus, if the user checks the **"Never ask again box"** and taps **"Deny"**, for some specific permission, the only way to change the permission is going to the Android Setting app.
And that's where this new method becomes useful. It'll allow our apps to programmatically send the the user to settings app.
Also, `openSettings()` doesn't receive a parameter to redirect to specific subsections of the Settings app because there's no public API to do it on iOS ([there's a way to have, via private API, but it causes the app to get rejected.](https://github.com/mauron85/cordova-plugin-background-geolocation/issues/394))
Create `Linking.openSettings()` for iOS and Android;
[General] [add ] - Add openSetting method to Linking module
Pull Request resolved: https://github.com/facebook/react-native/pull/23965
Differential Revision: D14502910
Pulled By: cpojer
fbshipit-source-id: d27d62282b9df499845c78d983d3b6936c36ea39
Summary:
This PRs makes an attempt at fixing the set up of the Android end to end tests, and the tests themselves. The end goal is to re-enable the tests on CircleCI (see #23561 for more details).
The goal of this PR is to the end to end tests to a working state. Better tests can be added at a later point.
I changed the tests using the menu button. These tests made something silently crash/hang, after which it was no longer possible to get an element or even get the source. A fix for this needs further investigation.
Also, I enabled the tests in the CircleCI config, however CircleCI is currently failing on them with the following error:
```
info Running /opt/android/platform-tools/adb -s emulator-5554 reverse tcp:8081 tcp:8081
error: closed
info Could not run adb reverse: Command failed: /opt/android/platform-tools/adb -s emulator-5554 reverse tcp:8081 tcp:8081
info Starting the app on emulator-5554 (/opt/android/platform-tools/adb -s emulator-5554 shell am start -n com.endtoendtest/com.endtoendtest.MainActivity)...
Starting: Intent { cmp=com.endtoendtest/.MainActivity }
Too long with no output (exceeded 10m0s)
```
Some help here would be appreciated. An alternative is to not enable the tests yet on CircleCI in this PR.
[Android] [fixed] - Fix and update end to end tests for Android
Pull Request resolved: https://github.com/facebook/react-native/pull/23958
Differential Revision: D14502884
Pulled By: hramos
fbshipit-source-id: 4316c3fd817451d332e64a10d88389b74a60d3dd
Summary:
This PR adds a number of unit tests for the Geolocation module, as a follow-up of #23903. I also added two missing documentation strings to that module, with references to the online documentation, for consistency with the other methods in the same module.
Not applicable, since it only adds tests.
Pull Request resolved: https://github.com/facebook/react-native/pull/23987
Differential Revision: D14502848
Pulled By: cpojer
fbshipit-source-id: 8f7c1cee6be3fae081d9770e5e942fadda65e6c2
Summary:
This PR add tests for several utilities in `Libraries/Utilities`, as a follow-up of #23903.
The following utilities are now tested:
* `clamp.js`
* `binareToBase64.js`
* `DeviceInfo.js`
* `mergeIntoFast.js`
* `PixelRatio.js`
* `infoLog.js`
* `logError.js`
* `warnOnce.js`
* `mapWithSeparator` (added a missing test)
Not applicable, since it only adds tests.
Pull Request resolved: https://github.com/facebook/react-native/pull/23989
Differential Revision: D14502806
Pulled By: cpojer
fbshipit-source-id: e2c3b3a35f4f765d5336b998ab92dba14eeac7bc
Summary:
I've realized after #23839 got merged, that `AccessibilityInfo` doesn't have a jest mock the same way as the other frameworks do.
This PR adds the testing mock for `AccessibilityInfo`.
Pull Request resolved: https://github.com/facebook/react-native/pull/23982
Differential Revision: D14502780
Pulled By: cpojer
fbshipit-source-id: ec11bd547b6f90858e7f51ed8230c8d02dc4904c
Summary:
Landing D14472633 again which failed because of a metro-buck issue.
Latest CLI requires `reactNativePath` to be explicitly set when `react-native` is not present under `node_modules` (which is the case when running from source).
Fixes#23936
This PR also updates CLI to latest version and removes private calls to `findPlugins` (it's now exposed under public interface).
We also remove custom `rn-cli.config.js` options that are no longer needed that we have `--reactNativePath`. I added them a month ago as a temporary workaround.
[GENERAL] [FIXED] - Internal - Update to the latest CLI
Pull Request resolved: https://github.com/facebook/react-native/pull/23940
Reviewed By: rickhanlonii
Differential Revision: D14501686
Pulled By: cpojer
fbshipit-source-id: c8dac71b3806d81c9d18b6d4a7e92d82962791f9
Summary:
This diff migrates RN to AndroidX.
As part of this diff I disabled few tests in RNAndroid OSS that will be re-enabled this week. As part of the refactor of BUCK files in OSS
Reviewed By: shergin
Differential Revision: D14200097
fbshipit-source-id: 932fcae251d1553e672acd67ecd0e703dcb364aa
Summary: 0.95 has a more accurate definition of JSON.stringify which could return void.
Reviewed By: dsainati1
Differential Revision: D14494286
fbshipit-source-id: 6cf9cb5889b4078548665bc66fe899a266c689ce
Summary:
fixes#23962, where trackColor is reset when value changed. This PR will set trackColor corresponding trackColor every-time value changes.
[Android] [Changed] - Fix Switch trackColor
Pull Request resolved: https://github.com/facebook/react-native/pull/23977
Differential Revision: D14495206
Pulled By: hramos
fbshipit-source-id: d712f540cd3f8359d6e85f79c12732689870a112
Summary:
Upgrade mobile `BUCK` and `.bzl` files to use C++14.
Let's see what happens.
Reviewed By: mzlee
Differential Revision: D14223329
fbshipit-source-id: ff642ca017103d9415c4d7f5beaf5ded07ef7ff1
Summary:
This is the couple of hacks I used after I finished #23802 in order to get fabric working on RNTester. This is inspired from prior work by kmagiera.
The goal of this PR is to show others what I’m struggling with, and to eventually merge it sans hacks.
- Yarn Install
- Uncomment the commented out pods in RNTester's pod file
- Open RNTesterPods workspace
- Run App
- this is only for pods, the non-pod RNTester will no longer work until updated with fabric too.
- `SurfaceHostingView` & `SurfaceHostingProxyRootView` both try to start the surface immediately, this leads to a race condition due to the javascript not having loaded yet, the hack here is:
1. Swizzle the `start` method on `RCTFabricSurface` to no-op when called.
2. Add observer for `RCTJavaScriptDidLoadNotification`
3. Call private method `_startAllSurfaces` on `_surfacePresenter` in AppDelegate when we receive `RCTJavaScriptDidLoadNotification`.
[General] [Added] - Use Fabric in RNTester
Pull Request resolved: https://github.com/facebook/react-native/pull/23803
Reviewed By: shergin, mdvacca
Differential Revision: D14450726
Pulled By: fkgozali
fbshipit-source-id: 8ae2d48634fecb60db539aaf0a2c89ba1f572c27
Summary: JS Deltas have been killing productivity of RN engineers lately. There's been several posts and questions asked that end in "Turn off JS Deltas". Disabling them until we can make them more stable.
Reviewed By: fkgozali
Differential Revision: D14491774
fbshipit-source-id: 29b1c8e5e72369882c2890e3b6347ecd2fe4bed1
Summary: Several things need to ironed out: 1) LocalState in Fabric C++, 2) setting dimensions of BottomSheet component to 0,0 for parent.
Reviewed By: shergin
Differential Revision: D14426167
fbshipit-source-id: 45a90a7971c87672872108a9e360926b4a6095f0
Summary:
Autofill Hints were added in [Android API 26](https://developer.android.com/reference/android/view/View.html#setAutofillHints(java.lang.String...)). Without this runtime check, pre-26 devices will crash.
[Android][Fixed] - Fixes crash on pre-26 Android devices when setting text content type
Reviewed By: lunaleaps
Differential Revision: D14479468
fbshipit-source-id: 238c1efd6aea682a93ecb45e1123aaed6bdcd9e3
Summary:
This package was a dependency for ListView, which is no longer part of RN. Removed the dependency from package.json and yarn.lock.
Also removed its pattern from the Jest preset -- ListView is not in this repo and also react-clone-referenced-element was written at a time when Node did not support the same modern JS features as RN. The latest Node 8+ supports the features that react-clone-referenced-element uses so we don't need to transform it.
[General] [Removed] - Removed unused react-clone-referenced-element dependency
Pull Request resolved: https://github.com/facebook/react-native/pull/23933
Differential Revision: D14477240
Pulled By: cpojer
fbshipit-source-id: 4f6975133b54cc75088262cedd11da20225cada8
Summary:
From https://github.com/facebook/react-native/pull/23861#issue-260337314
> changing "interval" example from "time-only" to "datetime" because there's a known bug that prevented the previous example from working
We need to ensure set minuteInterval after set datePickerMode, otherwise minuteInterval invalid in time mode.
cc. grabbou cpojer .
[iOS] [Fixed] - Fixed minuteInterval invalid in time mode
Pull Request resolved: https://github.com/facebook/react-native/pull/23923
Differential Revision: D14477549
Pulled By: cpojer
fbshipit-source-id: 2c612d488b6d592b1907e150df5e07fe83132829
Summary:
As a follow-up to this other PR #23839, it adds support for other, iOS only, flags into `AccessibilityInfo`.
It adds these other 4 methods:
* `isBoldTextEnabled()`
* `isGrayscaleEnabled()`
* `isInvertColorsEnabled()`
* `isReduceTransparencyEnabled()`
P.S: Android implementation for those methods just return `false` (with `Promise.resolve(false)`)
And the corresponding event listeners:
* `boldTextChanged`
* `grayscaleChanged`,
* `invertColorsChanged`,
* `reduceTransparencyChanged`
Pull Request resolved: https://github.com/facebook/react-native/pull/23913
Differential Revision: D14482214
Pulled By: cpojer
fbshipit-source-id: b97725fd12706957d4dad880a97e6b0993738272
Summary:
Latest CLI requires `reactNativePath` to be explicitly set when `react-native` is not present under `node_modules` (which is the case when running from source).
Fixes#23936
This PR also updates CLI to latest version and removes private calls to `findPlugins` (it's now exposed under public interface).
We also remove custom `rn-cli.config.js` options that are no longer needed that we have `--reactNativePath`. I added them a month ago as a temporary workaround.
[GENERAL] [FIXED] - Internal - Update to the latest CLI
Pull Request resolved: https://github.com/facebook/react-native/pull/23940
Differential Revision: D14472633
Pulled By: cpojer
fbshipit-source-id: b7ea92ee130da6730aa0093265958aa1b8c2ab97
Summary: Missed in D14434796. We'll think of adding a lint rule in open source for this separately.
Reviewed By: rubennorte
Differential Revision: D14477475
fbshipit-source-id: 9002d9a7feadcb42f84031f21ad23c481ac304e3
Summary:
This function returns a HOC that passes `scopedPerformanceLogger` as a prop to the wrapped component. That HOC
can be used whenever we can't declare `static contextType` as `PerformanceLoggerContext` on a component,
for example because React supports only one React Context per component.
Reviewed By: sahrens
Differential Revision: D14385560
fbshipit-source-id: 41971b4bf499f336c34b9220a3ee97c4ed89498d
Summary:
I was looking at the coverage report of the JavaScript code in the `Libraries` folder, and found some of the modules and functions to be (partially) untested. I believe that adding tests to them would formally capture their behaviour and avoid future regressions. In this PR, I've added some unit tests for 3 utility components.
Perhaps a more general question: Are these kinds of PRs appreciated? I'd be interested in submitting more of them in the future.
Not applicable, since it only adds tests.
Pull Request resolved: https://github.com/facebook/react-native/pull/23903
Differential Revision: D14477601
Pulled By: cpojer
fbshipit-source-id: c0700c5b514cd0df983fecfd91c93fc2bd049f5d
Summary:
Adds a deprecation warning for using status-bar package
Lean Core Issue: #23313
[General] [Deprecated] - Deprecated StatusBar as it has now been moved to react-native-community/statusbar
Pull Request resolved: https://github.com/facebook/react-native/pull/23898
Differential Revision: D14477606
Pulled By: cpojer
fbshipit-source-id: 2955374446f879c3e7cfea97cb8c379ec8b003cd
Summary:
I ran into a build error when `xcodebuild` would invoke a custom script (in my case `sentry-cli`):
```
error: Could not parse Info.plist file
caused by: invalid data
```
Upon further investigation it turned out the parse error was **caused by a comment**, and I found some other oddities with the default `Info.plist` template files:
- The problematic comment is a **dead link** (website does not exist)
- The main Info.plist contains a **duplicate entry** for `NSLocationWhenInUseUsageDescription`
- Some entries are _reordered_ and the comment is removed when modifying/saving the file in Xcode
This PR fixes these inconsistencies, unnecessary customizations, and potential sources of errors.
[iOS] [Fixed] - Fix Info.plist templates to prevent parse error
Pull Request resolved: https://github.com/facebook/react-native/pull/23924
Differential Revision: D14477557
Pulled By: cpojer
fbshipit-source-id: 6d734c5aa3b800f05394db189e8d8db63be8e353
Summary:
D14323747 broke SSTs. This PR optimized implementation of nativeID. Instead of searching entire tree to find a view, it uses a map to cache views which have nativeID set. The map uses keys with format <nativeID-rootViewTag>. Finding the rootViewTag causes a race condition, due to [this syncing code](https://fburl.com/93vqzlbg). The SST runner attempts to read the map to find a [SST view](https://fburl.com/8zadz024) before that view is added to the map.
My fix is to change the key format to simply <nativeID>. Product code should not duplicate nativeID since it is used to uniquely identify react managed views from native. I'll comment on PR with this fix.
Reviewed By: shergin, mmmulani
Differential Revision: D14416262
fbshipit-source-id: 3b707f2ff4049ac83ac8861e3cda435224d973d8
Summary:
Accidentally I noticed that the signature of Folly's hash_combine is different from boost's one.
The Folly's one is:
`size_t hash_combine(const T& t, const Ts&... ts)`, so the first argument is immutable and the method returns the result normally.
It means that all hashes that we compute in Fabric using `hash_combine` were `0`.
So I fixed it.
I have no idea why this difference exists, but some modern papers suggest that folly's variant has good chances to be standardized.
E.g.: http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0814r0.pdf
Technically, it should improve performance, but I doubt that it can be more than 1-2 ms per screen TTI.
Reviewed By: JoshuaGross
Differential Revision: D14430380
fbshipit-source-id: 97da999ee5780b940bb789bc3eb5bf9f89c194ca
Summary:
Part of: #23313.
This moves the `RCTTest` lib from `Libraries/RCTTest` to `RNTester/RCTTest`. This also removes `takeSnapshot` from React Native, and implements it as a standalone module in RNTester called `ScreenshotManager`.
[General] [Removed] - RCTTest & ReactNative.takeSnapshot
Pull Request resolved: https://github.com/facebook/react-native/pull/23721
Differential Revision: D14434796
Pulled By: PeteTheHeat
fbshipit-source-id: d6e103a0ea0b6702701cdb5ce8449163ca4628ce
Summary:
While the proper typographical terminology is [Strikethrough](https://en.wikipedia.org/wiki/Strikethrough), we should still support `line-through` as it goes through a deprecation phase.
[iOS] [Added] - line-through support for fabric text components
Pull Request resolved: https://github.com/facebook/react-native/pull/23911
Differential Revision: D14460610
Pulled By: shergin
fbshipit-source-id: 0dae41b765f21d166ea3618c463ebe1330607b30
Summary:
Fix#23849. When setting a semi-transparent background on text, it becomes obvious that we are drawing the background color twice. Since background color is handled by the view, we should not need to draw the glyph background color too.
| Before | After |
| ------------- |-------------|
|<img src="https://i.imgur.com/8JGpKTC.png" width="300"> | <img src="https://imgur.com/qjKU9Ze.png" width="300">
[iOS] [Fixed] - Semi-transparent backgrounds on text
Pull Request resolved: https://github.com/facebook/react-native/pull/23872
Differential Revision: D14430501
Pulled By: shergin
fbshipit-source-id: 19743415b2d20a3b941b1c80bd7b47144e929458
Summary: Upgrade Jest and related packages to their latest stable version (24.5.0)
Reviewed By: mjesun
Differential Revision: D14424512
fbshipit-source-id: 6292b9f95c3315a520233b80ae06074d69a0ea3b
Summary:
@public
This bumps Prettier to v1.16.4
Only format source files were updated.
Reviewed By: mjesun
Differential Revision: D14454893
fbshipit-source-id: 72f9872fe764a79dbf0d9fab9bebb1456b039f2f
Summary: Change the codegen `srcs` to match any `**/*Schema.js`
Reviewed By: TheSavior
Differential Revision: D14401232
fbshipit-source-id: 61e60b1c9ca2f33efacc5caa1903b02a93cc644e
Summary:
Moves rn_codgen to rn_library behind a `codegen` flag to limit the number of rules we generate
WIth this, modules with native components can enable the react-native-codegen schema parsing by just updating their buck rule to:
```
rn_library(
name = 'lib',
codegen = True,
// ...
)
```
Reviewed By: TheSavior
Differential Revision: D14401263
fbshipit-source-id: 1675bc28389db64da10153c988bb4eb00d715056
Summary:
Moved all layout outputs fields which are set always on yoga node java object.
This change set is for adding experiment for layout outputs batching using a float array
Reviewed By: davidaurelio
Differential Revision: D14355025
fbshipit-source-id: 371d9c49fcb631efa8a79b62f8051ba5a17c232c
Summary: These constants are used for setting bit fields so they should be in power of 2
Reviewed By: davidaurelio
Differential Revision: D14384999
fbshipit-source-id: fa1f6994c874aff7a039ca98d5947cba317fa749
Summary:
Currently, when relative sizes are given in margin or padding stylings (be it a percentage or an auto measure), the inspector crashes, due to frame rendering not properly handling those kinds of measurements. This PR adds a resolution step for them:
* Percentages are evaluated relative to the window size.
* I decided to simply not render `auto` margins/paddings, due to the complexities involved (e.g. when the margin is between multiple elements with relative sizes).
Since the inspector does not crash anymore on relative sizes on paddings or margins, I believe that this addresses #17496.
Fixes#17496
[General] [Fixed] - Fix inspector rendering of relative margins and paddings
Pull Request resolved: https://github.com/facebook/react-native/pull/23804
Differential Revision: D14437273
Pulled By: cpojer
fbshipit-source-id: c9f0f71a2e1b2399a2b2148cef2124787703ead3
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:
I moved `devDependencies` to `dependencies` section of `packages/eslint-config-react-native-community`, to avoid the need for installation of them in the main projects. Now the installation should match the guide, from https://github.com/facebook/react-native/tree/master/packages/eslint-config-react-native-community
[General] [Changed] - Moved `devDependencies` of eslint config to `dependencies` section.
Pull Request resolved: https://github.com/facebook/react-native/pull/23766
Differential Revision: D14436081
Pulled By: cpojer
fbshipit-source-id: 770110eb4b2b6dfbbb7456fd1b69e20a8473a4e2
Summary:
…ake sure Android does not crash from bad params when using useNativeDriver
Android apps crash when using Animated useNativeDriver: true and the toValue is not a number. See issue here with test case. [Issue](https://github.com/facebook/react-native/issues/23810)
[Android] [fixed] - Fix crash when using Animated with useNativeDriver and a non Number toValue
Pull Request resolved: https://github.com/facebook/react-native/pull/23812
Differential Revision: D14436113
Pulled By: cpojer
fbshipit-source-id: 89fb3180c08cc5ffb817b3984dacda0a80b4f703
Summary:
Each time, when I run `iOS` tests like `RNTesterIntegrationTests`, Xcode will copy the bundle in `DerivedData` directory, and we added `RNTesterUnitTestsBundle.js` to bundle, so it leads `Haste module naming collision`, I think we can add `DerivedData` directory to blacklist.
<img width="752" alt="c7d7dcbd-6507-481a-a8ef-64f16fec3a6f" src="https://user-images.githubusercontent.com/5061845/53960917-6888cc80-4122-11e9-9d1d-faac97f73a26.png">
[iOS] [Fixed] - Add DerivedData to BLACKLISTED_PATTERNS for haste paths
Pull Request resolved: https://github.com/facebook/react-native/pull/23807
Differential Revision: D14436103
Pulled By: cpojer
fbshipit-source-id: fa4bbd87d429f70167253aa38ff20049c9df58b4
Summary:
After some works, we already support some attributes to text input's placeholder, so we can add example to show it in RNTester.
[iOS] [Added] - Added placeholder attributes example to RNTester
Pull Request resolved: https://github.com/facebook/react-native/pull/23769
Differential Revision: D14436086
Pulled By: cpojer
fbshipit-source-id: 8637dcb82a2e6aa51e351fd696b049aaee893997
Summary: This diff wires up everything from the previous 8 diffs. After this, all codepaths that execute `modulesConformingToProtocol` in `RCTImageLoader.m` will instead use iOS plugins to retrieve the modules on FBiOS.
Reviewed By: fkgozali
Differential Revision: D14360252
fbshipit-source-id: 6f0cecfa8dffa1955ba2f9ed54bc1c130fb23341
Summary:
This fixes a few memory leaks in fabrics handling of colors for borders, when using CGColorRef's we must be diligent about releasing the memory back.
[iOS] [Fixed] - Border style memory leaks
Pull Request resolved: https://github.com/facebook/react-native/pull/23815
Differential Revision: D14431250
Pulled By: shergin
fbshipit-source-id: dc663c633ae24809cb4841800d31a6ac6eeb8aa5
Summary:
<!-- Explain the **motivation** for making this change. What existing problem does the pull request solve? -->
I have used RN for a long time, and for all this time, crash reporting has been less great than native development crash reporting. At some point, companies like sentry, bugsnag and a bunch of others started supporting sourcemaps for js crashes in RN, which helped a lot.
But native crashes were (and still are) much harder to diagnose.
..Until now :D
I have make a repo of a sample RN app, included this PR in it, and some code and screenshots to help.
The repo is [here](https://github.com/pvinis/react-native-project-with-crash-heaven-pr).
I was trying to get good crash reports from native crashes in iOS for a looong time. I spoke with people in sentry, in bugsnag and more, and I could not get this solved. There was no clear way to get the **native** crashed to display correctly.
I made two repos here, one for [sentry](https://github.com/pvinis/SentryBadStack) and one for [bugsnag](https://github.com/pvinis/BugsnagBadStack), demonstrating the correct js handling and the bad native handling.
After all this, and talks with their support, twitter etc, I investigated further, on **why** this was happening. I thought there must be some reason that native crashes look bad in all the tools, and in the same way. Maybe it's not their fault, or up to them to fix it, or maybe they didn't have the experience to fix it.
In a test project I created, I checked what's up with the `RCTFatalException`, and I found out that the React Native code is catching the `NSException`s that come from any native modules of a RN app and converting it into an string and sending it to `RCTFatal` that created an `NSError` out of that string. Then it checks if the app has set a fatal error handler and if not, goes ahead and throws that `NSError`.
The problem here is that `NSException` has a bunch more info that the resulting `NSError` is missing or is altering. Turning the callstack into a string renders crash reporting tools useless as they are missing the original place the exception was thrown, symbols, return addresses etc. In both repos above it can be seen that both tools were thinking that the error happened somewhere in the `RCTFatal` function, and it did, since we create it there, losing all the previous useful info of the original exception. That leaves us with just a very long name including a callstack, but very hard to actually map this to the code and dsym.
I added a fatal exception handler, that mirrors the fatal error handler, as the error handler is used around React Native internal code.
Then I stopped making a string out of the original `NSException` and calling `RCTFatal`, and I simply throw the exception. This way no info is lost!
Finally, I added some code examples of native and js crashes and added a part in the `RNTester` app, so people can see how a js and a native error look like while debugging, as well as try to compile the app in release mode and see how the crash report would look like if they connect it to bugsnag or sentry or their tool of choice.
I have attached some images at the bottom of this PR, and you can find some in the 3 repos I linked above.
[iOS] [Fixed] - Changed the way iOS native module exceptions get handled. Instead of making them into an `NSError` and lose the context and callstack, we keep them as `NSException`s and propagate them.
[General] [Added] - Example code for native crashes in iOS and Android, with buttons on RNTester, so developers can see how these look when debugging, as well as the crash reports in release mode.
Pull Request resolved: https://github.com/facebook/react-native/pull/23691
Reviewed By: fkgozali
Differential Revision: D14276366
Pulled By: cpojer
fbshipit-source-id: b308d5608e1432d7676447347ae77c0721094e62
Summary:
This adds new functionality to the `Image` component by allowing you to retrieve the width and height of an image just like you'd do with [`Image.getSize`](https://facebook.github.io/react-native/docs/image.html#getsize) but _with_ the ability to provide headers to your request.
Why would you need this you ask? Well, imagine that you have an image that you're loading into your `Image` component that is protected and you get access by using a token in a header (or something similar). That would work. However, getting the dimensions isn't possible since you can't provide those same headers.
This is something that is bothering me when using a third-party library (https://github.com/archriss/react-native-image-gallery) and instead of implementing this just for that single library I imagined that it would be useful for anyone else that needs to get the image dimensions before displaying it.
[Android] [Added] - Added Image.getSizeWithHeaders
[iOS] [Added] - Added Image.getSizeWithHeaders
Pull Request resolved: https://github.com/facebook/react-native/pull/18850
Differential Revision: D14434599
Pulled By: cpojer
fbshipit-source-id: 56d5e58889ddf7ddc12d5f6f7d9dc6921fa17884
Summary:
DatePickerIOS tests stopped working after US changed their time zone on CircleCI. I decided to update the tests to be more reliable, by:
- removing "timezoneoffset" from the examples - I don't think it's needed. We don't demonstrate other props and it was causing us some troubles when timezones actually changed
- changing "interval" example from "time-only" to "datetime" because there's a known bug that prevented the previous example from working https://github.com/facebook/react-native/issues/9566
- splitting the label to two: one for date and other one for time, so that we can match the date only when we test "date" mode only
[IOS] [FIXED] - Improved reliability of DatePickerIOS e2e tests
Pull Request resolved: https://github.com/facebook/react-native/pull/23861
Differential Revision: D14434324
Pulled By: cpojer
fbshipit-source-id: 0f82b7e94bb1cb6ce75b44badd0064d1754370b9
Summary:
The Stale bot closes issues that have been inactive for 97 days (90 days until marked as stale, then 7 days of no activity before it is closed). This helps us focus on issues that affect new releases, and gets rid of drive-by issues where there has been no follow up. This process, however, does not acknowledge there's a type of issue that trascends releases and which the team might want to keep track of in order to fix in a future release.
The "Resolution: Backlog" label can be used to mark these types of issues, and keep the bot from closing them.
[General] [Added] - GitHub: Add Backlog label
Pull Request resolved: https://github.com/facebook/react-native/pull/23789
Differential Revision: D14429112
Pulled By: hramos
fbshipit-source-id: ddec7d994a40e46b43de45b79a812fd4dbd28e6a
Summary:
@public
Removes the configuration field to avoid weak JNI refs. It is no longer used.
Reviewed By: marco-cova
Differential Revision: D14424594
fbshipit-source-id: f0877022615a11ac5079354e0977c6893b7d58d7
Summary:
@public
Completely removes the usage of weak JNI refs.
This is great, because node allocation and deallocation no longer go through a VM-global lock to access the weak reference table.
This is also great, because we can no longer overflow that ref table.
Performance is comparable to weak refs.
Reviewed By: marco-cova
Differential Revision: D14423068
fbshipit-source-id: 62003d2d6fd971e91460a26fb3477046f26e2ba5
Summary:
Right now we have a raw pointer to the js runtime in Java and we pass that to EventBeatManager's constructor; this diff adds a setter for the runtime ptr and removes it from the member initializer list, so that you can set it later from cpp instead.
Q: Should I just rewrite this to use RuntimeExecutor instead?
Reviewed By: shergin
Differential Revision: D14318893
fbshipit-source-id: 1221dd5959927967bad870f15c901c15e5455874
Summary: Easy cleanup of commented code in TextLayoutManager, I kept the TODOs to complete the code in the future
Reviewed By: shergin
Differential Revision: D14372356
fbshipit-source-id: ff87f9b09e9f40ed021256f463e39299467b3e0e
Summary: This diff is a part of an effort to resolve build errors that appear when compiling with the latest version of clang.
Reviewed By: shergin
Differential Revision: D14369797
fbshipit-source-id: e4c6f53e293f336efad18597f9d2705c025e1051
Summary:
Initially if a `react-native-web` project were to use a library that required internals `expo/webpack-config` would polyfill those internals. This `Platform.web` was used for cases where `react-native` modules needed other internal `react-native` modules, ex: `Animated/src/AnimatedEvent -> Renderer/shims/ReactNative -> Renderer/oss/ReactNativeRenderer-dev -> Core/InitializeCore -> Devtools/setupDevtools -> WebSocket/WebSocket -> Utilities/Platform`
The consensus is that if any `react-native` library references a `react-native` internal (ex: `react-native/*`), it should continue to throw errors. We've removed the use of internals from all of the Unimodules, `react-navigation`, and `react-native-gesture-handler`. This covers a wide enough area for a lot of projects to get web support.
* Add emitters for libs referencing internals necolas/react-native-web#1275
* Remove monkey patch that bundles RN, libs that use internals will crash instead expo/expo-cli#409
* Remove all unsupported internals and polyfills from the Expo suite expo/expo#3676
* Remove internals from react-native-gesture-handler kmagiera/react-native-gesture-handler#406
* Related #23387
[GENERAL] [REMOVED] - Platform.web.js
Pull Request resolved: https://github.com/facebook/react-native/pull/23830
Differential Revision: D14406145
Pulled By: hramos
fbshipit-source-id: bdda99a334d33f5543fdb954eb80e2e7186f985a
Summary: D13103990 updated the flow types for ScrollView. This diff just updates our internal callsites to address the flow errors.
Reviewed By: TheSavior
Differential Revision: D14305453
fbshipit-source-id: 58fe28da06a6c83a81ba29bebe96e74c2f3ed5e5
Summary:
Relates to #22100.
I left 2 `$FlowFixMe`s as I was not sure how to handle generic `React.Element<>` and which native props can I pass to ScrollView (would be cool to document it once we got proper types there).
I also got rid of `InternalScrollViewType` because we have better typings in original `ScrollView` now.
Pull Request resolved: https://github.com/facebook/react-native/pull/22301
Reviewed By: TheSavior
Differential Revision: D13103990
Pulled By: RSNara
fbshipit-source-id: 9664ee9d7f570b00992215e10901e5317f24fe5c
Summary:
I measured the performance of UIMananger methods and found that `create` method spends a significant amount of time on preallocating views (around 10 ms on my device). Interestingly, this time was actually spent on dispatching operations on the main thread, not on performing those operations. That makes me think about think about the preallocation problem one more time.
(Here and later I discuss preemptive optimistic preallocation views on iOS, but the issues are more-less applicable for all platforms.)
BTW, what's view preallocation? – In React Native we believe that we can get significant TTI wins instantiating platform views ahead of time while JavaScript thread is busy doing reconciliation and the main one is idle.
So, seems the current approach has those downsides:
* We spend too much time on dispatching only (jumping threads, creation Objective-C blocks, managing them in GCD, incrementing atomic refcountes inside `ShadowView` and so on). That's wasteful.
* We don't have much information during preallocations that can help prepare something to save time in the future. We don't know the future size of the component, so we cannot e.g. pre-draw a border or even allocate memory for a future drawing.
* We pre-allocate to much. At the moment of component creation, we don't know will this component be filtered out by view-flattening infra or not, so we always allocate a view for it. That's ~30% more views that we actually need.
* We don't stop allocating (or dispatching instructions for that) after the recycle pool is already filled in. That's also wasteful.
Why is this so bad and how can we fix it properly?..
I thought about this problem for months. And I think the answer is trivial: We don't know the exact shape of the interface until we finish creating it, and there is no way to overcome this problem on the client side. In the ideal world, the server size (or hardcoded manifest somewhere) tells the renderer (at the moment where we started navigating to it) how many views of which type will some surface use.
And until our world is not so perfect, I think we can get a significant performance improvement doing simple preallocation of 100 regular views, 30 text views, and 30 image views during rendering the first React Native surface. So I hardcoded that.
Reviewed By: JoshuaGross
Differential Revision: D14333606
fbshipit-source-id: 96beeb58b546258de1b8fd58550e0ae412b78aa9
Summary:
This was an idea to check by Joshua Gross
Changelog:
[General][Internal] Codegen: Adding test for negative zero floats
Reviewed By: JoshuaGross
Differential Revision: D14378418
fbshipit-source-id: 4d18eea18143c501d3f2e7ba334f35ec1dd140e6
Summary:
Right now we rely on the Paper UIManager to update animated node graphs - this hooks us into `RCTSurfacePresenter` in the same way so we are no longer reliant on Paper. Should also help with complex ordering corner cases with pre vs. post operations and restoring defaults when nodes are removed. More info:
https://github.com/facebook/react-native/pull/11819/files
Note that we don't have a way to differentiate animation nodes related to fabric views vs. paper views, so if paper and fabric are both rendering updates simultaneously it's possible they could get processed by the wrong callback. That should be very rare, rarely cause problems even if it does happen, and won't be a problem at all in a post-Paper world.
Reviewed By: shergin
Differential Revision: D14336760
fbshipit-source-id: 1c6a72fa67d5fedbaefb21cd4d7e5d75484f4fae
Summary:
We currently rely on the Paper UIManager calling `uiManagerWillPerformMounting` to flush the animated operations queue, which includes starting and stopping animations. This mostly works right now because Fabric always starts after Paper, but sometimes Paper doesn't fire `uiManagerWillPerformMounting` for a while, which can delay an animation starting.
To fix this, I force a flush of the queues on the UIThread whenever start or stop is called. This should be safe because the order of animation operations is still preserved, and start/stop are (almost?) always called in dedicated event handler loops, so any other updates like changing the way nodes are attached should already have been processed from a previous JS execution loop.
Reviewed By: JoshuaGross
Differential Revision: D14313502
fbshipit-source-id: 2a2b0c614fd1a591bd04b6b3fafcc09ff6c9d6e7
Summary: The hope is that it will remove many unnececery allocations improving overal perfromance.
Reviewed By: mdvacca
Differential Revision: D14249198
fbshipit-source-id: f0442b3919ccead0582a3190dea0e33d517d85f6
Summary:
SharedShadowNodeList is one of the core collections in Fabric. Every ShadowNode has one, it's used intensivly during diffing and so on.
Usually, nodes have a very few children, so using `small_vector` instead of regular `vector` should save us a lot of memory allocations.
Reviewed By: JoshuaGross
Differential Revision: D14249201
fbshipit-source-id: 53297caa027a74099d0a1ed4a3cce78f8feb651b
Summary:
Nowadays, every ShadowNode has a reference to a ComponentDescriptor, so now there is no need to do registry lookup for that.
That should save us 0.5-1.0 ms in my non-scientific measurements.
Reviewed By: mdvacca
Differential Revision: D14348369
fbshipit-source-id: 57f6a6f2f8bf0b7e58d89a414fec20b2db8876f7
Summary:
I noticed the links under `## Contents` weren't clickable in the README.md file. This PR makes the links in table of contents clickable again.
[General] [Fixed] - Fix broken links for the table of contents in `README.md`
Pull Request resolved: https://github.com/facebook/react-native/pull/23795
Differential Revision: D14350857
Pulled By: hramos
fbshipit-source-id: ddc02e7905b653cf65ad6ad631bccdbbca936a7f
Summary:
Followup to fe80a0c01d. Use a Markdown extension to let GitHub know this can be rendered as a Preview, otherwise GitHub will display the plaintext version.
[General] [Fixed] - Use Markdown in SUPPORT file
Pull Request resolved: https://github.com/facebook/react-native/pull/23791
Differential Revision: D14349422
Pulled By: hramos
fbshipit-source-id: 836746f35c6e962f3ca64a138bbf764529a6e043
Summary:
I'm changing all callsites to use either global or scoped perf logger explicitly in one diff.
`GlobalPerformanceLogger` is basically a singleton
`scopedPerformanceLogger` is scoped to the React tree by using a React Context
Reviewed By: sahrens
Differential Revision: D14186694
fbshipit-source-id: 062c76eea8fce9d9b531f0eddf153bb79d52f68d
Summary:
See https://help.github.com/en/articles/adding-support-resources-to-your-project. The SUPPORT file is surfaced by GitHub in several useful places. The goal is to increase discoverability of all support resources, giving the reader an opportunity to find the help they need before they open an issue in the repository. A secondary goal is to use a friendlier tone when communicating our processes.
The issue templates have been standardized to follow the format used by GitHub's template tool. A bug in the "Regressions" template, due to its use of multiple labels, is fixed as well.
The bot will explain how a changelog can be fixed when it nags a PR.
[General][Added] - Added SUPPORT resources, friendlier messaging.
Pull Request resolved: https://github.com/facebook/react-native/pull/23778
Differential Revision: D14333911
Pulled By: hramos
fbshipit-source-id: d4b3e75194ea7d5c932dd8df2393d5b189f30f35
Summary:
The `Dockerfile.android` had fallen out of date. We now point to the new community image being used in the Circle CI `test_android` workflow. After spending an hour or two working with these Docker images, I saw some opportunities to clean up the docs as well.
[ANDROID] [Fixed] - Use new React Native Community Android base image for local Docker tests.
Pull Request resolved: https://github.com/facebook/react-native/pull/23723
Differential Revision: D14331737
Pulled By: hramos
fbshipit-source-id: cf42820021c997c3c06cc8b3671f67c9d2650ee5
Summary:
androidx files were not being instrumented properly which meant we would have exceptions thrown by powermock
Robolectric Instrumentation config was changed by hand, the remainder is a codemod using abgs + xargs + sed
Differential Revision: D14323745
fbshipit-source-id: 56aa97dad5d7197f4eb0ba1fdd80b1583bcad6ac
Summary:
Clowntown.
This fixes a recent regression happened becasuse wrong order of parameters in ShadowViewMutation constructor.
Reviewed By: JoshuaGross
Differential Revision: D14329164
fbshipit-source-id: 5a0dc04b889fb3357050b951d56c3e436dbeefb1
Summary: Use the codegen for the Slider component with the new `inferfaceOnly` option
Reviewed By: TheSavior
Differential Revision: D14295981
fbshipit-source-id: 0482572892fbcffada43c7c6fbf17e70546300b8
Summary: These were moved to the codgen
Reviewed By: TheSavior
Differential Revision: D14307470
fbshipit-source-id: 49030c245f11bd595bb97e1b2f34a7c454be5c56
Summary: We need this in the Props.h files
Reviewed By: TheSavior
Differential Revision: D14307476
fbshipit-source-id: 34a86ced30e04bfb6d7f85dc292e43d2a1a0ac3e
Summary: In some cases the implementation for native modules are more advanced and we cannot currently generate some of the files. We've decided in these cases to only generate the props + events for now, so this flag `interfaceOnly` will only generate those files 👍
Reviewed By: TheSavior
Differential Revision: D14295980
fbshipit-source-id: 1790825143206a84469015e08958bf6f00ffde52
Summary:
Implement TODO, implement the nativeID functionality in a more efficient way instead of searching the whole view tree.
[iOS] [Fixed] - Implement the nativeID functionality in a more efficient way
Pull Request resolved: https://github.com/facebook/react-native/pull/23662
Differential Revision: D14323747
Pulled By: shergin
fbshipit-source-id: 3d45dbf53ad2b6adb79b4331600d53b51ede76d4
Summary:
This pull request removes the designated initializer in `LayoutMetrics.h`. This will help improve the portability of this file.
[General] [Changed] - Fabric: Remove designated initializer in LayoutMetrics.h
Pull Request resolved: https://github.com/facebook/react-native/pull/23758
Differential Revision: D14320526
Pulled By: shergin
fbshipit-source-id: 076ad389d0985d5213b521a2ffaca4ca7ae31599
Summary:
Keep placeholder paragraph style same with text input.
[iOS] [Fixed] - Keep placeholder paragraph style same with single line text input
Pull Request resolved: https://github.com/facebook/react-native/pull/23765
Differential Revision: D14321255
Pulled By: cpojer
fbshipit-source-id: 2b8cbb7f2c7ceb40a9a2b142065dd6f5eb3d62eb
Summary:
We always use `NSData` to send, for the `NSString` support, we already transform to `NSData` before call `_sendFrameWithOpcode` method. So we can remove these class check.
Changelog:
----------
[iOS] [Changed] [RCTSRWebSocket] - Remove class check and make data parameter of `_sendFrameWithOpcode` constraint to `NSData`
Pull Request resolved: https://github.com/facebook/react-native/pull/22633
Differential Revision: D14320451
Pulled By: cpojer
fbshipit-source-id: 63ac194d08965d7518a8ac38eea77fd5b43b6147
Summary:
This PR divides the accessibility tests into two activities-- a cross-platform activity for accessibility features which are expected to work on all platforms, and platform specific tests for Android and iOS.
We believe that most, if not all, accessibility features should be cross-platform, with fallback implementations where the underlying concept doesn't exist on a particular platform.
This division of the tests makes it clearer for developers which features are expected to work on all supported platforms, and which are platform-specific.
[CATEGORY] general, Android, iOS
[TYPE] change
Message
Refactor the RNTester accessibility activities to better represent where the features are expected to work. Moves all cross-platform tests to AccessibilityExample.js, Android-specific tests to AccessibilityAndroidExample.android.js, and iOS-specific tests to AccessibilityIOsExample.ios.js.
Pull Request resolved: https://github.com/facebook/react-native/pull/23722
Differential Revision: D14320696
Pulled By: cpojer
fbshipit-source-id: b5ab7a82a90f06d55a24262e86bd69fbdc890427
Summary:
After #23738 , we can add more text attributes to placeholder, so now, let's update the calculation of placeholder size based on placeholder attributes.
[iOS] [Fixed] - Fixed singleline text input placeholder size
Pull Request resolved: https://github.com/facebook/react-native/pull/23745
Differential Revision: D14320630
Pulled By: cpojer
fbshipit-source-id: 2d9e8b59ba70228202add762cfc9c6cbc77e5e95
Summary:
After some refactor of text input attributes, we can now add style attributes the same as text input's attributes, from https://github.com/facebook/react-native/issues/19002#issuecomment-467171589, user wants placeholder to support line-height , I think we can add it now for multiline text input.
[iOS] [Added] - Added lineHeight support of placeholder for multiline text input
Pull Request resolved: https://github.com/facebook/react-native/pull/23760
Differential Revision: D14320600
Pulled By: cpojer
fbshipit-source-id: ededeaa11560af089ca15ffc188e2e70db2ad7d4
Summary:
After #23738 , we can add more text attributes to placeholder, so now, let's update the calculation of placeholder size based on placeholder attributes.
[iOS] [Fixed] - Fixed multiline text input placeholder size
Pull Request resolved: https://github.com/facebook/react-native/pull/23742
Differential Revision: D14320489
Pulled By: cpojer
fbshipit-source-id: 6b0f07fe7406d5c99c7280d584f8b8e51fc84c00
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:
This component is being extracted.
These are flaky and constantly fail on Circle.
[General] [Removed] - Removed Detox e2e Switch tests
Pull Request resolved: https://github.com/facebook/react-native/pull/23753
Differential Revision: D14319130
Pulled By: cpojer
fbshipit-source-id: d0ea276440e034afbb11aa31762922532ad06402
Summary:
Between invalidating a bridge and suspending its JS thread, native modules may have their methods called.
Only warn when a native module has been invalidated, which happens right before its JS thread is suspended.
Avoid initializing a native module's instance if its bridge is invalidated.
/cc fkgozali https://github.com/facebook/react-native/commit/f94521244798f859648d1769f397102c06d763f0#commitcomment-32467567
[iOS] [Fixed] - Properly validate JS->native method calls
Pull Request resolved: https://github.com/facebook/react-native/pull/23658
Differential Revision: D14287594
Pulled By: fkgozali
fbshipit-source-id: 89dd1906a0c55f3f48ba4ff220aac0cddf2eb822
Summary:
This pull request removes the use of the GCC extension null coalescing operators (`?:`) and replaces them with ternary operators. This improves the portability of `ShadowNode.cpp` (and enables MSVC to build it)
[General] [Fixed] - Fabric: Removed null coalescing operators in `ShadowNode`
Pull Request resolved: https://github.com/facebook/react-native/pull/23438
Differential Revision: D14304958
Pulled By: shergin
fbshipit-source-id: 7d8e6778a72dabf09b1d99bc091a7578598b79c3
Summary:
This pull request removes the designated initializers in `RootShadowNode.cpp`. This will help improve the portability of this file.
[General] [Fixed] - Removed designated initializers in `RootShadowNode`
Pull Request resolved: https://github.com/facebook/react-native/pull/23715
Differential Revision: D14305167
Pulled By: shergin
fbshipit-source-id: e394580f103fdb59cf078828b5d2ee6df6cc534d
Summary:
This pull request removes the designated initializers under the `fabric/uimanager/` folder. This will help improve the portability of these files.
[General] [Fixed] - Removed designated initializers under the `fabric/uimanager/` folder
Pull Request resolved: https://github.com/facebook/react-native/pull/23717
Differential Revision: D14305203
Pulled By: shergin
fbshipit-source-id: 370911682e22cbb20c4bfd7382ed4da0ce1a598d
Summary: To satisfy Flow, we want to account for RegExp as a valid ignore pattern.
Reviewed By: TheSavior
Differential Revision: D14303072
fbshipit-source-id: 4988fff5c6c6a12da99027e47216cedcf5a4db5a
Summary:
This pull request removes the designated initializers in `ShadowNodeTest.cpp`. This will help improve the portability of this file.
[General] [Fixed] - Removed designated initializers in `ShadowNodeTest`
Pull Request resolved: https://github.com/facebook/react-native/pull/23714
Differential Revision: D14305162
Pulled By: shergin
fbshipit-source-id: 81803652ece734a9b223d7a8b462a8b62cde7d1d
Summary:
This pull request removes the designated initializers in `ComponentDescriptorTest.cpp`. This will help improve the portability of this file.
[General] [Fixed] - Removed designated initializers in `ComponentDescriptorTest`
Pull Request resolved: https://github.com/facebook/react-native/pull/23713
Differential Revision: D14305123
Pulled By: shergin
fbshipit-source-id: 64cfc76dd7eaf74b4b4395bac18a9fc370a3b322
Summary:
I am not sure why it compiled before, it clearly should not, IMO. The `const` types (and references!) are not allowed inside `std::vector` because they are not assignable.
Some experiments that I did caused compilation errors here, so I am changing that to be actually correct.
Reviewed By: JoshuaGross
Differential Revision: D14249199
fbshipit-source-id: 07a22ef13f5de9dfc7ab307493419e6006994bc2
Summary:
@public
GCC up until v7 flags our way of reading edges in `YGNodeSetStyleInputs` as unused variables. I managed to work around that by rearranging the casts a bit.
Reviewed By: SidharthGuglani
Differential Revision: D14299439
fbshipit-source-id: eec0266185504d1b790b9ef574bd4a83c0059d3a
Summary:
@public
Moves all Java classes used from C++ to their own header + implementation file. In `YGJNI.cpp`, we only call methods on these objects deriving from `jni::JavaClass`.
This is only a bit of cleanup, no functional change.
Reviewed By: SidharthGuglani
Differential Revision: D14261043
fbshipit-source-id: 2db1d81cb7f56a4cdc24b182b2166e1d7e24ba3c
Summary:
This pull request removes the designated initializers in `react/mounting/**` and `react/events/**` to improve portability.
A destructor was also defined for `ShadowView` to fix this error:
```
ShadowViewMutation.cpp:14: error: undefined reference to 'facebook::react::ShadowView::~ShadowView()'
ShadowViewMutation.cpp:24: error: undefined reference to 'facebook::react::ShadowView::~ShadowView()'
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
```
[General] [Changed] - Fabric: Remove designated initializers in Events and Mounting
Pull Request resolved: https://github.com/facebook/react-native/pull/23441
Differential Revision: D14298890
Pulled By: shergin
fbshipit-source-id: f5d8fc6e1f5968b94e8bb3ca0c3f0e81cf892f83
Summary:
Adds a moved warning to the CameraRoll import directing people to the react-native-community/cameraroll package.
[Lean Core] [Warning] add warning that CameraRoll has been moved to RNC
Pull Request resolved: https://github.com/facebook/react-native/pull/23733
Differential Revision: D14298485
Pulled By: cpojer
fbshipit-source-id: cf03660c604a7337f234da107d7069c0ccf99f36
Summary:
We have parse code to try to support exported method parameter annotated `__unused` and `nullable`, but actually, seems we don't support it entirely, for example, we parse `__unused` firstly, then we parse `nullable`, actually, this case not exist, because `nullable` macro must appear right after `(`, before `__unused`, so we can't parse success, leads to error signature and crash.
[iOS] [Fixed] - Fixed method invoke when both nullable and __unused exist
Pull Request resolved: https://github.com/facebook/react-native/pull/23726
Differential Revision: D14298563
Pulled By: cpojer
fbshipit-source-id: 934e1d384a5d67b7bbf117fd2dec51f50979c979
Summary:
Renamed `eslint-config-react-native` to `eslint-config-react-native-community`, due to the fact, that initial name is already taken on `npm`. Additionally, I added very simple `README.md` file, to prepare the package to be published.
[General] [Changed] - Changed `eslint-config-react-native` name to `eslint-config-react-native-community`
Pull Request resolved: https://github.com/facebook/react-native/pull/23718
Differential Revision: D14298553
Pulled By: cpojer
fbshipit-source-id: bad5a42502ccdebf5f95d8217187be23bbf8f26c
Summary:
SectionList accesses items outside of the array bounds.
This was discovered when using mobx, which warns you: `[mobx.array] Attempt to read an array index (${index}) that is out of bounds`. This is because `section.data[itemIndex + 1]` goes beyond array length.
This PR adds an array length check and simplifies the code a bit to avoid repetitive `this.props.`
Pull Request resolved: https://github.com/facebook/react-native/pull/23710
Differential Revision: D14298557
Pulled By: cpojer
fbshipit-source-id: fee3422ad5b053d91a097c5842f46e78a149c3d5
Summary:
We need to check `body[@"target"]` wether equal to `nil`, if it is, return to prevent crash.
[iOS] [Fixed] - Fixed crash if event doesn't have body parameter
Pull Request resolved: https://github.com/facebook/react-native/pull/23711
Differential Revision: D14298543
Pulled By: cpojer
fbshipit-source-id: d5e8cd69438f323ae102e61618c0371a01bee347
Summary:
...referencing stale function component limitations
While preparing a short tutorial on the DrawerLayoutAndroid using the v59 RC, I came across a comment that we can update that states refs as being available only in Class components. This updates that with both class and function components.
If we'd rather delete the comment entirely and move both examples to the website, I'm fine with that too. The current docs page doesn't address the imperative API. https://facebook.github.io/react-native/docs/drawerlayoutandroid
[General] [fixed] - Update stale comment to provide both class and functional component ref example for DrawerLayoutAndroid
Pull Request resolved: https://github.com/facebook/react-native/pull/23730
Differential Revision: D14298527
Pulled By: cpojer
fbshipit-source-id: 3e9f0d6ae49588045fd9d924996fe7cff3d6a156
Summary:
For the `NullabilityPostfix`, we can use `_Nullable` or `__nullable`. Please see https://developer.apple.com/swift/blog/?id=25 , and we also use it in our code.
[iOS] [Added] - Added support of __nullable and __nonnull for module exported method signature
Pull Request resolved: https://github.com/facebook/react-native/pull/23731
Differential Revision: D14298483
Pulled By: cpojer
fbshipit-source-id: 4dd3188f51be3808ea2b97ce19aa7a85ea1f4a9e
Summary:
We need to keep placeholder attributes sync with text input's text attributes, like `font`,`kern` ....., to keep style the same.
Also fixes#19002 .
[iOS] [Fixed] - Keep placeholder attributes sync with text input text's attributes
Pull Request resolved: https://github.com/facebook/react-native/pull/23738
Differential Revision: D14298482
Pulled By: cpojer
fbshipit-source-id: 3555091bf3bc01e4b026d5a4cdbe93b4122106e8
Summary:
Now that pre-allocation of views update props, we can just force the execution of "pre-allocation" instead of "create" mount item.
This diff removes the methods that were used by view creation
This way we reduce the amount of mountItems that are created during commit phase.
This should improve TTI (I'm running a MobileLab)
Reviewed By: shergin
Differential Revision: D14297477
fbshipit-source-id: a100bab798467e9f0fa9773e0206ba1ded472298
Summary:
Now that pre-allocation of views update props, we can just force the execution of "pre-allocation" instead of "create" mount item.
This diff adds systraces to the execution of pre-mountItems during commit
This should reduce the amount of mountItems that are created during commit phase.
This should improve TTI (I'm running a MobileLab)
Reviewed By: shergin
Differential Revision: D14297478
fbshipit-source-id: d8e515d34cf6edacce53c0903f74a08029259f6f
Summary:
Now that pre-allocation of views update props, we can just force the execution of "pre-allocation" instead of "create" mount item.
This should reduce the amount of mountItems that are created during commit phase.
This should improve TTI (I'm running a MobileLab)
Reviewed By: shergin
Differential Revision: D14297476
fbshipit-source-id: 3ade662848ed836dc3221abe78611bb4a2b94e00
Summary:
Cleaning up <android/log.h> from includes
We use LOG
```
LOG(INFO) << "message";
```
to log
Reviewed By: shergin
Differential Revision: D14297264
fbshipit-source-id: 1a9a760a092b6947cca7d7d59b66c574b3e41ad8
Summary: This diff removes the "isLayoutable" parameter from SchedulerDelegate.schedulerDidRequestPreliminaryViewAllocation. This now can be infered from the shadowView parameter
Reviewed By: shergin
Differential Revision: D14296481
fbshipit-source-id: b200504f9c2bef41f0a70257f1f5a274fbe97cbb
Summary: It can save us a couple of ms, hopefully.
Reviewed By: mdvacca
Differential Revision: D14249196
fbshipit-source-id: b5911bcd8b49be66de7b9d2da660df38ef7cc8cd
Summary: That should reduce the size of `ShadowNode`, make an instantiation of shadowNode a bit faster, and make `clone` operation a bit faster because simple dynamic dispatch is faster than std::function invocation. It also should help a bit with code size.
Reviewed By: mdvacca
Differential Revision: D14249200
fbshipit-source-id: c1332b139d27becebf15cd894475507b5fd0eb9f
Summary: We need this change to migrate away `cloneFunction` (to a pointer to ComponentDescriptor) inside ShadowNode.
Reviewed By: mdvacca
Differential Revision: D14249197
fbshipit-source-id: 773edcf40e17989886e2c5d3955823a0dbf3857a
Summary: Well, that was not so good idea to add that in the first place. Turns out that nowadays standard `string` and `vector` are good enought (but we still need small and inlined collections thought).
Reviewed By: JoshuaGross
Differential Revision: D14249202
fbshipit-source-id: a1b32b800c3f52b29a57f015e1221a0a0eb305c8
Summary: Surprisingly, we have some significant amount of text measuring requests where the string is empty. So, there is no need to go to platform specific layer to find that the size of those strings is zero.
Reviewed By: mdvacca
Differential Revision: D14297315
fbshipit-source-id: bf84cf27d5c0893262e8b27da8ff42fc77bcd6c5
Summary: `ParagraphMeasurementCache` was replaced with templated version of itself.
Reviewed By: mdvacca
Differential Revision: D14296515
fbshipit-source-id: 29e370f07baf14b25430f85a06f603907aed5563
Summary:
Creation NSAttributedString from attributedString is not so cheap process, so with this simple cache we hopefully can save a couple milliseconds.
The same string is used at least two times: first time for measuring and second for drawing.
Reviewed By: mdvacca
Differential Revision: D14296514
fbshipit-source-id: 6313aa2c6e9f63d873868131750f61c02d64d2de
Summary: SimpleThreadSafeCache is a simple thread-safe LRU cache; it's a generalized version of ParagraphMeasurementCache.
Reviewed By: mdvacca
Differential Revision: D14296516
fbshipit-source-id: 2b40ac1979ada12551848ece3642b2d99e369672
Summary:
Update Props during pre-allocation avoiding re-updating the same props during mounting
MobileLab test showed an improvement of:
MARKETPLACE_YOU_TTI_SUCCESS: -3.34% = 58ms
Reviewed By: shergin
Differential Revision: D14252170
fbshipit-source-id: 1f4e9ad5dcecbc06651fa065135ffeed4892d984
Summary: This diff introduces the concept of "updateProps" as part of InsertMutation and it changes the diffing algorithm to populate this field.
Reviewed By: shergin
Differential Revision: D14289608
fbshipit-source-id: 642f00d03d294a12ea7fa7482c72e701b756f3d4
Summary:
Before only the props of Images components were being applied during the pre-allocation phase.
Now that we have a limit of time that pre-allocations will be executed we can update props for any component
Reviewed By: shergin
Differential Revision: D14252171
fbshipit-source-id: afea4b71a32b7ae2c184b0cdce97f778bc3a47d2
Summary: This diff implements a limit on the execution of pre-allocation of views, taking into consideration the time it is left on the frame, with a maximum of 8 ms / frame
Reviewed By: shergin
Differential Revision: D14252172
fbshipit-source-id: 1780a489122a8bc476d6ec7c92b45fdc58993e1d
Summary:
This diff changes the pre-allocation of Images update the props on the ImageViews during the creation of ShadowNodes instead of during rendering.
The purpose of this change is to optimize TTI.
This was originally landed in D14214844 and then backed out in D14247897
Reviewed By: shergin
Differential Revision: D14286232
fbshipit-source-id: 8437f57f9473eb22ef98d80531b4020ee5fbb9ae
Summary: Re-enables the disabled codegens on android by renaming the test fixtures to something shorter
Reviewed By: TheSavior
Differential Revision: D14258414
fbshipit-source-id: 912c12df039930ec492b5bafc69bc298f913bdcc
Summary: It was weird that the default values for enums did not match the casing for the enum options
Reviewed By: TheSavior
Differential Revision: D14258101
fbshipit-source-id: f601e50390a6c67f20e7a18aa94b377597a831cc
Summary:
We are now generating the native cpp files for ActivityIndicatorView via Buck.
Deleting the hand written files and switching over.
Reviewed By: TheSavior
Differential Revision: D14247446
fbshipit-source-id: 63a6df3254e4184de6c8abb9ea2c89654ad54398
Summary:
This diff updates the flow types for the ActivityIndicator size prop.
The android component [here](diffusion/FBS/browse/master/xplat/js/react-native-github/ReactAndroid/src/main/java/com/facebook/react/views/progressbar/ReactProgressBarViewManager.java$31-30) does not use a size prop
The iOS component [here](diffusion/FBS/browse/master/xplat/js/react-native-github/React/Fabric/Mounting/ComponentViews/ActivityIndicator/RCTActivityIndicatorViewComponentView.mm;e82762cefe5cddad4a7e8144c42c76eb4d907e56$14-15,23) uses the size prop, but only for small/large, not for the number type
Reviewed By: TheSavior
Differential Revision: D14247432
fbshipit-source-id: 43b74574548eaf97f96d68c18ed627465fd5e133
Summary:
@public
Allows to limit the number of measure cache entries used. This is purely for experimentation.
The measure cache uses about half of every `YGNode`. Reducing its size would allow us to reduce resident memory used by Yoga.
Reviewed By: SidharthGuglani
Differential Revision: D14279027
fbshipit-source-id: e0d22138230bee7fb129c193eb6e4085de02a36e
Summary:
Props now have a special value that represents generation number of `Props` object, which
increases when the object was constructed with some source `Props` object.
Reviewed By: mdvacca
Differential Revision: D14293939
fbshipit-source-id: 4782bf33ccf37623d4079c09cc4d0268bb6c2690
Summary:
[General][Fixed] Fixed Flow typing of onError prop on Image component to include `error` field
reason: tried grabbing the error off nativeEvent in D14285176 but flow complained. Docs say it should be there & when actually running the code, it does exist, so I //think// this is ok?
Reviewed By: TheSavior
Differential Revision: D14285688
fbshipit-source-id: 19deb35ba8ab419de209a8deaf12df0b395e5b82
Summary: TurboModule needs sync calls from JS to native, and that's not supported with the current Chrome debugger. Until we have proper solution, disable it to avoid confusion.
Reviewed By: PeteTheHeat
Differential Revision: D14286383
fbshipit-source-id: e93903bf8fdfc714960d0d58e3f3eb0442c811bd
Summary:
When TurboModules are created, we need to broadcast this event using `NSNotificationCenter`. This is important because a number of TurboModules/ObjC classes listen to this notification and perform side effects.
I found these using https://fburl.com/codesearch/j0a9p3dr.
- FBReactKitServerSnapshotTests: After the RCTExceptionsManager is initialized, it assigns itself as the delegate to the RCTExceptionsManager instance.
- FBProfilePictureUploadFlowController: After FBProfileFrameNativeModule is initialized, it calls `[module setFlowController: self]`
- RCTFBSession: After every NativeModule is initialized, if that NativeModule conforms to the RCTFBSessionModule protocol, assign the session to it.
- TwilightLocalMedia: Hack to figure out when the bridge is initialized.
- FBMarketplaceMenuItemHandler: After FBMarketplaceNativeModule is initialized, attach a data source obtained from the session to the module. Then, attach module to data source.
- RCTModuleInitTests: Set local state based on if certain modules are initialized (https://fburl.com/e34kezb5).
- IGReactModule: When the RCTImageLoader is initialized, set it's image cache to `[IGReactImageCache new]`.
- RCTIGUserSession: Like RCTFBSession
- FBReactModuleTracker: This keeps a list of all dispatched notifications (for some reason).
- RCTModuleInitNotificationRaceTests: Sets self.didDetectViewManagerInit to true if RCTTestViewManager is initialized.
Reviewed By: fkgozali
Differential Revision: D14281557
fbshipit-source-id: 9fcf1bb5f5650fcc3a3e50c6d93405b0b618e271
Summary: [IOS] [FIXED] - This may cause weird race condition if JSI is accessed via multiple threads within the same method invocation. Since only the objc class methods need to be executed on the right queue, we can keep the conversion to jsi::Value in the originating JS thread.
Reviewed By: RSNara
Differential Revision: D14277167
fbshipit-source-id: c506aebb71e190e2afcbf19dce05088ce2b97833
Summary: `YGConfigContext` was using `global_ref` instances for the config, leading to the config object never being freed. Since we no longer need it after getting rid of cloning, we can make the context a pointer to a `global_ref` to the logger.
Reviewed By: SidharthGuglani
Differential Revision: D14258571
fbshipit-source-id: cce632499839a680eef00a3854f61ab74ae2a87a
Summary:
@public
Having assignment operators for `YGNode` means that existing children on the node assigned to would have to be handled somehow.
Deallocating might be incorrect. Ignoring might leak.
Here, we `delete` copy assignment, and make move assignment private (it is used in `YGNode::reset()`).
Copy and move constructors *can* be implemented. The move constructor has to take ownership of the children, while the copy constructor leaves ownership untouched. Since children are copied lazily during layout, this does not expose true value semantics. We should consider removing the copy constructor, too.
Reviewed By: SidharthGuglani
Differential Revision: D14241663
fbshipit-source-id: 39ffdb07f1028bfcf2710c0674a06cdebf3bd650
Summary:
Fixes#23459. It is not legal to write the character array of a std::string, and can result in undefined behavior.
[General] [Fixed] - Crash when substring intersects with emoji
Pull Request resolved: https://github.com/facebook/react-native/pull/23609
Differential Revision: D14198159
Pulled By: mdvacca
fbshipit-source-id: 71060b1b99ddab89793c98c09f99ec9974479e62
Summary:
Basing on discussion from this issue - https://github.com/react-native-community/discussions-and-proposals/issues/65 we moved ESLint/Prettier config to its own package inside packages directory.
At this moment we had to left all `eslint` dependencies in root `package.json` since `eslint-config-react-native` is not published yet.
[General] [Changed] - Move eslint/prettier config to packages/eslint-config-react-native
Pull Request resolved: https://github.com/facebook/react-native/pull/23688
Differential Revision: D14277068
Pulled By: cpojer
fbshipit-source-id: ef2d0b33210418318cc8324f15fedd84df0ef64d
Summary:
We use indent width with 2 spaces, but `RCTImageLoader` use 4 spaces, it's hard to code, code one line, adjust indent, or change Xcode's preference temporary. So let's prettier it.
[iOS] [Fixed] - Prettier Image loader code
Pull Request resolved: https://github.com/facebook/react-native/pull/23701
Differential Revision: D14278082
Pulled By: cpojer
fbshipit-source-id: 6e7db50741b0981f45622c19981cb5fd9bbc0a97
Summary:
The reason I change GIF image url is `tumblr` blocked in some countries, like China , Kazakhstan, Pakistan, Indonesia. (PS. I can only confirm China blocked it 😂 ), so can we change this to local image?
[iOS] [Fixed] - Make RNTester GIF example locate local file system image
Pull Request resolved: https://github.com/facebook/react-native/pull/23689
Differential Revision: D14275149
Pulled By: cpojer
fbshipit-source-id: c4141cdda40792e5d8bfa805ccc74279e2eef55a
Summary: Flesh out how surface will be used with a flag in ReactRootView
Reviewed By: mdvacca
Differential Revision: D14112897
fbshipit-source-id: adf6078048dbf83452d3523f0530a4d6dca7b3e8
Summary:
We set flags to true when setting margin, padding, border, position individually
Doing the same for batching API
Reviewed By: davidaurelio
Differential Revision: D14207550
fbshipit-source-id: ddfdcd5056bea0dd76bd6762f47e90370e26c9e1
Summary:
Added a new API `YGNodeSetLayoutStyleInputs` to pass layout style inputs from java to native code.
All the style inputs are passed in a float array in [key1, key2, value2, key3, value3a, value3b .....] format over JNI layer.
There are three types of style inputs
- do not need any value to be passed along with them like WidthAuto, HeightAuto
- need one value to be passed like Width, Height
- need two values to be passed like Margin, Padding (edge value and actual margin, padding value)
Reviewed By: davidaurelio
Differential Revision: D14166948
fbshipit-source-id: 4bea64d6a429959c3962c87e337914dcd99199fd
Summary:
We have now create a yoga node context which consists of weak reference to java yoga node object and flag which tells us whether margin, padding , border are set or not.
This flag was initially in java layer and we have moved this to native layer as it will help us with enabling the bacthing API for setting style inputs.
Reviewed By: davidaurelio
Differential Revision: D14243378
fbshipit-source-id: fed935ef18c1abf2b07e5d69d9ca79ced51699f2
Summary: We are now not setting flags when we set style inputs margin, padding, border and position on yoga node.
Reviewed By: davidaurelio
Differential Revision: D14224000
fbshipit-source-id: deef4c1ab1a60fbc4909183bc2aa59fa23939d43
Summary:
`Platform.isTesting` returns false when running SSTs. This diff changes that to true.
See https://our.intern.facebook.com/intern/qa/9690/how-to-detect-when-running-as-sst for inspiration.
I fixed this for iOS in D13981728.
Reviewed By: cpojer
Differential Revision: D14244606
fbshipit-source-id: ed95b772cc4206cf7c835aed7415aa5fc5fbdf7d
Summary:
@public
Previously open-sourced as `react-native-symbolicate`, this package is more closely coupled with Metro and should therefore be part of the latter.
Reviewed By: cpojer
Differential Revision: D14208031
fbshipit-source-id: 8bae2100149142394e12d499dc4b8a256f07647e
Summary: This new version uses paths relative to the `rootDir` option to compute cache keys, so it is compatible with remote caching.
Reviewed By: rickhanlonii
Differential Revision: D14241858
fbshipit-source-id: fbf244bbf389bf873fb8a42f35c9b023fb06182f
Summary:
@public
Moving logic from free C functions to the C++ layer.
This will allow us to get rid of the dangerous copy / move assignment operators of `YGNode`.
Reviewed By: SidharthGuglani
Differential Revision: D14241564
fbshipit-source-id: aae9f2a7ffd23bb839f1747e4a0694578bae86ae
Summary: Add assorted missing includes in `xplat` that would be exposed by future changes.
Reviewed By: ispeters, nlutsenko
Differential Revision: D14213660
fbshipit-source-id: 329f133784015fe20ee99feaec8ef05e117fe3a6
Summary:
This is a back-out of D14214844, we noticed that this regressed TTI for Marketplace You screen running in Fabric
Original commit changeset: b81005f2bf49
Reviewed By: JoshuaGross
Differential Revision: D14247897
fbshipit-source-id: de0cea92b437b2fbcd075f0d6a0066156800e3f0
Summary:
We have the wrong calculation of placeholder size currently, leads `contentSize` or some things inaccuracy.
[iOS] [Fixed] - Fixed wrong placeholder size calculation in multiline text input mode
Pull Request resolved: https://github.com/facebook/react-native/pull/23682
Differential Revision: D14255932
Pulled By: cpojer
fbshipit-source-id: a1f40e90fc2c848579694965da8316fae9e5c4c5
Summary:
Currently, we pick the max size of text view's contentSize and placeholder's size, actually, if placeholder is be hidden, we should only return text view's contentSize.
[iOS] [Fixed] - Fixed wrong contentSize calculation when placeholder is hidden in multiline text input
Pull Request resolved: https://github.com/facebook/react-native/pull/23683
Differential Revision: D14255915
Pulled By: cpojer
fbshipit-source-id: 198faa7e1c5657371eb920973345194aedf72e41
Summary:
If you try linking to a system URL scheme that isn't http or https such a tel, the linking promise will be rejected. I'm fixing this by relying on the output of `BOOL canOpen = [RCTSharedApplication() canOpenURL:URL];` to resolve the promise, but still falling back on the better error message if the given URL cannot be opened.
Changelog:
[iOS][fixed] - Allow linking to system URL schemes other than http or https
Reviewed By: cpojer
Differential Revision: D14250507
fbshipit-source-id: d74b2bd615eb6e320a39a956424e0ee34d476dab
Summary:
This is an effort to clean up the root of the repository. Everything related to Docker is being moved to the `.circleci` directory, as these images are used as part of the Circle CI 2.0 tests on Android.
[GENERAL] [Changed] - Moved Dockerfiles into .circleci directory
Pull Request resolved: https://github.com/facebook/react-native/pull/23677
Differential Revision: D14253735
Pulled By: cpojer
fbshipit-source-id: 4d482d531a71b8259b09c001b310d82ce5349b87
Summary:
Trivial PR. Cleaning up the CODEOWNERS file a bit.
[GENERAL] [Changed] - Clean up and annotate CODEOWNERS on GitHub
Pull Request resolved: https://github.com/facebook/react-native/pull/23678
Differential Revision: D14253726
Pulled By: cpojer
fbshipit-source-id: ffb47c18b7078b7489dadb352cdaa5ffea0d0aea
Summary:
1. Feature parity with Android, that already have this extensibility point on `build.gradle`:
https://github.com/facebook/react-native/blob/7c9805ce163c5a027da2b8458e87d9b582ba9ba6/react.gradle#L12
2. Helps with using react-native on a monorepo project (yarn workspaces) without having to use the no-hoist feature (e.g. in my case the `ENTRY_FILE` is on `root/packages/mobile/index.js` instead of `root/index.ios.js`)
[iOS] [Added] - Allow overriding ENTRY_FILE on react-native-xcode.sh script
Pull Request resolved: https://github.com/facebook/react-native/pull/23667
Differential Revision: D14247236
Pulled By: hramos
fbshipit-source-id: 2f678c65eb898fc04549ab738b62e5864d753afd
Summary: Small perf wins for both iOS and Android.
Reviewed By: PeteTheHeat
Differential Revision: D14237532
fbshipit-source-id: 2be114d36adfa6e8540cb8cbca5412782791d8ce
Summary:
@public
The cloning features of YogaNode don’t seem to be used. Let’s remove them.
Reviewed By: SidharthGuglani
Differential Revision: D14165624
fbshipit-source-id: 5b710964a4abf1b35f3bcc25b143ffc719a03cec
Summary: The changes allows to get the State object on mounting layer and initiate the updates.
Reviewed By: mdvacca
Differential Revision: D14217185
fbshipit-source-id: 370644e06e350932e93c39adbe46544b071c28b3
Summary:
In React Native there are several use cases where React State is not the only input that affects the component tree. E.g., in case of a <Modal> component, the screen size directly affects the layout of components inside modal; in the case of uncontrolled <TextInput> component, the text inside the input affects the layout of the surrounding components. `State` is a special (legit!) workaround for all those similar cases. Native part of React Native maintains a special shared object between all nodes of the same family and use that during cloning and commits.
See coming commits to know how to use that.
In the near future State will fully replace LocalData concept but for simplicity they both exist for now.
Reviewed By: mdvacca
Differential Revision: D14217184
fbshipit-source-id: 6e018c5b68208d662462013bce0f4e2733d2f673
Summary:
A couple of small changes:
1. `onEnqueue` was decoupled from `enqueueEvent` for easier and unified overiding in subclasses (other methods will call `onEnqueue` soon);
2. `flushEvents` was decoupled from `onBeat` (we will put more stuff into `onBeat` soon).
Reviewed By: mdvacca
Differential Revision: D14205769
fbshipit-source-id: 574c2b2caaa6432bc7782b2f3bc147fa1fb82bd3
Summary: `LayoutConstraints::clamp` clamps the provided `Size` between the `minimumSize` and `maximumSize` bounds of this `LayoutConstraints`.
Reviewed By: mdvacca
Differential Revision: D14205770
fbshipit-source-id: 4799608cead393451d334e47dd6906255699a1e8
Summary: Currently, trying to fetch "all" photos will loop and never complete. Now it appears to produce the expected results (acting like the "All Photos" smart library in Photos) and doesn't loop. Confirmed console log results, showing no loops: P60994983
Reviewed By: PeteTheHeat
Differential Revision: D14221545
fbshipit-source-id: 31381b1ba2c673fd210cb95f3b7d0f8ffc23ec3f
Summary:
The following stack is meant to fix all "unsatisfied peer dependencies" that I could find in xplat/js.
Starting from Yarn v2 such problems will become much more noticeable, as they currently behave in unpredictable ways that can include the peer dependency being satisfied by a random package from the dependency tree. The v2 will enforce well-defined relationships between packages.
In this case, RN was missing some dependency required by `babel-preset-fbjs` through peer dependencies.
Reviewed By: pvdz
Differential Revision: D14136856
fbshipit-source-id: 5a7eeee913ebfe63573353683c152ad5512a66e3
Summary:
Placeholder's font not consistent with text's font, it leads to cursor dislocation. We need to keep consistent between placeholder and text.
[iOS] [Fixed] - Fixed placeholder font not consistent with text's font when in multiline mode
Pull Request resolved: https://github.com/facebook/react-native/pull/23654
Differential Revision: D14226174
Pulled By: hramos
fbshipit-source-id: 7cfb3b73d8799d22d5cbbfe557df8de3f5fcf034
Summary:
We already only support `iOS9+`, so we can remove all compatible codes now.
[iOS] [Fixed] - Remove compatible system code for iOS8 and before
Pull Request resolved: https://github.com/facebook/react-native/pull/23656
Differential Revision: D14224986
Pulled By: hramos
fbshipit-source-id: cac9ffe6788dd3eaf4f4f5f2b219f325ba78e85f
Summary:
This diff removes ListView and SwipeableListView from React Native:
* Removes the code and all examples
* Removes the exports on `react-native-implementation` but leaves an error message in dev mode only
* Uses `deprecated-react-native-listview` for `ListView` and `deprecated-react-native-swipeable-listview` for `SwipeableListView`
Both ListView and SwipeableListView are now fully removed from React Native in open source and we will continue to use the deprecated packages internally.
Reviewed By: TheSavior
Differential Revision: D14181708
fbshipit-source-id: 5030c33791f998567de058fee934449c16fa1d54
Summary:
We assume `map` is the type of `Map`, but actually it's not, so we would get type error.
[iOS] [Fixed] - [RNTester] fix getter of result from Image query cache
Pull Request resolved: https://github.com/facebook/react-native/pull/23602
Differential Revision: D14221747
Pulled By: cpojer
fbshipit-source-id: 06cf08078a330e4d5731ad72010c87e9e69fcd7b
Summary: That's bummer that we have to do it, but it's actually reasonable. Files in `core` and `events` depend on each other creating circular dependencies and other similar hard problem.
Reviewed By: mdvacca
Differential Revision: D14195022
fbshipit-source-id: 96a44ae28631cc9ccd7d7de72a94526f9e0dd12a
Summary: Due to the way (initial) surface implementation plays with ReactRootView (RRV), the react tag from the UIManagerModule is now set on the surface container view rather than on RRV as it was historically done. RRV still caches the react tag but just doesn't use it as an id on the view so `RRV.getViewId()` no longer equals `RRV.getReactTag()`.
Reviewed By: mdvacca
Differential Revision: D14110104
fbshipit-source-id: 6dbcc41c85fd7a6c32c7250f68f4a84bed4e075a
Summary:
This diff changes the pre-allocation of Images update the props on the ImageViews during the creation of ShadowNodes instead of during rendering.
The purpose of this change is to optimize TTI.
Reviewed By: shergin
Differential Revision: D14214844
fbshipit-source-id: b81005f2bf494f62f421dc24846e1561e13b9a87
Summary:
iOS pretty much always immediately updates location with the last cached location. This leads to the getCurrentPosition() API often returning this stale location. This change adds filtering to keep waiting until CLLocationManager provides a location fix that passes the requirements for each pending request.
This is potentially breaking in that clients that rely upon getCurrentPosition being extremely fast may find that location fixes take longer than before. However in such cases they should relax their requirements for maximumAge and/or accuracy.
Reviewed By: mmmulani
Differential Revision: D13889626
fbshipit-source-id: f566314ed5968151dad0839b99e0d3c9a562af13
Summary:
Not super clean, but not terrible.
Unfortunately this still relies on the old Paper UIManager calling delegate methods to flush the operations queues. This will work for Marketplace You since Paper will be active, but we need to fix this, along with Animated Events which don't work at all yet.
Random aside: it seems like taps are less responsive in fabric vs. paper, at least on iOS. There is a sporadic delay between the touches event coming in nativly to the JS callback invoking the native module function to start the animation - this will need some debugging.
Reviewed By: shergin
Differential Revision: D14143331
fbshipit-source-id: 63a17eaafa1217d77a532a2716d9f886a96fae59
Summary: It's handy to have all in one file but it also make it hard/impossible to fight with circular dependencies, so I had to slit it.
Reviewed By: mdvacca
Differential Revision: D14188546
fbshipit-source-id: 20809f1ea227c6f8f32922ed5760226248b718e3
Summary:
The previous implementation of the method cloned the root node twice (one time at the very end of the method and one time at the end of loop body).
The new one does it once and a bit more readable.
Reviewed By: mdvacca
Differential Revision: D14187969
fbshipit-source-id: 9859deadd4b041ac115c37108188aab70200c75d
Summary:
RootShadowNode does not have ComponentDescriptor counterpart (because it cannot be created via UIManager) and we used to always clone it manually.
However, apparently, some algorithms (e.g. clone algorithm inside RootShadowNode, which is used by setNativeProps) require valid clone function associated with the node.
So, we implement it.
Reviewed By: JoshuaGross
Differential Revision: D14187762
fbshipit-source-id: a9b6b332a18583217ff0e4f9c15aea0ffb113ba2
Summary:
The ConcreteViewShadowNode was changed to be independend of actual amount of template arguments of ConcreteShadowNode.
We will use it soon.
Reviewed By: JoshuaGross
Differential Revision: D14187761
fbshipit-source-id: b4c8051e2ae3803932713b0c255492466e80d3bd
Summary:
The ScrollView component seems to have been written for a default touch up / touch down scrolling behavior. However, when using snapToInterval, this default behavior of adding PanResponders while the ScrollView is animating or has an active touch causes bugs with the PanResponder hijacking touches it is not supposed to hijack.
Pull Request resolved: https://github.com/facebook/react-native/pull/19110
Differential Revision: D14071342
Pulled By: hramos
fbshipit-source-id: ac285d9967dd6e2a347943b2455d4f986062ef62
Summary:
This mechanism is heavily abused inside of the react-native and inside of the various native modules.
The main problem is that people don't remove their listeners and as result, we have memory leaks.
Some modules like UIManager, NativeAnimatedModule have resources holding Activity context. Those modules are held through a pretty long chain of dependencies.
In order to allow GC to collect those listeners, I replaced the CopyOnWriteSet by WeakHashMap and synchronized access. It is not such a big deal in terms of performance as those listeners are not called/modified too frequently but this prevents hard to debug memory leaks.
Changelog:
----------
Help reviewers and the release process by writing your own changelog entry. When the change doesn't impact React Native developers, it may be ommitted from the changelog for brevity. See below for an example.
[Android] [Fixed] - ReactContext - lifecycle listeners don't cause the leaks even if not removed.
Pull Request resolved: https://github.com/facebook/react-native/pull/22318
Reviewed By: mdvacca
Differential Revision: D13106915
Pulled By: hramos
fbshipit-source-id: d506e5035a7f7bea1b57a6308fb5d9b5fcb277a7
Summary:
Signed-off-by: yukai <yk3372@gmail.com>
In some Android device such as Samsung S8, the ModalHostView's child view can't fill the screen.
before:

The JS ModalHostView can't fill the bottom, the area is device's navigation bar.
In class ModalHostShadowNode, follow code calculate is error:
`Point modalSize = ModalHostHelper.getModalHostSize(getThemedContext());`
This way not care the device's navigation bar, so the height is smaller than real.
For Samsung S8, real height is 2220 and modalSize.y is 2076.
Pull Request resolved: https://github.com/facebook/react-native/pull/18615
Differential Revision: D14206830
Pulled By: cpojer
fbshipit-source-id: abe35ce1ab253aa1472d2c798543b515218be445
Summary:
Currently, the final field mMainComponentName is used. This field is
initialized in the constructor of ReactActivityDelegate, and the
ReactActivityDelegate itself is initialized in the constructor of
ReactActivity. This means that the only way you can pass a main
component name to ReactActivityDelegate, is when your ReactActivity
subclass is constructed. At this point in the lifecycle of an
activity, the getIntent() value that the activity was initialized by
returns null, making it impossible to set the mainComponentName
dynamically based on data passed to the activity via an intent.
The mMainComponentName final field is also only used in onCreate of
the delegate, so it's not actually needed by the ReactActivityDelegate
at construction time. So the above limitation is not fundamental, it's
just a side effect of the API design.
By allowing subclasses of ReactActivityDelegate to implement a
getMainComponentName method, the subclass then has full control of how
to initialize the value. So an implementation of getMainComponentName
could be:
public String getMainComponentName() {
return getIntent().getStringExtra("reactMainComponentName");
}
This commit doesn't remove anything and only adds a new method, so it
should be fully backwards compatible.
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.
<!--
Required: Write your motivation here.
If this PR fixes an issue, type "Fixes #issueNumber" to automatically close the issue when the PR is merged.
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/19814
Differential Revision: D14206644
Pulled By: cpojer
fbshipit-source-id: 8532560f944362fe0cce263a7f9a503df8ae539f
Summary:
<!--
Required: Write your motivation here.
If this PR fixes an issue, type "Fixes #issueNumber" to automatically close the issue when the PR is merged.
-->
This PR resolves a warning `Implicit conversion loses floating-point precision: 'double' to 'CGFloat' (aka 'float')` when building not only this library **but also apps** for 32bit devices since it's declared in public header file.
Pull Request resolved: https://github.com/facebook/react-native/pull/19416
Differential Revision: D14206633
Pulled By: cpojer
fbshipit-source-id: a65a4774235fa7fb24fac2f9bf7e51ba2a027377
Summary:
Currently, if we has `defaultValue`, textAttributes like `letterSpacing` can works, but if textinput has not default text, when we typing the text, some attributes not applied.
[iOS] [Fixed] - Fix textAttributes not applied when typing text
Pull Request resolved: https://github.com/facebook/react-native/pull/23585
Differential Revision: D14206568
Pulled By: cpojer
fbshipit-source-id: 7db276d811684bf6e01f8d30287cca80095db87c
Summary:
Do not request interactive input when running on a CI
When I'm running the build on my CI server, many Terminal windows are remaining on the server because of the `read` command.
This PR prevent this behaviour when the `CI` environment variable is defined so that it doesn't alter the behaviour on local machines.
Pull Request resolved: https://github.com/facebook/react-native/pull/19663
Differential Revision: D14206458
Pulled By: cpojer
fbshipit-source-id: 476067ebebb07c6e708469fa8829a06e05c58200
Summary:
In iOS, seems we have no ways to check wether the cached item is from disk or memory, only `storagePolicy == NSURLCacheStorageAllowedInMemoryOnly ` we can think it's from memory. So we need to add a new result like `disk/memory`?
[iOS] [Added] - Add Image query cache result type
Pull Request resolved: https://github.com/facebook/react-native/pull/23608
Differential Revision: D14205902
Pulled By: cpojer
fbshipit-source-id: 29c253878b5c6776cd4776508e24c57e6bfa7dfa
Summary:
1. add role description for heading
2. add talkback navigation support for link and header
Fixes#22440
Pull Request resolved: https://github.com/facebook/react-native/pull/22447
Differential Revision: D14205822
Pulled By: cpojer
fbshipit-source-id: 86bfc3bfc851f3544b1962012abaf8d1a357a9d2
Summary: This diff changes the onMeasure method of the RootView to optimize the amount of times we call updateRootLayoutSpecs in Fabric
Reviewed By: shergin
Differential Revision: D14198155
fbshipit-source-id: ff2deee04540899c25d4e38b0bd93333f74c6ace
Summary: This diff adds a new metric in Fabric to measure time it takes to Fabric finish transaction in CPP
Reviewed By: shergin
Differential Revision: D14198153
fbshipit-source-id: 987d1db1ae669906192060cc9b9e077901da6787
Summary:
Inspired by [react-native-netinfo's config](https://github.com/react-native-community/react-native-netinfo/blob/master/.circleci/config.yml). Annotate each of the major sections in our Circle CI config to reduce friction when contributing to our open source test infrastructure.
I've also removed all single-use aliases. While the old layout improved readability when looking at a particular job, it also obscured the actual command being run, as well as introduced unnecessary friction (contributors would need to understand how aliases work, syntax is finicky).
I've also moved the oss sanity checks to the analysis job, as we don't want this test to block the checkout_code job from succeeding, which would block all other downstream jobs.
There should be no other material changes to the actual jobs.
[General] [Changed] - Updated open source test configuration
Pull Request resolved: https://github.com/facebook/react-native/pull/23606
Differential Revision: D14199783
Pulled By: hramos
fbshipit-source-id: 61072eec5c05b8731916a9d8f6bc09ae5191fbb5
Summary:
Add nullable annotations to BaseViewManager and ViewManager methods. This will improve Kotlin developer experience and help Android Studio to offer better autocomplete.
[Android] [Changed] - add nullable annotations to BaseViewManager and ViewManager methods. Might break ViewManagers in Kotlin.
Pull Request resolved: https://github.com/facebook/react-native/pull/23610
Differential Revision: D14198630
Pulled By: mdvacca
fbshipit-source-id: c596c88254e1d02f0af233a466f685200fac8917
Summary:
This commit fixes a bug introduced in a previous attempt (https://github.com/facebook/react-native/pull/23580) to address an issue where okhttp appended `charset=utf-8` to the Content-Type header when otherwise not specified.
In that commit, I converted all characters to UTF-8, however it should instead use an existing encoding when possible.
Related issues:
https://github.com/facebook/react-native/issues/8237#issuecomment-466304854
[Android][fixed] - Respect existing character set when specified in fetch() POST request
Pull Request resolved: https://github.com/facebook/react-native/pull/23603
Differential Revision: D14191750
Pulled By: hramos
fbshipit-source-id: 11c1bfd98ccd33cd8e54ea426285b7d2ce9c2d7c
Summary: "Critical" or "Fast" JNI methods are enticing by their name, but carry dangers that are not trivially visible.
Reviewed By: davidaurelio
Differential Revision: D14184560
fbshipit-source-id: 89ec70f53bb2cb89ff568d8b1fe222ede86c9824
Summary: This diff makes updateRootLayoutSpecs to run synchronously on any thread instead of schedulling this to run in the JS thread
Reviewed By: shergin
Differential Revision: D14142306
fbshipit-source-id: 746f9c51f13e6d987fd9bca35a7c502cc8622f7b
Summary:
* "rotate" is often used as shorthand for "rotateZ"
** Paper handles this here: diffusion/FBS/browse/master/xplat/js/react-native-github/React/Views/RCTConvert%2BTransform.m$89
* Sometimes react sends a string with units, e.g. "45deg", so we need to convert that to a Float.
** Paper handles this here: diffusion/FBS/browse/master/xplat/js/react-native-github/React/Views/RCTConvert%2BTransform.m$14-27
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D14154173
fbshipit-source-id: 53d7405f26c78bb470d46879309c9697d9985c1c
Summary:
This PR (https://github.com/facebook/react-native/pull/22546) broke single line text inputs. After inputting some text and tapping away, the text input reverts back to default text.
Revert solved the issue.
Reviewed By: cpojer
Differential Revision: D14185897
fbshipit-source-id: cc7f0f2ebfb0494062afbc628c4fe27ad27fb1c6
Summary:
@public
If `jni_YGNodeFree` is called while GC is running, the weak reference table lock is held by the GC, leading to deadlock.
Here, we revert the method to being a regular native method, solving that problem.
Reviewed By: SidharthGuglani
Differential Revision: D14184220
fbshipit-source-id: 2882fa10586617cea2df99550a7dd8885376d11e
Summary:
This is a fix for #5859, based on the feedback in #18587. Instead of using `didSetProps` it uses a setter. I will also note that setting to `nil` no longer works (crashes) so setting it to a blank string then back to the original works fine.
[iOS] [Fixed] - Toggling secureTextEntry correctly places cursor.
Pull Request resolved: https://github.com/facebook/react-native/pull/23524
Differential Revision: D14143028
Pulled By: cpojer
fbshipit-source-id: 5f3203d56b1329eb7359465f8ab50eb4f4fa5507
Summary:
Part of #22609. This brings the warning count down to 0 for the RNTester target, also adds a fancy new icon!
[General] [Fixed] - All RNTester warnings fixed
Pull Request resolved: https://github.com/facebook/react-native/pull/23584
Differential Revision: D14181197
Pulled By: cpojer
fbshipit-source-id: 4377a55cee6a2d87a7926f1c34663b8a070aef88
Summary:
Throw error warning when build Text module, we can add tvOS available check to remove error.
[iOS] [Fixed] - Fix build error warning of Text module
Pull Request resolved: https://github.com/facebook/react-native/pull/23586
Differential Revision: D14181198
Pulled By: cpojer
fbshipit-source-id: 6a62c831ba119ddcbc6effa0b24f22bd4588b982
Summary:
Before this commit, `fetch()` calls append `"charset=utf8"` to the `Content-Type` header on Android (and not on iOS). This is because of an implementation detail in the okhttp library. This means that you can make a call on the JavaScript side like:
```javascript
let body = JSON.stringify({ key: "value" });
let headers = {
"Content-Type": "application/json"
};
fetch("http://10.0.2.2:3000", { method: "POST", body, headers });
```
However the resulting request appends the utf8 character:
```
POST - 13:34:32:
content-type: application/json; charset=utf-8
content-length: 15
host: 10.0.2.2:3000
connection: Keep-Alive
accept-encoding: gzip
user-agent: okhttp/3.12.1
```
Passing byte array into the RequestBody avoids this, as recommended by a maintainer of okhttp:
https://github.com/square/okhttp/issues/2099#issuecomment-366757161
Related issues:
https://github.com/facebook/react-native/issues/8237
[Android][fixed] - Prevent fetch() POST requests on Android from appending `charset=utf-8` to `Content-Type` header.
Pull Request resolved: https://github.com/facebook/react-native/pull/23580
Differential Revision: D14180849
Pulled By: cpojer
fbshipit-source-id: b84cadf83361331a9f64d1ff5f2e6399a55527a6
Summary:
This adds the deprecated ListView package to xplat/js. I published this module in https://github.com/facebookarchive/react-native-deprecated-modules
The way it is published I tried to reduce duplication of dependencies as much as possible. With this diff and the changes in package.json, the bundle size should not regress (until the actually deprected ListView is included; and then it will be recovered once ListView is fully removed from React Native, which will happen within a short timeframe). The change to `react-clone-referenced-element` are non-breaking.
Reviewed By: TheSavior
Differential Revision: D14163988
fbshipit-source-id: 0fc2d1f33855a8b1a709f5316e68c734716ec049
Summary:
CameraRollView was the last remaining code in RN to use ListView, this refactor changes it to FlatList.
[General] [Fixed] - CameraRollView in RNTester uses FlatList instead of ListView
Pull Request resolved: https://github.com/facebook/react-native/pull/23517
Differential Revision: D14126509
Pulled By: cpojer
fbshipit-source-id: b2aa03758e7c56493fb5fc59a7a0fc452b98fbc3
Summary:
RN offers checkbox component on android: https://facebook.github.io/react-native/docs/checkbox.html
The Checkbox colors for checked and unchecked states cannot be controlled from JS at the moment; this PR adds support for that.
The essence of changing colors for the states is this:
```
ColorStateList cls = new ColorStateList(
new int[][] {
new int[] { -android.R.attr.state_checked }, // unchecked
new int[] { android.R.attr.state_checked } // checked
},
new int[] {
uncheckedColor,
checkedColor
}
);
checkBox.setSupportButtonTintList(cls);
```
Because of this, I did it so that both colors have to provided together in an object. This is similar to [switch](https://facebook.github.io/react-native/docs/switch#trackcolor)
Pull Request resolved: https://github.com/facebook/react-native/pull/18300
Differential Revision: D14180218
Pulled By: cpojer
fbshipit-source-id: 88a9d1faf061c0651e3e28950f697535b90fbfd4
Summary: [iOS] [Changed] - There seems to be a potential race condition during reloading that could cause "double registration" of modules. This should be mostly harmless, so downgrade to warning for the message instead of redboxing.
Reviewed By: cpojer
Differential Revision: D14179922
fbshipit-source-id: 5c16ac674f633a548353277d9f875544ed10ba9b
Summary:
Instead of using measure specs to set certain yoga properties on the root node (like max width, auto width, specific width), use yoga's calculateLayout(width, height) instead. The measure specs will be stored in the shadow node. This allows us to remove duplicated code that processes the measure specs and allows us to remove other logic like the enableLayoutCalculation() method.
This diff also removes MeasureSpecProvider. MeasureSpecProvider was originally introduced to pass previously measured view measure specs to the initial creation of the root shadow node, but it turns out that this is unnecessary. We can update the root layout specs from the root view instead.
Reviewed By: mdvacca
Differential Revision: D9729744
fbshipit-source-id: 79b0b27ca879758f5dc3fc7cc8a0d38856a6cc79
Summary:
`react-native-symbolicate` usage output claim to work with 4 arguments, though the code supports 3. Furthermore, `Symbolication.parseFileName` is getting a lineNumber argument instead of fileName. Described issues disable usage of sectioned source map symbolication, which was discussed in https://github.com/getsentry/sentry-cli/issues/408.
Duplicate of https://github.com/facebook/react-native/pull/23514 without modified commit history
[General] [Fixed] - enable symbolicate for sectioned/indexed/segmented source maps
Pull Request resolved: https://github.com/facebook/react-native/pull/23572
Differential Revision: D14179787
Pulled By: cpojer
fbshipit-source-id: 15f983c285fc6ac5570d01550fc939b975375bfa
Summary:
This PR implements the first part of [RFC0004: CocoaPods Support Improvements](https://github.com/react-native-community/discussions-and-proposals/blob/353d44f64957113409eb16f836e23dba396a6b46/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects.
The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are:
* `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies.
* The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`.
*Next steps (not in scope of this PR):*
- Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`.
- Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR)
[iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project
Pull Request resolved: https://github.com/facebook/react-native/pull/23559
Differential Revision: D14179326
Pulled By: cpojer
fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
Summary:
Clearing the android TextInput text programmatically (i.e. calling: this.textInputRef.clear()) does not clear the previously composing text, if enabled, causing inconveniences when such behaviour is desired (i.e. chat input box, where you constantly have to clear the input after sending a message). Instead, the currently observed behaviour is that, after a new text is entered (usually as soon as the first letter), the previously composing text reappears making the input unusable.
The effect is only observable on some devices, for example, we observed it on Samsung S6 devices using both Android 6 and 7, and several LG devices running Android 6.
This issue is only present when clearing the text; setting text to some other value does not produce the same effect.
<!--
Required: Write your motivation here.
If this PR fixes an issue, type "Fixes #issueNumber" to automatically close the issue when the PR is merged.
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/18859
Differential Revision: D14067144
Pulled By: hramos
fbshipit-source-id: 09f337edc026b83221f8a399749222cd75457ec7
Summary:
Our `ws` dependency is super outdated, and is [insecure](https://www.npmjs.com/advisories/550). It is used for the websocket example code in RNTester. This PR updates the dependency, and removes undefined console.logs.
[General] [Security] - Updates ws dependency to 6.4.1
Pull Request resolved: https://github.com/facebook/react-native/pull/23520
Differential Revision: D14147596
Pulled By: cpojer
fbshipit-source-id: a03041f613a84bf019d8d0a8c5028d6657b5d89a
Summary:
Part of #23561. Small refactor to use 1 marker for the different tests, as it doesn't matter where it is- so long as we can detect it.
[General] [Fixed] - turn on JS e2e tests
Pull Request resolved: https://github.com/facebook/react-native/pull/23571
Differential Revision: D14172069
Pulled By: hramos
fbshipit-source-id: cdde369a09d3528d05fec01d015613b3397714e6
Summary: Currently xcode fails profile builds since these variables are unused when asserts are disabled.
Reviewed By: PeteTheHeat
Differential Revision: D14160565
fbshipit-source-id: 997352dd148d23c28fa92d4171071c1abbb742f5
Summary: Trivial. If it compiles, it works.
Reviewed By: JoshuaGross
Differential Revision: D14146579
fbshipit-source-id: 6f6895d1634709a5bde012850c5df756171320ab
Summary:
@public
`setBaseLine` was the only place where we used a capitalised *L.* Fixed here.
Reviewed By: SidharthGuglani
Differential Revision: D14152320
fbshipit-source-id: abf54fe7d6088e03775968baa8421c4bf43d6a6e
Summary:
@public
Adds the ability to opt into avoiding global weak JNI refs via `YogaConfig`.
Note that only homogeneous trees are supported, i.e. **mixing weak-ref and non-weak-ref nodes will break!**
Not using JNI refs hopefully will help with avoiding JNI reference table overflows, and will help creating trees on multiple threads, as no lock has to be acquired at any time.
Reviewed By: SidharthGuglani
Differential Revision: D14151037
fbshipit-source-id: 56d94713d39aee080d54be4cb4cdf5e3eccb473a
Summary:
Fix two bugs with Location when not using ACCESS_FINE_LOCATION:
- If we request highAccuracy=false, because we don't have ACCESS_FINE_LOCATION, but we don't have access to the NETWORK_PROVIDER...then the code should not trigger a SecurityException because it fell-back to using GPS_PROVIDER (which we don't have permission for)
- If the device is pre-lollipop, and doesn't have a provider, we should detect this properly instead of letting the pre-lollipop code raise a SecurityException.
Unfortunately, SecurityExceptions cannot be caught by the calling JS code. But I am not fixing that one here, instead choosing to fix/obviate the SecurityExceptions altogether.
Pull Request resolved: https://github.com/facebook/react-native/pull/10291
Differential Revision: D4163659
Pulled By: cpojer
fbshipit-source-id: 18bb4ee7401bc4eac4fcc97341fc2b3a2a0957c9
Summary:
This does fix the issue, however, another, perhaps related issue persists, the dialog/modal occasionally uses what would be the height of the app in non-immersive mode, in immersive mode. Meaning that the background, what ever it is set as, does not use the full available height.
See https://stackoverflow.com/a/23207365 for more info.
Known Problems:
---------
* [Date/time picker](https://facebook.github.io/react-native/docs/datepickerandroid) still brings app out of immersive mode - The date/time picker dialog needs the same treatment (this MR) as `RN Modal` using a wrapper.
* Focusing on text input, which brings up keyboard, also brings app out of immersive mode. Sometimes temporarily, sometimes permanently - Needs investigating. I have tried [this](https://stackoverflow.com/a/25129542), unfortunately it doesn't work. **Workaround I'm using for this, is to call a native module method to re-apply immersive mode flags after `keyboardDidHide` on JS side.**
Changelog:
----------
[Android] [Fixed] - Dialog (RN Modal) brings app permanently out of immersive mode
Pull Request resolved: https://github.com/facebook/react-native/pull/21078
Differential Revision: D14163127
Pulled By: cpojer
fbshipit-source-id: e0b67c91fa81880b19438a939bca26c128309799
Summary:
When an image source is parsed via `RCTImageFromLocalAssetURL` there seem to be certain situations in which `imageName` is empty from `RCTBundlePathForURL`. Any call to `UIImage imageNamed` with a an empty parameter will throw an exception:
```
CUICatalog: Invalid asset name supplied: '(null)'
```
In my case, the asset URL was pointing to an image in the application sandbox rather than the `NSBundle`. In this case `UIImage imageNamed` was throwing before the call to `NSData dataWithContentsOfURL` below could correctly resolve the image.
This change simply skips the call to `UIImage imageNamed` if no `imageName` value is set.
Pull Request resolved: https://github.com/facebook/react-native/pull/20120
Differential Revision: D14163101
Pulled By: cpojer
fbshipit-source-id: ceec95c02bf21b739962ef5618947a5726ba0473
Summary:
Add an option to dev menu to change packager location on the fly on iOS (similar to Dev Settings in Android)
Pull Request resolved: https://github.com/facebook/react-native/pull/21970
Differential Revision: D14162776
Pulled By: cpojer
fbshipit-source-id: 3cca4f4fbd8c599bd5342ba1ae64905a03270d48
Summary:
As part of #23561 this is an attempt at fixing iOS.
[iOS] [Fixed] - e2e test
Pull Request resolved: https://github.com/facebook/react-native/pull/23566
Differential Revision: D14162780
Pulled By: cpojer
fbshipit-source-id: b55d32e30f88370100f7fbddf9dfb208280844f4
Summary:
When making use of the network inspector on a react-native app, it can be quite annoying that as new requests come in the network inspector instantly sticks to the bottom.
This PR makes this logic smarter by allowing the user to be scrolled away from the bottom by two rows to override this automatic scrolling to the bottom logic.
Pull Request resolved: https://github.com/facebook/react-native/pull/21952
Differential Revision: D14162762
Pulled By: cpojer
fbshipit-source-id: ad49858509dd74a817ebabab54fdacc99773bf22
Summary:
Native Android sets the EditText widget to multiline only if the InputType flags are set to Text (or its variants like textEmailAddress) and Multiline, which causes the React Native TextInput to not break the line when set to multiline={true} and keyboardType={'numeric'} as it only have the flags Multiline and Number set.
This fix forces the widget to enable multiline, by calling setSingleLine(false) everytime a state change needs to be commited and the multiline prop is set to true.
Pull Request resolved: https://github.com/facebook/react-native/pull/21884
Differential Revision: D14162701
Pulled By: cpojer
fbshipit-source-id: b7d3fc8c5a4444dcfd29ad74d515a8ae486c7ede
Summary:
Fix scrollview `offset` out of content size in iOS, Android uses `scrollTo` and `smoothScrollTo` which not have this issue.
Fixes like #13594#22768#19970 .
[iOS] [Fixed] - Fixed scrollView offset out of content size.
Pull Request resolved: https://github.com/facebook/react-native/pull/23427
Differential Revision: D14162663
Pulled By: cpojer
fbshipit-source-id: a95371c8d703b6d5f604af0072f86c01c2018f4a
Summary:
Fixes#23500 , if user set prop `contentInsetAdjustmentBehavior="automatic"` of ScrollView, it not works when initial on the screen. We fixes it by filter valid offset, if offset is valid, just return.
[iOS] [Fixed] - Fixed ScrollView adjust inset behavior
Pull Request resolved: https://github.com/facebook/react-native/pull/23555
Differential Revision: D14161593
Pulled By: cpojer
fbshipit-source-id: 01434e55106ffde7f8e39f66dd5b0f02df9b38b1
Summary:
I downgrade the invalid bridge warning because I believe that it is a pain that every time that the JS gets refreshed this warnings are being thrown. If the project increase size and more and more NativeModules are added this warnings just spam the emulator or the device.
I understand the reason of validating if the bridge is valid. However in case of invalidness nothing is done, just the warning is thrown. Hence, the reason of downgrading it to improve the development process.
The error message still exist and it will be in the logs. But it will not spam the development screen
[iOS] [Changed] - Downgrade the Invalid bridge warning message to a log
Pull Request resolved: https://github.com/facebook/react-native/pull/23557
Differential Revision: D14161290
Pulled By: cpojer
fbshipit-source-id: e5608a9b2db5625309fd18d133fe69a9013043f3
Summary:
As part of #22609, this fixes yet more warnings.
- Adding more __unused to params.
- Refactors `isPackagerRunning` to use NSURLSession.
- Turns off suspicious comma warnings
[iOS] [Fixed] - Xcode Warnings
Pull Request resolved: https://github.com/facebook/react-native/pull/23565
Differential Revision: D14161151
Pulled By: cpojer
fbshipit-source-id: 339874711eca718fc6151e84737ccc975225d736
Summary:
Do not run disabled tests, even when the commit / PR is pushed by hramos. See the existing functionality at https://circleci.com/gh/facebook/react-native/73844?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link:

There are a handful of tests that are known to be broken in Circle CI. This has been the case since at least Fall 2017, when we migrated to Circle 2.0. These tests haven't been fixed for several reasons, one of them being that once they were removed from the Circle CI config, the pressure to fix them has been lowered.
Last year, I added these disabled tests back to Circle CI, but used a script to prevent them from running unless the job was initiated by myself. This would allow us to get good signal from Circle CI without polluting results with known failing tests, while still showing me which tests needed some work before getting re-enabled again.
In practice, this functionality is introducing more friction as I work on fixing new CI failures: my own fixup PRs are marked as failing due to these "disabled tests" (see test_android on https://github.com/facebook/react-native/pull/23558). To ensure we don't lose track of these failures, I've created an umbrella issue at https://github.com/facebook/react-native/issues/23561.
Pull Request resolved: https://github.com/facebook/react-native/pull/23562
Differential Revision: D14161172
Pulled By: cpojer
fbshipit-source-id: 040500dcb433d3127c64a42b31f94af6bbaa6ed1
Summary:
From the git log, we added `__fbRequireBatchedBridge` in this commit https://github.com/facebook/react-native/commit/6dc3a83e88ed120decbeaed8e4e62dc2bb7107a3, I don't ensure wether I missed something, we actually don't define `__fbRequireBatchedBridge` on `JS` or `Native` side, so `__fbRequireBatchedBridge` getter operation itself would throw exception.
[General] [Fixed] - Remove __fbRequireBatchedBridge call when not get batchedBridge
Pull Request resolved: https://github.com/facebook/react-native/pull/23547
Differential Revision: D14160706
Pulled By: cpojer
fbshipit-source-id: df9180a9a16716a91369249333752316fb6648c5
Summary:
* Added a default value for HMRLoadingView this will prevent errors from being thrown when `HMRClient` attempts to include it in a `web` context.
* [Web] [Added] - HMRLoadingView
Pull Request resolved: https://github.com/facebook/react-native/pull/23389
Differential Revision: D14045475
Pulled By: cpojer
fbshipit-source-id: df5c3cf3536af3b37eaf82342b6346bc25054319
Summary: Let JS decide if a missing method should be treated as an error, or whether it allows optional methods (e.g. methods that are only for android or for ios).
Reviewed By: JoshuaGross
Differential Revision: D14155799
fbshipit-source-id: 1e298b46a59761cf09e98147da885b1e9a9a675a
Summary:
@public
Adds `YogaConfig#avoidGlobalJNIRefs` to control whether nodes created with a config will use weak global JNI refs. Used for experimentation.
Reviewed By: SidharthGuglani
Differential Revision: D14149982
fbshipit-source-id: c777c8b3af2167d96154db5aa6afec1476dac35b
Summary:
@public
Context-aware cloning functions are an internal Yoga feature that will be used for Yoga’s JNI code.
It will be possible to specify a context when calculating layout, which will be passed on to cloning functions. This will be a private feature.
Reviewed By: SidharthGuglani
Differential Revision: D14149470
fbshipit-source-id: 1d11106e65f9d872d10f191763da001f8d158a61
Summary:
@public
Limit child cloning to layout calculation. This also allows for mixing shared and owned children.
Rationale:
We do allow for shared children if the caller manages themselves. The single known use case is React Native.
So far, we have cloned children eagerly whenever child lists are mutated, or layout is run. This was to allow for a quick check of the owner of any first child, assuming that either *all* or *no* child of a node are shared.
For Yoga/Java, we want to get rid of global weak JNI refs, and these are also used to invoke clone callbacks. We can achieve that goal by switching to an alternative approach, passing additional data to the layout pass. This additional data has to be passed to any configured cloning callback. Therefore, it is desirable to **only call cloning functions during the layout pass.**
The obvious solution seems to be to not uphold the invariant of the first child determining shared/owned state of all siblings, and allow for a mix of shared and own children.
Reviewed By: shergin
Differential Revision: D14136223
fbshipit-source-id: 34490cfeeb2170c99d6ed1b9bdcbcedb316813af
Summary:
@public
Encapsulates node cloning within `YGConfig`.
This is necessary for allowing for context-aware cloning functions, which will ultimately allow for removal of weak global JNI references.
Reviewed By: shergin
Differential Revision: D14132608
fbshipit-source-id: 0dec114c8e172b1e34a4b7fd146c43f13c151ade
Summary:
This PR bumps gradle to 5.0, which includes Kotlin DSL 1.0, and android gradle plugin to 3.3.1, which includes includes various bug fixes and performance improvements. Also Gradle 5.x requires Java 8.
This is preparation for Kotlin DSL migration.
[Android] [Changed] - Bump Gradle to 5.0
Pull Request resolved: https://github.com/facebook/react-native/pull/23324
Reviewed By: mdvacca
Differential Revision: D14028563
Pulled By: hramos
fbshipit-source-id: 61fe1a2d4ea5707d6f07945acbd950f852420e13
Summary:
This PR reduces the number of warnings in React from 68 to 18. Mostly by marking unused variables. RNTester's warnings are more than halved.
[iOS] [Fixed] - Xcode warnings
Pull Request resolved: https://github.com/facebook/react-native/pull/23553
Differential Revision: D14151339
Pulled By: hramos
fbshipit-source-id: 8255330bf910a69a4c03051d91d7b0de3fadf2d1
Summary:
This is a re-submit of #23367, which was accidentally over-written in this commit:
https://github.com/facebook/react-native/commit/0d7faf6f73b942126e1f45016cde8fd480fd0164
This pull request makes this change to `jsi.h`:
* Tweak the call to constructor `Pointer(Runtime::PointerValue* ptr)` in the constructor for `PropNameID`. I am not sure why MSVC wasn't working with the original version, but it compiles after I tweak that.
[General] [Fixed] - Tweaked `jsi.h` to build on MSVC
Pull Request resolved: https://github.com/facebook/react-native/pull/23492
Differential Revision: D14151511
Pulled By: hramos
fbshipit-source-id: 52d726d7b978d321a0343566ee527f2ec25e93f8
Summary:
People in open source are now contributing to our symbolication code. They cannot figure out how to run buck for their tests so I instead converted them to Jest tests. See https://github.com/facebook/react-native/pull/23514 for an example contribution where people are struggling.
This PR:
* Changes the stdin reading mechanism to also work inside of a forked child process
* I manually verified that the previous BUCK tests were all passing after my modifications to the main script
* I rewrote each test using Jest
* I then switched the passing tests over to use snapshots
As a result, there are now a few fewer files and they all run inside of Jest. The code being tested is identical and keeps working.
Reviewed By: davidaurelio
Differential Revision: D14147615
fbshipit-source-id: 699044a579278f6451bb9d26a05712f00e4b7c04
Summary:
This is an updated version of #22579 which uses compile conditionals to prevent `use of undeclared identifier` errors when compiling on older versions of Xcode.
--------
Currently the only `textContentType` values that work are: `username`, `password`, `location`, `name` and `nickname`. This is due to the strings provided by React Native not matching up with the underlying string constants used in iOS (with the exception of the aforementioned types). Issue #22578 has more detail examples/explanation.
Pull Request resolved: https://github.com/facebook/react-native/pull/22611
Differential Revision: D13460949
Pulled By: cpojer
fbshipit-source-id: e6d1108422b850ebc3aea05693ed05118b77b5de
Summary:
iOS 9 introduced a whitelist for schemes that apps are allowed to open / check against, the current behavior of React Native is to simple return `NO` when a scheme is missing from that whitelist. It would be more helpful to throw an error with a suggested fix for the problem:
```
Unable to open URL: asos://checkout, add asos to LSApplicationQueriesSchemes in Info.plist.
```
[iOS] [Changed] - canOpenURL throws when custom scheme isn't in LSApplicationQueriesSchemes.
Pull Request resolved: https://github.com/facebook/react-native/pull/23535
Differential Revision: D14143005
Pulled By: cpojer
fbshipit-source-id: 4ead5f073690e627b4a4bbe3fa5a6cb5af46b589
Summary:
If we change the text attributes dynamically, for example, change the textColor, it not works in iOS, Android works fine.
[iOS] [fixed] - Fixed textInput appearance not update when text attributes changed
Pull Request resolved: https://github.com/facebook/react-native/pull/23533
Differential Revision: D14146700
Pulled By: cpojer
fbshipit-source-id: 4a7c84d6e7f818acb712242bea6484b177a775c6
Summary:
I found the TextInput can't control input length when default value's length > maxLength.
for example:
1.Set the value in special cases
```
<TextInput value={'12345678'} maxLength={6}/>
```
2.Quickly press the keyboard with multiple fingers
```
// RCTBaseTextInputView.m
……
if (_maxLength) {
NSUInteger allowedLength = _maxLength.integerValue - backedTextInputView.attributedText.string.length + range.length;
if (text.length > allowedLength) {
……
```
when value's length > maxLength,the allowedLength not a negative number.it was transformed into a big number,because it is type NSUInteger.so the `text.length > allowedLength` always false.
[iOS][Fixed] - fix the TextInput can't control input length when value's length > maxLength
Pull Request resolved: https://github.com/facebook/react-native/pull/23545
Differential Revision: D14146581
Pulled By: cpojer
fbshipit-source-id: f53b1312ae55fad9fc10430ab94784c1a9ad4723
Summary:
Sometimes images are slow to load, and they are quite heavy. This converts the ScrollViewExample to a list of simple text items, similar to the append example inside of it.
What it looks like: https://i.imgur.com/jt083Iv.png
[iOS] [Fixed] - Fix testScrollViewExample flakiness
Pull Request resolved: https://github.com/facebook/react-native/pull/23541
Differential Revision: D14142947
Pulled By: hramos
fbshipit-source-id: c897a4caa5374ef67e3d67306e3124c29b969565
Summary: If we don't group accessibility children, we can get into a state where the accessibility frame for our content lines up in such a way that VoiceOver doesn't know to scroll the scroll view, and instead jumps to the next piece of content (like the tab bar at the bottom)
Reviewed By: ikenwoo
Differential Revision: D14141532
fbshipit-source-id: 53b0971f494a39f0eba827e441a4cd9e08317663
Summary:
CALayer will crash if we pass NaN or Inf values.
It's unclear how to detect this case on cross-platform manner holistically, so we have to do it on the mounting layer as well.
NaN/Inf is a kinda valid result of some math operations. Even if we can (and should) detect (and report early) incorrect (NaN and Inf) values which come from JavaScript side, we sometimes cannot backtrace the sources of a calculation that produced an incorrect/useless result.
Besides that, I will investigate why the crash is actually happening, so we might need to fix something in layout engine. But, it general, we cannot capture all errors like that, so we need to have it here anyway.
Reviewed By: JoshuaGross, mmmulani
Differential Revision: D14126058
fbshipit-source-id: 807e5a223bdef48af9a3b7210803863431e8c507
Summary: This task fixes an AssertionError in EventDispatcher class, this is produced by a race condition.
Reviewed By: JoshuaGross
Differential Revision: D14134907
fbshipit-source-id: 7b670ee35e47c0d8a9f7f7b68a3b8f7193b7de54
Summary:
@public
Here, we extract an abstract class from `YogaNode`, in order to allow for experimentation with different implementations.
The reason for not choosing an interface is to keep ABI compatibility for `YogaNode.create()`.
Reviewed By: pasqualeanatriello
Differential Revision: D14044990
fbshipit-source-id: f8eb246338b55f34f0401198c0655abfcb7c9f37
Summary:
@public
Switches instance creation from `new YogaNode()` to `YogaNode.create()`.
This allows for experimentation with different implementations, while maintaining API + ABI compatibility internally at FB, as well as for dependent projects in open source and elsewhere.
Reviewed By: amir-shalem
Differential Revision: D14122975
fbshipit-source-id: f194b146b7cd693dba1a7dafdf92d350e54cb179
Summary: Use the new copyright header format used elsewhere in the React Native repository.
Reviewed By: shergin
Differential Revision: D14091706
fbshipit-source-id: b27b8e6bcdf2f3d9402886dbc6b68c305150b7d5
Summary:
@public
Context-aware print functions are an internal Yoga feature that will be used for Yoga’s JNI code.
It will be possible to specify a context when calculating layout, which will be passed on to baseline and measure functions. This will be a private feature.
Reviewed By: SidharthGuglani
Differential Revision: D14131098
fbshipit-source-id: 7a9da307274ceccba9f7debba581b70c1ebf2c98
Summary:
@public
Removes `YGNodeGetPrintFunc`, and encapsulates node printing within `YGNode`.
This is necessary for allowing for context-aware callback functions, which will ultimately allow for removal of weak global JNI references.
On a side node, the printing logic does not seem to be well thought through: print functions print as a side effect to whatever output they choose. Printing that uses callbacks is printing to different output streams or strings, though.
We need to consolidate Yoga debugging, and make it all more stringent.
Reviewed By: SidharthGuglani
Differential Revision: D14131024
fbshipit-source-id: 68704682dab3e7dfba61930bb03003d7d4723b80
Summary:
publc
Adds the ability to calculate layout with a context pointer set.
The context is passed through to measure and baseline functions of individual nodes.
This will be used to remove the necessity of holding weak global JNI references for each node.
Reviewed By: SidharthGuglani
Differential Revision: D14101426
fbshipit-source-id: 25047e1e44af48feb22ea686285d70803e8961bb
Summary:
@public
Context-aware measure and baseline functions are an internal Yoga feature that will be used for Yoga’s JNI code.
It will be possible to specify a context when calculating layout, which will be passed on to baseline and measure functions. This will be a private feature.
Reviewed By: SidharthGuglani
Differential Revision: D14100509
fbshipit-source-id: acf4a030549b2e38d5ce0cd5dbe837864e5ffd81
Summary:
@public
Stricter encapsulation of baseline and measure callbacks withing `YGNode`.
Instead of invoking these callbacks directly (`node->getBaseline()(...)`), they are invoked via methods on `YGNode` (`node->baseline(...)`).
This change will allow us to add the concept of a *Layout Context,* where measure and baseline functions will be able to receive an additional `void *` argument if configured accordingly. This API will be used internally for Yoga’s JNI bindings, to avoid storing a weak JNI reference for each node, and avoid reference table overflows.
Changed API:
- `YGNodeGetMeasureFunc()` -> `YGNodeHasMeasureFunc()`
- `YGNodeGetBaselineFunc()` -> `YGNodeHasBaselineFunc()`
- `YGNode::getMeasure()` -> `YGNode::hasMeasureFunc()` + `YGNode::measure()`
- `YGNpde::getBaseline()` -> `YGNode::hasBaselineFunc()` + `YGNode::baseline()`
Reviewed By: SidharthGuglani
Differential Revision: D14099550
fbshipit-source-id: 2653ab36acc252a9747986bc88d21dac22d8c91b
Summary:
@public
Context-aware logging functions are an internal Yoga feature that will be used for Yoga’s JNI code.
It will be possible to specify a context when calculating layout, which will be passed on to baseline and measure functions. This will be a private feature.
Reviewed By: SidharthGuglani
Differential Revision: D14123482
fbshipit-source-id: 8ba3b6c493bf79fe09831f22d2b6da44f09e3d95
Summary:
@public
Stricter encapsulation of logging callbacks within `YGConfig`.
Instead of invoking the logging callback directly (`node->logger(...)`), callers now have to go through `YGConfig::log()`.
This change will allow us to add the concept of a *Layout Context,* where logging functions will be able to receive an additional `void *` argument if configured accordingly. This API will be used internally for Yoga’s JNI bindings, to avoid storing a weak JNI reference for each node, and avoid reference table overflows.
Changed API:
- `YGConfig::logger()` -> `YGConfig::log()`
Reviewed By: SidharthGuglani
Differential Revision: D14123483
fbshipit-source-id: 87b8bb7de0e4346b6a41e57a70ac4eb8d79b24af
Summary:
@public
Makes logging implementation internal to Yoga.
Breaking changes: removed `YGLog` and `YGLogWithConfig`.
The upcoming changes to the JNI layer (removal of weak global refs for each node) requires adding additional parameters to the logging functions that will only be available when calculating layout.
Reviewed By: SidharthGuglani
Differential Revision: D14123390
fbshipit-source-id: 468e4a240c190342868ffbb5f8beb92324cdfdd6
Summary:
I checked the documentation over at https://facebook.github.io/react-native/docs/permissionsandroid and the documented properties `buttonPositive`, `buttonNegative` and `buttonNeutral` are not available in the flow-type definitions.
___
Also the Rationale type is not exported which makes it hard to reuse it in a library or in your own application code.
However I do not know if it is actually intended to import "internal" flow-types from `react-native` since I could not find any other type or interface being exported. So I am not 100% sure if I should have done this.
[General] [Added] - Export Rationale flow-type and add missing properties `buttonPositive`, `buttonNegative` and `buttonNeutral` to the documentation.
Pull Request resolved: https://github.com/facebook/react-native/pull/23510
Differential Revision: D14123848
Pulled By: cpojer
fbshipit-source-id: 4040590932db645da6422d680246fed1d46dbe79
Summary:
Part of Lean Core #23313
Removes `SnapshotViewIOS` from the public RN interface.
I think there's a wider discussion to be had here about whether `RCTTest` should be part of the public distribution or at least whether this should be split into a separate utils package. It's mainly used by the RNTester app. It seems to be little known about but there are [some references to it online](https://blog.callstack.io/testing-your-react-native-apps-abfe41903dfd).
[iOS] [Removed] - `SnapshotViewIOS` is no longer publicly exported from RN
Pull Request resolved: https://github.com/facebook/react-native/pull/23497
Differential Revision: D14123280
Pulled By: cpojer
fbshipit-source-id: badaf6cb5d2195268f0f8b429fc11d6525747708
Summary:
Adds a factory method to `YogaNode`.
While this is purely redundant at the moment, it will allow experimentation in follow-up diffs. We will have concrete implementations deriving from `YogaNode` (which will be abstract).
Going through `YogaNode.create()` means that we can maintain ABI compatibility.
Reviewed By: amir-shalem
Differential Revision: D14122974
fbshipit-source-id: 15d92f296d91cc8bbd79a196f370d2dbb69b3f92
Summary:
SYSTEM_ALERT_WINDOW permission is used only for debug builds to show draw overlay views or show warnings/errors. This permissions is unused in release builds, and there is an issue regarding removing unused permissions on Android build https://github.com/facebook/react-native/issues/5886#issuecomment-464495388. This PR removes SYSTEM_ALERT_WINDOW from all builds bug debug.
[Android] [Changed] - SYSTEM_ALERT_WINDOW permissions available only in debug builds
Pull Request resolved: https://github.com/facebook/react-native/pull/23504
Differential Revision: D14123045
Pulled By: cpojer
fbshipit-source-id: 68829a774ff23c7cb2721076a9d3870405f48fea
Summary:
add `clang-format` toolchain. we have 2558 files need to process in current task.
cc cpojer empyrical shergin matthargett
Pull Request resolved: https://github.com/facebook/react-native/pull/23434
Differential Revision: D14067789
Pulled By: cpojer
fbshipit-source-id: ddf812fc9579068ebb850bacedde6675376f18b7
Summary:
1. We expose the `initialAppState` for Android in #19935, so we can remove the fallback check for Android.
2. Rename `RCTCurrentAppBackgroundState` to `RCTCurrentAppState`, it's a private file function, so it's safe to rename, `RCTCurrentAppState` is more suitable because we actually get app state, not app background state.
[Android] [Enhancement] - Remove android `initialAppState` fallback check.
Pull Request resolved: https://github.com/facebook/react-native/pull/23487
Differential Revision: D14121293
Pulled By: cpojer
fbshipit-source-id: fec196cef2969fe6f6f1571f4ebcafcec26266a1
Summary:
In API 26, autofill framework was introduced in Android.
Read more about Autofill at https://developer.android.com/guide/topics/text/autofill.
Now, if in case for some text input if developer wants to disable
autofill then he can take help from this `importantForAutoFill` prop
and pass `no` to it.
Also important of auto fill can be configured with this prop, like:
* `auto`: Let the Android System use its heuristics to determine if the view is important for autofill.
* `no`: This view isn't important for autofill.
* `noExcludeDescendants`: This view and its children aren't important for autofill.
* `yes`: This view is important for autofill.
* `yesExcludeDescendants`: This view is important for autofill, but its children aren't important for autofill.
Default value if `auto`.
Read more at: https://developer.android.com/guide/topics/text/autofill-optimize
Changelog:
----------
[Android] [Added] - Add prop to configure `importantForAutofill` in `TextInput`.
Pull Request resolved: https://github.com/facebook/react-native/pull/22763
Differential Revision: D14121242
Pulled By: cpojer
fbshipit-source-id: aa4360480dd19f6dde66f0409d26a41a6a318c94
Summary: This diff implements equality for ReadableNativeMap, the underlying implementation relies on the method HashMap.equals()
Reviewed By: kathryngray
Differential Revision: D14019065
fbshipit-source-id: aeaec22ce1066241ed85f0527f5cd804e3c763dd
Summary: This diff implements equality on RedableNativeArray objects. This relies on the Arrays.deepEquals method
Reviewed By: kathryngray
Differential Revision: D14022108
fbshipit-source-id: 48b59529a9060a2bddba5fc8e3681c922ec31be4
Summary: This allows using this annotation when Buck has `java.abi_generation_mode = source_only` set.
Differential Revision: D14119311
fbshipit-source-id: 020e709924e70adb8a160069a1da9b209b99befa
Summary: The hacks we added for lazy viewmanagers don't really apply to TurboModule lookup system, so let's enable lazy lookup as needed only if TurboModule is enabled.
Reviewed By: PeteTheHeat
Differential Revision: D14116548
fbshipit-source-id: 701e963ef0593cd890198725f8cb6d0d29434cd9
Summary:
Some modules may have args with types stricter than just `NSDictionary`. For now, allow these modules to manually define a __turbo__* variant of the same method that receives basic NSDictionary/NSArray typed args. That helper method can do the conversion to the stricter type as necessary. This is only needed during migration phase of TurboModule.
Without this workaround, existing methods may get unrecognized selector errors.
Reviewed By: PeteTheHeat
Differential Revision: D14115981
fbshipit-source-id: ca7fcf497490ef9cce14c3d3444991c50d3cb550
Summary:
Context: https://fb.workplace.com/groups/735885229793428/permalink/2329819300400005/
A large number of RN SSTs (https://fburl.com/screenshot_tests/itlks3mn) stopped working last week. Turns out I silently broke them with D13981728.
The issue is that SSTs were being run with `RCTRunningInTestEnvironment == false`. When D13981728 changed that, borders began drawing from a different code path (this diff). Somehow, using the graphics context to draw borders breaks https://fburl.com/pcce4y0h in SSTs.
Going forward, it doesn't make any sense to me why borders should be drawn any differently when testing.
Reviewed By: sahrens
Differential Revision: D14109654
fbshipit-source-id: b8a5c01b923c93c32a8fa8954a850070f55764bc
Summary:
There's a very old issue with reload logic: invalidation and resetting up of the bridge could be racing. In this case, we hit a redbox when:
* Chrome debugger is enabled in previous app run, then we launch the app again
* The bridge starts, then immediately reloads itself to connect to Chrome
* On the 2nd setup, the logic to update the green loading bar, with the % indicator for loading off metro, failed to find the DevLoadingView module instance because the bridge is in the middle of invalidating
See https://github.com/facebook/react-native/issues/23235
To test:
Using react-native init from github, do the steps in https://github.com/facebook/react-native/issues/23235, no more redbox. Note that the loading indicator % won't be proper still, but at least it doesn't crash/redbox.
Reviewed By: JoshuaGross
Differential Revision: D14110814
fbshipit-source-id: 835061e50acc6968bffbcc2ddfbe8da79a100df9
Summary:
TL;DR: Setting `autoComplete` will allow the system to suggest autofill options for the `<TextInput>` component.
Android Oreo introduced the AutoFill Framework, for secure communication between an app and autofill services (e.g. Password managers). When using `<TextInput>` on Android Oreo+, the system already tries to autofill (based on heuristics), but there is no way to set configuring options or disable.
The quick solution would be to just add the same Android attributes (`autofillHints` & `importantForAutofill`) in React Native TextInput, but that doesn't bond well with the cross-platform nature of the library.
Introduces an `autoComplete` prop based on HTML's `autocomplete` attribute, mapping to Android `autofillHints` & `importantForAutofill` and serving as a proper placeholder for autofill/autocomplete in other platforms:
Also gives you the ability to disable autofill by setting autocomplete="off".
Pull Request resolved: https://github.com/facebook/react-native/pull/21575
Differential Revision: D14102949
Pulled By: hramos
fbshipit-source-id: 7601aeaca0332a1f3ce8da8020dba037b700853a
Summary:
React native is missing a keyboard type for iOS so I included support for it. So it can be used in react native app
https://developer.apple.com/documentation/uikit/uikeyboardtype/uikeyboardtypeasciicapablenumberpad
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.
If this PR fixes an issue, type "Fixes #issueNumber" to automatically close the issue when the PR is merged.
Pull Request resolved: https://github.com/facebook/react-native/pull/20597
Differential Revision: D14103498
Pulled By: cpojer
fbshipit-source-id: b0aa17f3e527734c6e90eadc73c96db4dd002698
Summary:
On UWP, when the app is executing a Background task, the OS can request it to cancel the task (for various reasons). If the app does not cancel its background task quickly, the OS might terminate the app.
This change adds support to cancel the headless task which can be used by native code to forward the cancellation request from the OS to the JS code.
Pull Request resolved: https://github.com/facebook/react-native/pull/20416
Differential Revision: D10052080
Pulled By: cpojer
fbshipit-source-id: 2c0322ebb45f7835739f68bdf82a7100d968c516
Summary:
Basically I want my cursor to be the same color of the text. Which means obviously that selecting the text will make it invisibible (ie, red text on red selection rectangle)
Today, setting a selection color does set a cursor color, which may be a good default in some cases, but we don't always couple these 2 colors together.
See original commit of janicduplessis https://github.com/facebook/react-native/commit/ae57b25134c4db8be8539a0f0e6e52d46c850339
I'd like to be able to set different colors for selection and cursor.
Pull Request resolved: https://github.com/facebook/react-native/pull/20276
Differential Revision: D14102952
Pulled By: cpojer
fbshipit-source-id: 652ff782044277a0c8a821dd628f0373659a7850
Summary:
Location updates are not working in background when user allows **When in use authorization**, but works when user allows **Always allow**.
In Geolocation/RCTLocationObserver.m, setAllowsBackgroundLocationUpdates are set only for **Always allow** case, but native iOS allows us to setAllowsBackgroundLocationUpdates even for **When in use authorization**.
Solution:
setAllowsBackgroundLocationUpdates is now set for both cases.
[iOS] [Fixed] RCTLocationObserver - Enable background location updates when NSLocationWhenInUseUsageDescription is set
Pull Request resolved: https://github.com/facebook/react-native/pull/20911
Differential Revision: D13891852
Pulled By: cpojer
fbshipit-source-id: 5aae8dc12a147e7bed688807f34466b0f5a69344
Summary: This will allow publishing the package to npm.
Reviewed By: davidaurelio
Differential Revision: D14083973
fbshipit-source-id: b5f68b87b82a3b6bc644727de403bd449ec17239
Summary: This moves the internal symbolication code out to open source so that people can look up source locations for stack traces in RAM bundles. Wix needs this, and there is no reason to keep this code internal.
Reviewed By: bthood
Differential Revision: D14083307
fbshipit-source-id: afd2435c1b549b04ae7a04340ceeac1c5e4c99f0
Summary:
Upgrade `jest-junit` to the latest version (breaking change between 5 and 6 was reverted). In particular, 6.2.0 removes the dependency on `jest-config` which pulls in `babel-core@6` etc.
I noticed this since `react-native` had `jest-junit` in `dependencies` until #23276. So not as big of an issue. Still a nice cleanup, I'd say
/cc palmerj3
Btw, any reason Jest is still at alpha?
[General] [Fixed] - upgrade `jest-junit` to avoid older jest dependencies
Pull Request resolved: https://github.com/facebook/react-native/pull/23476
Differential Revision: D14100133
Pulled By: cpojer
fbshipit-source-id: 79877261b7ea995ac1f4249a12a6980ec488f655
Summary:
Bump Android Plugin to 3.3.1, with many bug fixes and performance improvements. Split the change from https://github.com/facebook/react-native/pull/23324 to make cherry-pick easy to 0.59 branch.
[Android] [Changed] - bump Android Plugin to 3.3.1
Pull Request resolved: https://github.com/facebook/react-native/pull/23473
Differential Revision: D14099741
Pulled By: cpojer
fbshipit-source-id: 7491c49cd2467f1bb8776345bdda2ab9cea11c06
Summary:
Move react_native_config.xml so that it's available to all Android versions, and fixes https://github.com/facebook/react-native/issues/23445. It's my bad, I should've tested previous change on multiple versions of Android.
[Android] [Changed] - Fix network security
Pull Request resolved: https://github.com/facebook/react-native/pull/23470
Differential Revision: D14099612
Pulled By: cpojer
fbshipit-source-id: 15b5e5f575de8033bbfd524d9ad2aa0e22daa813
Summary:
This adds a new jsi API prepareJavaScript. This accepts the same
parameters as evaluateJavaScript() but does not evaluate anything; instead
it returns a new object PreparedJavaScript which can itself be evaluated,
via the new API evaluatePreparedJavaScript().
There is a new empty class PreparedJavaScript which may be subclassed by
each Runtime variant to store its particular prepared form.
Reviewed By: mhorowitz
Differential Revision: D10491585
fbshipit-source-id: 702b9e23f2ff03d71a8ab17efb7e154b16dd8e87
Summary:
This changes jsi::evaluateJavaScript() to accept a
const shared_ptr<Buffer> & instead of a unique_ptr<Buffer.
It is reasonable to want to pass the same buffer to evaluateJavaScript()
multiple times. This will also help unify the API with the upcoming
prepareJavaScript() API.
Because shared_ptr has a unique_ptr constructor, this is compatible with
all call sites.
Reviewed By: mhorowitz
Differential Revision: D14001664
fbshipit-source-id: b7a0b7ec578a3fd6a6272241d50067269d2b03e4
Summary:
This changes fix small perf problem in RCTImageManager (and layout!) saving (in my completly non-scientific tests) up to 2 ms.
Maybe that's not much, but it fires during layout (and ShadowNodeTree reconsiliation processes), so it has to be very performant.
Reviewed By: JoshuaGross
Differential Revision: D14072077
fbshipit-source-id: 0baa54584dc3ae6a5f43be13fd152b84801c8539
Summary:
`SharedFunction` implements a pattern of a shared callable object that contains the same executable inside. It's similar to `std::function` with one important difference: when the object is copied, the stored function (and captured values) are shared between instances (not copied).
`SharedFunction` can be stored inside `std::function` because it's callable.
It useful in some scenarios, such as:
* When captured by `std::function` arguments are not copyable;
* When we need to replace the content of the callable later on the go.
We will use it in the coming diffs.
Reviewed By: mdvacca
Differential Revision: D14072078
fbshipit-source-id: 9df4ad2d1b92394e2dfef5c283f35c7c0bd4b500
Summary: We want to use a Regex for potentially more complicated string warnings. This will allow ignoring dynamic rules that include ID fields for example.
Differential Revision: D14079118
fbshipit-source-id: aff01c6b6eedc77cd91638988700c093dcda0488
Summary: Java symbols are likely being stripped at compile-time, preventing Reflection from working properly in C++. Should fix T40449334.
Reviewed By: mdvacca
Differential Revision: D14070629
fbshipit-source-id: f180fa3294b66f660ab1568250c47432cbf0c774
Summary:
This PR fixes no existing issue. BouncyCastle library is used inside React-Native but the current version is not updated anymore and this version is subject to `CVE-2013-0169`
Current maven link : http://mvnrepository.com/artifact/org.bouncycastle/bcprov-jdk16/1.46 . The descrption says that this jar is for SDK 1.6 but no updated since 2011.
Proposed maven link : http://mvnrepository.com/artifact/org.bouncycastle/bcprov-jdk15on The description says that that jar is for SDK 1.5 to SDK 1.8 and latest release was done in January 2018.
Nop.
But there was a discussion about bouncy castle few years ago https://github.com/facebook/react-native/issues/2793
[GENERAL] [Changes] robolectric - Upgrade bouncycastle lib to fix CSV vulnerabilities
Pull Request resolved: https://github.com/facebook/react-native/pull/19074
Reviewed By: mmmulani
Differential Revision: D14068062
Pulled By: hramos
fbshipit-source-id: 24e63cab33c3e8b5a088b9a8843afdc23b43553d
Summary: This module has been deprecated for two years. There is `Vibration`, backed by the same native module, with cross platform support.
Reviewed By: rickhanlonii
Differential Revision: D14080979
fbshipit-source-id: 7bf60cfdca9517c6858b3c7f8a2b16eab0ce8e80
Summary: These modules have been deprecated for at least one release or more. By landing this diff now, they will be fully removed from 0.60 (to be released in ~April).
Reviewed By: rickhanlonii
Differential Revision: D14080869
fbshipit-source-id: cf39cc1782eec1dd09750d20b55c76f580320f4d
Summary:
There are couple of packages which are installed as dependency but are not directly used in the project. In this PR I have remove those packages from dependency from the package.json.
[General] [Removed] - Remove the unused packages from package.json
Pull Request resolved: https://github.com/facebook/react-native/pull/23428
Differential Revision: D14065342
Pulled By: cpojer
fbshipit-source-id: 48a423e51d47742dcf0c8a8b2ec43e6a0f2e94fd
Summary:
Lock the version will help us to test new dependency version like ndk or buck.
Pull Request resolved: https://github.com/facebook/react-native/pull/23424
Differential Revision: D14065171
Pulled By: cpojer
fbshipit-source-id: 954297ca7c69ff829a4522f34274ae8ab162b36b
Summary:
Sometimes, when we deal with ImageRequest and ImageResponseObserverCoordinator we subscribe for status (or access the coordinator) without owning an ImageRequest. In those cases, we have to retain the coordinator explicitly.
For those cases, ImageRequest now exposes `ImageResponseObserverCoordinator` as a `std::shared_ptr`.
Eg, concretely in the code, `completionBlock` and `progressBlock` copied a raw pointer to the observer inside which can lead to a crash when ImageRequest is being deallocated before we received an image data.
Reviewed By: JoshuaGross
Differential Revision: D14072079
fbshipit-source-id: e10120bc05bf685e288f7b3d69092714dcd91d43
Summary:
This diff refactors JNI methods used by the Binding.cpp class in order to use ReadableMap instead of ReadableNativeMap
This will be helpful to provide a different implementation of ReadableMap from C++
Reviewed By: shergin
Differential Revision: D14077762
fbshipit-source-id: 595b0c2d3a2d6070112257b65c1141a8af36f0e1
Summary:
This pull request implements some suggestions made in #23414, namely:
* Rename `ShadowNodeFragment::nullSharedProps()` (and family) to `ShadowNodeFragment::propsPlaceholder()`;
* Introduce similar functions for the rest of members (tag and rootTag);
Later pull requests to remove designated initializers from Fabric (for MSVC support) will use these
I'd like to do the rename of `rootTag` to `surfaceId` as well, but would make sense to do in a separate diff as that would result in a great deal of changes.
[General] [Changed] - Changed naming scheme of `ShadowNodeFragment` placeholders, and added placeholders for remaining members
Pull Request resolved: https://github.com/facebook/react-native/pull/23437
Reviewed By: mdvacca
Differential Revision: D14072007
Pulled By: shergin
fbshipit-source-id: d5bb10a82c16d45955f417a49b503f215c4bc521
Summary:
This pull request removes a constructor in `DebugStringConvertibleItem.h` that was causing this issue in MSVC:
```
DebugStringConvertibleItem.cpp(20): error C2600: 'facebook::react::DebugStringConvertibleItem::DebugStringConvertibleItem': cannot define a compiler-generated special member function (must be declared in the class first)
```
It was likely conflicting with the constructor that has default values for all of its arguments.
[General] [Fixed] - Fixed `DebugStringConvertibleItem` compilation on MSVC
Pull Request resolved: https://github.com/facebook/react-native/pull/23436
Reviewed By: shergin
Differential Revision: D14067760
Pulled By: mdvacca
fbshipit-source-id: 303cf9b3559932c3d06514a1f3a8739d0f6f9dc2
Summary:
https://our.intern.facebook.com/intern/sandcastle/job/18014398585083744
```
xplat/js/react-native-github/React/Views/ScrollView/RCTScrollViewManager.m:38:20: warning: 'UIScrollViewContentInsetAdjustmentBehavior' is only available on iOS 11.0 or newer [-Wunguarded-availability-new]
```
Reviewed By: mattrobmattrob
Differential Revision: D14076127
fbshipit-source-id: 4050131c4f5211757383069567a2cf5382979735
Summary: Apparently, I haven't modify all files in D14018903. Here is the last (I hope) chunk.
Reviewed By: JoshuaGross
Differential Revision: D14058288
fbshipit-source-id: b21950cdd1aa9aa55b0c72fac0f8b44e4a7d131c
Summary:
The current system would always end up falling back to `true` for release builds
Pull Request resolved: https://github.com/facebook/react-native/pull/18892
Differential Revision: D14069444
Pulled By: hramos
fbshipit-source-id: 16e32a366b3b2e252a98a967da827ba1ebaeff85
Summary:
Fixes#17989
Previously, `ImagePickerIOS.openCameraDialog` would not render a `Video` option when the camera screen opened. If you passed `ImagePickerIOS.openCameraDialog({ videoMode: true }, ...)` the app would crash with an error complaining about the proper mediaType(s) not being set (see issue: #17989 for full details).
This is a 2 line change that sets the mediaTypes properly, so now users can capture videos in addition to photos.
Pull Request resolved: https://github.com/facebook/react-native/pull/19170
Differential Revision: D14068078
Pulled By: hramos
fbshipit-source-id: d04a3d267ca83ea58e88c880a85ac34ddd4744c8
Summary:
This PR expands the code analysis script to allow for customizing the GitHub Review left by analysis-bot whenever it finds code-level issues.
Some, but not all, `eslint` errors are fixable by running `yarn lint --fix`. When the `eslint` converter finds warnings or errors, the bot will suggest running the command as part of the review.
The script could be adjusted to only suggest this when `eslint` returns a non-zero `fixableErrorCount` or `fixableWarningCount`, but I think this is a good first step to get people to unblock themselves when they see this type of review from the bot.
I've also excluded `bots/` and `scripts/` from eslint as these have several `eslint` errors that need to be addressed. These directories do not contain core RN code, so they can be excluded for now.
[GENERAL] [Changed] - analysis-bot will suggest fixing eslint warnings on code reviews
Pull Request resolved: https://github.com/facebook/react-native/pull/23413
Differential Revision: D14065757
Pulled By: cpojer
fbshipit-source-id: cc588643f7ddb3c4631d89c26b799f7a7244e616
Summary:
This PR is trying to improve Android Network Security configuration introduced in https://github.com/facebook/react-native/commit/84572c4051f11f68ddf0928d2c3df5850ae15491. I found that Android merges all manifest files into a single manifest file when building an app, so this PR provides AndroidManifest.xml with network security config in debug folder, that will be used only for debug builds. Also the network security configuration will be applied to only app that target API 28. Moved security config file to xml-v28, so that it'll only visible to API 28 and above.
See https://developer.android.com/studio/build/manifest-merge
[Android] [Changed] - Android Network Security configuration.
Pull Request resolved: https://github.com/facebook/react-native/pull/23429
Differential Revision: D14065124
Pulled By: cpojer
fbshipit-source-id: 0f5ac5addbe968ed7e5cb57f356e2572de2690a8
Summary:
node 8 image has yarn too. Also the official one has the latest yarn.
Pull Request resolved: https://github.com/facebook/react-native/pull/23425
Differential Revision: D14065105
Pulled By: cpojer
fbshipit-source-id: 4eb3347fc191d928091e984fe3e5887861ec8aa9
Summary:
Here are some leftovers from nullable annotations for native modules, discovered while developing native module in Kotlin. This will help improve Kotlin developer experience
[Android] [Changed] - Add Nonnull annotations to ReactPackage
Pull Request resolved: https://github.com/facebook/react-native/pull/23415
Differential Revision: D14064607
Pulled By: cpojer
fbshipit-source-id: af2ce1fc1911ee03c54b20a4fc3a6d1aba9267da
Summary:
The official node image bundled with yarn by default, and it has maintained by the official group so we can always get the latest version.
Pull Request resolved: https://github.com/facebook/react-native/pull/23423
Differential Revision: D14064773
Pulled By: cpojer
fbshipit-source-id: c24a2bc2d0dda7ae852b25c340ca0d149f4c196c
Summary:
Turn off translations in fbandroid to mitigate the parse time regression. Translate the remaining `xplat//` to `fbsource//xplat/` to do so
run_all_tests
Reviewed By: scottrice
Differential Revision: D14041085
fbshipit-source-id: 9d3bc493c6662c03c4028aaebfbec58d145e8c6b
Summary:
In the past, Alert and AlertIOS were separate modules and both were shipped on Android even though only Alert can be used there. We unified the two modules but it meant that the code for both was still shipped on both platforms.
This diff changes it so that platform specific code is gated in a `Platform.OS` block, which means that the unnecessary code per platform is being stripped out. I'm not looking to win a beauty contest with the code in this module - we have barely touched it in years and I don't think we will touch it anytime soon, so I just merged the sub-classes (which only had static methods anyway) directly into the main class. I'm aware I could make two separate files with platform extensions but that ends up being more code here and it seems straightforward enough to me.
Reviewed By: TheSavior
Differential Revision: D14057404
fbshipit-source-id: 1ae1d227a39d76de9779b3db62960cca46e9b75c
Summary: SizeMonitoringFrameLayout was used to set layout contraints on the root shadow node when the native view's size changes. Since then, we introduced ways for the root node to use proper layout contraints using the root view's measure specs, which provides more accurate constraints for the root node, so SizeMonitoringFrameLayout is no longer needed. This ends up making a lot of UIManagerModule's method signatures cleaner
Reviewed By: mdvacca
Differential Revision: D9565720
fbshipit-source-id: c569cd15991a09987cc01e89612dc9193ad99b45
Summary:
Fixes#22824#21945 , the bug comes from #21208 , it was to fix#11897. Now Let's constrain edge adjust only when view has corners.
[iOS] [Fixed] - Fix triangle views on iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/23402
Differential Revision: D14059192
Pulled By: hramos
fbshipit-source-id: be613bf056d3cc484f281f7ea3d08f251971700a
Summary:
'Switch that starts on should switch' appears to be flaky, as it has failed on seemingly unrelated commits, only to succeed on the next CI run. `Switch` is scheduled to be removed from the core repository anyway, so I'm removing this test to ensure we get a clear signal for the rest of the repository.
[GENERAL] [Changed] - Tests: Removed flaky Switch e2e test.
Pull Request resolved: https://github.com/facebook/react-native/pull/23410
Differential Revision: D14057068
Pulled By: cpojer
fbshipit-source-id: dc7bc74c3d23ec3856107fec4ee9fa388adce2e5
Summary:
Ensure that the current openExample (stored in AsyncStorage) exists in the module list.
It's possible for the example to be missing if a test was removed & previously open in RNTester OR when actively developing RNTester tests & switching between branches
[General] [Fixed] - Potential crash in RNTester when removing/developing test cases
Pull Request resolved: https://github.com/facebook/react-native/pull/23406
Differential Revision: D14055695
Pulled By: cpojer
fbshipit-source-id: 6cf00e097e934f7a342e7d210b6319e1cba142ca
Summary:
I'm trying to fix DialogModule crashes we have in production: #6228
In this PR I'm fixing the following problem:
The fragment manager methods should be called only from the foreground. Now dismissExisting is protected by the mIsForeground variable as well as showNewAlert method.
[ANDROID] [Fixed] DialogModule - Race condition in dialog module fixed.
Pull Request resolved: https://github.com/facebook/react-native/pull/19332
Reviewed By: mdvacca
Differential Revision: D13804542
Pulled By: hramos
fbshipit-source-id: 9d59c8eaad49e2d3f141e255467627d411ae8797
Summary:
There's a bug in the OSS Switch component where the track color value is reset to the default value when the switch is toggled. It looks like the Java class resets the track color value in `setOn` (which fires in a press event): https://fburl.com/vmugfzja but these values aren't actually initialized from JS - in Switch.js we only pass through the current track color: https://fburl.com/vytekd0o.
The React component already has an API for defining both true/false track colors. However, we should also make sure not to reset these values for people using the old API of `tintColor`/`onTintColor`, so I'm changing it to only reset the value when both of those props are null.
Reviewed By: mdvacca
Differential Revision: D14035007
fbshipit-source-id: 12d968076bd47d54deedbfc15b12ff3cd77e2fd0
Summary:
Some MP E2E tests started failing when I introduced AnimatedMock (D13811035) with this error:
> message: Timeout exception: Message: element located by locator {"id":"mp_your_items_tab_button"} is not visible
The test relied on the button to animate in, which AnimatedMock disabled. The fix is to complete animations instantly in AnimatedMock. This diff implements that for spring and timing.
Reviewed By: cpojer
Differential Revision: D14036172
fbshipit-source-id: 18a422ce8ef6de05ff9224c94214524511a76949
2019-02-12 10:40:23 -08:00
2010 changed files with 87671 additions and 54483 deletions
This is a high-level overview of the test configuration using Docker.
It explains how to run the tests locally.
## Docker Installation
It is required to have Docker running on your machine in order to build and run the tests in the Dockerfiles.
See <https://docs.docker.com/engine/installation/> for more information on how to install.
## Convenience Scripts
We have added a number of default run scripts to the `package.json` file to simplify building and running your tests.
### Configuring Docker Images
The following two scripts need to be run first before you can move on to testing:
-`yarn run docker-setup-android`: Pulls down the React Native Community Android image that serves as a base image when building the actual test image.
-`yarn run docker-build-android`: Builds a test image with the latest dependencies and React Native library code, including a compiled Android test app.
### Running Tests
Once the test image has been built, it can be used to run our Android tests.
-`yarn run test-android-run-unit` runs the unit tests, as defined in `scripts/run-android-docker-unit-tests.sh`.
-`yarn run test-android-run-e2e` runs the end to end tests, as defined in `scripts/run-ci-e2e-tests.sh`.
-`yarn run test-android-run-instrumentation` runs the instrumentation tests, as defined in `scripts/run-android-docker-instrumentation-tests.sh`.
#### Instrumentation Tests
The instrumentation test script accepts the following flags in order to customize the execution of the tests:
`--filter` - A regex that filters which instrumentation tests will be run. (Defaults to .*)
`--package` - Name of the java package containing the instrumentation tests (Defaults to com.facebook.react.tests)
`--path` - Path to the directory containing the instrumentation tests. (Defaults to ./ReactAndroid/src/androidTest/java/com/facebook/react/tests)
`--retries` - Number of times to retry a failed test before declaring a failure (Defaults to 2)
For example, if locally you only wanted to run the InitialPropsTestCase, you could do the following:
`yarn run test-android-run-instrumentation -- --filter="InitialPropsTestCase"`
## Detailed Android Setup
There are two Dockerfiles for use with the Android codebase.
The base image used to build `reactnativecommunity/react-native-android` is located in the https://github.com/react-native-community/docker-android GitHub repository.
It contains all the necessary prerequisites required to run the React Android tests.
It is separated out into a separate Dockerfile because these are dependencies that rarely change and also because it is quite a beastly image since it contains all the Android dependencies for running Android and the emulators (~9GB).
The good news is you should rarely have to build or pull down the base image!
All iterative code updates happen as part of the `Dockerfile.android` image build.
Lets break it down...
First, you'll need to pull the base image.
You can use `docker pull` to grab the latest version of the `reactnativecommunity/react-native-android` base image.
This is what you get when you run `yarn run docker-setup-android`.
This will take quite some time depending on your connection and you need to ensure you have ~10GB of free disk space.
Once you have downloaded the base image, the test image can be built using `docker build -t reactnativeci/android -f ./.circleci/Dockerfiles/Dockerfile.android .`. This is what `yarn run docker-build-android` does. Note that the `-t` flag is how you tell Docker what to name this image locally. You can then use `docker run -t reactnativeci/android` to run this image.
Now that you've built the test image, you can run unit tests using what you've learned so far:
```bash
docker run --cap-add=SYS_ADMIN -it reactnativeci/android bash .circleci/Dockerfiles/scripts/run-android-docker-unit-tests.sh
```
> Note: `--cap-add=SYS_ADMIN` flag is required for the `.circleci/Dockerfiles/scripts/run-android-docker-unit-tests.sh` and `.circleci/Dockerfiles/scripts/run-android-docker-instrumentation-tests.sh` in order to allow the remounting of `/dev/shm` as writeable so the `buck` build system may write temporary output to that location.
Every time you make any modifications to the codebase, including changes to the test scripts inside `.circleci/Dockerfiles/scripts`, you should re-run the `docker build ...` command in order for your updates to be included in your local docker test image.
For rapid iteration, it's useful to keep in mind that Docker can pass along arbitrary commands to an image.
For example, you can alternatively use Gradle in this manner:
```bash
docker run --cap-add=SYS_ADMIN -it reactnativeci/android ./gradlew RNTester:android:app:assembleRelease
"no-loop-func": 0, // disallow creation of functions within loops
"no-multi-str": 0, // disallow use of multiline strings
"no-native-reassign": 0, // disallow reassignments of native objects
"no-new": 1, // disallow use of new operator when not part of the assignment or comparison
"no-new-func": 2, // disallow use of new operator for Function object
"no-new-wrappers": 1, // disallows creating new instances of String,Number, and Boolean
"no-octal": 1, // disallow use of octal literals
"no-octal-escape": 1, // disallow use of octal escape sequences in string literals, such as var foo = "Copyright \251";
"no-proto": 1, // disallow usage of __proto__ property
"no-redeclare": 0, // disallow declaring the same variable more then once
"no-return-assign": 1, // disallow use of assignment in return statement
"no-script-url": 1, // disallow use of javascript: urls.
"no-self-compare": 1, // disallow comparisons where both sides are exactly the same (off by default)
"no-sequences": 1, // disallow use of comma operator
"no-unused-expressions": 0, // disallow usage of expressions in statement position
"no-void": 1, // disallow use of void operator (off by default)
"no-warning-comments": 0, // disallow usage of configurable warning terms in comments": 1, // e.g. TODO or FIXME (off by default)
"no-with": 1, // disallow use of the with statement
"radix": 1, // require use of the second argument for parseInt() (off by default)
"semi-spacing": 1, // require a space after a semi-colon
"vars-on-top": 0, // requires to declare all vars on top of their containing scope (off by default)
"wrap-iife": 0, // require immediate function invocation to be wrapped in parentheses (off by default)
"yoda": 1, // require or disallow Yoda conditions
// Variables
// These rules have to do with variable declarations.
"no-catch-shadow": 1, // disallow the catch clause parameter name being the same as a variable in the outer scope (off by default in the node environment)
"no-delete-var": 1, // disallow deletion of variables
"no-label-var": 1, // disallow labels that share a name with a variable
"no-shadow": 1, // disallow declaration of variables already declared in the outer scope
"no-shadow-restricted-names": 1, // disallow shadowing of names such as arguments
"no-undef": 2, // disallow use of undeclared variables unless mentioned in a /*global */ block
"no-undefined": 0, // disallow use of undefined variable (off by default)
"no-undef-init": 1, // disallow use of undefined when initializing variables
"no-unused-vars": [1, {"vars": "all", "args": "none", ignoreRestSiblings: true}], // disallow declaration of variables that are not used in the code
"no-use-before-define": 0, // disallow use of variables before they are defined
// Node.js
// These rules are specific to JavaScript running on Node.js.
"handle-callback-err": 1, // enforces error handling in callbacks (off by default) (on by default in the node environment)
"no-mixed-requires": 1, // disallow mixing regular variable and require declarations (off by default) (on by default in the node environment)
"no-new-require": 1, // disallow use of new operator with the require function (off by default) (on by default in the node environment)
"no-path-concat": 1, // disallow string concatenation with __dirname and __filename (off by default) (on by default in the node environment)
"no-process-exit": 0, // disallow process.exit() (on by default in the node environment)
"no-restricted-modules": 1, // restrict usage of specified node modules (off by default)
"no-sync": 0, // disallow use of synchronous methods (off by default)
// ESLint Comments Plugin
// The following rules are made available via `eslint-plugin-eslint-comments`
"eslint-comments/no-aggregating-enable": 1, // disallows eslint-enable comments for multiple eslint-disable comments
"eslint-comments/no-unlimited-disable": 1, // disallows eslint-disable comments without rule names
"eslint-comments/no-unused-disable": 1, // disallow disables that don't cover any errors
"eslint-comments/no-unused-enable": 1, // // disallow enables that don't enable anything or enable rules that weren't disabled
// Flow Plugin
// The following rules are made available via `eslint-plugin-flowtype`
// These rules are purely matters of style and are quite subjective.
"key-spacing": 0,
"keyword-spacing": 1, // enforce spacing before and after keywords
"jsx-quotes": [1, "prefer-double"], // enforces the usage of double quotes for all JSX attribute values which doesn’t contain a double quote
"comma-spacing": 0,
"no-multi-spaces": 0,
"brace-style": 0, // enforce one true brace style (off by default)
"camelcase": 0, // require camel case names
"consistent-this": 1, // enforces consistent naming when capturing the current execution context (off by default)
"eol-last": 1, // enforce newline at the end of file, with no multiple empty lines
"func-names": 0, // require function expressions to have a name (off by default)
"func-style": 0, // enforces use of function declarations or expressions (off by default)
"new-cap": 0, // require a capital letter for constructors
"new-parens": 1, // disallow the omission of parentheses when invoking a constructor with no arguments
"no-nested-ternary": 0, // disallow nested ternary expressions (off by default)
"no-array-constructor": 1, // disallow use of the Array constructor
"no-empty-character-class": 1, // disallow the use of empty character classes in regular expressions
"no-lonely-if": 0, // disallow if as the only statement in an else block (off by default)
"no-new-object": 1, // disallow use of the Object constructor
"no-spaced-func": 1, // disallow space between function identifier and application
"no-ternary": 0, // disallow the use of ternary operators (off by default)
"no-trailing-spaces": 1, // disallow trailing whitespace at the end of lines
"no-underscore-dangle": 0, // disallow dangling underscores in identifiers
"no-mixed-spaces-and-tabs": 1, // disallow mixed spaces and tabs for indentation
"quotes": [1, "single", "avoid-escape"], // specify whether double or single quotes should be used
"quote-props": 0, // require quotes around object literal property names (off by default)
"semi": 1, // require or disallow use of semicolons instead of ASI
"sort-vars": 0, // sort variables within the same declaration block (off by default)
"space-in-brackets": 0, // require or disallow spaces inside brackets (off by default)
"space-in-parens": 0, // require or disallow spaces inside parentheses (off by default)
"space-infix-ops": 1, // require spaces around operators
"space-unary-ops": [1, { "words": true, "nonwords": false }], // require or disallow spaces before/after unary operators (words on by default, nonwords off by default)
"max-nested-callbacks": 0, // specify the maximum depth callbacks can be nested (off by default)
"one-var": 0, // allow just one var statement per function (off by default)
"wrap-regex": 0, // require regex literals to be wrapped in parentheses (off by default)
// Legacy
// The following rules are included for compatibility with JSHint and JSLint. While the names of the rules may not match up with the JSHint/JSLint counterpart, the functionality is the same.
"max-depth": 0, // specify the maximum depth that blocks can be nested (off by default)
"max-len": 0, // specify the maximum length of a line in your program (off by default)
"max-params": 0, // limits the number of parameters that can be used in the function declaration. (off by default)
"max-statements": 0, // specify the maximum number of statement allowed in a function (off by default)
"no-bitwise": 1, // disallow use of bitwise operators (off by default)
"no-plusplus": 0, // disallow use of unary operators, ++ and -- (off by default)
// React Plugin
// The following rules are made available via `eslint-plugin-react`.
"react/display-name": 0,
"react/jsx-boolean-value": 0,
"react/jsx-no-comment-textnodes": 1,
"react/jsx-no-duplicate-props": 2,
"react/jsx-no-undef": 2,
"react/jsx-sort-props": 0,
"react/jsx-uses-react": 1,
"react/jsx-uses-vars": 1,
"react/no-did-mount-set-state": 1,
"react/no-did-update-set-state": 1,
"react/no-multi-comp": 0,
"react/no-string-refs": 1,
"react/no-unknown-property": 0,
"react/prop-types": 0,
"react/react-in-jsx-scope": 1,
"react/self-closing-comp": 1,
"react/wrap-multilines": 0,
// React-Hooks Plugin
// The following rules are made available via `eslint-plugin-react-hooks`
"react-hooks/rules-of-hooks": "error",
// React-Native Plugin
// The following rules are made available via `eslint-plugin-react-native`
"react-native/no-inline-styles": 1,
// Jest Plugin
// The following rules are made available via `eslint-plugin-jest`.
about:You want to report a reproducible bug or regression in React Native.
labels:"Type: Bug Report"
name:"🐛 Bug Report"
about:Report a reproducible bug or regression in React Native.
title:''
labels:'Bug'
---
## 🐛 Bug Report
<!--
A clear and concise description of what the bug is.
<!--
Please provide a clear and concise description of what the bug is.
Include screenshots if needed.
Please test using the latest React Native release to make sure your issue has not already been fixed: http://facebook.github.io/react-native/docs/upgrading.html
-->
## To Reproduce
<!--
Steps to reproduce the behavior.
React Native version:
<!--
Run `react-native info` in your terminal and copy the results here.
-->
## Expected Behavior
<!--
A clear and concise description of what you expected to happen.
## Steps To Reproduce
1.
2.
<!--
Issues without reproduction steps or code are likely to stall.
-->
## Code Example
<!--
Describe what you expected to happen:
Snack, code example, or link to a repository:
<!--
Please provide a Snack (https://snack.expo.io/), a link to a repository on GitHub, or
provide a minimal code example that reproduces the problem.
Here are some tips for providing a minimal example: https://stackoverflow.com/help/mcve.
Issues without a reproduction link are likely to stall.
-->
## Environment
<!--
Run `react-native info` in your terminal and copy the results here.
about:You need help writing your React Native app.
labels:"Type: Question"
name:"🤔 Questions and Help"
about:The issue tracker is not for questions. Please ask questions on https://stackoverflow.com/questions/tagged/react-native.
title:'Question:'
labels: 'Type:Question'
---
GitHub Issues in the `facebook/react-native` repository are used exclusively for tracking bugs in the React Native framework. Please do not submit support requests through GitHub.
🚨 The issue tracker is not for questions. 🚨
For questions or help, please see:
- The React Native help page: http://facebook.github.io/react-native/help
- The React Native channel in Reactiflux: https://discord.gg/0ZcbPKXt5bZjGY5n
- The react-native tag on Stack Overflow: http://stackoverflow.com/questions/tagged/react-native
As it happens, support requests that are created as issues are likely to be closed. We want to make sure you are able to find the help you seek. Please take a look at the following resources.
If you have a coding question related to React Native, it might be better suited for Stack Overflow. It's a great place to browse through frequent questions about using React Native, as well as ask for help with specific questions.
### Please note that this issue tracker is not a help forum and requests for help will be closed.
## Talk to other React Native developers
### https://www.reactiflux.com/
Reactiflux is an active community of React and React Native developers. If you are looking for immediate assistance or have a general question about React Native, the #react-native channel is a good place to start.
If you want to participate in casual discussions about the use of React Native, consider participating in one of the following forums:
If you'd like to discuss topics related to the future of React Native, or would like to propose a new feature or change before sending a pull request, please check out the discussions and proposals repo:
<!-- 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. -->
<!-- Help reviewers and the release process by writing your own changelog entry. See https://github.com/facebook/react-native/wiki/Changelog for an example. -->
Thanks for using React Native! If you need help with your React Native app, the right place to go depends on the type of help that you need.
## 🤔 I have a question or need help with my React Native app.
If you have a coding question related to React Native, it might be better suited for Stack Overflow. It's a great place to browse through [frequent questions about using React Native](https://stackoverflow.com/questions/tagged/react-native?sort=frequent&pageSize=15), as well as [ask for help with specific questions](https://stackoverflow.com/questions/tagged/react-native).
[Reactiflux](https://www.reactiflux.com/) is an active community of React and React Native developers. If you are looking for immediate assistance or have a general question about React Native, the #react-native channel is a good place to start.
## 📃 I found something that seems wrong in the documentation.
The React Native website is hosted on a [separate repository](https://github.com/facebook/react-native-website). If you want to report something that is wrong or missing from the documentation, [please open a new issue there](https://github.com/facebook/react-native-website/issues).
## 🐛 I found a bug in React Native.
If you want to report a reproducible bug or regression in the React Native library, you can [create a new issue](https://github.com/facebook/react-native/issues/new?labels=Type%3A+Bug+Report&template=bug_report.md). It's a good idea to look through [open issues](https://github.com/facebook/react-native/issues) before doing so, as someone else may have reported a similar issue.
## 🚀 I want to discuss the future of React Native.
If you'd like to discuss topics related to the future of React Native, please check out the [React Native Community Discussions and Proposals](https://github.com/react-native-community/discussions-and-proposals) repository.
## 💬 I want to talk to other React Native developers.
If you want to participate in casual discussions about the use of React Native, consider participating in one of the following forums:
# Comment to post when marking an issue as stale. Set to `false` to disable
markComment:>
Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs.
You may also label this issue as "For Discussion" or "Good first issue" and I will leave it open.
You may also label this issue as a "Discussion" or add it to the "Backlog" and I will leave it open.
Thank you for your contributions.
# Comment to post when closing a stale issue. Set to `false` to disable
We want to make contributing to this project as easy and transparent as possible. Read on to learn more about our development process and how to propose bug fixes and improvements. The [How to Contribute](https://facebook.github.io/react-native/docs/contributing.html) guide on the website goes into more detail for each of these areas.
Thank you for your interest in contributing to React Native! From commenting on and triaging issues, to reviewing and sending Pull Requests, all contributions are welcome. We aim to build a vibrant and inclusive [ecosystem of partners, core contributors, and community](ECOSYSTEM.md) that goes beyond the main React Native GitHub repository.
## Our Development Process
The [Open Source Guides](https://opensource.guide/) website has a collection of resources for individuals, communities, and companies who want to learn how to run and contribute to an open source project. Contributors and people new to open source alike will find the following guides especially useful:
Most changes from engineers at Facebook will sync to [GitHub](https://github.com/facebook/react-native) through a bridge with Facebook's internal source control. Changes from the community are handled through GitHub pull requests. Once a change made on GitHub is approved, it will first be imported into Facebook's internal source control. The change will eventually sync back to GitHub as a single commit once it has passed Facebook's internal tests.
* [How to Contribute to Open Source](https://opensource.guide/how-to-contribute/)
Please make sure the following is done when submitting a pull request:
### [Code of Conduct](https://code.fb.com/codeofconduct/)
1. Fork the repo and create your branch from `master`.
2. If you've added code that should be tested, add tests.
3. If you've changed APIs, update the documentation.
4. Ensure the test suite passes.
5. Make sure your code lints.
6. If you haven't already, complete the Contributor License Agreement ("CLA").
As a reminder, all contributors are expected to adhere to the [Code of Conduct](https://code.facebook.com/codeofconduct).
## Contributor License Agreement ("CLA")
## Ways to Contribute
In order to accept your pull request, we need you to submit a CLA. You only need to do this once to work on any of Facebook's open source projects.
If you are eager to start contributing code right away, we have a list of [good first issues](https://github.com/facebook/react-native/labels/good%20first%20issue) that contain bugs which have a relatively limited scope. As you gain more experience and demonstrate a commitment to evolving React Native, you may be granted issue management permissions in the repository.
Complete your CLA here: <https://code.facebook.com/cla>
There are other ways you can contribute without writing a single line of code. Here are a few things you can do to help out:
## Issues
1.**Replying and handling open issues.** We get a lot of issues every day, and some of them may lack necessary information. You can help out by guiding people through the process of filling out the issue template, asking for clarifying information, or pointing them to existing issues that match their description of the problem. We'll cover more about this process later, in [Handling Issues](http://github.com/facebook/react-native/wiki/Handling-Issues).
2.**Reviewing pull requests for the docs.** Reviewing [documentation updates](https://github.com/facebook/react-native-website/pulls) can be as simple as checking for spelling and grammar. If you encounter situations that can be explained better in the docs, click **Edit** at the top of most docs pages to get started with your own contribution.
3.**Help people write test plans.** Some pull requests sent to the main repository may lack a proper test plan. These help reviewers understand how the change was tested, and can speed up the time it takes for a contribution to be accepted.
We use GitHub issues to track public bugs. Please ensure your description is clear and has sufficientinstructions to be able to reproduce the issue.
Each of these tasks is highly impactful, and maintainers will greatly appreciate your help.
### Our Development Process
We use GitHub issues and pull requests to keep track of bug reports and contributions from the community. All changes from engineers at Facebook will sync to [GitHub](https://github.com/facebook/react-native) through a bridge with Facebook's internal source control. Changes from the community are handled through GitHub pull requests. Once a change made on GitHub is approved, it will first be imported into Facebook's internal source control and tested against Facebook's codebase. Once merged at Facebook, the change will eventually sync back to GitHub as a single commit once it has passed Facebook's internal tests.
You can learn more about the contribution process in the following documents:
We also have a thriving community of contributors who would be happy to help you get set up. You can reach out to us through [@ReactNative](http://twitter.com/reactnative) (the React Native team) and [@ReactNativeComm](http://twitter.com/reactnativecomm) (the React Native Community organization).
### Repositories
The main repository, <https://github.com/facebook/react-native>, contains the React Native framework itself and it is here where we keep track of bug reports and manage pull requests.
There are a few other repositories you might want to familiarize yourself with:
* **React Native website** which contains the source code for the website, including the documentation, located at <https://github.com/facebook/react-native-website>
* **Releases** are coordinated through the <https://github.com/react-native-community/react-native-releases> repository. This includes important documents such as the Changelog.
* **Discussions** about the future of React Native take place in the <https://github.com/react-native-community/discussions-and-proposals> repository.
* **High-quality plugins** for React Native can be found throughout the [React Native Community GitHub Organization](http://github.com/react-native-community/).
Browsing through these repositories should provide some insight into how the React Native open source project is managed.
## Handling Issues
We use GitHub issues to track bugs exclusively. You can report an issue by filing a [Bug Report](https://github.com/facebook/react-native/issues/new/choose). Watch this space for more details on how to get involved and triage issues.
### Security Bugs
Facebook has a [bounty program](https://www.facebook.com/whitehat/) for the safe disclosure of security bugs. In those cases, please go through the process outlined on that page and do not file a public issue.
## Coding Style
## Helping with Documentation
We use Prettier to format our JavaScript code. This saves you time and energy as you can let Prettier fix up any formatting issues automatically through its editor integrations, or by manually running `npm run prettier`. We also use a linter to catch styling issues that may exist in your code. You can check the status of your code styling by simply running `npm run lint`.
The React Native documentation is hosted as part of the React Native website repository at https://github.com/facebook/react-native-website. The website itself is located at <https://facebook.github.io/react-native> and it is built using [Docusaurus](https://docusaurus.io/). If there's anything you'd like to change in the docs, you can get started by clicking on the "Edit" button located on the upper right of most pages in the website.
However, there are still some styles that the linter cannot pick up, notably in Java or Objective-C code.
If you are adding new functionality or introducing a change in behavior, we will ask you to update the documentation to reflect your changes.
**Objective-C:**
### Contributing to the Blog
* Space after `@property` declarations
* Brackets on *every*`if`, on the *same* line
*`- method`, `@interface`, and `@implementation` brackets on the following line
* *Try* to keep it around 80 characters line length (sometimes it's just not possible...)
*`*` operator goes with the variable name (e.g. `NSObject *variableName;`)
The React Native blog is generated [from the Markdown sources for the blog](https://github.com/facebook/react-native-website/tree/master/website/blog).
**Java:**
Please open an issue in the https://github.com/facebook/react-native-website repository or tag us on [@ReactNative on Twitter](http://twitter.com/reactnative) and get the go-ahead from a maintainer before writing an article intended for the React Native blog. In most cases, you might want to share your article on your own blog or writing medium instead. It's worth asking, though, in case we find your article is a good fit for the blog.
* If a method call spans multiple lines closing bracket is on the same line as the last argument.
* If a method header doesn't fit on one line each argument goes on a separate line.
* 100 character line length
We recommend referring to the [CONTRIBUTING](https://github.com/facebook/react-native-website/blob/master/CONTRIBUTING.md) document for the `react-native-website` repository to learn more about contributing to the website in general.
## License
## Contributing Code
By contributing to React Native, you agree that your contributions will be licensed
under the LICENSE file in the root directory of this source tree.
Code-level contributions to React Native generally come in the form of [pull requests](https://help.github.com/en/articles/about-pull-requests). The process of proposing a change to React Native can be summarized as follows:
1. Fork the React Native repository and create your branch from `master`.
2. If you've added code that should be tested, add tests.
3. If you've changed APIs, update the documentation.
4. Ensure the test suite passes, either locally or on CI once you opened a pull request.
5. Make sure your code lints (for example via `yarn lint --fix`).
6. Push the changes to your fork.
7. Create a pull request to the React Native repository.
8. Review and address comments on your pull request.
1. A bot may comment with suggestions. Generally we ask you to resolve these first before a maintainer will review your code.
9. If you haven't already, complete the Contributor License Agreement ("CLA").
If all goes well, your pull request will be merged. If it is not merged, maintainers will do their best to explain the reason why.
### Step-by-step Guide
Whenever you are ready to contribute code, check out our [step-by-step guide to sending your first pull request](https://github.com/facebook/react-native/wiki/Pull-Requests#getting-ready-to-submit-your-first-pull-request), or read the [How to Contribute Code](https://github.com/facebook/react-native/wiki/How-to-Contribute) wiki for more details.
### Tests
Tests help us prevent regressions from being introduced to the codebase. The GitHub repository is continuously tested using Circle and Appveyor, the results of which are available through the Checks functionality on [commits](https://github.com/facebook/react-native/commits/master) and pull requests. You can learn more about running and writing tests in the [Tests wiki](http://github.com/facebook/react-native/wiki/Tests).
## Community Contributions
Contributions to React Native are not limited to GitHub. You can help others by sharing your experience using React Native, whether that is through blog posts, presenting talks at conferences, or simply sharing your thoughts on Twitter and tagging @ReactNative.
## Where to Get Help
As you work on React Native, it is natural that sooner or later you may require help. In addition to the resources listed in [SUPPORT](.github/SUPPORT.md), people interested in contributing may take advantage of the following:
* **Twitter**. The React Native team at Facebook has its own account at [@reactnative](https://twitter.com/reactnative), and the React Native Community uses [@reactnativecomm](https://twitter.com/reactnativecomm). If you feel stuck, or need help contributing, please do not hesitate to reach out.
* **Proposals Repository**. If you are considering working on a feature large in scope, consider [creating a proposal first](https://github.com/react-native-community/discussions-and-proposals). The community can help you figure out the right approach, and we'd be happy to help.
* **React Native Community Discord**. While we try to hold most discussions in public, sometimes it can be beneficial to have conversations in real time with other contributors. People who have demonstrated a commitment to moving React Native forward through sustained contributions to the project may eventually be invited to join the React Native Community Discord.
This is a high level overview of the test configuration using docker. It explains how to run the tests locally
and how they integrate with the Jenkins Pipeline script to run the automated tests on ContainerShip <https://www.containership.io/>.
## Docker Installation
It is required to have Docker running on your machine in order to build and run the tests in the Dockerfiles.
See <https://docs.docker.com/engine/installation/> for more information on how to install.
## Convenience NPM Run Scripts
We have added a number of default run scripts to the `package.json` file to simplify building and running your tests.
`npm run docker-setup-android` - Pulls down the base android docker image used for running the tests
`npm run docker-build-android` - Builds the docker image used to run the tests
`npm run test-android-run-unit` - Runs all the unit tests that have been built in the latest react/android docker image (note: you need to run test-android-build before executing this, if the image does not exist it will fail)
`npm run test-android-run-instrumentation` - Runs all the instrumentation tests that have been built in the latest react/android docker image (note: you need to run test-android-build before executing this, if the image does not exist it will fail). You can also pass additional flags to filter which tests instrumentation tests are run. Ex: `npm run test-android-run-instrumentation -- --filter=TestIdTestCase` to only run the TestIdTestCase instrumentation test. See below for more information
on the instrumentation test flags.
`npm run test-android-run-e2e` - Runs all the end to end tests that have been built in the latest react/android docker image (note: you need to run test-android-build before executing this, if the image does not exist it will fail)
`npm run test-android-unit` - Builds and runs the android unit tests.
`npm run test-android-instrumentation` - Builds and runs the android instrumentation tests.
`npm run test-android-e2e` - Builds and runs the android end to end tests.
## Detailed Android Setup
There are two Dockerfiles for use with the Android codebase.
The `Dockerfile.android-base` contains all the necessary prerequisites required to run the React Android tests. It is
separated out into a separate Dockerfile because these are dependencies that rarely change and also because it is quite
a beastly image since it contains all the Android dependencies for running android and the emulators (~9GB).
The good news is you should rarely have to build or pull down the base image! All iterative code updates happen as
part of the `Dockerfile.android` image build.
So step one...
`docker pull containership/android-base:latest`
This will take quite some time depending on your connection and you need to ensure you have ~10GB of free disk space.
Once this is done, you can run tests locally by executing two simple commands:
We aim to build a vibrant and inclusive ecosystem of partners, core contributors, and community that goes beyond the main React Native GitHub repository. This document explains the roles and responsibilities of various stakeholders and provides guidelines for the community organization. The structure outlined in this document has been in place for a while but hadn't been written down before.
There are three types of stakeholders:
* **Partners:** Companies that are significantly invested in React Native and have been for years.
* **Core Contributors:** Individual people who contribute to the React Native project.
* **Community Contributors:** Individuals who support projects in the [react-native-community](https://github.com/react-native-community) organization.
## Partners
Partners are companies that are significantly invested in React Native and have been for years. Informed by their use of React Native, they push for improvements of the core and/or the ecosystem around it. Facebook's partners think of React Native as a product: they understand the trade offs that the project makes as well as future plans and goals. Together we shape the vision for React Native to make it the best way to build applications.
Our current set of partners include Callstack, Expo, Infinite Red, Microsoft and Software Mansion. Many engineers from these companies are core contributors, and their partner responsibilities also include:
* **[Callstack](https://callstack.com/):** Manages releases, maintains the [React Native CLI](https://github.com/react-native-community/react-native-cli) and organizes [React Native EU](https://react-native.eu/)
* **[Expo](https://expo.io/):** Builds [expo](https://github.com/expo/expo) on top of React Native to simplify app development
* **[Microsoft](https://www.microsoft.com/en-gb/):** Develops [React Native Windows](https://github.com/Microsoft/react-native-windows) for the Universal Windows Platform (UWP)
* **[Software Mansion](https://swmansion.com/):** Maintain core infrastructure including JSC, Animated, and other popular third-party plugins.
In terms of open source work, pull requests from partners are commonly prioritized. When you are contributing to React Native, you'll most likely meet somebody who works at one of the partner companies and who is a core contributor:
## Core Contributors
Core contributors are individuals who contribute to the React Native project. A core contributor is somebody who displayed a lasting commitment to the evolution and maintenance of React Native. The work done by core contributors includes responsibilities mentioned in the “Partners” section above, and concretely means that they:
* Consistently contribute high quality changes, fixes and improvements
* Actively review changes and provide quality feedback to contributors
* Manage the release process of React Native by maintaining release branches, communicating changes to users and publishing releases
* Love to help out other users with issues on GitHub
* Mentor and encourage first time contributors
* Identify React Native community members who could be effective core contributors
* Help build an inclusive community with people from all backgrounds
* Are great at communicating with other contributors and the community in general
These are behaviors we have observed in our existing core contributors. They aren't strict rules but rather outline their usual responsibilities. We do not expect every core contributor to do all of the above things all the time. Most importantly, we want to create a supportive and friendly environment that fosters collaboration. Above all else, **we are always polite and friendly.**
Core contributor status is attained after consistently contributing and taking on the responsibilities outlined above and granted by other core contributors. Similarly, after a long period of inactivity, a core contributor may be removed.
We aim to make contributing to React Native as easy and transparent as possible. All important topics are handled through a [discussion or RFC process on GitHub](https://github.com/react-native-community/discussions-and-proposals). We are always looking for active, enthusiastic members of the React Native community to become core contributors.
## Community Contributors
Community contributors are individuals who support projects in the [react-native-community](https://github.com/react-native-community) organization. This organization exists as an incubator for high quality components that extend the capabilities of React Native with functionality that many but not all applications require. Facebook engineers will provide guidance to help build a vibrant community of people and components that make React Native better.
This structure has multiple benefits:
* Keep the core of React Native small, which improves performance and reduces the surface area
* Provide visibility to projects through shared representation, for example on the React Native website or on Twitter
* Ensure a consistent and high standard for code, documentation, user experience, stability and contributions for third-party components
* Upgrade the most important components right away when we make breaking changes and move the ecosystem forward at a fast pace
* Find new maintainers for projects that are important but were abandoned by previous owners
Additionally, some companies may choose to sponsor the development of one or many of the packages that are part of the community organization. They will commit to maintain projects, triage issues, fix bugs and develop features. In turn, they will be able to gain visibility for their work, for example through a mention of active maintainers in the README of individual projects after a consistent period of contributions. Such a mention may be removed if maintainers abandon the project.
If you are working on a popular component and would like to move it to the React Native community, please create an issue on the [discussions-and-proposals repository](https://github.com/react-native-community/discussions-and-proposals).
`Unable to define method 'getConstants()' on NativeModule '${moduleName}'. NativeModule '${moduleName}' already has a constant or method called 'getConstants'. Please remove it.`,
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.