Summary:
Previously, we'd throw std::runtime_error objects when we invoked RCTPromiseResolveBlock and RCTPromiseRejectBlock. This would crash the app. Now, we'll just show RedBoxes. The RedBoxes also contain the name of the NativeModule, along with the method.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25549149
fbshipit-source-id: 33d5fc4480a577a1c17961c856ac42a9363b35f6
Summary:
All NativeModules that used to use the bridge to require other NativeModules now require other NativeModules via the Venice-compatible RCTModuleRegistry abstraction. Therefore, we can safely get rid of synthesize bridge = _bridge from them.
## How did I generate this diff?
1. Search for all NativeModules that have `synthesize bridge =`
2. Remove the `synthesize bridge = _bridge` from each NativeModule, and if it doesn't contain `_bridge`, `setBridge:`, or `elf.bridge`, add it to this codemod.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25551295
fbshipit-source-id: 585d50ad55cb9ab083e430b07e1cf30e31f0d3c5
Summary:
Remove proguard keep rules on okhttp3. The library already contains its own consumer proguard --> see https://square.github.io/okhttp/r8_proguard/
The keep rules will increase the final apk size of android app. Currently, there is no way to disable proguard rules from transitive dependencies ( https://issuetracker.google.com/issues/37073777). So any android app that use react native will also contains this proguard rules.
## Changelog
[Android] [Removed] - Remove okhttp3 proguard rules
Pull Request resolved: https://github.com/facebook/react-native/pull/30514
Test Plan: n/a
Reviewed By: mdvacca
Differential Revision: D25616704
Pulled By: fkgozali
fbshipit-source-id: eb0bcbc4ace398a55ce6902e34c17b030bb87130
Summary:
Upgrades the severity of the [`react/jsx-no-comment-textnodes`](https://github.com/yannickcr/eslint-plugin-react/blob/master/docs/rules/jsx-no-comment-textnodes.md) lint rule from warning to error.
The higher severity is warranted because, in React Native code in particular, rendering an unintended text node is likely to throw an error at runtime (unless it happens to be wrapped in `<Text />`).
Furthermore, this lint is highly actionable because there's always a workaround that is less ambiguous:
1. If intending to write a comment (likely), wrap it in curly braces:
`<>{ /* this is a comment */ }</>`
2. If intending to write an actual text node beginning with `//` or `/*` (unlikely), wrap it in curly braces and quotes:
`<>{'/* this is a text node */'}</>`
Changelog: [Internal]
Reviewed By: GijsWeterings
Differential Revision: D25615642
fbshipit-source-id: d5a59989b04c244111071893efc546083641ac54
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/30595
Changelog: [Internal]
Add support for loading HBC bundles from Metro in Twilight.
* adds `runtimeBytecodeVersion` to the bundleURL
* adds logic to check chunk hermes bytecode bundles
* adds support for running the bytecode bundles
Reviewed By: cpojer
Differential Revision: D24966992
fbshipit-source-id: acdd03a2e9e2b3e4c29c99c35a7c9136a3a7ef01
Summary:
After fixing `calculateShadowViewMutationsForNewTree` I realized that it will be even better to test Stacking Context and mutation instructions infra using both functions: `calculateShadowViewMutationsForNewTree` (used for testing) and the Differentiator itself. This diff implements it.
Now we have two similarly working functions with different implementations that we can use for testing Differentiator and other parts of the infra.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D25576922
fbshipit-source-id: 7922e9ebfb9d6ef1792566554ba0c4a14f835ae2
Summary:
Working on zIndex tests I found that calculateShadowViewMutationsForNewTree (that we use for testing) does not take zIndex into account. This fixes it.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D25576923
fbshipit-source-id: a71b3a4630430488c783cd5010c0fbb7273bdaa5
Summary:
The test covers most props that must generate views.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D25576921
fbshipit-source-id: df5bedb8f6d409b5142e472ca2edcb1953bee4e1
Summary:
According to https://github.com/facebook/react-native/issues/20011, the first onPress will not work after pull to refresh.
Dive into the code, found out that is because the state `isTouching` in `Libraries/Components/ScrollResponder.js` is not updated after the pull to refresh.
Update the `isTouching` state in `scrollResponderHandleResponderRelease` to fix this.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[iOS] [Fixed] - First press not working after pull to refresh
Pull Request resolved: https://github.com/facebook/react-native/pull/30291
Test Plan:
### Before
- The first onPress fail
### After
- The first onPress success
Eli:
I tested this myself internally using this code sample:
```
'use strict';
import PlaygroundRoute from 'PlaygroundRoute';
import type {SurfaceProps} from 'Surface';
import TetraText from 'TetraText';
import TetraView from 'TetraView';
import {TouchableOpacity, Text, View, ScrollView, RefreshControl, StyleSheet} from 'react-native';
import * as React from 'react';
type Props = SurfaceProps<PlaygroundRoute>;
class App extends React.Component<{}> {
constructor() {
super();
this.state = {refreshing: true, items: []};
}
componentDidMount() {
this.refresh();
}
refresh = () => {
this.setState({
refreshing: true,
items: [],
});
setTimeout(
() =>
this.setState({
refreshing: false,
items: [0, 1, 2, 3, 4, 5],
}),
1500,
);
};
renderItem = ({item}) => {
return (
<TouchableOpacity onPress={() => alert('pressed!')} key={`${item}`}>
<Text style={{width: '100%', height: 48, backgroundColor: 'white'}}>
{item}
</Text>
<View style={{width: '100%', height: 1, backgroundColor: 'gray'}} />
</TouchableOpacity>
);
};
render() {
return (
<View style={{flex: 1, padding: 48}}>
<ScrollView
style={{
flex: 1,
backgroundColor: '#aaa',
borderColor: 'gray',
borderWidth: 1,
}}
keyExtractor={item => `${item}`}
refreshControl={
<RefreshControl
refreshing={this.state.refreshing}
onRefresh={this.refresh}
/>
}>
{this.state.items.map(item => this.renderItem({item}))}
</ScrollView>
</View>
);
}
}
export default function Playground(props: Props): React.Node {
return (
<App />
);
}
const styles = StyleSheet.create({
container: {
padding: 10,
paddingTop: 30,
},
});
```
{F351458967}
Reviewed By: appden
Differential Revision: D25574927
Pulled By: TheSavior
fbshipit-source-id: 7abf8a2f947d94150419e51d46a19e792441c981
Summary:
RCTBlobManager actually has the name "BlobModule", not "BlobManager".
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25569865
fbshipit-source-id: f6b41300bda6485cef3f18d3d0308dad9c002b77
Summary:
This small PR introduces the following changes to the `Pressability`:
* fixes typo in internal `isActivationTransiton` variable name
* assigns `onPressMove` to variable before check and potential usage (this is the common pattern in this file)
* utilizes destructuring assignment to simplify passing coordinates to `_touchActivatePosition`
## Changelog
[Internal] [Fixed] - Pressability: fix typo in variable, follow event check pattern, small tweak
Pull Request resolved: https://github.com/facebook/react-native/pull/30151
Test Plan: Successful `yarn test` run.
Reviewed By: kacieb
Differential Revision: D25545662
Pulled By: nadiia
fbshipit-source-id: 8d311fe21b485ee707e05dad120322b3027e686b
Summary:
During cleanup, RCTNativeAnimatedModule [requires the RCTEventDispatcher](https://fburl.com/diffusion/0bnln893) to remove itself from the dispatcher a dispatch observer.
When the bridge is invalidated, if RCTEventDispatcher is has been cleaned up by then, we don't warn when this lookup fails: https://fburl.com/diffusion/rfioe5ay. This diff replicates that behaviour in the TurboModule infra.
Notes:
- In the legacy NativeModule infra, we can still query NativeModules post invalidation - we just won't create them. In the TurboModule infra, all requests for TurboModules from the TurboModuleManager start returning nil. Therefore, I simply did an early return inside TurboModuleManager moduleForName in the case that we're already invalidated. In addition to not displaying the warning, we just don't request/create the TurboModule in the first place.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25560228
fbshipit-source-id: 102dcc147bab6121daacdb39890bad48c0e60894
Summary:
When building React Native application in Release mode for an iPhone Simulator _and_ targeting `armv7`, Xcode will build all architectures (due to `ONLY_ACTIVE_ARCH` set to `false`, unlike in Debug mode). As a result, Xcode will try building for `i386` (32-bit iPhone Simulator), which fails as we don’t build Hermes binaries for `i386`.
Fix is to disable `i386`, since it is not supported by `Hermes` and certain `Folly` features.
## Changelog
[IOS] [BREAKING] - `i386` architecture will be automatically disabled when Hermes is being used. This might be potentially breaking for your workflow if you target `armv7` devices, as you will no longer be able to test on the simulator.
[IOS] [FEATURE] - Replace `flipper_post_install` with `react_native_post_install` hook. Will automatically detect if Flipper is enabled.
Pull Request resolved: https://github.com/facebook/react-native/pull/30592
Test Plan: Run React Native application with Hermes enabled (or Flipper) in Release mode and it should work just fine.
Reviewed By: appden
Differential Revision: D25564738
Pulled By: TheSavior
fbshipit-source-id: e786ab73fb0a77de5869cf9e5999726c7d29f1d4
Summary:
Recently introduced steps to run Hermes accidentally removed `!` from the `use_react_native`, causing `pod install` to fail with an error.
## Changelog
[INTERNAL] [iOS] - Fix Podfle in default template
Pull Request resolved: https://github.com/facebook/react-native/pull/30571
Test Plan: Run `pod install` with this file and it should work.
Reviewed By: appden
Differential Revision: D25537263
Pulled By: TheSavior
fbshipit-source-id: da7f21775cbe641e34aded87a92c696539f4d5c3
Summary:
Fixes https://github.com/facebook/react-native/issues/29984
Right now, running a React Native application with Xcode 12 in Release mode on an iPhone Simulator will fail with something like below:
> [some file path], building for iOS Simulator, but linking in object file built for iOS, file '[some file path]' for architecture arm64
The best explanation of this issue has been provided by alloy in https://github.com/facebook/react-native/issues/29984:
> This issue has started coming up with Xcode 12 and support for the new ARM based Macs, as `arm64` now no longer can be assumed to _only_ be for iOS devices. This means Xcode 12 will now also build for `arm64` simulator SDKs and it has become ambiguous if an arch slice in a prebuilt binary is meant for a simulator or device.
>
> In any case, for now this means that you can configure your Xcode project to exclude `arm64` when building for any iOS simulator SDK.
This PR implements aforementioned workaround.
## Changelog
[FIX] [IOS] - Fix running React Native project with Xcode 12 in Release on iPhone Simulator
Pull Request resolved: https://github.com/facebook/react-native/pull/30543
Test Plan: Switch your scheme to Release and run the app on simulator. Will complete w/o issues.
Reviewed By: appden
Differential Revision: D25537295
Pulled By: TheSavior
fbshipit-source-id: 2dc05cb80e59f1d95d2a84ab55ed6a5b5446411c
Summary:
This is to address a UBN blocking FBiOSv300 rollout. A TM is attempting to invoke a promise more than once and crashing. We can't find the TM, so downgrading this to a warning to unblock the release.
Plan going forward:
- Replace this with some better logging to try and identify the culprit module.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D25539676
fbshipit-source-id: 5b75b71110eaa393378049de6e0d9a77e6328831
Summary:
We see crashes in `updateProps:oldProps:` methods in several components, and we suspect it might happen because of the props object being null.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D25535605
fbshipit-source-id: f278a5cec47b7fd54d31d015427fa918c02d913b
Summary:
We see crashes in this method, so we need asserts to understand why exactly it happens.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D25535606
fbshipit-source-id: 8b0d275825a028f51343e4ab91682c8299904e8d
Summary:
Currently, installing `react-native-community/eslint-config` with projects using eslint v7 causes the following warning
```
warning "react-native-community/eslint-config > eslint-plugin-react-native@3.8.1" has incorrect peer dependency "eslint@^3.17.0 || ^4 || ^5 || ^6".
```
This PR updates the eslint-plugin-react-native module to suppress the warning
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[Internal] [Changed] - update eslint-plugin-react-native for community eslint-config
Pull Request resolved: https://github.com/facebook/react-native/pull/30350
Test Plan: eslint working without error with projects using eslint v7
Reviewed By: GijsWeterings
Differential Revision: D25480912
Pulled By: nadiia
fbshipit-source-id: 2a956070e5bb75168d68501f9ec9486a34011349
Summary:
This should make `testID` prop work as it works in pre-Fabric renderer on iOS.
On Android it should already work fine.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D25524890
fbshipit-source-id: 3f25eb427d4449abaab790099546be18ae573f98
Summary:
Ran `xbgs .accibilityManager`, and found all the NativeModules that used the bridge to access AccessibilityManager. Then, I migrated them to use RCTModuleRegistry.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25504726
fbshipit-source-id: fcfb1fffbeedc136ee160d043949d9859300b1e3
Summary:
All NativeModules that use `[RCTBridge moduleForName:]` to access other NativeModules are now instead using the Venice-compatible RCTModuleRegistry to access other NativeModules.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D25508910
fbshipit-source-id: 85fc390063af264f2f2843e5640fa7336a784ab4
Summary:
All NativeModules that use `[RCTBridge moduleForClass:]` to access other NativeModules are now instead using the Venice-compatible RCTModuleRegistry to access other NativeModules.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D25508277
fbshipit-source-id: 1b415a5ad4055290940879e100ceaa84ae83feeb
Summary:
Ran `xbgs .redBox`, and found all the NativeModules that used the bridge to access RedBox. Then, I migrated them to use RCTModuleRegistry.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D25507829
fbshipit-source-id: 91033ca4c57d5be5e8e6fa904b636960ec12c584
Summary:
Ran `xbgs .devSettings`, and found all the NativeModules that used the bridge to access DevSettings. Then, I migrated them to use RCTModuleRegistry.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25503402
fbshipit-source-id: 26afc45cd1bc63d5de99ea331e7b2949b66be7ce
Summary:
All NativeModules that access the _bridge from self to require the DevSettings NativeModule now instead get the DevSettings NativeModule from the _moduleRegistry.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25503289
fbshipit-source-id: ebd1fd45d40aca37c0ead83bbaab59fa99d45044
Summary:
All NativeModules that access the _bridge from self to require the WebSocketModule NativeModule now instead get the WebSocketModule NativeModule from the _moduleRegistry.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25500433
fbshipit-source-id: 21aebc5684dd6a058de4e35b042c9fb255ffcb33
Summary:
Ran xbgs `.devMenu`, and found all the NativeModules that used the bridge to access DevMenu. Then, I migrated them to use RCTModuleRegistry.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25499960
fbshipit-source-id: 70478616d44808f3788dd0b194da155db0877db9
Summary:
Spotted a few errors in Codemod that migrated bridge.networking calls to [_moduleRegistry moduleForName:"Networking"] calls. This diff fixes those mistakes.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25499699
fbshipit-source-id: 29f296fc1011cf65d30e083e0ef001e3185edbfb
Summary:
All NativeModules that access the _bridge from self to require the Networking NativeModule now instead get the Networking NativeModule from the _moduleRegistry.
NOTE: xbgs .networking reveal any other usages. So, there won't be a manual migration diff associated with this codemod.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25499412
fbshipit-source-id: 7b0e33135c6c91ffc1e041ad3ab95f1346a8bc22
Summary:
All NativeModules that access the _bridge from self to require the ImageStoreManager now instead get the ImageStoreManager from the `_moduleRegistry`.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25498774
fbshipit-source-id: 1d97888ed2ef8d295aa35cf08cb9e9f3bc33ed05
Summary:
We currently spam the log with verbose state change messages by default.
These messages are really only useful for internal Inspector
development, so turn them off by default.
Changelog: [Internal]
Reviewed By: avp
Differential Revision: D25500449
fbshipit-source-id: 57e0901856f104be613f79de3b3ac9e3e95b2655
Summary:
Ship LayoutAnimations to 100% of users by removing feature-flag gating.
The `collapseDeleteCreateMountingInstructions_` stuff is always disabled for LayoutAnimations, so we can get rid of that too.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25510740
fbshipit-source-id: 71bac44f829530458e4906ecd1e7e68e766de2ec
Summary:
In preparation for flipping the default, marking autoglob as False in places where it isn't explicitly specified.
Changelog: [Internal]
Reviewed By: strulovich
Differential Revision: D25497305
fbshipit-source-id: 142e5caca2d67efcb3c25067a36934f7f6dd4b21
Summary:
Changelog: [internal]
Cloning of `LegacyViewManagerInteropViewProps` causes loss of `sourceProps.otherProps` if the cloning happens before shadow node is mounted. This was happening in WebView and callback `onLoadEnd` was dropped because of this.
Reviewed By: JoshuaGross
Differential Revision: D25474581
fbshipit-source-id: 74d7c5cd32b7318bb99306c82bc8b5e5eab63db2
Summary:
This is a followup to the issue described in D25477044, basically the TM cache can get messed up if `TurboModuleManager` is asked for "RCTNetworking" vs "Networking". This solves that issue globally.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D25480624
fbshipit-source-id: 2024560eadbcf58cdc3d7d5675b4120aa2fa2582
Summary:
While investigating a bridgeless networking issue, I noticed something very peculiar. **Two** networking turbo modules are built and used in bridgeless mode. Upon debugging, I realized that each of them have a different `TurboModuleHolder`. The reason is the following:
1. In JS, the module's name is [Networking](https://fburl.com/diffusion/f2xu4wie)
2. In ObjC, we call the module "RCTNetworking" (examples in this diff)
3. Both scenarios end up creating the correct Turbo Module: [RCTNetworking](https://www.internalfb.com/intern/diffusion/FBS/browsefile/master/xplat/js/react-native-github/Libraries/Network/RCTNetworking.mm?link_ref=search), but the `TurboModuleHolder` doesn't know that "RCTNetworking" and "Networking" are the same. Any other modules accessed this way will have the same issue.
An alternative solution would be to tell `TurboModuleHolder` to strip the `RCT` suffix, which would solve the problem globally. RSNara thoughts?
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D25477044
fbshipit-source-id: 02219de578ef4d19e579110e4242883a30cefcd6
Summary:
This is an extension of D25449795. I searched for all usages of .eventDispatcher within NativeModules, and migrated them all to the Venice-compatible RCTModuleRegistry API.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25473844
fbshipit-source-id: 2b8deec236e019f3adfb59fadd745c249ff822f4
Summary:
All NativeModules that use the bridge to require the eventDispatcher are now instead using the RCTModuleRegistry I introduced in D25412847 (https://github.com/facebook/react-native/commit/0ed81b28d3d786ea3b1cf0b932a008ef1f806ec4).
## What does this codemod do?
For all ObjC files that contain `synthesize bridge = _bridge`, migrate calls that access the React Native bridge from `self`, and use it to load the event dispatcher.
**Thoughts on Codemod Safety:** If we can access the bridge from self, then that means that if we synthesize the module registry, we can access the module registry from self. Therefore, this codemod is safe.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25449795
fbshipit-source-id: 2f7235d14659e73d673ae08763dc2cccdde55a19
Summary:
This should be a noop. It just makes writing codemods easier.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25442218
fbshipit-source-id: dba0c35a6f566e83ed5b7142075fff6929efeada
Summary:
The bridge now creates the RCTModuleRegistry, and assigns it to all NativeModules it creates.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25414108
fbshipit-source-id: 81c6a05bde0e52cff8ed60297f27d8aa3ff15a87
Summary:
NativeModules and TurboModules should use this API to lookup other NativeModules/TurboModules.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25414341
fbshipit-source-id: d8fab3d1b30b940fc5d1faa56bf195b9fda8d377
Ramanpreet Nara
doniwinata0309
Moti Zilberman
Keion Anvaripour
Valentin Shergin
Mike
Ron Edelstein
Samuel Susla
simek
Mike Grabowski
Peter Argany
Jesse Katsumata
Will Holen
Joshua Gross
Aditya Kumar
