Summary:
This diff changes the type of the SwipeRefreshLayoutManager.size prop from Int to String in Fabric.
The current implementation of this prop allows JS developers to use "int" type when fabric is enables and "int or string" types when using Fabric is disabled.
Since long term we want to only support "string" type for this prop, I'm changing the type of the prop to be String.
After my diff Fabric will start supporting only "string" types, non fabric screens will keep supporting "int or string" values.
**Will this break production?**
No, because there are no usages of RefreshControl.Size prop in fbsource
**What about if someone start using this prop next week?**
IMO It's very unlikely because of the nature of this prop, I will be monitoring next week and if there's an usage it will be detected by flow when trying to land D25933457.
Changelog: [Android][Changed] - RefreshControl.size prop changed its type to string, the valid values are: 'default' and 'large'
Reviewed By: JoshuaGross
Differential Revision: D25933458
fbshipit-source-id: 55067d7405b063f1e8d9bb7a5fd7731f5f168960
Summary:
Changelog:
[Internal][Fixed] - Add a default value for the cache breaker value
Reviewed By: fkgozali
Differential Revision: D25907137
fbshipit-source-id: 243346cbc67d1a85519bb469f4d68d61676ba547
Summary:
Restore the `android_hyphenationFrequency` attribute in the view config for `Text`. This was accidentally dropped by D23708205 (https://github.com/facebook/react-native/commit/06ce64356594a921cd9ae4f71c15dd56dd0e53a3) (06ce643565).
Changelog:
[Android][Fixed] - Restore `android_hyphenationFrequency` on `Text`.
Reviewed By: mdvacca
Differential Revision: D25889971
fbshipit-source-id: 622eef618370efdd9a8b060ccd3272e25de218fa
Summary:
Changelog: [internal]
Revert a change introduced in https://github.com/facebook/react-native/pull/30333 where rickhanlonii asked it to be reverted as well.
The change breaks sticky header in Fabric.
Reviewed By: rubennorte
Differential Revision: D25883861
fbshipit-source-id: b01305c6def390d0664c7be939ab3fc72186a07a
Summary:
allow-large-files
Changelog: [iOS] Remove iOS10/tvOS10 suppport
Similar to D19265731 (https://github.com/facebook/react-native/commit/674b591809cd1275b5f1c4d203c2f0ec52303396) for iOS9.
I just ran this command:
`find . -type f -exec sed -i '' 's/{ :ios => "10.0" }/{ :ios => "11.0" }/' {} +`
and then updated pods
Reviewed By: fkgozali
Differential Revision: D25693227
fbshipit-source-id: 0073d57ecbb268c52d21962cef202316857bcbd2
Summary:
This change contains the suppressions for the up coming v0.142.0 Flow release.
The new suppressions are a result the following changes:
* Disallow flowing functions or inexact objects to indexed objects to improve object soundness. This can cause errors if you are passing a function or inexact objects when an indexed object is expected.
* Flow now processes imports before checking the body of a file. In some rare cases this can expose previously skipped errors due to the processing order.
Reviewed By: mroch
Differential Revision: D25820434
fbshipit-source-id: 59cc1d852ffc8cc39f0d5112ce485fb33f05c092
Summary:
Adds types to Event Emitters and migrates the most relevant modules using them in `react-native`.
The most relevant file of this diff is `react-native/Libraries/vendor/emitter/__flowtests__/EventEmitter-flowtest.js` with the Flow tests showing and testing the behavior of the new types
Changelog: [Internal] Add types for Event Emitters and subclasses
Reviewed By: motiz88
Differential Revision: D25587936
fbshipit-source-id: feeb09f9ad15d383cdd82deaaaba0d12b94e868b
Summary:
The `Systrace` and `Refresh` dependencies are injected into the `metroRequire` implementation by assigning the values to e.g. `require.Systrace = ...`.
The issue with this approach is that some `require` implementations might not support extending the `require` object or doing so results in a degraded performance. An example where this is the case is Hermes where changing the `require` object forces Hermes to opt out of the static require optimization.
This diff extends Metro so that the `Systrace` and `Refresh` implementation can either be injected by assigning to `require.Systrace` or by exposing the implementation in the global scope. It further changes the `Systrace` and `Refresh` modules to inject the instances using the global scope instead of extending `require`.
Changelog:
[Internal][Changed] - Expose Systrace and ReactRefresh as globals instead of extending require.
Reviewed By: motiz88
Differential Revision: D25693381
fbshipit-source-id: 254d66d43e7a56d3310cf1a17d5146b8d1307562
Summary:
This prevents having to modify too many files when we add the proper typing for that module
Changelog: [Internal]
Reviewed By: nadiia
Differential Revision: D25586848
fbshipit-source-id: 16001ada4a37a58f83b6e5a4400daebf9257be72
Summary:
Migrates all usages of `NativeEventEmitter` to `NativeEventEmitter<$FlowFixMe>`.
This prevents having to modify a very large number of files in the same change that adds support for typed events. It adds an unused typed parameter to `NativeEventEmitter` so we can change all usages to add `$FlowFixMe`.
Changelog: [Internal]
Reviewed By: nadiia
Differential Revision: D25575774
fbshipit-source-id: c7979e1502e980401d9c03456282eba333c1606d
Summary:
Migrates `CodegenTypes` and its transitive dependencies to Flow strict to unblock this mode in Native Modules and Native Components.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D25540629
fbshipit-source-id: 7bed2ee58af7a789b50932734c7a86cf1719e2c5
Summary:
This new type will be valid in Flow strict mode and can be used by native modules and components to replace `Object`, with the same semantics.
This unblocks the migration of the most modules in the React Native package to Flow strict.
Changelog: [Internal] Add UnsafeObject type compatible with Flow strict mode to use in native modules and components
Reviewed By: RSNara
Differential Revision: D25540631
fbshipit-source-id: 60b80bbc84a53aecc747e3a1799cdf551e1859cd
Summary:
Consolidate CocoaPods codegen scripts under a single `use_react_native_codegen!` method in `react_native_pods.rb`.
This is the first step towards making the codegen scripts library-agnostic. There are still a handful of hardcoded assumptions in place (e.g. the output directory structure, the use of a separate directory for components), but with some work one would be able to add codegen support to arbitrary CocoaPods podspecs.
The codegen script no longer takes a CODEGEN_PATH argument, and will instead attempt to use the local react-native-codegen package if available, and fallback to using the node_modules/react-native-codegen package if not.
## Usage
The `use_react_native_codegen!` method has two arguments:
- `spec`, a pod [Specification](https://www.rubydoc.info/github/CocoaPods/Core/Pod/Specification) object.
- `options`, an optional object. Supported keys:
- `:srcs_dir`, the path to your JavaScript sources. Your native module or component specs should be located somewhere in this directory.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25728053
fbshipit-source-id: feec587b656d5b220598ce6196ea6bb34a9580a9
Summary:
Even though replacing an error with a warning does not look like a future-proof solution here are the reasons for this:
* The measuring operation might just fail because of the async nature of React Native. And here, from my understanding, we don't even have a good reason for measuring. Auto-scrolling to selected textinput (which is the reason for this code, AFAIK) is a standard feature that OS does for all text input. I suspect that this (very old) feature was built in a timeframe where this system feature was originally broken (sometime before 2016).
* This product-facing API does not have an error-callback, so just loggin an error here is as (not) actionable as logging a warning.
* The error callback was never implemented in the pre-Fabric world, so it *never* got called for years, and now when Fabric is starting calling in some cases, it is being "punished" for this. In the next diff, I will try to retrofit this feature back to Paper to reach parity with Paper.
Changelog: [Internal]
Differential Revision: D25700156
fbshipit-source-id: 319a146b17cc2130848148ad11adbde16e86c5d5
Summary:
## Changes
All `rn_library(codegen_modules = True)` must now also specify native_module_android_package_name, like so:
```
rn_library(
name = "FBAuth"
codegen_modules = True,
native_module_spec_name = "Foo",
native_module_android_package_name = "com.facebook.fbreact.specs",
)
```
This will generate the FBAuth Java spec files under the appropriate directory: "com/facebook/fbreact/specs". It will also make the code-generated specs have the appropriate package name: "com.facebook.fbreact.specs".
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D25723176
fbshipit-source-id: 6efec1cbee43d70110c0ef23e2422e08609b61d4
Summary:
The `isFabric` method used in createAnimatedComponent is unreliable (another reason in a long list of reasons why you should not duplicate this code elsewhere, and why we want to delete it ASAP).
In particular, during the first render, the ref component has not been set yet, so we /cannot/ detect if the component is Fabric or non-Fabric and assume it's non-Fabric.
In Fabric, this causes `collapsable` and `nativeID` values to change after the first render.
To reduce this re-rendering, but not eliminate it for all components, I've introduced a flag that indicates if a component will /never/ be flattened. In particular, Image components, ScrollViews, Text cannot ever be flattened,
so we should always pass `collapsable:false` and the same nativeID prop for those components. For Animated <View>s and other components, the re-rendering issue is still a problem in Fabric for now.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25720322
fbshipit-source-id: fe3234d8ae974911a2b5f82e4f6a093216f43d4b
Summary:
Changelog:
[Internal][Added] - Create a general utils for assets and add a cache breaker utility to set/get a urlparam for remote assets.
Reviewed By: motiz88
Differential Revision: D25521331
fbshipit-source-id: 042e52a27e826bc9993e80bc68cc6fc68abaf224
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:
## 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:
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:
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:
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:
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:
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:
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:
This commit:
* Generate Fabric component Java files along side Java NativeModule specs, when `USE_FABRIC=1` is set
* Adjust the component codegen to place output files in a subdir based on package name
* Adjust existing Buck targets to filter the right nativemodule vs component java files (this avoids duplicated symbols)
* Compiles the Java output during build time on RNTester/ReactAndroid (Gradle)
Not in this commit:
* Fabric C++ files
* Removing checked-in generated component files.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25416614
fbshipit-source-id: fd670ead2198c9b5a65812c692b7aed9f3d7cd58
Summary:
Changelog: [internal]
In D25386708 (https://github.com/facebook/react-native/commit/408bcdeedbc89cc9b90de73684d3f691b8e2e724) `synthesize bridge` was removed. But two modules actually depend on this.
`RCTFileReaderModule` and `VerseThreadView` which both use it.
Reviewed By: RSNara
Differential Revision: D25423574
fbshipit-source-id: daf95d9b27841cf8d205d8ea2666d5aa69a6d720
Summary:
This is a codemod. All these NativeModules demand access to the bridge. However, they don't use it.
Changelog: [Internal]
Reviewed By: PeteTheHeat, RoelCastano
Differential Revision: D25386708
fbshipit-source-id: f05f4777d2527e96e53581e7ac58f6be47411dce