Summary:
ConcreteStateTeller is being replaced with a new built-in state autorepeat mechanism.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D25687692
fbshipit-source-id: a89d0a4d63b9c97775a312afa3df43f26b5ecc08
Summary:
Original commit changeset: a3324b5df6e6
ConcreteStateTeller is being replaced with a new built-in state autorepeat mechanism.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D25687697
fbshipit-source-id: 849bb8b6c244b17a49b5fe140346d90a9a7e52ff
Summary:
Original commit changeset: 4c0d7b249175
ConcreteStateTeller is being replaced with a new built-in state autorepeat mechanism.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D25687698
fbshipit-source-id: b7eac808db1acdc7ef3297313ac352162bdccd5b
Summary:
Original commit changeset: b82301e5db48
ConcreteStateTeller is being replaced with a new built-in state autorepeat mechanism.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D25687694
fbshipit-source-id: 17a737d394cb7f460b239be421466981bc46f995
Summary:
Original commit changeset: 2b82e2d43cc6
ConcreteStateTeller is being replaced with a new built-in state autorepeat mechanism.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D25687699
fbshipit-source-id: d318155509b00064e29fc32efe893151a9723fd5
Summary:
ConcreteStateTeller is being replaced with a new built-in state autorepeat mechanism.
Original commit changeset: 8c777ae1264c
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D25687695
fbshipit-source-id: 334cb6c7497270c040e4aec262a30441bc7529ce
Summary:
Changelog: [internal]
Previous implementation of "measure" in UIManagerBinding returned 0, 0 for x and y coordinates.
Reviewed By: shergin
Differential Revision: D25681586
fbshipit-source-id: fa69b6d4803f083a8299e00cae8bb59932c8bf78
Summary:
Changelog: [internal]
The loop inside `UIManager::getNewestCloneOfShadowNode` is unnecessary as ancestorList already has index of the children.
Reviewed By: shergin
Differential Revision: D25681296
fbshipit-source-id: e8fab6c6d945064b0a7e63b6fd22697054fb7ea2
Summary:
Changelog: [internal]
Return original image instead of calling `abort()` when malloc fails.
Should we show a redbox? I don't think so, the redbox wouldn't be actionable for product engineer.
Reviewed By: PeteTheHeat
Differential Revision: D25678532
fbshipit-source-id: dd44d5e87198a0f76767ea40fe111ed347a7669a
Summary:
Original PR contents:
This pull request updates the Podspecs and associated build scripts, and some source files so they build on OSS. RNTester now compiles with `fabric_enabled` again.
The following changes have been made:
* Various spots that were pointing to the old `ReactCommon/fabric` location have now been updated to `ReactCommon/react/renderer`
* Files that were attempting to use internal FB header `FBRCTFabricComponentsPlugins.h` were changed to use `RCTFabricComponentsPlugins.h`
* `RCTFabricComponentsPlugins` in OSS was updated to include the `Image` fabric component (thanks tsapeta)
* Replaced old `generate-rncore.sh` build script with new `generate-rncore.js` script which does not require `flow-node` and uses the `react-native-codegen` API directly, so there is no longer any need for an interim `schema-rncore.json` file.
* Updated Yoga podspec which wasn't fully synced with changes from the main Yoga repo
* Updated Fabric podspec with additional needed subspecs
Additions to PR by hramos:
* Replaced use of generate-rncore scripts with the original generate-native-modules-specs.sh script, which is now generate-specs.sh and supports both codegen for Native Modules and Components now (TurboModules/Fabric).
* Codegen now runs at build time as part of the Xcode build pipeline instead of as part of `pod install`. The build script is injected by the FBReactNativeSpec pod, as the pod is part of both Fabric and non-Fabric builds.
## Changelog
[General] [Fixed] - RNTester compiles with `fabric_enabled` again
Pull Request resolved: https://github.com/facebook/react-native/pull/29810
Test Plan:
RNTester now compiles and runs in the simulator again when `fabric_enabled` is set to `true`.
```
cd xplat/js/react-native-github/packages/rn-tester
USE_FABRIC=1 pod install
open RNTesterPods.xcworkspace
# Build and run
```
Reviewed By: fkgozali
Differential Revision: D24058507
Pulled By: hramos
fbshipit-source-id: 8b2ea3694e6cb9aa23f83f087e2995fd4320e2bb
Summary:
This commit makes both `:ReactAndroid` and `:rn-tester:android:app` always compile in Fabric codegen outputs. However, one may still enable/disable Fabric at runtime by setting `USE_FABRIC` env var (set to 1 or 0, default is 0).
Note that we can't register custom components specific to the app, yet, so only the components in react-native github repo is covered by this commit.
RNTester doesn't enable Fabric by default yet due to known UI bugs that haven't been addressed yet.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25674311
fbshipit-source-id: 8db660c959319250ebc683c84076677cf6489e94
Summary:
Generate Fabric C++ files along side TM spec files for RNTester. The combined .so then has both TM and Fabric files.
This commit also removed the checked-in JNI files.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25674313
fbshipit-source-id: 8091d5a00f42849a74cab50e8d24f4010d500e5b
Summary:
The TM specs and Fabric files should be combined into the same .so. For short term parity with Fabric components and iOS, let's rename ReactAndroidSpec (default name based on project path) to "rncore".
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25674312
fbshipit-source-id: 3d71aa0cc945affecb06dcfc15e807dd48c76468
Summary:
For core components, we can start using the codegen output during build time instead of the checked in files in: https://github.com/facebook/react-native/tree/master/ReactAndroid/src/main/java/com/facebook/react/viewmanagers
Note: Some files seemed to be handwritten, so this only removed those that use codegen.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D25453157
fbshipit-source-id: f7eabddfd3fd668bef0c4aef3fddcb38c8b046a0
Summary:
This diff fixes a racecondition in registration of event listeners.
mPostEventDispatchListeners is accessed from different threads, most of the times this variable is used to executed the listeners. It is only written during initialization and turn down of the renderer.
changelog: [internal]
Reviewed By: PeteTheHeat
Differential Revision: D25667988
fbshipit-source-id: 1bf95f5193d55a737bad9403206cc3320185b8cb
Summary:
Changelog: [internal]
If `otherGestureRecognizer` prevents Fabric's gesture recogniser, we need to manually reset the inner state.
This cancels any currently active touches.
Reviewed By: shergin
Differential Revision: D25664384
fbshipit-source-id: 9e3cd41351381bcfed2836dad3e80d5f021f936c
Summary:
This diff adds another complexity level for Stacking Context and zIndex tests: Now we test not only "noting-to-something" cases but also cases where we apply changes to an already non-empty tree, validating our assumption of each step.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D25623176
fbshipit-source-id: 29a447d93522a2a4e7912351f907c46ac7b218bb
Summary:
This will help us migrate our iOS EventEmitters off the bridge.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D25656902
fbshipit-source-id: 2ca434e073383a1bf5b1d7366f1e1858c0c49aa6
Summary:
After this diff, NativeModules can synthesize the RCTModuleRegistry, and use that to query for UIViews of components, given their reactTags.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D25645052
fbshipit-source-id: bb17606cc4862d07b739ef2c31a5e57f59201364
Summary:
After we create the RCTSurfacePresenter in Venice, we use it to create an RCTBridgelessComponentViewProvider, and pass it over to the RCTTurboModuleManager. In Venice, this allows all TurboModules to query components' UIViews given their reactTag.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D25643261
fbshipit-source-id: 31da07c490d249534f700b7c8430e9cb43b5b0db
Summary:
Now, TurboModules that synthesize RCTModuleRegistry will have it available at runtime.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D25643260
fbshipit-source-id: e9915f3da8412de823ae3d3e17849979c5cbd465
Summary:
## Problem
Many of our NativeModules use the bridge to access the UIManager. They then use the UIManager to call viewForReactTag. This makes all these NativeModules Venice-incompatible. P155700869
## Solution
This diff introduces a Venice-compatible API called RCTViewRegistry that will implement viewForReactTag. When the bridge exists, RCTViewRegistry will delegate to the UIManager. When the bridge doesn't exist, it'll delegate to RCTSurfacePresenter. Fingers crossed, this should allow us move ~50 NativeModuels off the bridge.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25641391
fbshipit-source-id: 144f4f7a35af1245401ad640068852dd66bbf65d
Summary:
The new UIManagerCommitHook can be used to implement commit-atering features without modifying the core.
E.g. State Reconciation seems can be implemented as a coomit hook but first we will use it for a new feature called Timeline (see the coming diffs).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D25221312
fbshipit-source-id: dbe41b475bc8b36e1780d81447ab43b32758bdff
Summary:
With the change, a new delegate method allows a receiver to alter a new (proposed) shadow tree with another tree by returning the altered tree.
We will it use in future diffs to implement Commit Hooks.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D25221313
fbshipit-source-id: 9f83577d862b713fff71fa365ce660cc1de87c84
Summary:
## Context
Every time we call RCTNetworking.sendRequest(), we [set up six event listeners inside XMLHttpRequest](https://fburl.com/diffusion/85k6ou5w) by calling RCTNetworking.addListener(). Seeing how RCTNetworking.addListener() is implemented, each call results in two async NativeModule call: [one to addListener()](https://fburl.com/diffusion/ng21jek6), and [another to removeEventListener()](https://fburl.com/diffusion/nua3y973).
For RCTNetworking, both of these NativeModule calls are unnecessary, as explained in D24272663 (https://github.com/facebook/react-native/commit/dabca52f77799bcdedb6b0ec44b1f6297483a46d)
> RCTNetworking.startObserving and RCTNetworking.stopObserving don't exist. The main purpose of RCTEventEmitter.addListener is to call these methods, and increment the _listeners counter, so that we can start dispatching events when _listeners > 0. In D24272560 (https://github.com/facebook/react-native/commit/82187bfb6b54fdffc5dadaa56e8bf97d2209708a), I made RCTEventEmitter dispatch events even when _listeners <= 0. This is sufficient for us to stop calling these two RCTNetworking methods entirely.
Therefore, this experiment gets rid of on average 6-8 NativeModule method calls for every network call we make in React Native on iOS.
Reviewed By: PeteTheHeat
Differential Revision: D25618704
fbshipit-source-id: 0da20475a0882ed737cf32de27f266fd2cd016af
Summary:
## Description
During TurboModule method invocation, when we convert JavaScript callbacks (i.e: jsi::Functions) into ObjC blocks inside the TurboModule jsi::HostObject, we [push them into an array](https://fburl.com/diffusion/r1n75ikx) that [gets cleared after the method gets invoked](https://fburl.com/diffusion/ubbvdmfs).
Prior to this experiment, we pushed these ObjC blocks into the array without copying them first. This goes contrary to ObjC best practices, which suggest that if you need to retain a block past its creation context for later invocation, you should defensively copy it to prevent it from being freed early. See the [Apple docs](https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/Blocks/Articles/bxUsing.html#//apple_ref/doc/uid/TP40007502-CH5-SW1):
> Typically, you shouldn’t need to copy (or retain) a block. You only need to make a copy when you expect the block to be used after destruction of the scope within which it was declared. Copying moves a block to the heap.
The diff that introduced the fix: D23764329 (https://github.com/facebook/react-native/commit/9b76e217bb16935069f0ea5b60f4c4d9b73f86d6).
Reviewed By: PeteTheHeat
Differential Revision: D25617672
fbshipit-source-id: 24863b31a2d82c8d39a91c8ea8eb3a62724b800a
Summary:
## Context
The legacy NativeModule infra implements promise methods using [async NativeModule method calls](https://fburl.com/diffusion/tpkff6vg). In the TurboModule infra, promise methods [treat as sync methods](https://fburl.com/diffusion/yde7xw71), and executed directly on the JavaScript thread. This experiment makes TurboModule promise methods async, and dispatches them to the NativeModules thread, when they're executed from JavaScript.
Reviewed By: fkgozali
Differential Revision: D25623192
fbshipit-source-id: 2b50d771c5272af3b6edf150054bb3e80cab0040
Summary:
## Context
Every time we require a NativeModule in Java, we [first try to create it with the TurboModuleManager](https://fburl.com/diffusion/3nkjwea2). In the TurboModule infra, when a NativeModule is requested, [we first create it](https://fburl.com/diffusion/d2c6iout), then [if it's not a TurboModule, we discard the newly created object](https://fburl.com/diffusion/44gjlo6y). This is extremely wasteful, especially when a NativeModule is requested frequently and periodically, like UIManagerModule.
Therefore, in D24811838 (https://github.com/facebook/react-native/commit/803a26cb003e6b790e3a1ab31beb0c95795fff0c) fkgozali launched a fix to the infra that would avoid creating the non-TurboModule object in the first place. Today, we're launching this optimization.
Reviewed By: fkgozali
Differential Revision: D25621570
fbshipit-source-id: dedba4d5ac6fcf2ec3c31e7163a6a226065c708b
Summary:
This diff fixes a race condition in the execution of FabricUIManager.StartSurface method.
The rootcause is that startSurface is executing getViewportOffset from a background thread.
changelog: [internal]
Reviewed By: shergin
Differential Revision: D25617154
fbshipit-source-id: 9351201088164e74bb0b9454e30651e1de0da912
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
Valentin Shergin
Samuel Susla
Luna Wei
Ramanpreet Nara
empyrical
Kevin Gozali
David Vacca
Javier Fraire
Ron Edelstein
doniwinata0309
Moti Zilberman
Keion Anvaripour
Mike
