Summary:
When there are multiple sticky headers, ScrollViewStickyHeader should push up the header above it when it gets to the top.
This behavior was accidentally changed in D21948830 (https://github.com/facebook/react-native/commit/fa5d3fb6b8c561b749f3e86316d06543a52dcc1c) when this component was fixed to work in Fabric.
This diff added a new variable `_shouldRecreateTranslateY`, which determines whether the `translateY` value should be recreated on render. `_shouldRecreateTranslateY` was not being set to true during `setNextHeaderY`, so the next header's Y value was never accounted for at render.
Changelog:
[General][Fixed] Fix ScrollViewStickyHeader to push up header above it
Reviewed By: lunaleaps
Differential Revision: D27277829
fbshipit-source-id: 83c9aacd454be178649bf8d060d1a5c750f4060f
Summary:
Updating the regex to avoid a potential regular expression denial-of-service vulnerability.
Changelog: Update validateBaseUrl to use a more robust regular expression. Fixes CVE-2020-1920, GHSL-2020-293
Reviewed By: lunaleaps
Differential Revision: D25507604
fbshipit-source-id: c36a03c456881bc655c861e1a2c5cd41a7127c9d
Summary:
This addesses a few issues I noticed while migrating my app to the new build-time codegen on iOS.
1. I noticed random failures because of codegen on iOS. This is mostly due to the fact the codegen output files are not specified in the xcode script. The only reason it works relatively fine currently is because the codegen output is inside the input files directory. This has the side effect of causing files to be regenerated every build, then causes all core modules to be recompiled which adds up a significant amount of time to rebuilds. To fix this I added the generated files to the script phase output and moved the FBReactNativeSpec dir outside of the codegen source (Libraries). I moved it to the React directory as this seemed to make sense and is where a lot of iOS files are as well as the core modules. Note this might require internal changes. This removes the circular dependency between our build phase input and output so consecutive builds can be cached properly.
2. Add `set -o pipefail` to the xcode script, this helped propagate errors properly to xcode because of the `| tee` pipe so it fails at the script phase and not later with a header not found error. Also add `2>&1` to pipe stderr to stdout so errors are also captured in the log file.
3. Add the `-l` flag to the bash invocation to help finding the yarn binary. With my setup yarn is added to the system PATH in my user .profile. Adding this file will cause bash to source the user environment which xcode scripts does not by default. I think this will help with most setups.
4. If yarn is not found the `command -v yarn` would make the script exit without any output because of the -e flag. I made a change to ignore the return code and check later if YARN_BINARY is set and have an explicit error message if not.
[iOS] [Fixed] - Make codegen more reliable on iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/30792
Test Plan:
Tested various project states to make sure the build always succeeds in RN tester:
- Simulate fresh clone, remove all ignored files, install pods, build
- Build, delete FBReactNativeSpec generated files, build again
- Build, build again, make sure FBReactNativeSpec is cached and not rebuilt
- Make the script fail and check that xcode shows the script error logs properly
Note: Did not test fabric
Reviewed By: fkgozali
Differential Revision: D26104213
Pulled By: hramos
fbshipit-source-id: e18d9a0b9ada7c0c2e608d29ffe88087f04605b4
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:
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.
[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
```
Reviewed By: fkgozali
Differential Revision: D24058507
Pulled By: hramos
fbshipit-source-id: 8b2ea3694e6cb9aa23f83f087e2995fd4320e2bb
Summary:
This is an extension of https://github.com/facebook/react-native/issues/29798 which was reverted due to cases where the soft keyboard could not be dismissed.
## 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
-->
[General] [Fixed] - Avoid eating clicks/taps into ScrollView when using physical keyboard
Pull Request resolved: https://github.com/facebook/react-native/pull/30374
Test Plan: Validated with iOS simulator that taps on default ScrollView will dismiss soft keyboard and be eaten if open, but taps are not eaten when emulating a connected physical keyboard.
Reviewed By: kacieb
Differential Revision: D24935077
Pulled By: lyahdav
fbshipit-source-id: 19d9cf64547e40a35f9363896e3abbdccb95b546
Summary:
Move the codegen invocation out of Podfiles and into the FBReactNativeSpec Pod itself. With this change, developers do not need to modify their existing project's Podfiles, and yet the codegen will be integrated into their projects automatically by way of the FBReactNativeSpec Pod.
This is accomplished in part by injecting a script build phase into the Pods Xcode project that is generated by CocoaPods. The build phase will save the output of the codegen script to a log in the derived files directory. The codegen will be executed if the codegen log file is not present, or if the contents of the Libraries directory has changed.
The codegen will thus be invoked in these situations:
**RNTester:**
* When `packages/rn-tester/RNTesterPods.xcworkspace` is built, if the codegen output logfile is not present or if the input files have changed.
**OSS React Native apps:**
* When `ios/AwesomeProject.xcworkspace` is built, if the codegen output file is not present or if the input files have changed. Normally, this should not happen, as we do not expect folks to update the contents of `node_modules/react-native/Libraries`.
Pull Request resolved: https://github.com/facebook/react-native/pull/30449
Changelog: [Internal] - Moved codegen invocation out of Podfile and into FBReactNativeSpec Pod
Reviewed By: fkgozali
Differential Revision: D25138896
fbshipit-source-id: 4779f822459cea2c30fd544eee19a49e8d80153d
Summary:
When shouldEnableLoggingForRequestUrl is false, ImageTelemetry is not initialized, and no logging is done.
* Replace `- (NSString *)loaderModuleNameForRequestUrl:(NSURL *)url` with `- (BOOL)shouldEnableLoggingForRequestUrl:(NSURL *)url`
* Rename RCTImageLoaderInstrumentableProtocol.h -> RCTImageLoaderLoggableProtocol.h
Reviewed By: fkgozali
Differential Revision: D24523984
fbshipit-source-id: a5463eceea1c40f9452b0ad2ee6bf047f71a02c1
Summary:
Adds an annotation in the performance logger that indicates if the component was rendered using Fabric or not.
Changelog: [internal]
Reviewed By: JoshuaGross, ShikaSD
Differential Revision: D24596131
fbshipit-source-id: 489f3a03f09c5425c870678ed593ee8f16a2d98b
Summary:
This diff cleans up a bunch of code in `symbolicateStackTrace`. According to motiz88 all of it is dead code and I can confirm symbolication does not break with the changes applied.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D24585849
fbshipit-source-id: 5b2c76f56dbbbf27449ce1472cdd0271ed230c35
Summary:
In D24521951 (https://github.com/facebook/react-native/commit/2ff1d4c041ee662871a84363a3f85a8bc9e857ce) I refactored the JS-side queueing for NativeAnimated API calls, and used randomized IDs for queueing. This could cause bugs or unexpected behavior, and potentially crashes, if there's ever a collision in random numbers generated or
a collision between random number and one of the deterministic numbers generated in createAnimatedComponent.
In this diff I make both of them namespaced with a string, and deterministic, to eliminate any potential collisions. This could also be slightly faster (but not meaningfully) since we're not relying on Math.random.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D24553557
fbshipit-source-id: 8b765e21597ad4f8e641453c1f9f90bdf1ee022f
Summary:
This defines a separate codegen entrypoint for the entire react-native repo, picking up all JS files under Libraries/ subdir. Buck can then build the codegen library targets. This is a pre-req for removing the checked in Java spec files for NativeModules.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D24518569
fbshipit-source-id: 2ece53c7274698e2431a00e590fad213e3a0bece
Summary:
Prepares for production experimentation of a reimplementation of the `Text` component that uses `Pressability` and React Hooks.
After I validate the new experimental implementation of `Text`, I will revert these changes and replace `Text.js` with the new implementation.
Changelog:
[Internal]
Reviewed By: nadiia, kacieb
Differential Revision: D24490569
fbshipit-source-id: 1ee4af72fcbda1b1d283a81c6bdf3fe67aa17e73
Summary:
This small PR fixes few "no-unused-var" issues and and removes two old entries for no longer existing files from the `.eslintignore`.
## Changelog
[Internal] [Fixed] - Lint: fix few "no-unused-var" warnings for imports
Pull Request resolved: https://github.com/facebook/react-native/pull/30157
Test Plan: Successfully run of `yarn lint` script. Warnings count has been reduced from `61` to `58`.
Reviewed By: yungsters
Differential Revision: D24288226
Pulled By: appden
fbshipit-source-id: 06e4ef015a331e3f2eac3b9aa6f757a3764e3ed9
Summary:
There's no reason for us to have lint ignores for `react-native/codegen/react-native-modules`. This diff removes all such ignores. I'll address any actual problems with the specs in subsequent diffs.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24529238
fbshipit-source-id: bbd2f4fb5dace65d803a8f93bd0d9a1c5a1cfb34
Summary:
I believe the old method of queueing these operations for Fabric is causing crashes because "connectNode" is on a separate JS queue from setting up nodes.
In hindsight, this seems silly. We must ensure that nodes are created before they're connected, and we weren't doing that?
Using a single queue is conceptually simpler, should be easier to reason about, and should fix some crashes.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24521951
fbshipit-source-id: f6c38ac0023faa28414063d8b96daf32ba95524d
Summary:
The method `imageURLLoaderForURL` can be called from multiple threads. This adds a mutex to make sure that _loaders is initialized with a non-nil value only once.
We'll only lock this mutex at one point in time as long as `_loadersProvider()` gives a value, so the mutex doesn't affect performance.
Changelog: [iOS][Fixed] Synchronize RCTImageLoader loaders initialization
Reviewed By: fkgozali
Differential Revision: D24513083
fbshipit-source-id: b89ef8a82729eda508162b01f7fdaa8a291f40d0
Summary:
Refines the exported type of `Text` so that it is more accurate.
Instead of `HostComponent<TextProps>` (which is not exactly accurate), we use the recently introduced types: `NativText` and `NativeVirtualText`.
Changelog:
[Changed][General] - Refined Flow type for `Text` component.
Reviewed By: nadiia
Differential Revision: D24486720
fbshipit-source-id: fad114fd14335933ebc2f7430d7b8b7838b6b523
Summary:
Removes the generated FBReactNativeSpec files from source control.
## Generating FBReactNativeSpec files
The files will be generated automatically by CocoaPods when the `RNTesterPods` Xcode workspace is generated:
```
cd packages/rn-tester
pod install
```
The spec files can be re-generated by invoking the script directly:
```
./scripts/generate-native-modules-specs.sh
```
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D24261167
fbshipit-source-id: acb7ac856e5e519932e4f587f79e24f49cd84a91
Summary:
On Hermes, RN can directly use the Promise from global w/o the need of polyfilling it.
PromiseRejectionTrackingOptions are extracted to its own file so it can be shared by
both codepaths and preserve the behaviors that it's only imported on dev.
Some zero-overhead type gymnastics are used to flow-type it properly.
Changelog:
[General] - made promise polyfill conditionalized on Hermes
Reviewed By: cpojer
Differential Revision: D24068716
fbshipit-source-id: 3e0b1675493908324f27cc5b7300d8cc42a03acc
Summary:
If a native module schema has `excludedPlatforms` defined, honor it and skip the module that doesn't belong to the platform.
E.g. NativeImagePickerIOS shouldn't generate anything for Android codegen output.
Similarly, IntentAndroid shouldn't generate anything for iOS codegen output.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D24373092
fbshipit-source-id: cfeb455a18c92f60191d988af2e9ce7ea5021304
Summary:
Adding support to the pointData to Android React Native
Changelog: [internal]
Reviewed By: swillard13
Differential Revision: D24256346
fbshipit-source-id: b970f771047cff580d9ebe7d6e2ad737394d6416
Summary:
NOTE: Flow and Jest won't pass on this diff. Sandcastle, should, however, be green on D24236405 (i.e: the tip of this stack).
## Changes
1. NativeModule generators now use the new RN Codegen NativeModule schema.
2. Tangential: We're no longer removing the `Native` prefix from the NativeModule filename, assuming that that's the module name (problem: wrong), and prefixing again with Native (problem: redundant), when we're generating code. Instead, like the internal codegen, we simply pass the filename to the Codegen output. Our linters enforce that all NativeModule specs are contained with files that start off with `Native`.
3. `GenerateModuleCpp` was fixed to use the actual module name as opposed to the spec name. I added a comment inline.
Changelog: [Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: PeteTheHeat
Differential Revision: D24236405
fbshipit-source-id: ccd6b5674d252c350be0ec8a86e7ca5f2f614778
Summary:
In D24324247 (https://github.com/facebook/react-native/commit/56c363e39af6488904cbfd2046314c45babeb0f4), I split NativeLinking into NativeLinkingManager and NativeIntentAndroid. There was this line in NativeLinking.js, that I didn't migrate correctly:
```
export default ((Platform.OS === 'android'
? TurboModuleRegistry.getEnforcing<Spec>('IntentAndroid')
: TurboModuleRegistry.getEnforcing<Spec>('LinkingManager')): Spec);
```
I separated this conditional statement into two others:
```
export default TurboModuleRegistry.getEnforcing<Spec>('IntentAndroid');
export default TurboModuleRegistry.getEnforcing<Spec>('LinkingManager');
```
The problem here is that now on iOS, we're hard requiring IntentAndroid, and on Android, we're hard requiring LinkingManager. Understandably, this started throwing errors in our e2e infra. This diff fixes this problem by:
1. Changing the relevant `getEnforcing` calls into `get` calls.
2. Wrapping all usages of NativeIntentAndroid, and NativeLinkingManager, which are already guarded by `Platform.OS` checks, by a nullthrows. This should satisfy flow. **Note:** NativeIntentAndroid is only used on Android, where it must be available. Similarly, NativeLinkingManager is only used on iOS, where it must be available.
Changelog: [Internal]
build-break
overriding_review_checks_triggers_an_audit_and_retroactive_review
Oncall Short Name: fbandroid_sheriff
Differential Revision: D24338558
fbshipit-source-id: b0d22cba77e67837834269deaa317dc73d2457dc
Summary:
Although the interface for both NativeModules is the same, we'd like to enforce 1 `TurboModuleRegistry.get` call per NativeModule spec file. Therefore this diff splits the one spec into two.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24325260
fbshipit-source-id: f18718e4235b7b8ccbfc44a7e48571ecf483a36c
Summary:
The iOS and Android NativeModules are very different. It's better to split the two interfaces, than to have one merged interface.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24324247
fbshipit-source-id: 097273829ffc719eff006ed2dde55f0dd6bd7d95
Nicola Corti
Lorenzo Sciandra
Luna Wei
Lorenzo Sciandra
Kacie Bawiec
Neal Poole
Mike Grabowski
Janic Duplessis
Héctor Ramos
empyrical
Nick Gerleman
Samuel Susla
Koichi Nagaoka
Luke Walczak
Paige Sun
Rubén Norte
Christoph Nakazawa
Oleksandr Melnykov
Joshua Gross
Kevin Gozali
Tim Yung
Rick Hanlon
simek
Ramanpreet Nara
Hugo Cuvillier
Xuan Huang
Pieter Vanderwerff
Dmytro Voronkevych
