Summary: Now that Flow v0.92.1 is deployed, we can backout {D13942380}, which was a temporary fix.
Reviewed By: avikchaudhuri
Differential Revision: D13952515
fbshipit-source-id: d423379a03fff09316aa499e1152b410a1bb4178
Summary:
This diff adds performance loggers for Fabric in Android to be able to compare current version or RN with Fabric
This is the summary of Points and Annotations:
- **UIManager_CommitStart**: time that React starts the commit (react tree is ready to start rendering in native)
- **UIManager_LayoutTime**: this is the time it takes to calculate layout in yoga
- **UIManager_FabricFinishTransactionTime**: Time it takes transform "C++ mutationInstructions" into "Java MountItems" and cross boundaries from C++ to Java (including serialization of data) (THIS IS ONLY FABRIC)
- **UIManager_DispatchViewUpdates**: time right before RN moves the mount operations to the Queue that is going to be processed in the next tick UI thread
- **UIManager_BatchRunStart**: time right before the mountItems are going to be process in the UI Thread
- **UIManager_BatchedExecutionTime**: time it took to run batched mountItems (usually layout and prop updates on views)
- **UIManager_NonBatchedExecutionTime**: time it took to run non-batched mountItems (usually creation of views)
Reviewed By: fkgozali
Differential Revision: D13838337
fbshipit-source-id: 0a707619829e7d95ce94d9305ff434d1224afc46
Summary:
ViewHelper has only setBackground method which works identical to ViewCompat.setBackground from Android Support Library. This PR removes ViewHelper, and uses ViewCompat instead.
[Android] [Changed] - remove ViewHelper, use ViewCompat instead
Pull Request resolved: https://github.com/facebook/react-native/pull/23280
Differential Revision: D13950510
Pulled By: mdvacca
fbshipit-source-id: 10b5122affac17d4b66fb995339c6715c0871ed0
Summary:
Follow-up to https://github.com/facebook/react-native/pull/19809
This fix generalizes the `setAttributedString:` fix to single-line text fields.
Fixes#19339
_Pull requests that expand test coverage are more likely to get reviewed. Add a test case whenever possible!_
Pull Request resolved: https://github.com/facebook/react-native/pull/22546
Differential Revision: D13948951
Pulled By: shergin
fbshipit-source-id: 67992c02b32f33f6d61fac4554e4f46b973262c1
Summary: Just tightened up the lookup logic to guard against nullptr.
Reviewed By: RSNara
Differential Revision: D13948001
fbshipit-source-id: 55bf46619712e60e195ea12f2b8eb799f80a3bbe
Summary:
It's okay for TurboModules to not exist. Therefore, `__turboModuleProvider(moduleName)` should return null if `moduleName` doesn't refer to an actual TurboModule. The current implementation assumes that the TurboModule must exist, and therefore, it crashes the app when it doesn't (assertion error).
This change is important because it helps us land D13887962. When we switch `I18nResources` to `TurboModuleRegistry` in D13887962, on Wilde, it won't be found in `NativeModules`. Therefore, we'll try to lookup this module in `__turboModuleProvider`, and this will crash the app. It seems like `I18nResources` is a Java-only module?
Reviewed By: fkgozali
Differential Revision: D13924589
fbshipit-source-id: 7ac7b1873e06852e5aafcaaef5c24cbc548ee444
Summary: `__turboModuleProxy` doesn't exist if you're not in the TurboModules QE. If such is the case, then we should just return null when `TurboModuleRegistry.get` is called.
Reviewed By: fkgozali
Differential Revision: D13937143
fbshipit-source-id: d3f11c52b7cbecaefba675d714f0d67236071389
Summary:
@public
Makes it work nicely with gtest.
Also allows rhs *and* lhs to offer `operator(YGStyle)()`.
Reviewed By: SidharthGuglani
Differential Revision: D13942573
fbshipit-source-id: ff8b3a9aa6f05ca1b0572eb97d0ad23b09d77871
Summary:
@public
Adds `_pt` and `_percent` user defined literals to create `YGValue` instances.
This allows to create `YGValue`s in the following form:
```
use namespace facebook::yoga::literals;
auto a = 123_pt; // == YGValue{123.0f, YGUnitPoint}
auto b = -12.5_percent; // == YGValue{-12.5f, YGUnitPercent}
```
Reviewed By: SidharthGuglani
Differential Revision: D13942100
fbshipit-source-id: ce1e2f9431c3e2a99c6e11896a712539cc535e0d
Summary: Flow v0.92 is crashing sometimes after a save when run through Nuclide. This fixes the issue temporarily until we can push a Flow v0.92.1
Reviewed By: samwgoldman
Differential Revision: D13942380
fbshipit-source-id: f7bf2aef0aab90980bbb786d89710f399c9427d5
Summary:
When using react-native inside a monorepo with yarn workspaces the react-native installation can get hoisted and the assumption that the project is located in the folder where node_modules is is no longer true.
To handle this case I added an option to pass the path of the project root.
For example when using yarn workspace we can use something like this in the xcode scripts:
Assumes the following folder structure
/packages/myapp
/node_modules/react-native
```sh
export NODE_BINARY=node
export PROJECT_ROOT=$PWD/..
../../../node_modules/react-native/scripts/react-native-xcode.sh
```
It could be possible to change the default to `$PWD/..` since pwd is where the xcode project is located but then it would break if the native project structure is not the one we assume. To avoid the breaking change I decided to just keep the existing behaviour and allow changing the path with `PROJECT_ROOT`.
[ios] [added] - Allow changing the project path in react-native-xcode.sh
Pull Request resolved: https://github.com/facebook/react-native/pull/23273
Differential Revision: D13941793
Pulled By: cpojer
fbshipit-source-id: f394641b1c9d01f32bc4169097e39fc14df8191f
Summary:
When using building React Native using the `.xcodeproj` (either via linked projects in Xcode, or precompiling React Native, which is what we do), you'll get a duplicate symbol error:
```
duplicate symbol __ZN8facebook5react10IInspectorD0Ev ...
```
And a few more.
This is because the `InspectorInterfaces.cpp` file is included in _both_ the `React` target _and_ the `jsinspector` target, and since the `jsinspector` target gets linked into the `React` target, this means the symbols from `InspectorInterfaces.cpp` end up in `libReact.a` twice.
<img width="187" alt="screen shot 2019-02-04 at 11 43 39 am" src="https://user-images.githubusercontent.com/819705/52189088-93190880-288a-11e9-8411-b44b59e8e461.png">
This PR removes `InspectorInterfaces.cpp` from the `React` target, as I believe was the original intent.
Since this bug is in the `xcodeproj` it only affects builds that use that, so CocoaPods and Buck users are unaffected.
[iOS][Fixed] - Fix potential linker issues when using xcode project
Pull Request resolved: https://github.com/facebook/react-native/pull/23284
Differential Revision: D13941777
Pulled By: cpojer
fbshipit-source-id: 8a3ffb4fc916ff6570bbff8794b4515b48055667
Summary:
- Improve type inference of the `event.easing` keyboard event property with the `KeyboardEventEasing` type.
- Exporting `KeyboardEventName` and `KeyboardEventEasing` for others to use.
- Removing unnecessary optional property flag (ie.`?`) for all properties in `KeyboardEvent`. (I personally haven't seen any of the properties not being returned for all keyboard events).
[iOS] [Changed] - Refine Keyboard API Event typings
Pull Request resolved: https://github.com/facebook/react-native/pull/23272
Differential Revision: D13941758
Pulled By: cpojer
fbshipit-source-id: 4891898c29cf6963069dbe6b4d439694761fd9e7
Summary:
Commit 06c13b3e066636b414f5dc19c919dcb138763c71 pretend to update jest
to new version, but also adds jest and jest-junit to runtime dependencies
list (in addition to dev dependencies).
This commit fixes this, by removing jest and jest-junit from runtime
dependeincies.
As for motivation... story is short:
1. Updating RN 0.58.1 -> 0.58.3 I found that whole babel@6 infrastructure was returned to my `node_modules` (it is dangerous, because many tools like metro can found it and use it instead of babel@7).
2. It was because of this commit: 9d19ab0c0ca3cb50b4edddde52ae25dc6e80e055 that have 130 random files changed (and provides no meaning description).
But it points to: b864e7e63ef496facd12d65919b624e446203922 (which also provides no meaning description, why it was reverted?)
And finally points to: 696bd89013aa08ebffcbd2c4595ac393b6c26531, which was a "sync with master" commit. Ok. So it was from master.
3. Then I checked that jest still in runtime dependencies on master and fixed that. Also I hope this will be cherry picked into 0.58-stable.
[General] [Fixed] - Fix jest and jest-junit to be only development dependencies
Pull Request resolved: https://github.com/facebook/react-native/pull/23276
Differential Revision: D13941275
Pulled By: cpojer
fbshipit-source-id: a6f3377e670554b21f3ebd2f12d33e29d2969df1
Summary: This is a temporary change to measure production data
Reviewed By: fkgozali
Differential Revision: D13906807
fbshipit-source-id: 2a2f71aa379c4aca63c7bb4a9644704f713cb088
Summary: Simple diff that adds QPL marker to track time it takes to load .so file used by RN Fabric
Reviewed By: fkgozali
Differential Revision: D13934149
fbshipit-source-id: a5cb0fc255394cf6c936b9018c753dcc774c347f
Summary: The goal is to be able to use MobileConfig params inside of core React Native C++ code. This works on Catalyst iOS now and Wilde; need to add support for FB4A and Catalyst Android.
Reviewed By: fkgozali
Differential Revision: D13883007
fbshipit-source-id: 115fe6cc884d2a0b9ca26dadf867a5f0ae99f262
Summary: For now, do `require('NativeModules')` instead of `import {NativeModules} from 'react-native'`.
Reviewed By: mdvacca
Differential Revision: D13934066
fbshipit-source-id: 5188b11428a4dca8cecd1934e593d89a6e3fde2e
Summary:
Given two apps loaded side-by-side and when a `Keyboard` event is triggered, there is no way to ascertain which app triggered the keyboard event. This ambiguity can arise in slide over/split view scenarios.
This pull request exposes the `isLocalUserInfoKey` property of the native `UIKeyboard` iOS events to the `Keyboard` event listener; this property will return `true` for the app that triggered the keyboard event.
(Also, I threw in a couple of Keyboard.js tests just for fun 😅)
[iOS][Added] - Expose isLocalUserInfoKey to keyboard event notifications
1. Load two apps side-by-side, with the app on the left side subscribing to the keyboard events (and logging out the events as they happen)
1. Trigger a keyboard to appear with the left app. The logged keyboard event will contain the `isEventFromThisApp` property which will be true.
1. Dismiss the keyboard
1. Trigger a keyboard to appear with the right app. The left app will still log the keyboard event, but the event's `isEventFromThisApp` property will be false (because the left app didn't trigger the keyboard event)
Pull Request resolved: https://github.com/facebook/react-native/pull/23245
Differential Revision: D13928612
Pulled By: hramos
fbshipit-source-id: 6d74d2565e2af62328485fd9da86f15f9e2ccfab
Summary:
In https://github.com/facebook/react-native/pull/20602, I tried to make ReactActivity to extend AppCompatActivity per Google recommendation. But import failed, now ReactActivity extends FragmentActivity which is a parent class of AppCompatActivity and step forward to extend AppCompatActivity.
Pull Request resolved: https://github.com/facebook/react-native/pull/22662
Reviewed By: mdvacca
Differential Revision: D13505140
Pulled By: hramos
fbshipit-source-id: d4edc8dc5c606c45811c1deddf5727a47ad484d8
Summary:
ScrollView (as well as FlatList) used with horizontal={true} and inverted={true} do not scroll as expected due to a known Android P bug.
Fixes#22710. This is pretty much a clone of PR #21117, applied to a horizontal ScrollView.
[Android] [Fixed] - Fix Inverted Horizontal ScrollView on Android
1. Create a test application with a FlatList with horizontal={true} inverted={true}.
2. Fill it with data
3. Scroll and release your finger
Pull Request resolved: https://github.com/facebook/react-native/pull/23233
Differential Revision: D13915911
Pulled By: cpojer
fbshipit-source-id: d32c82e6d9076f5ffdf342fcd71bd921e9c8a97b
Summary:
Fixes#23076 , the reason is `blur()` is managed by `UIManager`, `UIManager` maintains all operations and execute them each `batchDidComplete`, which means every time `JS` finish callback native , but `Alert` module would call directly, this mess up the order of method call, for example like below, even `this.$input.blur()` is called before `Alert.alert()`, but in native side, `Alert.alert()` is called before `this.$input.blur()`.
```
<TextInput style={{ borderWidth: 1 }} ref={$input => this.$input = $input} />
<Button title="Show Alert" onPress={() => {
// // `blur` works if using without `Alert`
this.$input && this.$input.blur()
// // `blur` is not working
Alert.alert('show alert', 'desc', [
{ text: 'cancel', style: 'cancel' },
{ text: 'show', onPress: () => {
}},
])
}} />
```
[iOS] [Fixed] - Fixes alert view block first responder
After fix, example like below, `blur` can works.
```
import * as React from 'react';
import { TextInput, View, Alert, Button } from 'react-native';
export default class App extends React.Component {
render() {
return (
<View style={{ flex: 1, justifyContent: 'center' }}>
<TextInput style={{ borderWidth: 1 }} ref={$input => this.$input = $input} />
<Button title="Show Alert" onPress={() => {
this.$input && this.$input.blur()
Alert.alert('show alert', 'desc', [
{ text: 'cancel', style: 'cancel' },
{ text: 'show', onPress: () => {
}},
])
}} />
</View>
);
}
}
```
Pull Request resolved: https://github.com/facebook/react-native/pull/23240
Differential Revision: D13915920
Pulled By: cpojer
fbshipit-source-id: fe1916fcb5913e2b8128d045a6364c5e3d39c516
Summary:
Bump soloader to 0.6.0, which added support for App Bundling and help reduce app size.
[Android] [Changed] - Bump Soloader to 0.6.0
CI is green and everything works just fine.
Pull Request resolved: https://github.com/facebook/react-native/pull/23239
Differential Revision: D13915901
Pulled By: cpojer
fbshipit-source-id: 917705326b76fc3356828e5d00e6148e292bd12a
Summary:
The updated Dangerfile config lets pull-bot warn when the PR lacks a Summary, on top of the existing Test Plan and Changelog warnings.
It will also be a bit more lenient when it comes to the changelog, making the `-` optional after TYPE.
Finally, I removed the "large PR" warning. We haven't had a problem with large PRs recently, and I feel we can deal with these on a case by case basis.
[GENERAL] [Changed] Adjust pull-bot to handle new PR template.
Tested against this PR (note the non-standard section titles):
```
$ yarn
$ yarn danger pr https://github.com/facebook/react-native/pull/23236📋 Missing Summary - <i>Can you add a Summary? To do so, add a "## Summary" section to your PR description. This is a good place to explain the motivation for making this change.</i>
-
📋 Missing Test Plan - <i>Can you add a Test Plan? To do so, add a "## Test Plan" section to your PR description. A Test Plan lets us know how these changes were tested.</i>
-
📋 Missing Changelog - <i>Can you add a Changelog? To do so, add a "## Changelog" section to your PR description. A changelog entry has the following format: [`[CATEGORY] [TYPE] - Message`](http://facebook.github.io/react-native/docs/contributing#changelog).</i>
Found only warnings, not failing the build
✨ Done in 4.86s.
```
Pull Request resolved: https://github.com/facebook/react-native/pull/23236
Differential Revision: D13915716
Pulled By: cpojer
fbshipit-source-id: 6f1c3e67140c14359fc369b36b900aedf9a3bd8a
Summary:
NativeModules are instantiated by the bridge. If they choose, they can capture the bridge instance that instantiated them. From within the NativeModule, the bridge can then be used to lookup other NativeModules. TurboModules have no way to do such a lookup.
Both NativeModules and TurboModules need to be able to query for one another. Therefore, we have four cases:
1. NativeModule accesses NativeModule.
2. NativeModule accesses TurboModule.
3. TurboModule accesses NativeModule.
4. TurboModule accesses TurboModule.
In summary, this solution extends the bridge to support querying TurboModules. It also introduces a `RCTTurboModuleLookupDelegate` protocol, which, implemented by `RCTTurboModuleManager`, supports querying TurboModules:
```
protocol RCTTurboModuleLookupDelegate <NSObject>
- (id)moduleForName:(NSString *)moduleName;
- (id)moduleForName:(NSString *)moduleName warnOnLookupFailure:(BOOL)warnOnLookupFailure;
- (BOOL)moduleIsInitialized:(NSString *)moduleName
end
```
If TurboModules want to query other TurboModules, then they need to implement this protocol and synthesize `turboModuleLookupDelegate`:
```
protocol RCTTurboModuleWithLookupCapabilities
property (nonatomic, weak) id<RCTTurboModuleLookupDelegate> turboModuleLookupDelegate;
end
```
NativeModules will continue to use `RCTBridge` to access other NativeModules. Nothing needs to change.
When we attach the bridge to `RCTTurboModuleManager`, we also attach `RCTTurboModuleManager` to the bridge as a `RCTTurboModuleLookupDelegate`. This allows the bridge to query TurboModules, which enables our NativeModules to transparently (i.e: without any NativeModule code modification) query TurboModules.
In an ideal world, all modules would be TurboModules. Until then, we're going to require that TurboModules use the bridge to query for NativeModules or TurboModules.
`RCTTurboModuleManager` keeps a map of all TurboModules that we instantiated. We simply search in this map and return the TurboModule.
This setup allows us to switch NativeModules to TurboModules without compromising their ability to use the bridge to search for other NativeModules (and TurboModules). When we write new TurboModules, we can have them use `RCTTurboModuleLookupDelegate` to do access other TurboModules. Eventually, after we migrate all NativeModules to TurboModules, we can migrate all old callsites to use `RCTTurboModuleLookupDelegate`.
Reviewed By: fkgozali
Differential Revision: D13553186
fbshipit-source-id: 4d0488eef081332c8b70782e1337eccf10717dae
Summary:
Specifically, updates the UWP .vcxproj for MSBuild and also exposes the UseLegacyStretchBehaviour API for use with react-native-windows.
Pull Request resolved: https://github.com/facebook/yoga/pull/848
Reviewed By: SidharthGuglani
Differential Revision: D13848609
Pulled By: davidaurelio
fbshipit-source-id: eab046ff3c47e49706f515e209d8aaf750c2198f
Summary:
Fixes#14161
Android crashes in some cases if an animated transform config contains a string value, like a rotation.
This PR fixes that by ensuring all values sent to the native side are doubles. It adds `__transformDataType` to AnimatedTransform.js.
Added integration test `ReactAndroid/src/androidText/js/AnimatedTransformTestModule.js` This test fails with the following error `INSTRUMENTATION_RESULT: longMsg=java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Double`, if the changes to AnimatedTransform.js are reverted.
[Android] [Fixed] - Fixes Android crash on animated style with string rotation
Pull Request resolved: https://github.com/facebook/react-native/pull/18872
Differential Revision: D13894676
Pulled By: cpojer
fbshipit-source-id: 297e8132563460802e53f3ac551c3ba9ed943736
Summary:
For better modularity, each module conforming to RCTTurboModule should provide a getter for the specific TurboModule instance for itself. This is a bit more extra work for devs, but simplify tooling and allow better modularity vs having a central function that provides the correct instance based on name.
Note: Android may or may not follow this new pattern -- TBD.
Reviewed By: RSNara
Differential Revision: D13882073
fbshipit-source-id: 6d5f82af67278c39c43c4f7970995690d4a82a98
Summary:
See https://github.com/facebook/react-native/issues/7680.
On iOS the RCTLocationObserver delegate is overriding `desiredAccuracy` every time CLLocationManager calls `didUpdateLocations` or `didFailWithError`. `desiredAccuracy` is reset to
`RCT_DEFAULT_LOCATION_ACCURACY` (100 meters) This effectively makes it impossible for a react-native app to use any location accuracy other than the default.
This commit simply removes the code which resets the desired accuracy, as there seems to be no rationale for doing so. The reset code was added as part of [a large general
change](705a8e0144) so the original intention is unclear from the history. If somebody can explain it to me, I'm happy to rework this PR accordingly.
Changelog:
----------
[iOS] [Fixed] - Location Services accuracy constantly reset to default of 100 meters.
Pull Request resolved: https://github.com/facebook/react-native/pull/23209
Differential Revision: D13879497
Pulled By: cpojer
fbshipit-source-id: f3c6c9c5ef698b23b99c407fd764ac990d69bf8c
Summary:
There is a variation in iOS and Android output while performing perspective transformation. The variation exists even when used in Android devices with different screen density.
Pull Request resolved: https://github.com/facebook/react-native/pull/18302
Differential Revision: D13877483
Pulled By: cpojer
fbshipit-source-id: e48be047a8047c7562722923a67666cb098243d8
Summary:
As a maintainer, I noticed that the description for a PR is often missing, which makes it hard to understand why a change is made. Because some of the text isn't using HTML comments, the same text explaining how to fill out the changelog and test plan pops up and isn't removed by people. This PR fixes both of these issues.
I also made another small update to the main issue template to urge people to use one of the other templates, with an explanation that we will close poorly formatted issues.
Changelog:
----------
[General] [Changed] - Updated GitHub templates
Pull Request resolved: https://github.com/facebook/react-native/pull/23187
Differential Revision: D13877752
Pulled By: cpojer
fbshipit-source-id: 8ed88cde9151a41931848cccc669208cabe1e9ef
Summary: simple diff to eager initialize the PreAllocateViewMountItem class with the rest of the Fabric classes
Reviewed By: sahrens
Differential Revision: D13860612
fbshipit-source-id: d1fbc653420c1c1546bbf605c682ad5bb611d76b
Summary: This diff changes the way pre-allocation of views are executed in Fabric. Before this diff the execution of view preallocation was schedulled at the end of the UIThread queue, now the views are pre-allocated in the next "tick"
Reviewed By: sahrens
Differential Revision: D13857614
fbshipit-source-id: 386bf966d3c8a0d5c0bd626119a92810465aecb7
Summary:
@public
Adds the maximum number of measure cache entries in use to the metrics for `YGMarkerLayout`
Reviewed By: SidharthGuglani
Differential Revision: D13844731
fbshipit-source-id: fa66dbf1b7a1799494f72ecc17dfaef04d0b56e4
