Summary:
This PR fixes a few issues with the Appearance API (as noted here https://github.com/facebook/react-native/issues/28823).
1. For the Appearance API to work correctly on Android you need to call `AppearanceModule.onConfigurationChanged` when the current Activity goes through a configuration change. This was being called in the RNTester app but not in `ReactActivity` so it meant the Appearance API wouldn't work for Android in newly generated RN projects (or ones upgraded to the latest version of RN).
2. The Appearance API wasn't working correctly for brownfield scenarios on Android. It's possible to force an app light or dark natively on Android by calling `AppCompatDelegate.setDefaultNightMode()`. The Appearance API wasn't picking up changes from this function because it was using the Application context instead of the current Activity context.
3. The Appearance API wasn't working correctly for brownfield scenarios on iOS. Just like on Android its possible to force an app light or dark natively by setting `window.overrideUserInterfaceStyle`. The Appearance API didn't work with this override because we were overwriting `_currentColorScheme` back to default as soon as we set it.
## 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
-->
### Fixed
https://github.com/facebook/react-native/issues/28823
* [Android] [Fixed] - Appearance API now works on Android
* [Android] [Fixed] - Appearance API now works correctly when calling `AppCompatDelegate.setDefaultNightMode()`
* [iOS] [Fixed] - Appearance API now works correctly when setting `window.overrideUserInterfaceStyle`
Pull Request resolved: https://github.com/facebook/react-native/pull/29106
Test Plan: Ran RNTester on iOS and Android and verified the Appearance examples still worked [correctly.](url)
Reviewed By: hramos
Differential Revision: D31284331
Pulled By: sota000
fbshipit-source-id: 45bbe33983e506eb177d596d33ddf15f846708fd
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:
This diff refactors the UIManagerHelper.getUIManager method to return null when there's no UIManager registered for the uiManagerType received as a parameter.
This is necessary to workaround: https://github.com/facebook/react-native/issues/31245
changelog: [changed] UIManagerHelper.getUIManager now returns null when there's no UIManager registered for the uiManagerType received as a parameter
Reviewed By: fkgozali
Differential Revision: D28242592
fbshipit-source-id: c3a4979bcf6e547d0f0060737e41bbf19860a984
Summary:
Hermes has a way to set up a callback that is invoked when a fatal error
such as Out of Memory occurs. It is a static API that should be called at
most once, so it uses `std::call_once` to achieve that.
The fatal error handler is simple, it just uses glog to log an error message
to logcat, then aborts (using `__android_log_assert`).
The reason is typically very helpful for understanding why `hermes_fatal` was called.
Changelog:
[Android][Internal] - Print a logcat message when Hermes has a fatal error
Reviewed By: mhorowitz
Differential Revision: D25792805
fbshipit-source-id: 45de70d71e9bd8eaa880526d8835b4e32aab8fe3
Summary:
Currently the dimensions are created once, and then cached. This change will reload the dimensions when the device orientation changes to insure that dimension update events follow orientation changed events.
this should help address the following issues, that I know of:
https://github.com/facebook/react-native/issues/29105https://github.com/facebook/react-native/issues/29451https://github.com/facebook/react-native/issues/29323
## 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
-->
[Android] [Fixed] - Dimension update events are now properly sent following orientation change
Pull Request resolved: https://github.com/facebook/react-native/pull/30324
Test Plan: Open up RNTester app. Select the Dimensions API list item. Rotate the device and verify that the dimensions are correct based on orientation.
Reviewed By: fkgozali
Differential Revision: D24874733
Pulled By: ejanzer
fbshipit-source-id: 867681ecb009d368a2ae7b67d94d6355e67dea7b
Summary:
This pr fixes: https://github.com/facebook/react-native/issues/30123 .
When secureTextEntry is true, setInputType will set the inputType of textInput to password type.
Password type default font-family will be monospace font, so we need to setTypeface after the setInputType.
## Changelog
[Android] [Fixed] - Font family is not apply when secureTextEntry is true.
Pull Request resolved: https://github.com/facebook/react-native/pull/30164
Test Plan:
Before this pr:
After this pr:
Please initiated a new project and replaced the App.js with the following code:
```
iimport React from 'react';
import {SafeAreaView, TextInput} from 'react-native';
const App = () => {
return (
<SafeAreaView>
<TextInput
id={'email'}
placeholder={'Email'}
secureTextEntry={false}
style={{fontFamily: 'Helvetica', fontSize: 14, fontWeight: '400'}}
/>
<TextInput
id={'password'}
placeholder={'Password'}
secureTextEntry={true}
style={{fontFamily: 'Helvetica', fontSize: 14, fontWeight: '400'}}
/>
</SafeAreaView>
);
};
export default App;
```
Thanks you so much for your code review!
Reviewed By: cpojer
Differential Revision: D24686222
Pulled By: hramos
fbshipit-source-id: 863ebe1dba36cac7d91b2735fe6e914ac839ed44
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:
Since iOS 14 refresh control is sometimes visible when it shouldn't. It seems to happen when it is removed and added back to the window. This repros easily when using react-native-screens with react-navigation tabs. Inactive tabs are detached from the window to save resources.
Calling endRefreshing when refresh control is added to the window fixes the layout. It will also be called on first mount where it is not necessary, but should be a no-op and didn't cause any issues. I also decided to call it for all ios versions, although it is only needed on iOS 14+ to avoid forking behavior more.
## Changelog
[iOS] [Fixed] - Fix RefreshControl layout when removed from window
Pull Request resolved: https://github.com/facebook/react-native/pull/31024
Test Plan:
Before:
https://user-images.githubusercontent.com/2677334/108666197-93ea5a80-74a4-11eb-839b-8a4916967bf8.mov
After:
https://user-images.githubusercontent.com/2677334/108666223-9ea4ef80-74a4-11eb-8489-4e5d257299c8.mov
Reviewed By: shergin
Differential Revision: D26590759
Pulled By: PeteTheHeat
fbshipit-source-id: b8c06068a24446b261cbeb88ff166289724031f1
Summary:
allow-large-files
RN Tester is using an old version of Flipper. This will help testing regressions in the latest version (which is installed when starting a new project). This also fixes an issue where libevent is incompatible between the one in flipper and when using hermes on iOS. To fix it I changed to use the version published on cocoapods instead of using a local podspec (see https://github.com/facebook/flipper/issues/1916).
[General] [Changed] - Update flipper
Pull Request resolved: https://github.com/facebook/react-native/pull/31010
Test Plan:
- Tested that RN tester builds and flipper works with hermes enabled / disabled and fabric on iOS
- Tested that RN tester builds and flipper works on Android
Reviewed By: fkgozali
Differential Revision: D26592317
Pulled By: PeteTheHeat
fbshipit-source-id: 2cd278c7a51b1859dab0465846b061221f07d3f6
Summary:
Currently, Codegen bash wrapper (`generate-specs.sh`) for Xcode invokes JS-based Codegen tooling via `yarn --silent node <...>`. This breaks both:
- when Yarn is not installed (if NPM is used), for obvious reasons
- when Yarn v2 ("Berry") is active
This PR changes the way `generate-specs.sh` locates `node` executable to the following algorithm:
- use the path provided in the `NODE_BINARY` env var
- if `NODE_BINARY` env var is not defined, find `node` with `command -v node`
## Changelog
[iOS] [Fixed] - Fix Codegen silently failing when Yarn is not installed, or when Yarn v2 is active.
Pull Request resolved: https://github.com/facebook/react-native/pull/30781
Test Plan:
### Case 1 (no Yarn installed)
1. Ensure `yarn` is not present in PATH
2. Run Xcode build
3. Check that Codegen artifacts are produced
### Case 2 (Yarn v2 is used)
1. Ensure `yarn` is running in the v2 ("Berry") mode
2. Run Xcode build
3. Check that Codegen artifacts are produced
Reviewed By: fkgozali
Differential Revision: D26187081
Pulled By: hramos
fbshipit-source-id: 77d3089f523b8c976d8223b77ff9553cb6cf68a5
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:
The codegen helper script, `generate-specs.sh`, is being used to generate code for the FBReactNativeSpec and React-Fabric/rncore pods. The script now supports overriding several defaults by setting the following environment variables:
- SRCS_DIR: Path to JavaScript sources, defaults to $RN_DIR/Libraries/
- LIBRARY_NAME: Defaults to FBReactNativeSpec
- MODULES_OUTPUT_DIR: Defaults to Libraries/$LIBRARY_NAME/$LIBRARY_NAME
- COMPONENTS_LIBRARY_NAME: Defaults to rncore
- COMPONENTS_OUTPUT_DIR: Defaults to ReactCommon/react/renderer/components/$COMPONENTS_LIBRARY_NAME
The CocoaPods codegen integration has been updated to take advantage of these.
**Example CocoaPods usage:**
```
# packages/rn-tester/NativeModuleExample/RNTesterSpecs.podspec
Pod::Spec.new do |s|
s.name = "RNTesterSpec"
# ...
use_react_native_codegen!(s, { :srcs_dir => __dir__, :modules_output_dir => __dir__ })
end
```
Changelog:
[Internal]
Reviewed By: fkgozali
Differential Revision: D25738466
fbshipit-source-id: c68f5a3cd0996283a7af287e992e2f973024f44c
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:
The TurboModuleUtils.h includes "folly/Optional.h" which is not used and creates an unnecessary dependency on Folly.
In this PR we remove this unnecessary include.
It is required for the https://github.com/microsoft/react-native-windows/pull/6804 where we add an experimental support for the C++ TurboModules. While the C++ TurboModules use the same JSI and TurboModule code defined in react-native, we provide a layer that let them to work over the ABI-safe Microsoft.ReactNative.dll boundary. The RNW Nuget distribution with DLL files includes a few source files to create native/turbo modules that work through the ABI-safe API. The TurboModuleUtils.h is one of such files. By removing the dependency on Folly we reduce requirements for the native module code. After this PR is merged we will remove the fork of the TurboModuleUtils.h added in https://github.com/microsoft/react-native-windows/pull/6804.
## Changelog
[Internal] [Fixed] - Remove dependency on Folly in TurboModuleUtils.h
Pull Request resolved: https://github.com/facebook/react-native/pull/30672
Test Plan:
The change does not bring any functional changes. It may only affect code compilation where some code may depend on TurboModuleUtils.h when it needs the "folly/Optional.h". The fix is add the `#include <folly/Optional.h>` there explicitly.
I had run the iOS tests and they passed:
```
yarn
pod install in packages\rn-tester
./scripts/objc-test.sh test
```
Reviewed By: mdvacca
Differential Revision: D25758927
Pulled By: fkgozali
fbshipit-source-id: 347d8f6bc333a3df67095ea0dc7221c818432fab
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:
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:
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
https://github.com/facebook/hermes/releases/tag/v0.7.2 is out so we can bump the pod version 🎉
Question:
Is `~> 0.7.2` too strict? Would `>= 0.7.2` be better?
Also, It doesn't look like we are restricting any version on the trunk?
Summary:
Just thought I'd add these instructions so devs don't have to check the docs. Also, it makes iOS match Android with instructions in the configuration files
## Changelog
N/A (in my opinion)
Pull Request resolved: https://github.com/facebook/react-native/pull/30461
Test Plan: N/A (because not a code change)
Reviewed By: hramos
Differential Revision: D25309687
Pulled By: TheSavior
fbshipit-source-id: a1907089b9d2e7fe6f2498ce27129c3ae65f7c9a
Summary:
The wrong value for the path to react-native-codegen was being used. The issue was introduced during the refactoring of this script for use in FBReactNativeSpec.podspec.
Changelog: [Internal]
Motivation:
Reviewed By: fkgozali
Differential Revision: D25290355
fbshipit-source-id: 5a46c680e7ea41157b03cf54a640a8816fb682b3
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:
Upgrading CLI to latest. This diff is intended to be cherry-picked to 0.64.
cc grabbou kelset alloy
[Internal] [Changed] - Bump CLI to ^5.0.1-alpha.0
Pull Request resolved: https://github.com/facebook/react-native/pull/30420
Test Plan: None
Reviewed By: MichaReiser
Differential Revision: D25063261
Pulled By: cpojer
fbshipit-source-id: e1788fd40db2b00daaf888e7b2afaf708ade5451
Summary:
Part of https://github.com/react-native-community/releases/issues/207
Migrate warnings in index.js to point to new lean core repos
NOTE: some npm modules has been transferred to new nom namespace, such as `react-native-picker/picker` `react-native-async-storage/async-storage` `react-native-masked-view/masked-view`.
Some lean core repo has been transferred to new repo, but its npm namespace remains the same. ex: clipboard module exists in react-native-clipboard/clipboard repo, but npm package name is still `react-native-community/clipboard` (they're planned to be migrated in the future)
## 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] [Changed] - Migrate warnings in index.js to point to new lean core repos
Pull Request resolved: https://github.com/facebook/react-native/pull/30422
Test Plan:
- Updated repo URL can be accessed
- Updated npm package can be installed
Reviewed By: rickhanlonii
Differential Revision: D25077750
Pulled By: cpojer
fbshipit-source-id: b736ea449835bdf3d2a2f85e5c86e5253b90db78
Summary:
Use pre-built react-native-codegen library from npm in the iOS app template.
Built react-native-codegen from source when used with RNTester.
Published react-native-codegen@0.0.6.
Changelog:
[iOS][Added] - Use react-native-codegen in iOS app template
[Internal] - Bump react-native-codegen: 0.0.6
Reviewed By: fkgozali
Differential Revision: D25128036
fbshipit-source-id: f294c23b9b911aae6f404edc01b62426fb578477
Summary:
Fixes https://github.com/facebook/react-native/issues/30415
This is a quick and dirty fix to unblock publish, of excluding a class from Javadoc generation that is importing a class current build logic cannot handle. This is not a long-term fix for the issue.
## 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] [Fixed] - Fix :ReactAndroid:androidJavadoc task
Pull Request resolved: https://github.com/facebook/react-native/pull/30417
Test Plan: Tested that the task now completes locally.
Reviewed By: lunaleaps
Differential Revision: D25041282
Pulled By: fkgozali
fbshipit-source-id: f774ab30a09db473178e2a51c77860e4985dd8e3
Summary:
Add the `react-native-codegen` source to the `react-native` npm package.
Instead of using `react-native-codegen` from npm, the iOS app template will now build the package from source. Doing so removes the need to carefully time `react-native-codegen` npm releases to oss `react-native` releases, as the codegen and the oss release will be cut at the same time.
Changelog: [Internal] - Removed react-native-codegen dependency from iOS app template
Reviewed By: TheSavior
Differential Revision: D24904655
fbshipit-source-id: a07932bc748e2afb9359de584181bcb9dd0810ea
Summary:
When running yarn install from the codegen directory it will reinstall all dependencies for the react-native workspace inside the react-native package. In my case this caused issues with metro because it would now have 2 copies of it (node_modules/metro and node_modules/react-native/node_modules/metro).
To avoid this copy the react-native-codegen source in a temporary directory and yarn install from there, then copy the built files back.
## Changelog
[Internal] - Build rn-codegen in a temporary directory
Pull Request resolved: https://github.com/facebook/react-native/pull/30292
Test Plan: Tested the script in an app with codegen enabled. Fresh install with rn-codegen not built, made sure no extra modules are installed under node_modules/react-native/node_modules.
Reviewed By: yungsters
Differential Revision: D24893216
Pulled By: fkgozali
fbshipit-source-id: 2c372b755632ea6f50ad5d4562248612b349a9a6
Summary:
For some interrupted animations we will execute a "final" mutation associated with the animation, if it exists. For example, "UPDATE" animations always have a final Update animation associated with them.
Some, however, do not. For example: INSERT animations do not have a final mutation associated by default. In these cases (before this diff) if the animation from opacity 0 to 1 was interrupted, the View will
appear "stuck" at some intermediate opacity. To mitigate that, we generate a synthetic "final" mutation at 100% progress through the animation if it is interrupted.
Changelog: [Internal]
Reviewed By: fred2028
Differential Revision: D24691151
fbshipit-source-id: d9730b8a3493a5eeac4de325e7e0a7a64f73c8a0
Summary:
Fix broken links in README by removing `.html` from any `reactnative.dev/docs`
## Changelog
General Fixed - Fixed broken links in README.md
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/30286
Reviewed By: hramos
Differential Revision: D24673358
Pulled By: cpojer
fbshipit-source-id: 726a4742c3ae19dc51f2490619d04934f8aa861d
Summary:
This PR makes it possible to build iOS applications with Hermes. Note that it doesn't work with `use_frameworks!` just yet.
Fixes https://github.com/facebook/react-native/issues/27845 (by downgrading iOS deployment target for RCT-Folly to 9.0)
Fixes https://github.com/facebook/react-native/issues/28810 (as above)
Checklist:
- [x] Adjust release scripts to create Hermes bytecode bundle
- [x] Release new Hermes npm package that includes iOS files (unreleased right now, if you want to try locally, you have to clone Hermes and `yarn link` its master to this project)
- [x] Test on a new React Native application in both Debug and Release (Device)
- [x] Test on an RNTester application in both Debug and Release (Device)
- [x] Add missing `i386` to Hermes framework and enable Bitcode
- [x] Inspect CI failures for possible regressions
- [x] Resolve Folly issue as reported https://github.com/facebook/react-native/issues/27845 and https://github.com/facebook/react-native/issues/28810
- [x] Release new Hermes and test against it that everything works
## Changelog
[IOS] [FEATURE] - Enable Hermes on iOS
[INTERNAL] - Upgrade to CocoaPods 1.10.0 to resolve Xcode 12.0 issues
[INTERNAL] - Upgrade to Xcode 12.0 on the CircleCI
[INTERNAL] - Fix building RNTester in Release mode
[INTERNAL] - Fix build-time errors of `libevent` with `use_frameworks!`
[INTERNAL] - Introduce `USE_HERMES` variable and test all RNTester configurations on the CI
[INTERNAL] - Do not fetch CocoaPods repository since we're using CDN anyway
Pull Request resolved: https://github.com/facebook/react-native/pull/29914
Test Plan:
Turn on `hermes_enabled` to true in your `Podfile`, install pods, and run the iOS application. Your app should be running Hermes now.
Preview: (note "Engine: Hermes")
<img width="395" alt="Screenshot 2020-09-09 at 19 22 32" src="https://user-images.githubusercontent.com/2464966/92631584-d7c01d80-f2d1-11ea-9b40-33d73db96a53.png">
Reviewed By: hramos
Differential Revision: D24684845
Pulled By: cpojer
fbshipit-source-id: 900cbe3bf9398a6fd4a773d552899a001bf5146b
Summary:
Historically, `UIScrollView`s in React Native do not cancel touches started on `UIControl`-based views (as normal iOS `UIScrollView`s do).
This diff implements this behavior.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D24661106
fbshipit-source-id: 1fb98d62f9e1528f11e7699d460aaefcec534e97
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/30265
The CocoaPods Specs mirror provided by Circle CI is no longer supported, and is no longer necessary, as of CocoaPods v1.8. We are already using the CDN in the Podfile, so the step may be removed from the Circle CI config.
Reference: https://circleci.com/docs/2.0/testing-ios/#optimizing-cocoapods
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24601585
fbshipit-source-id: c794102cf573e0cf47ae936bf3c1eb386e089315
Summary:
For over a month I've been searching for a crash that occurs during Android's native `dispatchDraw` method on View. The stack traces didn't show anything useful - everything in the stack trace was native Android code,
not React Native code.
This also seems to only repro on certain vendors, and only on a very few React Native screens - I'm still not sure why either of those are the case, but from my repro, a *very* specific set of interactions needs to happen
to trigger this crash. See comments inline and an example stack trace.
Luckily, the fix is trivial. Since this code is used for animations, accessibility, and a number of other important interactions, I'm gating this change for now.
In general we must be careful to only mutate the View hierarchy only when we /know/ for certain it is safe to do so. Indirectly mutating the View hierarchy during measure, onMeasure, layout, dispatchDraw, etc, can all be
very dangerous. This is one of the last "escape hatches" that can cause view hierarchy modifications unexpectedly, so I think it's a very good idea to "secure" this further, and only update props synchronously here - and
ensure that other MountItems like `Delete` are definitely /not/ executed here.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D24639793
fbshipit-source-id: b6219ce882e8d2204b4d10bf99f6a1120a33cb5a
Summary:
I've had my eyes on this optimization for a while: during TTRC especially, but really during any heavy render path, Fabric will create hundreds to thousands of MountItem class instances in order to construct a BatchMountItem.
This results in: hundreds/thousands of round-trip JNI calls, hundreds/thousands of Object allocations, etc. This will also result in increased memory and GC pressure.
Theoretically, by reducing the number of JNI calls and reducing allocations, we may be able to get some small wins in memory and CPU usage during very hot paths.
I am motivated to do this, in part, to indirectly measure the cost of JNI calls as well as allocating many objects vs an int buffer. I am unaware of such a measurement that we can use to make architectural decisions for React Native Android overall.
The other reason this could be a positive change: if it's successful and we can delete the old path, we'll be able to delete a bunch of Java classes entirely which is great for APK size wins.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D24631230
fbshipit-source-id: 86a46ffcaef4ecbec2e608ed226aed0b5c4b832e
Summary:
Cleaning up an old experiment, it was `static true` for a couple of months already.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D24642808
fbshipit-source-id: 50ba955490d848a9c1698e1c6d0c296e833386f3
Summary:
This re-uses the same logic as `logTaggedMarker` for `logTaggedMarkerWithInstanceKey`. When no instanceKey specified, use 0.
Changelog: [Internal]
Differential Revision: D24607919
fbshipit-source-id: 4a29e5ece9a5462eb1163185d26370ee873f1412
Summary:
These are new markers that will be placed around initializing an RCTInstance.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D24607905
fbshipit-source-id: 8e83a2476e2ae878c523217aeb5a3b4bfc5bf911
Summary:
Changelog: [internal]
The condition inside `[RCTCxxBridge handleMemoryWarning]` was preventing JS VM from handling memory pressure if React Native was loading. This seems incorrect as loading only occurs once at the startup but memory pressure event occurs mostly after React Native was initialised. Therefore, JS VM wasn't handling memory pressure events.
Reviewed By: shergin
Differential Revision: D24646724
fbshipit-source-id: 7b4420fe675261e434c3427c8ad366ba0086a453
Summary:
According to the crash, RCTEventEmitter is being asked to emit events before RN is set up {emoji:1f928}. Neither the bridge, nor bridgeless mode is ready to send events.
In this scenario, drop the events on the floor instead of crashing.
Changelog: [Internal]
Reviewed By: naftaly
Differential Revision: D24634701
fbshipit-source-id: 933e5dfd15e5ee7c2215489305c71de46e78a9e5
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:
Changelog:
Fix the cloneWithChildren implementation that was not copying the list of children on the java object.
We were missing on copying the list of children when cloning. This is pretty bad as it means that the clone operation was mutating the old node as well as the new. When multiple threads were involved this could cause crashes.
Reviewed By: SidharthGuglani
Differential Revision: D24565307
fbshipit-source-id: 4e2e111db389e25c315ce7603b4018ac695bb0f1
Summary:
Update engines to node >= 12
## 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] [Changed] - Update node engine to version 12
Pull Request resolved: https://github.com/facebook/react-native/pull/30252
Reviewed By: yungsters
Differential Revision: D24558093
Pulled By: fkgozali
fbshipit-source-id: 7a10bb935f89ba3374b0909161db9974e1fc477a
Summary:
The callback `dispatchEvent` is called asynchronously on the JavaScript thread, so all data it uses must be copied to the lambda. To work around this constraint we use a shared pointer for the counter.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D24598840
fbshipit-source-id: fb5581858d54dc806863caf0c7c4f612ed6046e2
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:
Bump Gradle Wrapper to 6.7, to keep tooling on edge. Here are the highlights of this release:
- File system watching is ready for production use
- Declare the version of Java your build requires
- Java 15 support
## Changelog
[Android] [Changed] - Bump Gradle Wrapper to 6.7
Pull Request resolved: https://github.com/facebook/react-native/pull/30200
Test Plan: RNTester builds and runs as expected. Also my apps.
Reviewed By: cpojer
Differential Revision: D24560233
Pulled By: fkgozali
fbshipit-source-id: 0d94b4527b2ee5b28b22478128c25761929fbdc7
Summary:
Android Studio 4.1 release with Android Gradle Plugin 4.1.0, thus I expect developers will update to newer version and expect React Native support. Thus release include many fixes and improvements, see[release notes](https://developer.android.com/studio/releases/gradle-plugin#4-1-0), but most importantly Google released it's API documentation at https://developer.android.com/reference/tools/gradle-api. We lacked the API documentation to develop proper React Gradle Plugin.
## Changelog
[Android] [Changed] - bump Android Gradle Plugin to 4.1.0
Pull Request resolved: https://github.com/facebook/react-native/pull/30201
Test Plan: RNTester builds and runs as expected, also my apps.
Reviewed By: cpojer
Differential Revision: D24560213
Pulled By: fkgozali
fbshipit-source-id: 9cf1e2373f278885b35b4f9176c7ad736ec50f6b
Summary: We support setting the text color in the ReactPicker component, but we don't apply the text color to the little arrow icon that appears next to it. This diff applies the color tint from the picker's primary text color (set with a style prop on the main picker component, *not* the 'color' prop on the Picker.Item) to the background of the picker, which tints the arrow icon.
Reviewed By: makovkastar
Differential Revision: D24480642
fbshipit-source-id: 7ce84d616ae677da8975be9444428392020c57dc
Summary:
Bump Okio to 1.17.5, which includes fixes for many bugs and crashes since current version. Also removed android.enableR8=false from gradle.properties because it's deprecated. And moved FEST_ASSERT_CORE_VERSION from gradle.properties to build.gradle because it's used in single line.
## Changelog
[Android] [Changed] - bump Okio to 1.17.5
Pull Request resolved: https://github.com/facebook/react-native/pull/30204
Test Plan: RNTester builds and runs as expected.
Reviewed By: hramos
Differential Revision: D24560711
Pulled By: fkgozali
fbshipit-source-id: 433075293ca2dc41869dbb272d674625639c8b83
Summary:
When working with RN installed from npm and a regular project structure `$rootDir` won't be at the react-native package root. Instead we can use `$projectRoot` which will always be the ReactAndroid folder.
## Changelog
[Android] [Internal] - Use $projectDir instead of $rootDir for ReactAndroid codegen
Pull Request resolved: https://github.com/facebook/react-native/pull/30220
Test Plan: Test building an app with RN as a regular dep with codegen enabled
Reviewed By: hramos
Differential Revision: D24560634
Pulled By: fkgozali
fbshipit-source-id: 434d32f37e6f9d48a8c562655ceff7249bd056ce
Summary:
Pass the ReactAndroid project build directory as a variable to the ndk build so it can be used instead of assuming that the build directory is under ReactAndroid/build.
## Changelog
[Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/30222
Test Plan: Tested in an app with a custom build directory
Reviewed By: yungsters
Differential Revision: D24560643
Pulled By: fkgozali
fbshipit-source-id: cc65a70582f546ca2e2ca9fb6a2ff03ea70ca9d8
Summary:
The recursive copy statement fixed here behaved differently in MacOS vs Linus (CI), because of the missing dot (.)
The trailing slash on the source directory behaves differently on Mac (BSD) than Linux (GNU):
> If the source_file ends in a /, the contents of the directory are copied rather than the directory itself.
This should fix the CI failure: https://app.circleci.com/pipelines/github/facebook/react-native/6847/workflows/36d59aab-bc4a-4d21-9ce1-a8348e71aea3/jobs/173681
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D24560543
fbshipit-source-id: c3ab2c28616b717891bcf5d2ad762340cfb97e3d
Summary:
## Context
We currently run ESLint using `flow-node`. This is a very recent change that was introduced in these two diffs:
- Switch VSCode ESLint plugin using flow-node: D24454702.
- Switch all ESLint scripts to use flow-node: D24379783 (https://github.com/facebook/react-native/commit/ad5802cf916c1cbe3e142385a29810a0d7205c6c).
## Problem
Because `react-native/eslint-plugin-codegen` (written in vanilla JavaScript) requires two files from `react-native-codegen` (written with Flow typings), we force all requires executed while initializing ESLint to compile out Flow types. Issues:
- In the grand scheme of things, this is such a tiny and isolated problem. It shouldn't be the reason why we switch over to using flow node. That's a larger decision that should be discussed outside of this diff.
- On VSCode cold start, in D24454702, I measured that using flow-node adds approximately 320ms to JavaScript file lint time. So, this is just slow.
## Solution
- Switch ESLint back to using regular node:
- Revert the changes to VSCode's ESLint plugin: D24454702
- Revert the changes to the internal ESLint scripts: D24379783 (https://github.com/facebook/react-native/commit/ad5802cf916c1cbe3e142385a29810a0d7205c6c).
- Inside the ESLint plugin, register a temporary require hook to remove Flow types from the NativeModule spec parser, before we require it. We de-register this hook after the requires finish.
## Implementation Notes:
- The `with-babel-register/` is a fork of `babel/register`, except I simplified the implementation based on the assumption that we're using it literally to only compile `react-native-codegen`.
- `with-babel-register/` uses a disk cache, so we only call transformSync when a the input file (1) hasn't been transformed before, or (2) the cache entry was created before the file was last modified.
- I ported over the source-map logic, so that when the NativeModule spec parser throws non-parsing errors, we get the correct stack trace. **Note:** I'm not sure if the source maps will work if there's a babel/register earlier during initialization. However, I don't think this will pose an actual problem, since we don't use a babel/register hook earlier. So, I think we should punt on this investigation.
## Alternative: Why aren't we using babel/register?
Every time you call babel/register, it replaces the last registered hook. We don't want the ESLint plugin to be changing any existing require hooks that people have set up. Abandoned diff with babel/register: D24519349.
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D24551549
fbshipit-source-id: bbd7c5be44f74c0e9adbb20fe86e09802410b123
Summary:
This does a few things:
* Remove USE_CODEGEN flag so that TurboModule is enabled by default for RNTester
* Use the codegen output for Java/JNI spec files
* Remove the checked in com.facebook.fbreact.specs Java/JNI files
Changelog: [Changed][Android] RNTester now enables TurboModule by default using codegen.
Reviewed By: RSNara
Differential Revision: D24382083
fbshipit-source-id: 87e3e0581bac3287ef01c1a0deb070c1d7d40f2d
Summary:
The Gradle codegen integration requires the JS CLI to be first built via `yarn run build`. This commit puts that logic in a `build.sh` script, then defines a Gradle task to build it.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D24556992
fbshipit-source-id: 7092de7c1126edc157b122f4b2243e55f7188846
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:
To unify with Android, this uses the target off the same BUCK file.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D24522269
fbshipit-source-id: 5aa0c08962890b884081faeb1ec801aebec9c2dd
Summary:
This moves all deps on the checked in fbreact/specs files to use the generated output (during build time) instead.
TLDR:
`react_native_target("java/com/facebook/fbreact/specs:FBReactNativeSpec")` ==> `react_native_root_target("Libraries:generated_java_modules-FBReactNativeSpec")`
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D24520293
fbshipit-source-id: 3fb34f172f1ab89b7198dfb4fccf605fbc32d660
Summary:
This fixed a bug in the JS Java spec generator. Optional methods were still marked `abstract` before this fix. Instead it should be a normal method with potentially falsy return value.
The JavaPoet version does this correctly already, but there was a minor typo with void return type vs optional.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D24524432
fbshipit-source-id: 57a248580a78bc255f34d0492ebe3a4691e66667
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:
We don't currently support object spreads in `ObjectTypeAnnotation`s. This diff adds an explicit error for the case in the parser, so that when people use object spreads in ObjectTypeAnnotations, they get feedback from the linter rule and parser.
Previously, the Linter would crash, and the parser would fail, but the error wouldn't be immediately obvious.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24543650
fbshipit-source-id: 76f389c72f858ee6281c5aff5ce797f3be685096
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:
- This fix resolves https://github.com/facebook/react-native/issues/29398
- After updating gradle to 6.5+ and android gradle plugin to 4.1.0+(which is recommended in the latest Android Studio 4.1), Running `:app:assembleRelease` or `:app:bundleRelease` will not contain `index.android.bundle` in Apk/AAB. It will be included when the command executed twice.
<img width="949" alt="Screen Shot 2020-10-17 at 11 32 43 PM" src="https://user-images.githubusercontent.com/6277118/96360808-38165c00-10d5-11eb-8b6e-f098517a24c7.png">
- This is caused by the task ordering update introduced in gradle plugin 4.1.0+/gradle 6.5. `mergeResources` task runs before `currentAssetsCopyTask`(copying the bundle asset file to intermediate output directory) which causes generated Apk/AAB not including the bundle file.
- The fix ensures mergeResources task runs after currentAssetsCopyTask
## Changelog
[Android] [Fixed] - Fix App Bundle/Release build missing index.android.bundle with gradle plugin 4.1.0/gradle 6.5
Pull Request resolved: https://github.com/facebook/react-native/pull/30177
Test Plan:
- Reproducible repository https://github.com/tomoima525/android_build_test_rn
- This project is generated with `create-react-native-app` and updated Gradle version to 6.5 and com.android.tools.build:gradle plugin to 4.1
- Run `./gradlew clean :app:assembleRelease` and `./gradlew clean :app:bundleRelease` => reproduces the issue
- After adding the fix above and run `./gradlew clean :app:assembleRelease` and `./gradlew clean :app:bundleRelease` => The issue is resolved
- Also confirmed the build works properly with android gradle plugin `3.5.3` and `gradle 6.2`(the default value of `create-react-native-app`)
Reviewed By: fkgozali
Differential Revision: D24551605
Pulled By: cpojer
fbshipit-source-id: b0effe2c6ea682748af185061af951e2f2bce722
Summary:
Changelog: [internal]
Problem:
`props.transform` gets out of sync with `self.layer.transform`.
To avoid writing out value of transform matrix, in the follow example I will only consider identity matrix and non-identity matrix. It is sufficient to demonstrate the point.
1. View is reused with transform being something besides identity. This causes `props.transform` and `self.layer.transform` to be non-identity.
2. View is taken from pool and animated with transform set to non-identity.
3. React JS props arrive and set `view.props` to identity but `self.layer.transform` stays unchanged because it is managed by native animation. This is the point where `props.transform` and `self.layer.transform` get out of sync.
4. Native animation wants to set transform to identity to finish the animation. But inside `[RCTViewComponentView updateProps:oldProps:]` `self.layer.transform` does not get set because current `view.props` is already identity.
Solution:
After native animation layer calls `[RCTViewComponentView updateProps:oldProps:]`, verify that values were set. If they weren't, set them directly without depending on `[RCTViewComponentView updateProps:oldProps:]`.
Reviewed By: JoshuaGross
Differential Revision: D24538442
fbshipit-source-id: ba8c59c5c9bb751306118bd1c7f0ccd9d0fb7fba
Summary:
Sometimes stopSurface crashes when unmountReactApplication is called under Fabric; knowing the stack trace up to this point might assist in debugging.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D24532027
fbshipit-source-id: f350e77fb1a2de52eb146b449f1d2f6e960fa017
Summary:
Ensure the react-native-codegen package is built before the codegen is invoked during RNTester's pod install.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24515852
fbshipit-source-id: eeb1237f601d83a79a5274261c374bb5fc5689eb
Summary:
Changelog: [internal]
Background executor performs unnecessary operations when second `completeRoot` message from React arrives before first `completeRoot` was finished. This produces unnecessary `ShadowViewMutations`.
Mechanism:
Everytime `completeRoot` is received, before the call is dispatched on the background queue, `completeRootEventCounter_DO_NOT_USE_` is incremented.
Inside `ShadowTree::tryCommit` we check if the value has been incremented to determine if another `completeRoot` is queued.
Reviewed By: JoshuaGross
Differential Revision: D24419160
fbshipit-source-id: 11e19026feca01db6c8981b093a691a6b58a006f
Summary:
This moves the test script that generates **all outputs using all generators** to a dedicated "generate-all" CLI. This allows us to use it via Buck, at FB and OSS.
Also renamed the target to be more specific: "rn_codegen" => "generate_all_from_schema"
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D24513995
fbshipit-source-id: 8435d3d065718eb1309c1c61fe28fb592787311a
Summary:
Changelog: [internal]
`onScroll` event needs to be fired when scroll view ends the scrolling animation and when scrollTo is called.
This is how Paper does it and client code might depend on it.
Reviewed By: JoshuaGross
Differential Revision: D24527189
fbshipit-source-id: bdec099f16b3d8c97686975a1f769db4d2c0d832
Summary:
Changelog: [internal]
ScrollTo command needs to clamp the value in order to not scroll out of content view of scroll view. Paper does the same thing.
Reviewed By: JoshuaGross
Differential Revision: D24526992
fbshipit-source-id: 47c48ecb01f4ae40791306016dd7847079263128
Summary:
Fabric should be inserting Views into the hierarchy in the correct order based on z-index already, so there should be no reason to enable this mechanism.
At best it's a perf pessimisation and at worst it could be causing consistency issues or crashing (TBD). Most likely this is a noop.
Changelog: [Internal]
Reviewed By: ejanzer
Differential Revision: D24512203
fbshipit-source-id: b9336240ef8506742bcbd8d08fc8b830f82cdfe2
Summary:
Our NativeModule spec parser parses the TurboModuleRegistry.get<Spec>(...) calls to figure out what the name of the NativeModule is. The parser assumes the argument is a string literal. Therefore, we should lint to validate this case.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24500412
fbshipit-source-id: 5aa5e9255db5a2e0cd86d6dd96e6787caa673fc4
Summary:
TurboModule specs should have exactly one TurboModuleRegistry.get or TurboModuleRegistry.getEnforcing call. When a JS file contains more than one call into TurboModuleRegistry, this lint rule will report an error on all calls.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24499286
fbshipit-source-id: 2c47185165a2a81c4b7b7ad9a7b8458e9aa8c018
Summary:
This diff guts the React Native Modules ESLint rule, and makes it instead call into the NativeModule spec parser. After calling into the parser, the lint rule loops over all collected errors, and reports them.
## Benefits
- There is now one source of truth of what is a "correct" NativeModule spec: The NativeModule spec parser.
- Every change we make to the NativeModule spec parser will reflect in the lint rule. We have a number of changes planned for the NativeModule parser that will change what it means for a NativeModule spec to be correct. These changes now won't have to be duplicated in the ESLint rule.
- The linter will *never* show any false positive errors. If there's an error in the linter, you *need* to fix it. Otherwise, the codegen *will* fail. This is huge. Previously, people were used to ignoring the linter, because it over-reported errors. This behavior won't slide after this stack lands.
NOTE: This will run the NativeModules parser on all our NativeModule specs. We may have to check the specs, or the parser. Therefore, this could take some time to land.
## How does the lint rule work now?
In every JavaScript file, the ESLint rule looks for `CallExpression` AST Nodes. Once it detects a `CallExpression` that corresponds to a `TurboModuleRegistry.get` or `TurboModuleRegistry.getEnforcing` it:
1. Marks the file as a TurboModule spec
2. Validates the `CallExpression` to verify that it is called with the <Spec> type parameters (i.e: like this: TurboModuleRegistry.get<Spec>(...)).
When we're done the visition for the JavaScript file (i.e: in `Program:exit`), if the JavaScript file was a TurboModule spec:
1. Report a lint error if the filename doesn't start with Native.
2. We parse the source using flow-parser, and run the NativeModule spec parser on it. We capture all ParserErrors and report them via ESLint.
## When can I start using this lint rule in VSCode?
I made the ESLint VSCode plugin use flow-node in D24454702. It'll take 3-4 weeks for this change to be shipped to everyone's VSCode. After the update, the linter will automatically start working in VSCode. Until then, we'll only get feedback on Sandcastle/Landcastle for lint rule violations.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24379783
fbshipit-source-id: 222778d8a84d7010eb7b3ad71b34a7fe1f52e509
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:
I want to see if the child count changes before/after this method execute; that would help pinpoint the cause of these crashes.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D24510064
fbshipit-source-id: 11b4baf15bc5e0beb23d65546605b378d84d1b20
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:
On October 27, 2020, Node 14 will enter active LTS status, and Node 12 will enter maintenance LTS status at the end of November.
With these upcoming dates in mind, I am bumping the Circle CI NodeLTS executor to use Node 14, and the NodePrevLTS executor to use Node 12.
With these changes, Node 12 will be hereto considered the minimum supported version.
## 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
-->
[Changed] [JavaScript] - Bump minimum Node version to 12 LTS
Pull Request resolved: https://github.com/facebook/react-native/pull/30237
Test Plan: Circle CI
Reviewed By: PeteTheHeat
Differential Revision: D24513133
Pulled By: hramos
fbshipit-source-id: 2651d954d546e5f7c9e40b54ef3ee976ad9b2d5e
Summary:
With the release of Node 15 on October 20, 2020, the `nvm i node` command started installing Node 15 by default during the Docker setup step on Circle CI. This version of Node now requires user interaction down in `npx envinfo@latest` during the same step.
With these changes, we ensure we automatically accept the installation of any necessary packages.
## 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
-->
[CATEGORY] - Internal
Pull Request resolved: https://github.com/facebook/react-native/pull/30235
Test Plan: Circle CI.
Reviewed By: fkgozali
Differential Revision: D24510043
Pulled By: hramos
fbshipit-source-id: bce72fd8ea8b0a4df501f75e48984eca0b10a090
Summary:
The value of the `ScrollView.snapToOffsets` property can be an empty array (most likely an issue in the product code), which will crash the app. This diff adds a check to prevent crashing in this scenario and falling back to the default snap behaviour.
Changelog:
[Android][Fixed] - Do not crash when ScrollView snapToOffsets is empty
Reviewed By: sammy-SC
Differential Revision: D24502365
fbshipit-source-id: c63b8e3b8f2fb323ebd6c962ee628015934d8e11
Summary:
Changelog: [internal]
There are two exceptions inside `TelemetryController::pullTransaction`:
- Empty Optional cannot be unwrapped
- mutex lock failed: Invalid argument
By marking this method `noexcept`, stack trace is lost and it makes it more difficult to track down the issue.
What does compiler do if a method is marked `noexcept`?
```
void f() noexcept {
try {
// do work
}
catch (...) {
std::terminate(); // This is the std::terminate() we are seeing in stack traces.
}
}
```
Removing noexcept specifier might give us more information about the exception.
Reviewed By: JoshuaGross
Differential Revision: D24477861
fbshipit-source-id: 80f26e9ab160a5330c2848b89a01d60bfc0a4611
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:
As of right now, index.js contains a big blob of imports that are mostly in alphabetical order, with a few exceptions. In addition, the imports aren't separated by Components / API / Plugins, so comments were added for ease of future maintainability.
## Changelog
[Internal] [Changed] - Reordered imports into alphabetical order and added comments to divide imports into sections (components, apis, plugins, prop types)
Pull Request resolved: https://github.com/facebook/react-native/pull/30217
Test Plan:
This change did not change the codebase. Building rn-tester still works.
rickhanlonii
Reviewed By: cpojer
Differential Revision: D24490715
Pulled By: rickhanlonii
fbshipit-source-id: 7340395c8e10833b700dcfe8e83ab4a66b79e47b
Summary:
Proxy is now enabled by default in hermes 0.7 (https://github.com/facebook/hermes/releases/tag/v0.7.0). However we currently disable it because of the config we pass.
This removes the config so proxy is now enabled.
## Changelog
[Android] [Changed] - Use default for hermes es6 proxy enabled
Pull Request resolved: https://github.com/facebook/react-native/pull/30142
Test Plan: Tested that proxy is now enabled (typeof Proxy !== 'undefined') with hermes 0.7.
Reviewed By: cpojer
Differential Revision: D24494182
Pulled By: mhorowitz
fbshipit-source-id: 7f8a506e2c436f2f1611e183ca22d33dc763643c
Summary:
Since changes to support hermes on iOS the js bundled is moved away from the location where it is generated when calling metro. This causes issues with the RN sentry integration since it relies on intercepting this path to find the bundle file after running react-native-xcode.sh. Seems kind of like a hacky way to get the bundle location, but let's avoid breaking it.
https://github.com/getsentry/sentry-cli/blob/master/src/commands/react_native_xcode.rs
## Changelog
[iOS] [Fixed] - Make sure js bundle still exists at bundle-output path
Pull Request resolved: https://github.com/facebook/react-native/pull/30149
Test Plan:
Checked that the bundle file exists both at bundle-output path and in the .app.
Checked that the sentry release script works.
Reviewed By: cpojer
Differential Revision: D24480115
Pulled By: appden
fbshipit-source-id: c01c80d47ed54319f97063ec635c021552a95c22
Summary:
Introduced a helper macro `rn_codegen_cli()` that defines ":write_to_json" and ":rn_codegen" targets differently based on the environment. When run at FB, it uses FB-specific setup. When run in OSS as a standalone repo, we use `yarn install` and `yarn run build` directly, then use `node` to run the output CLI.
This way, the same target can be used in both environments on other Buck targets.
Motivation: we need this to define rn_codegen_modules() to use codegen to produce Java TurboModule specs, that can be built by CircleCI (we build ReactAndroid via Buck as well). That way we can finally removed the checked-in .java spec files.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D24442468
fbshipit-source-id: b1e5fce275100cfe3a1b3ae6d61c1c6d4b25651b
Summary:
Added a few FB vs OSS polyfills:
* react_native_root_target() to refer to the root FB react-native-github/ dir or repo dir in OSS
* react_native_xplat_synced_target() for anything xplat
* a few others
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D24437245
fbshipit-source-id: ee290a87a98a8e9be67b102a96f2faac2a2cb92b
Summary:
There's a crash for a small number of users that looks like it is happening when cutting the text via a context menu, or deleting content near the end.
This is only happening because we cache the Spannable and it detects changes due to the cache mechanism itself. I'm making a minor change that will hopefully result
in Spannables being copied instead of the same Spannable instances being used for display on the View and measurement; and also swallowing this error, since it should
not be considered as a fatal, unrecoverable error for now. Hopefully we can delete entirely in the future.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D24430622
fbshipit-source-id: 495458b3d85733e46a7e62b5c954b7cb6b00470b
Summary:
Changelog: [internal]
Copy `blurRadius` into a variable instead of accessing it through a reference which might not exist when the block is dispatched.
Reviewed By: cpojer
Differential Revision: D24472850
fbshipit-source-id: 936ef671255ae0e825e1d2dfda9649824b63d297
Summary:
Changelog:
[General][Fixed] - Fix handling of very deeply nested data across the bridge
fixesfacebook/hermes#339
Reviewed By: sammy-SC
Differential Revision: D24182938
fbshipit-source-id: b674283a112b98cc63f20e436c538e3789ddf6dd
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:
Just published react-native-codegen to npm. This diff bumps the version in package.json
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24433252
fbshipit-source-id: 35327b11ca4db270f207b6f778dabf86dd7dcb4c
Summary:
This change adds a testID to each item in the RNTester list. This helps Appium find items in the list for automated tests. The change was added in react-native-windows as part of end-to-end test infrastructure changes. See https://github.com/microsoft/react-native-windows/pull/5555
We'd like to remove this forked file, upstreaming this change will enable us to do that.
## 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] [Changed] - add testID to items in RNTester test list, helps test automation tools find the items
Pull Request resolved: https://github.com/facebook/react-native/pull/30138
Test Plan: Change is currently running in react-native-windows CI loop.
Reviewed By: cpojer
Differential Revision: D24434352
Pulled By: appden
fbshipit-source-id: 998916d8fe4e4e4cd6ac764baabb9fd5f2e312c7
Summary:
We've deprecated API 20 and below. This is just a cleanup to remove code that assumes API level <21.
Changelog: [Android][Deprecated] Deprecate support of Android API levels 19 and 20.
Reviewed By: fkgozali
Differential Revision: D24380233
fbshipit-source-id: d8f98d7cb19446a60ba36137f1f9290e35f27c02
Summary:
This diff updates the minsdkversion of RN OSS template to API level 21.
Changelog: [Android][Deprecated] Deprecate support of Android API levels 19 and 20. The new minSDK version will be 21+ moving forward.
Reviewed By: fkgozali
Differential Revision: D24379607
fbshipit-source-id: 6801cdcd363065807cdc11006bd94217f914fac7
Summary:
This makes the build configuration compatible with OSS Buck (but doesn't provide the complete capability).
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D24414408
fbshipit-source-id: 4632933b8659389543ed72ae7c11c63d86bb3dce
Summary:
For now, separate the definition of `modules` generator per platform to avoid file output collision. Additionally:
* For Android, produce files under java/ (plus nested subdirs based on packageName) and jni/ (for C++ files) - JavaPoet version already does it
* Allow configuring packageName for Android - JavaPoet version has this
* Avoid tmp directory dance in the CLI script, given the proper modules separation
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D24410864
fbshipit-source-id: 9bd6bc1d65bec037bfca32ec478f3af50d72e927
Summary:
Move FBReactNativeSpec codegen invocation to shared `react_native_pods.rb` script and trigger codegen to run as part of `pod install` in both RNTester as well as React Native for iOS projects.
These files need to be generated before CocoaPods generates the Pods project, so the codegen is invoked as part of a `pre_install` hook during `pod install`.
The codegen hook can now take optional paths to allow it to run within different contexts (as part of a `react-native` repo checkout with access to the codegen source, or as part of a React Native iOS project that depends on the `react-native-codegen` npm package).
## Motivation
The FBReactNativeSpec ObjC++ source files (FBReactNativeSpec.h and FBReactNativeSpec-generated.mm) can be generated on demand from the native module specs in `Libraries/` using `react-native-codegen`. They can therefore be removed from the repository, but before we do so, we must ensure they get generated when a React Native iOS workspace is created or updated.
Invoking the codegen as part of the `pod install` step that creates a React Native iOS Xcode workspace ensures the specs are available in the following scenarios:
* Whenever a new React Native iOS project is created. The `react-native init` command invokes `pod install`.
* Whenever a React Native iOS project is upgraded. The `react-native upgrade` command invokes `pod install` as well.
* For contributors to the open source project running the RNTester application, the codegen will be invoked when the RNTester workspace is generated by CocoaPods using `pod install` in `packages/rn-tester`.
In any other case, the codegen can still be invoked directly via `scripts/generate-native-modules-specs.sh`.
> **Note:**
> The codegen will only process native modules in React Native's own Libraries directory.
Changelog:
[iOS][Changed] - Generate FBReactNativeSpec ObjC++ source files using CocoaPods.
Reviewed By: fkgozali
Differential Revision: D24348111
fbshipit-source-id: d62ae5c6f8ce6358bf96a2801c3cdb3d94dd868d
Summary:
Fixes a NPE in debug mode. This will only impact developers who have explicitly turned this debug flag on, so it's a very low-pri fix.
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D24410825
fbshipit-source-id: 08c8a0c6d0e0fb7c132725ad6af9460b91a7edf3
Summary:
## Rationale
Previously, the NativeModule spec parser would throw an error the first time it encountered an invalid Flow type. While this is ideal from a parsing standpoint, from a linting standpoint, however, we may want to display all errors that make the NativeModule spec invalid.
## Changes
This diff extends the NativeModule spec parser to collect all parsing errors in an array. In the codegen, if after building the schema, any parsing errors were detected, we throw the first one. In the ESLint rule, if after building the schema, any parsing errors were detected, the plan is to display them all.
## Notes
- All ParserErrors keep a track of the invalid AST Node
- When a Parsing error occurs, the Parser tries its best to continue parsing the rest of the source. For function parameters, it'll move on to the next param. For object proroperties, it'll move to the next property. It'll form a half-baked schema in the process, when a parsing error occurs. However, higher up in the stack, we have a check that discards the half-baked schema, if any ParsingErrors were collected.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24379511
fbshipit-source-id: 1989433da9b356b9ad5d9dcf901b429f585803c2
Summary:
## Why
We want to reuse these functions inside the ESLint rule. Therefore, it's better to make them accept the AST node object, as opposed to a custom type defined in codegen.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24379512
fbshipit-source-id: 9f7378fc6c5f48cce34da109f5a7c017332b302a
Summary:
In our Codegen generators, we were using `codegenModuleName` to refer to the name of the spec file. Calling this `hasteModuleName` makes it more clear what this name refers to (i.e: the name of the spec file). This diff performs that rename.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24386282
fbshipit-source-id: fe2beda9a0abf63a5cf88fa0664f83416c9f1aa2
Summary:
The previous implementation always replaced the prop set on every props update coming from Animated. Now, we merge the new set of props with the previous one.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D24370751
fbshipit-source-id: 779272d47c776cc42071d3c93d06443b6c96a877
Summary:
The specific file filtering in the CLI only covers the case where the input is a directory. We should filter when files are provided as well.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D24399225
fbshipit-source-id: 186e39c157faf90bdd825ec5c5860017d49e9404
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:
In Chrome, there's a garbage can icon in the memory profiler page that you can
click to force a garbage collection.
Hermes was previously not responding to that button. Add support for this inspector
message type.
The collection it starts is fully synchronous and will block JS from running. It typically
completes quite fast for small heaps, and about 1 second for heaps over 100 MB big.
Changelog:
[Internal][Added] Add support for garbage collection during heap profiling with Hermes
Reviewed By: neildhar
Differential Revision: D24349262
fbshipit-source-id: fe62b8df4d2b67ab3930e5d57f94478b2a88a549
Summary:
So that it's easier for C++ targets to depend on libglog.so for debugging purpose.
Changelog: [Internal]
Differential Revision: D24382033
fbshipit-source-id: 00ad6b2365d571583d6d1aaa40fac2c96974abf1
Summary:
The GenerateModuleJavaSpec.js mistakenly treated nullable getConstants() properties as required, such that the Java spec will throw an exception when the properties are missing. This fixed it.
Note that the JavaPoet-based generator got this correct already.
Changelog: [Internal]
Differential Revision: D24381941
fbshipit-source-id: c95d2181c66443e2191318f09b6454a5296009e4
Summary:
Fixed URL of ChainReactConf website on the ECOSYSTEM.md
## 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] [Fixed] - Fix URL of ChainReactConf Website
Pull Request resolved: https://github.com/facebook/react-native/pull/30199
Test Plan: URL leads to the ChainReactConf website
Reviewed By: makovkastar
Differential Revision: D24386708
Pulled By: cpojer
fbshipit-source-id: 27a48e84547ef3bc067845b3c302dd57decc34b2
Summary:
#changelog: [internal]
When I built ThreadStorage I didn't know about existence of `thread_local` keyword. Because it achieves the same goal, using built in c++ features is preferred over building our own.
Reviewed By: JoshuaGross, shergin
Differential Revision: D24380680
fbshipit-source-id: e961fc34c6d3f085fc9b918b20bb4827de0d5624
Summary:
The NativeModules spec parser uses `moduleName` to refer to the name of the NativeModule spec. This is confusing, because the NativeModules spec also has a `moduleNames` array, which refers to names of the NativeModules that get required in the spec.
This diff renames `moduleName` to `hasteModuleName` within the NativeModule spec parser.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24386279
fbshipit-source-id: 8e4eb8dfc647241bf2bdae54dc8d9ab0122f49f9
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:
Some existing NativeModules have either Android or IOS suffix to denote the exclusive intent for that platform. For now, note this in the codegen schema output, so that the generator can skip irrelevant modules. Long term, each Flow type for module Spec should denote the intended/excluded platforms directly.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D24370568
fbshipit-source-id: 8f725bdb39107d73c1aba0689db7f47ed7c374b0
Summary:
The manual lookup logic was needed before we properly parse the module names from the spec js files. This is no longer necessary after the commit stack starting with https://github.com/facebook/react-native/commit/3a75b376cc3c44f9693d99b33046cf76d6fafa89
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D24370567
fbshipit-source-id: fc307d93cdda240a977e37dfe602502bd3f7c2a4
Summary:
Fabric has a feature that preallocates views before mounting even need them. We never tested the impact of this feature thought. This diff adds a way to enable/disable it and run an experiment.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D24355612
fbshipit-source-id: fefd653e57232044cd7b28b160e12a4ef85dbb8b
Summary:
Changelog:
[General][Added] - Adds the Hermes runtime bytecode version number to the JS bundle requestURL. This allows Metro with Bytecode to work with prebuilt binaries.
Reviewed By: cpojer
Differential Revision: D24327852
fbshipit-source-id: e8ee8db4f9b01f0500ab9dd851b5818c4adf3303
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:
NOTE: Flow and Jest won't pass on this diff. Sandcastle, should, however, be green on D24236405 (i.e: the tip of this stack).
Changelog: [Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: PeteTheHeat
Differential Revision: D24236504
fbshipit-source-id: 0ca70101a855fb713fa15ed63849b138eb73dc6c
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
Previously, the "Module" schema could either contain a `components` property, or a `nativeModules` property. The existence of the `components` property was used to determine (1) if the generators would run and (2) filter schemas on which the generators would run. Now, we simply check whether the type of the "Module" schema is `Component`.
Changelog: [Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: PeteTheHeat
Differential Revision: D24236508
fbshipit-source-id: 68cb3f25178b6757c9a4aee767bb6173db4932a6
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).
Changelog: [Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: PeteTheHeat
Differential Revision: D24236507
fbshipit-source-id: 2ffa0414db731a6ee844a2d1a5b07dc32bc763cb
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).
Changelog: [Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: PeteTheHeat
Differential Revision: D24236502
fbshipit-source-id: 288c6d9588bde177732fe8165d3374eeacad999d
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).
Changelog: [Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: PeteTheHeat
Differential Revision: D24236509
fbshipit-source-id: 1b603e8728d7be1e8bdede5878f57d6556b5c52f
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. Update the RN Codegen Module Parser
2. Update all RN Codegen Module Parser Jest tests & snapshots.
Changelog: [Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: PeteTheHeat
Differential Revision: D24236505
fbshipit-source-id: e24a39b4837c75a90fb4c957c56dfcf789511cc9
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. Update the RN Codegen Component Parser
2. Update all RN Codegen Component Parser snapshots.
Changelog: [Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: PeteTheHeat
Differential Revision: D24236503
fbshipit-source-id: 975d97dd29bb5ca08e5de96e7814290c3dc4357b
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).
## Description
The Codegen deals with "Modules". Hence:
```
type SchemaType = {
modules: {
[moduleName]: ...
}
};
```
Each "Module" has a name, and represents a file. The `moduleName` is the base name of the file. This file can contain a component specification or a NativeModule specification. Hence:
```
type SchemaType = {
modules: {
[moduleName]: ComponentSchema | NativeModuleSchema
}
};
```
The `ComponentSchema` can contain specifications for many different components. Hence:
```
type ComponentSchema = {
type: 'Component'
components: {
[componentName]: ComponentShape
}
}
```
The `NativeModuleSchema` contains
1. Type aliases (no surprises/nothing new).
2. One Flow interface that extends `TurboModule`.
3. Potentially many different NativeModule requires (for now) via `TurboModuleRegistry.get(Enforcing)?<specName>('moduleName')`.
Hence, the shape looks like:
```
type NativeModuleSchema = {
type: 'NativeModule',
aliases: NativeModuleAliasMap, // nothing new
spec: NativeModuleSpec,
moduleNames: $ReadOnlyArray<string>
}
type NativeModuleSpec = {
properties: $ReadOnlyArray<...>,
}
```
## Major Notes
1. We now parse the NativeModule requires (TurboModuleRegistry.get(Enforcing)?<Spec> calls) and record them in the schema.
2. A Codegen "Module" can contain either a Component schema, or a NativeModule schema, but **not** both.
## Snapshot Updates
The changes to the schema are visible in the snapshots updated in D24236505.
Changelog: [Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: fkgozali
Differential Revision: D24236510
fbshipit-source-id: bd344d67136418725d840e7332fd2f6957326bb4
Summary:
changelog: [internal]
Prevents 2 type converions:
1. int <-> size_t
2. int <-> int32_t
# Why is using size_t better when working with indexes.
## 1. Type conversion isn't for free.
Take this example
```
size_t calculate(int number) {
return number + 1;
}
```
It generates following assembly (generated with armv8-a clang 10.0.0):
```
calculate(int): // calculate(int)
sub sp, sp, #16 // =16
str w0, [sp, #12]
ldr w8, [sp, #12]
add w9, w8, #1 // =1
mov w8, w9
sxtw x0, w8
add sp, sp, #16 // =16
ret
```
That's 9 instructions.
If we get rid of type conversion:
```
size_t calculate(size_t number) {
return number + 1;
}
```
Assembly (generated with armv8-a clang 10.0.0):
```
calculate(unsigned long): // calculate(unsigned long)
sub sp, sp, #16 // =16
str x0, [sp, #8]
ldr x8, [sp, #8]
add x0, x8, #1 // =1
add sp, sp, #16 // =16
ret
```
Compiler now produces only 7 instructions.
## Semantics
When using int for indexing, the type doesn't say much. By using `size_t`, just by looking at the type, it gives the reader more information about where it is coming from.
Reviewed By: JoshuaGross
Differential Revision: D24332248
fbshipit-source-id: 87ef982829ec14906ed9e002ea2e875fda4a0cd8
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:
We will need it soon.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D24290775
fbshipit-source-id: a312e537a3c3954e709a10c8792b3462b574054a
Summary:
RCTSurfaceTouchHandler is not a thread-safe object and must be used (and initialized) on the main thread. Therefore we need to move the initialization to `view` method which is guaranteed to be called on the main thread.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D24290776
fbshipit-source-id: fc1f2f157599aff6fca053451f89bf7cca3c812a
Summary:
Changelog: [internal]
Fabric uses view commands instead of setNativeProps. This diff removes what's left of setNativeProps from the core.
Reviewed By: JoshuaGross
Differential Revision: D24309999
fbshipit-source-id: 70e54f0a984f8c36f77ba2cd59f59fc6923bc832
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
Summary:
This NativeModule is actualy not used! Removing this now.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24324362
fbshipit-source-id: 1322c5e072961f1c6c54bfc6dbd562d42f9e5b3f
Summary:
The codegen output for the native modules in `Libraries/` has been verified to work with RNTester.
Publishing a new version as a prerequisite to start using the codegen at build time in open source.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24314972
fbshipit-source-id: edd0066c1cf33ba8e536cc5f145c057ca992eec1
Summary:
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, I made RCTEventEmitter dispatch events even when _listeners <= 0. This is sufficient for us to stop calling these two RCTNetworking methods entirely.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24272663
fbshipit-source-id: de9c968bc71e6e6d69a22b934644e6dfa3266b3f
Summary:
## Rationale
For every 1 call to RCTNetworking.sendRequest, we execute 6 calls to RCTNetworking.addListener. This is followed by at least one call to RCTNetworking.removeListeners. Aside from incrementing and decrementing the `_listeners` integer, these two methods accomplish nothing else: RCTNetworking doesn't implement the `startObserving` and `stopObserving` methods.
This diff makes RCTEventEmitter dispatch events without looking at the listeners integer. In the future, this will allow us to stop making these ~8 unnecessary NativeModule calls for every Network request we send.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24272560
fbshipit-source-id: 7996eba5abfa4669a89c43a3ffa536c0faa214a8
Summary:
With Xcode 12 being the latest, Detox 15.x has issues - in particular, it means that if you try to `yarn install` the dependencies for the repo, you'll be greeted by this error:
```bash
error /<stuff>/react-native/node_modules/detox: Command failed.
Exit code: 1
Command: node scripts/postinstall.js
Arguments:
Directory: /<stuff>/react-native/node_modules/detox
Output:
/<stuff>/Library/Detox/ios/5824c837515589f21c08f09b716a6eda088aa31f was found, but could not find Detox.framework inside it. This means that the Detox framework build process was interrupted.
deleting /<stuff>/Library/Detox/ios/5824c837515589f21c08f09b716a6eda088aa31f and trying to rebuild.
Extracting Detox sources...
Building Detox.framework from /<stuff>/Developer/OSS/react-native/node_modules/detox/ios_src...
child_process.js:637
throw err;
^
```
With the {emoji:1f44d} of hramos & alloy I've prep'd up a small defensive PR that can be quickly merged before cutting 0.64, that bumps the version of Detox from 15.4.4 to the highest version available within the reach of "no breaking changes" in changelog.
The main reason why with 16.x this error doesn't happen is that from [16.0.0](https://github.com/wix/Detox/releases/tag/16.0.0):
> Detox now comes as a prebuilt framework on iOS, thus lowering npm install times and saving some build issues that happen due to unexpected Xcode setups.
It would have been better to update directly to latest (at the time of writing 17.7.1) but there are at least two versions that had changelogs that seem to involve bigger changes:
* https://github.com/wix/Detox/releases/tag/17.4.7
* https://github.com/wix/Detox/releases/tag/16.8.0
Hopefully CI will will show that the bump doesn't break any test �
## 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] - Bumped Detox in the repo to 16.7.2 for Xcode 12 compatibility
Pull Request resolved: https://github.com/facebook/react-native/pull/30084
Test Plan: Running yarn in the main repo with Node 14 & Xcode 12, without this change, will cause the error copy-pasted above. After upgrading to this version, the error disappear.
Reviewed By: cpojer
Differential Revision: D24293226
Pulled By: hramos
fbshipit-source-id: 2b4d23b033be621274966262ec19200bee44df58
Summary: Changelog: [RN][iOS] Allow gate to be set for Fabric logging from the React Module
Reviewed By: fkgozali
Differential Revision: D24256546
fbshipit-source-id: 7b290efb9abd3035559f743e6e5b6701e02053e1
Summary:
This diff ended up being a bit more complicated than I anticipated, since the source files in `ReactInternal` were depending on `RCTEventDispatcher`. I made the following changes:
1. Make `RCTEventDispatcher` a `protocol`, keep it in `ReactInternal`.
2. Rename the `RCTEventDispatcher` NativeModule to `RCTEventDispatcherModule`, make it conform to the `RCTEventEmitter` `protocol`, and move it to `CoreModules`.
3. Where necessary, replace categories of `RCTEventDispatcher` with functions.
Changelog:
[iOS][Added] - Make RCTEventDispatcher TurboModule-comaptible
Reviewed By: fkgozali
Differential Revision: D18439488
fbshipit-source-id: b3da15c29459fddf884519f33b0c3b8c036b5539
Summary:
There are a few places where we have JNI table ref leaks, and more places where we can aggressively clean up smart pointers immediately instead of waiting for them to be cleaned up at some later point.
In theory these smart pointers should be cleaned up immediately, but in cases where many components are being measured at once, the JNI table could grow until all measure calls are done. In extreme cases this
could cause a crash, which I want to avoid. At the very least, freeing memory more aggressively in this case can't hurt.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D24293775
fbshipit-source-id: 159741ba955e5a6fe02caf6e65d1e4d6d4afadee
Summary:
This should fix a race condition uncovered by ASAN build that results in `m_shutdown` being referenced after destruction.
This mirrors a similar fix made in react-native-macos: https://github.com/microsoft/react-native-macos/commit/ea7767a211e5d1e5b18171c79404553b712539c7
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D24263156
fbshipit-source-id: 5fb1e7053c107dfb7050242fce8fcf0435e5592c
Summary: This completes the Picker stack. Use a handwritten view config to avoid calling `requireNativeComponent` in Bridgeless mode.
Differential Revision: D23663596
fbshipit-source-id: 5d0811014fd6f66956803a1db5fee8fd1119d5bc
Summary:
This builds on the last diff to remove type a type union from Picker. This diff focuses on Picker internals.
Changelog: [JS] Remove type union in PickeriOS/PickerNativeComponent
Reviewed By: sammy-SC
Differential Revision: D24254615
fbshipit-source-id: f788a2e123135c1e8b9909870c40f53b2dea0227
Summary:
Flow type unions don't play well with Fabric components. This diff removes a union in `Picker.js` and fixes all the flow errors.
Before this diff, all these surfaces would crash with the new Fabric Picker impl, because the impl asserts that this field is a string.
Reviewed By: sammy-SC
Differential Revision: D24236317
fbshipit-source-id: 6e646c84fcd16658aaabe5e93507f5f33b346a65
Summary:
This adds support for a controlled `<Picker/>` component .
Changelog: [iOS][Fabric] Fabric Picker support
Reviewed By: sammy-SC
Differential Revision: D24005475
fbshipit-source-id: c50e9918f74f6ef5cdfbfe67cb6c132c12d64916
Summary:
This adds support for `<Picker style={}/>` prop for text styling. It reuses most of conversion logic from BaseText. This means that it actually supports more styles than Paper Picker supported. (Paper picker only supported ~4 styles, this supports everything that Text supports, so 10+ styles).
The only tricky thing is that Picker supports multiple ways of setting text color. Both
<Picker
itemStyle={{color: '#008BD0'}} >
<Picker.Item label="Java" value="java" />
<Picker.Item label="JavaScript" value="js" />
</Picker>
and
<Picker>
<Picker.Item label="Java" value="java" color={'#008BD0'} />
<Picker.Item label="JavaScript" value="js" />
</Picker>
technically work in Paper. I've decided to maintain this behaviour (since there's lots of product code callsites to both options).
Changelog: [iOS][Fabric] Fabric Picker support
Reviewed By: sammy-SC
Differential Revision: D23980319
fbshipit-source-id: e469a837e28af0ad97cf0e171df26ee19adff3ab
Summary:
This builds on previous diff to properly parse `<Picker.Item/>` into a cpp struct.
This fixes the dummy text and text color TODOs.
Changelog: [iOS][Fabric] Fabric Picker support
Reviewed By: sammy-SC
Differential Revision: D23964557
fbshipit-source-id: f42c6c9cf410bfc5e66ff078645b6378548481de
Summary:
This is a starting point for the handwritten Fabric Picker component. It is incomplete, and needs to be landed with the rest of the stack above it.
In general, this creates a new `ComponentView`, `ComponentDescriptor`, `ShadowNode`, `Props` and a few other boilerplate classes for Picker. A bunch of the logic in `ComponentView` was copied over from the Paper `RCTPicker` and `RCTPickerManager`.
What works in this diff:
- A `<Picker>` with items can be created in JS, and a corresponding `UIPicker` is created in native with placeholder text, default styling and the correct amount of items
What doesn't work yet (implemented in later diffs):
- Parsing items to use correct text and styling in native
- Events/commands
Reviewed By: sammy-SC
Differential Revision: D23941821
fbshipit-source-id: e049ca6004757fbd1361985644d5dbb8f53e1ce6
Summary:
When switching between non-Fabric and Fabric screens, I believe that `initializeEventListenerForUIManagerType` is not always being called on the NativeAnimatedNodesManager if
`NativeAnimatedModule.initializeLifecycleEventListenersForViewTag` is being called before the NativeAnimatedNodesManager ivar has been set. This should occur very infrequently, but logs
indicate that it /does/ happen in some marginal cases. Protecting against these cases should be trivial, by using the `getNodesManager` method which is responsible for returning a nodes manager or creating a new one.
The existing uses of the `NativeAnimatedNodesManager` ivar also occur on different threads and we were not protecting against this, so I'm changing it to an atomic. It's very likely that
the inconsistency issues in the past were caused not by ordering errors, but thread races.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24267118
fbshipit-source-id: 68abbff7ef3d0b2ecc9aa9977165663ad9447ab8
Summary:
RNTester has some imports left over that operate on directory traversal, assuming it is contained within react-native sources. This change makes these imports relative to react-native, enabling usage outside of the RN repo.
Relates to https://github.com/microsoft/react-native-windows/issues/6210
## Changelog
[Internal] [Fixed] - Avoid File Structure Assumptions in RNTester Imports
Pull Request resolved: https://github.com/facebook/react-native/pull/30141
Test Plan: Validated we can bundle and flow-check both iOS + Android
Reviewed By: cpojer
Differential Revision: D24259628
Pulled By: appden
fbshipit-source-id: 0c21b5d354b01785d8402599da3b0a5be81b4c6d
Summary:
shergin added a new assert to dimensions calculations in D24038911 (https://github.com/facebook/react-native/commit/e85372298109abf258d5154e2a28bc6496fb9529). This crashes in bridgeless mode b/c no bridge.
This diff uses `turboModuleRegistry` as a bridge workaround. The registry is a [weak property](https://www.fburl.com/diffusion/sunv3bx9) so retain cycles shouldn't be an issue here, let me know if that's incorrect.
As a nice bonus, this fixes dynamic font sizing in bridgeless mode. It was broken before since it relied on the bridge.
Changelog: [Internal]
Reviewed By: ejanzer
Differential Revision: D24256338
fbshipit-source-id: 141d36239ac6a6e9e87ca96eea7aeec56729095d
Summary:
Changelog: [Internal]
If `uiTouch.view` isn't managed by Fabric, go up the view hierarchy to find first view that is.
This is important for host views wrapped by <Touchable>, otherwise touches are not delivered to the component.
Reviewed By: yungsters
Differential Revision: D24219223
fbshipit-source-id: 17b4e3460735371553ee0d30b41776a977f8eafb
Summary:
This PR attempts to fix issue https://github.com/facebook/react-native/issues/28278 and https://github.com/facebook/react-native/issues/29525
On Crashlytics, the following error occurs in file `RCTWebSocketModule.m` at method `-[RCTWebSocketModule webSocket:didFailWithError:]` when a nil value is inserted into a dictionary as a value.
```
Fatal Exception: NSInvalidArgumentException
*** -[__NSPlaceholderDictionary initWithObjects:forKeys:count:]: attempt to insert nil object from objects[0]
```
This PR is following the suggestion of this: https://github.com/facebook/react-native/issues/28278#issuecomment-597461650 and it replaces the values of any property if it is nil. In detail:
- it converts `error` to empty NSString if the original value is nil
- it converts `socketID` to a NSNumber object, which stores `-1` if the original value is nil
## Changelog
[iOS] [Fixed] - A crash in WebSocket module
Pull Request resolved: https://github.com/facebook/react-native/pull/30066
Test Plan: We were not able to reproduce the crash, but the report itself provided enough information to find a solution for this issue.
Reviewed By: shergin
Differential Revision: D24241147
Pulled By: sammy-SC
fbshipit-source-id: d5d632b49ca77b5d8be8b9c32358bef68f17d30a
Summary:
This makes a few change to the template xcodeproj
- Update to recommended settings for Xcode 12
- Remove the main.jsbundle file that doesn't exists, this file is included automatically in the app bundle and doesn't need to be in xcode (it won't even be at that path).
- Add -e to the bundle images script. It seems like Xcode doesn't fail the build on script errors anymore so this makes it so the build stop. If it doesn't stop the app will launch and crash because the bundle doesn't exist (note this is only if running the app in release mode since in debug we don't generate the bundle).
## Changelog
[iOS] [Added] - Update template to xcode 12
Pull Request resolved: https://github.com/facebook/react-native/pull/30150
Test Plan: Made the same changes in an app and made sure it ran well.
Reviewed By: cpojer
Differential Revision: D24237481
Pulled By: sammy-SC
fbshipit-source-id: 2b06a24c510c423eb45a1a840ea365b64506321b
Summary:
When taking a heap timeline, Hermes wasn't showing any data until the timeline
was written to disk and then reloaded.
Turns out we were missing support for two events:
* `HeapProfiler.lastSeenObjectId`: This event reports the most recently
allocated object ID. Used to know when objects were allocated in the
timeline.
* `HeapProfiler.heapStatsUpdate`: Report how many objects and bytes
exist for a "time fragment", represented by a fragment index. Later updates
to the same index can decrease the amount of live memory, which show up
as grey spikes instead of blue spikes
Previously, we only supported these by writing out to a file, and they didn't work
with a "live" profiling view. To fix this, I changed the periodic sampling thread
to instead be a periodic flush of a sample every few allocations. The performance
impact is tucked away only when profiling is turned on, and it's very non-invasive to
the rest of the GC. The flush calls a callback with the relevant information if the
inspector is on, and the inspector sends a message back to the browser.
Changelog: [Internal] Fix for Hermes heap timeline profiling
Reviewed By: neildhar
Differential Revision: D23993363
fbshipit-source-id: 8e0b571130cbb7e839dfb009b04f584f5179085d
Summary:
## Previously
- When TurboModules system was on, we'd only log events from the TurboModules system.
- When TurboModules system was off, we'd only log events from the NativeModule system.
This ultimately gives us less data to analyze both systems in production.
## Changes in This Diff
When perf. logging is on, we'll log events from both systems. Each QPL event now include an annotation of which system the event is coming from. Concretely, this will allow us to see how much of the NativeModule system is being exercised in the TurboModule test group.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D24232594
fbshipit-source-id: 7dff57bd74fc7ef744d3e06ff174304f25790456
Summary:
Index adjustment is tricky. Seems more reliable to adjust each immediate mutation, and then immediately adjust delayed mutations based on it, rinse and repeat.
Previously it was possible to construct examples where the UI would get into a weird state because index adjustment caused items to be inserted in the wrong location.
Changelog: [Internal]
Reviewed By: kacieb
Differential Revision: D24232926
fbshipit-source-id: f8c445213528c2d2aedacf3e0c73c5bbeb62bc3d
Summary:
Changelog: [internal]
RCTViewComponent view should have multipleTouchEnabled set to YES.
Paper has it enabled by default as well.
Reviewed By: JoshuaGross, yungsters
Differential Revision: D24219076
fbshipit-source-id: 74c18632457147b944a8abbacdbecb57e57f62ef
Summary:
We're planning a fix in Flow (D24112595) that uncovers some existing errors that were
previously suppressed. Adding these annotations prevents them from surfacing during the
deploy of the fix.
Changelog: [Internal]
Reviewed By: dsainati1
Differential Revision: D24147994
fbshipit-source-id: fef59a9427da6db79d4824e39768dd5ad0a8d1a3
Summary:
Types First and the various esproposal flags are on by default as of 0.135
Clean up flowconfigs that have to be in sync with the main one
Changelog: [Internal]
Reviewed By: jimmy623
Differential Revision: D24221995
fbshipit-source-id: 5da2867e2f013ad729a436ada192ecab690cb413
Summary:
There are cases under investigation where unmountReactApplication is called before the ReactRootView gets an ID; in some or all of those cases, UIManagerBinding.stopSurface cannot get the ReactFabric JSI module and crashes there.
It's still unclear why `unmountReactApplication` is being called in these circumstances - maybe another crash causing React Native teardown?
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D24214712
fbshipit-source-id: 796594653f4ff6d87088c4841b89f06cc873b46f
Summary:
Use the ObjC++ native modules files generated by `react-native-codegen` for the FBReactNativeSpec library.
People working with the core native modules may now re-generate these ObjC++ files using `USE_CODEGEN=1 pod install` or `scripts/generate-native-modules-specs.sh`.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D22249978
fbshipit-source-id: a12db23defacdba36099a24ce0b8475c8973bd6d
Summary:
This PR removes unused `qs` package (query string parser) from the main `package.json` file.
I was not able to find any explicit usage of this package in the repository. Looking at the commit which introduced this package it is not clear why it has been added, query string is not processed in any way.
I have also run ` yarn update-lock` to clean up lock after latest dependencies bumps. There are no `qs` package entry removal in yarn lock, because it is already required by `request` package.
Refs: https://github.com/facebook/react-native/commit/b4785e514430dc3ba45ed6d136ec63574be88e26
## 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] [Removed] - remove unused `qs` dependency
Pull Request resolved: https://github.com/facebook/react-native/pull/30125
Test Plan: This change should not affect the code base.
Reviewed By: appden
Differential Revision: D24184372
Pulled By: cpojer
fbshipit-source-id: 4f159f3c554c48ed21839370c8370848df181046
Summary:
In D23640968 (https://github.com/facebook/react-native/commit/78b42d7fb7180102c1e8ec917dcccd2d9d4076db) I introduced a mechanism to update offsetX/offsetY whenever onMeasure/onLayout were called, to ensure that `measureInWindow` had the correct metrics and would work properly.
However, now `uiManager.updateRootLayoutSpecs` gets spammed and is called too often. For example, whenever a TextInput is focused/blurred, `uiManager.updateRootLayoutSpecs` may be called 5+ times even though
the measure specs/offsets may only change once.
Thus, we just compare with previous values before calling into the UIManager. This should give us a very small perf improvement.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D24176867
fbshipit-source-id: f0dcc816e651a843607e9e5d40d8f3489894d4ba
Summary:
dispatchDraw, dispatchGetDisplayList, updateDisplayListIfDirty, recreateChildDisplayList, etc, can all crash internally for a variety of reasons and it can be very tricky to track down the root cause. This isn't a fix, this just adds extra logging to hopefully make debugging easier.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D24166149
fbshipit-source-id: 1bbaf34a92a9bcac5a594a25522c66e6e0cc80ca
Summary:
According to Node's documentation: https://nodejs.org/api/util.html#util_util_inspect_object_showhidden_depth_colors
> The util.inspect() method returns a string representation of object that is intended for debugging. **The output of util.inspect may change at any time and should not be depended upon programmatically.**
Therefore, this diff switches over our RN Codegen snapshot tests to use a `JSON.stringify` call, followed by a replace of `"` with `'`. This gets the job done without compromising readability.
**Question:** Why do we not use `"`? A: Jest escapes all `"` in the snapshots, which makes reading the snapshots/using them in the console harder.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D24157056
fbshipit-source-id: 2f1aa2df28ac3ed4aa17bcdbcd23846ddbf804cf
Summary:
This PR changes ReadableNativeMap.getNullableValue to return null if key not found, instead of throwing exception. This matches method signature and nullable annotation.
## Changelog
[Android] [Changed] - fix ReadableNativeMap.getNullableValue to match signature
Pull Request resolved: https://github.com/facebook/react-native/pull/30121
Test Plan: RNTester app builds and runs as expected, and getNullableValue will return null instead of throwing exception.
Reviewed By: JoshuaGross
Differential Revision: D24164302
Pulled By: fkgozali
fbshipit-source-id: 572c1d4ae5fd493aa0018c2df1dfc7fc91cb4b6b
Summary:
Fix ReadableArray annotations, because these methods throw ArrayIndexOutOfBoundsException instead of null if index is not found.
## Changelog
[Android] [Changed] - fix ReadableArray null annotations. Possibly breaking change for Kotlin apps.
Pull Request resolved: https://github.com/facebook/react-native/pull/30122
Test Plan: RNTester app builds and runs as expected, and show correct type in when used with Kotlin code.
Reviewed By: JoshuaGross
Differential Revision: D24164326
Pulled By: fkgozali
fbshipit-source-id: 0c3f8fa9accbd32cc71c50befe9330e5201643f6
Summary:
The captured `instance_` will result in a call to JVM code to release the reference when the lambda is destroyed. However, Hermes may destroy the lambda in a non-JVM background thread.
Since `instance_` is a member of the class, and `this` is already captured, there is no need to capture it.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D24141179
fbshipit-source-id: e3b268485ed229ee933281a80e5dbe2feba55719
Summary:
# Changelog:
[Internal][Changed] - Close the global perf logger when we create the scoped performance logger and absorb the global perf logger into the scoped logger
Reviewed By: rubennorte
Differential Revision: D23898621
fbshipit-source-id: 0d9bfd95175e660c0bd0bc74974126f92fe409b2
Summary:
Our Babel plugin that strips irrelevant platform-specific code does not currently know how to deal with early return statements.
This minor change to a couple call sites enables the output bundle for Android to omit code specific to iOS.
Changelog:
[Internal]
Reviewed By: ejanzer
Differential Revision: D24139922
fbshipit-source-id: 467c0c38dd45679b889a8a94d85f73fd969e5b36
Summary:
Remove extraneous newlines before and after structs, before copyright headers, and other locations.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24117137
fbshipit-source-id: 194996019b4cadef9239a78334f31c0bc89e3901
Summary:
react-native has moved more code to be flow-strict. Part of this move involved adding custom flow-typed definitions for some third-party dependencies where not previously present. These definitions are not currently published, which prevents type-checking some parts of react-native externally.
This change publishes these type definitions as part of the react-native NPM package. Impact to package size is pretty negligible.
## Changelog
[Internal] [Fixed] - Publish Custom Flow Library Definitions
Pull Request resolved: https://github.com/facebook/react-native/pull/30102
Reviewed By: TheSavior
Differential Revision: D24099502
Pulled By: cpojer
fbshipit-source-id: bf3942aa973df4cfc2843ec3e7dbec82623f0447
Summary:
The UserFlow API takes in a FlowId as a parameter on all of its calls. However, this type is currently not exported so consumers cannot store a generated FlowId without creating their own matching type.
Changelog: [Internal]
Reviewed By: dmitry-voronkevich
Differential Revision: D24115983
fbshipit-source-id: 63afbca01343a31aa60042db3693a96a6b854939
Summary:
When I landed D24042677 (https://github.com/facebook/react-native/commit/030d2c1931fb9ff97f682343914503a1c359e1c4), I had the right idea in spirit but forgot to negate the if statement. Oops.
This means that in non-Fabric, the cached spannable will be updated (potentially causing a crash) and the cached spannable will *never* be updated, meaning that most TextInputs will be measured as 0 in Fabric.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D24119952
fbshipit-source-id: dc86137956535e1f2b147bb432d050b3561e2658
Summary:
Fixes an issue where, if a spec uses an array of elements where the element is a type alias, the generated code would use the wrong variable name.
An example of such a spec can be found in `NativeExceptionsManager.js`:
```
+reportSoftException: (
message: string,
stack: Array<StackFrame>,
exceptionId: number,
) => void;
```
The fix ensures the local variable name is passed through, ensuring that either p or itemValue_N is used when appropriate.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D24116429
fbshipit-source-id: f39b75adb604c751d70a284a11a7fa6649b1344d
Summary:
This is a resubmit of D21499015. It resolves https://github.com/facebook/react-native/pull/28852 and https://github.com/facebook/react-native/issues/27787.
From Harry Yu's original PR (too old to merge now):
Text in TextInputs can't be selected by long press. This happens only when they're inside of FlatLists that are rendered with removeClippedSubview prop set to true on Android.
Fixes https://github.com/facebook/react-native/issues/27787
Issue https://github.com/facebook/react-native/issues/6085 2 years ago had fixed this issue with a quick fix, but the code has since disappeared in another change. It has a longer explanation for why it's fixed, but essentially - the text is assumed to be not selectable since the TextInput is initialized without being attached to the window. We need to explicitly set the text to be selectable on attachment. This change redoes that change with a 1-line fix.
Changelog: [Android] [Fixed] - Fixed TextInput not being selectable in removeClippedSubviews FlatLists
Pull Request resolved: https://github.com/facebook/react-native/pull/28852
Test Plan:
This can be tested with a new toggle in RNTesterApp.
Go to the FlatList in RNTesterApp
Toggle on "removeClippedSubviews"
Try selecting some text in the list header. It should fail without this comment but succeed with it
Reviewed By: sammy-SC
Differential Revision: D24043533
Pulled By: JoshuaGross
fbshipit-source-id: c8e60f8131ccc5f6af31ed976c4184d0a16eb3af
Summary:
Now we check for `_state` being nullptr before dereferencing this.
`accessibilityElements` (as a bunch of other methods that have the same check) can be called by OS any moment (we cannot predict when), so at some very rare moments, it can be called when the view is not fully initialized yet. To prevent crashing we just need to return some default value indicating that the view is empty.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D24095654
fbshipit-source-id: d8a37f269c5bf7718acb0b512e7a9313e199398e
Summary:
RCTParagraphComponentView does not need to have the state teller because it does not change the state.
Also, we are thinking about removing State Teller, so to simplify a fix coming in the next diff, we are backout the introducing a state telled in RCTParagraphComponentView.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D24095655
fbshipit-source-id: 90bd21cb8b01056c0db902a604b4088bf8c7750e
Summary:
In theory, view configs can be hierarchical (one can depend on another), at least it was semi-supported on iOS once. And AFAIK there is only one component that seems to use this feature - `RCTComponentHostingView`, all other components essentially inherit RCTView or nothing. At the same time, RCTComponentHostingView does not really need it because RCTComponentHostingView itself does not expose any props.
Changelog: [Internal] Removed outdated warning
Reviewed By: kacieb
Differential Revision: D24095348
fbshipit-source-id: 5629c7433f151b72aae8201c58dd42062990b77e
Summary:
We're seeing that GCs caused by memory warnings on Android are barely collecting
any memory and are operating on much smaller heaps than natural GCs.
This is likely due to some of the TRIM_MEMORY_* events firing too often.
Log which event name it was, instead of the generic "memory warning", to narrow
down the cases where the memory warning was helpful. Unhelpful warnings will
later be moved to not force a GC.
Note that this diff changes Venice, but we don't see any Venice heaps in production,
so it won't matter much other than making the code match up.
Also note that iOS has a similar memory warning in `RCTCxxBridge.mm`, but it hasn't
been called in production. Perhaps iOS is less trigger-happy for memory warnings than
Android.
Changelog: [Internal]
Reviewed By: neildhar
Differential Revision: D24093394
fbshipit-source-id: 03304f0f79083133c4d9b730559aef291319b6eb
Summary:
The `flow-typed/npm` path contains third-party code. The propietary Facebook license header should not be included in these files.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24082894
fbshipit-source-id: 34928c7a6a3d1fdf8d91b4cdd86eb72ca6341545
Summary:
At this point, I think we are ready to enable validation
Changelog: [INTERNAL]
Differential Revision: D24062829
fbshipit-source-id: c82dcd2c376e5cdeb164451e16b6fb3a666106f4
Summary: Renaming methods in UserFlow to match other APIs
Reviewed By: swillard13
Differential Revision: D24078270
fbshipit-source-id: c3a65d440e389d7b3c76de7706372265584353c8
Summary: Creating UserFlow API to track reliability of user interactions
Reviewed By: swillard13
Differential Revision: D23937121
fbshipit-source-id: 83701b8216c9b18c9c3d8c332efa84942ac26ba6
Summary:
Changelog: [internal]
Changing value of Switch should animate except for first rendering of the switch.
Reviewed By: JoshuaGross
Differential Revision: D24046268
fbshipit-source-id: d0b2a1a4837fc8daebce2f0e6d3d82212b490ba4
Summary:
Small PR to bump the CLI version to latest available pre-cut of branch 0.64, as per usual cc thymikee
*(ignore name of the branch, i typoed the version �{emoji:2642})*
## 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] - Bump CLI in the repo to 4.13, latest available
Pull Request resolved: https://github.com/facebook/react-native/pull/30085
Test Plan: Nothing in particular to test, it's just a chore.
Reviewed By: JoshuaGross, kacieb
Differential Revision: D24068562
Pulled By: cpojer
fbshipit-source-id: 0df662775248aa0e95c77fdd246fadabce10f670
Summary:
iOS Fabric actually ignores the `index` property and just uses parent and child tags to remove the child from a parent. This brings Android slightly closer to iOS: we try to use the index, but if the index is incorrect, we either (1) throw if the child isn't contained in the parent, or (2) find the correct index, and continue.
In debug, this will still crash, so we'll get more signal about why this happens.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D24056375
fbshipit-source-id: 07507cc32ad02505d3271fc95ecb45d080109078
Summary:
This will make sure that the snapshot tests for the generators work with NullableTypeAnnotation.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D24027246
fbshipit-source-id: cee93e40be7585ec527087d114f8326c2ecb9ddd
Summary:
Previously, all our type annotations contained a `nullable` property. This diff removes that property from all our NativeModule type annotations, and instead introduces a `NullableTypeAnnotation`.
**Some Benefits:**
- In all our serialization functions, we use Flow exhaustive checking to ensure that all type-annotations can be serialized. Since nullability is now recorded as a type annotation, Flow will ensure we always explicitly handle nullability. Previously, with nullability as a property, we could ignore it without any feedback from flow.
- This aligns the NativeModule schema with the ESTree spec.
- After this diff, we're one step closer to sharing type annotations with Codegen's schema. Many NativeModule type annotations now have the same shape as their Codegen counterparts. They will be merged in a subsequent diff.
**Downsides:**
- If you want to check whether a type annotation is of type `T`, you have to remember to unwrap the type annotation *yourself*. Flow won't warn you if you forget to unwrap the type, which can lead to incomplete handling to nullable types in our generators.
- When you're creating type annotations in code, previously, you *had* to specify nullability, since it was a property on all type annotation objects. Now, it's very possible for you to forget to wrap the type annotation, which will just lead to nullability bugs.
**Notes:**
- In the scheam, exported type annotations are *always* required. They can be made nullable using the new `Nullable` genric type.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24026887
fbshipit-source-id: 9e71e2c6102dc506824403dbb712488ca8507d08
Summary:
The Flow Parser's snapshots, which are serializations of the CodegenSchema object, are extremely difficult to read. In this diff, I explicitly serialized the schema objects using Node's `util.inspect`.
**Benefits:**
- The snapshots are more readable now.
- You can copy-paste the objects from the snapshot files directly into the Chrome console, or into other JavaScript files. This is a very useful feature, when we're testing the generators, or other infra that depends on the codegen.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D24063112
fbshipit-source-id: 2c6ec3424aac8bab2688dc6ae286b73f90e4bef1
Summary:
Adding another method to ReactMarker to log a marker with both a tag and an instanceKey. The instanceKey is used to attach the event to the correct marker instance - this is used already in Java, but not in C++ yet.
The way that ReactMarker is currently set up makes this change a little more complex/confusing. For some reason I'm not totally clear on, we're using C-style exports with some platforms-specific ifdefs in ReactMarker.h (even though the impl is .cpp?). And we swap out the implementation for `logTaggedMarker` at runtime in platform-specific code (JReactMarker and RCTCxxBridge).
In this diff, I just add a new function alongside `logTaggedMarker`, `logTaggedMarkerWithInstanceKey`. I did it this way because I figured modifying `logTaggedMarker` to add an argument would be a breaking change.
Reviewed By: PeteTheHeat
Differential Revision: D23831533
fbshipit-source-id: f5b3eba1f43a80f7723fdb64cfc0a792548db2ba
Summary: We need this checks to make the results of those function more reliable.
Reviewed By: sammy-SC
Differential Revision: D24038911
fbshipit-source-id: 3b54fe3056c9508cde84ea157beebea57e7e49b6
Summary:
Changelog: [internal]
This code was put in when we didn't have view commands implementation in Fabric. Now we do so let's get rid of it.
Reviewed By: JoshuaGross
Differential Revision: D24046269
fbshipit-source-id: d0f203bc09bf22f5307cb1844d14b295fe3550dd
Summary:
Changelog: [internal]
# Problem
Fabric doesn't know when NativeAnimatedModule control a prop and overrides its change whenever any prop changes. For example component A is animating its opacity from 1 to 0. NativeAnimatedModule starts calling `[RCTViewComponentView updateProps:oldProps:]` method interpolating opacity from 1 to 0.
After it is finished, if any prop is updated on the component. Its opacity will be set to default.
# Fix
This is a temporary problem until Unified Animation System is put in place. To work around the issue for now, we keep a set of prop keys controlled by animated and only update the prop if it isn't in this list. List is cleared when the component is reused.
Reviewed By: JoshuaGross
Differential Revision: D24046848
fbshipit-source-id: 63cca6854f97b2de764cb3ed505d328323c64525
Summary:
This is a different approach to break the retain cycle: instead of detaching a view manually, we store a pointer to a view weakly.
I am working on some change that will make possible (and make use of it) to call `start` and `stop` on Surface objects mutiple times, so to make it happens we need to remove detaching from `stop` method.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D24041524
fbshipit-source-id: 700b13d715d2eb84d52bf3e51e0fd2896a55baf8
Summary:
With this change a RCTFabricSurface instance will not longer to hold a `RCTSurfacePresenter`. This change will enforce the guarantee that retaining a `RCTFabricSurface` is not enough for the service to run (something also should retain a `RCTSurfacePresenter`).
For now it's a very small fix that should not anything, but this is a crusial part of some changes I am working on (one aspect of which implied calling unregistration in a `RCTFabricSurface`'s destructor). I need to decouple this part to test this change earlier and decouple this part of the complexity from the future diffs.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D24039581
fbshipit-source-id: c289ae057f0cd5b438f0aa9a1eb8577e1e00b39c
Summary:
Flow will soon stop allowing generic types to "escape" out of the scope in which they were defined. The fix will be to add annotations to currently-unannotated variables, parameters, and function returns, so that generics don't become inputs to type inference for those positions. This diff adds new type annotations to xplat where possible to minimize the impact of this change.
This diff was generated by running
```
buck run //flow/src/facebook/komodo/binaries:annotate_escaped_generics -- --write ../../xplat/js
```
from within the flow directory, and then reverting changes that led to new errors. Most changes were reverted by running:
```
facebook/flowd check --json --json-version=2 ../../xplat/js &> post-json
jq -f j.jq < post-json | xargs hg revert
```
where `j.jq` is
```
def locs: [.primaryLoc.source, (select(.rootLoc.source != null) | .rootLoc.source), .referenceLocs[].source ] | unique;
[.errors[] | locs[]] | unique | .[]
```
Changelog: [Internal]
Reviewed By: panagosg7
Differential Revision: D24006427
fbshipit-source-id: 0cd6ec8a9611d8b1e9b14c54f9fffd2d7de2fd9e
Summary:
This is a check to execute code only in Fabric, and... it's just wrong. This object is *always* present, for Fabric and non-Fabric. We instead need to check if there's actually a state object, as other parts of the code check for.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D24042677
fbshipit-source-id: 5cf6ebc8f07987d917fdf11042d1715876fa8229
Summary:
If removeViewAt crashes, log the children of the parent view, and all of the parent's ancestors.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D24019515
fbshipit-source-id: c5b1ca0948ebc47f2648e161770affa8542ca5dd
Summary:
This diff removes an incorrect assert and replaces it with a debug-only verification phase that compares "what we want" with "what we get".
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: PeteTheHeat
Differential Revision: D23983123
fbshipit-source-id: 03a628b4f8baa1f5fe4b55354b7c943e38b5e537
Summary:
It was recently upgraded to 4.4, so we don't need the 4.3.1 anymore.
Changelog: [Android][Removed] Removed Robolectric 4.3.1 setup
Reviewed By: jselbo
Differential Revision: D24030822
fbshipit-source-id: 09b3c577d32028723e7bbc02f13459a7ae69b749
Summary:
A `cat` to file was removed accidentally, preventing the configuration script from executing successfully as part of a `pod install`.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24024824
fbshipit-source-id: 94af0c6e663320bfac04ee8f6fb37bd4bdc379a4
Summary:
This was causing a crash in babel:
```
$ babel src --out-dir bin --source-maps
Error: Cannot find module 'babel-plugin-idx' from
'~/fbsource/xplat/js/react-native-github/ReactCommon/hermes/inspector/tools/msggen'
- If you want to resolve "idx", use "module:idx" {
code: 'MODULE_NOT_FOUND'
}
```
It didn't appear that this module was used, so I deleted it.
Changelog: [Internal]
Reviewed By: neildhar
Differential Revision: D23993272
fbshipit-source-id: dd34f0fc652cb27c87c891ca37d0eba66a19a6cf
Summary:
Changelog: [internal]
Components can update state multiple times before the state update queue is flushed. This causes unnecessary layout/diff and mount passes. To solve this, drop stale state updates inside `stateUpdateQueue_ ` for specific `ShadowNodeFamily`.
Delivering stale status updates is redundant. Let's take SafeAreaView as an example. It schedules 5-6 state updates before `stateUpdateQueue_` is flushed. That's unnecessary work blocking JS thread. We only care about the latest state update. Same for TextInput and other components using state updates.
Reviewed By: JoshuaGross
Differential Revision: D23987707
fbshipit-source-id: 2e3f92cc93af61d78ac564aa40aef165af64b8c1
Summary:
These native modules are now filtered downstream in `combine-js-to-schema-cli.js`.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24003572
fbshipit-source-id: d858dbf4a4b6d522ed528f9c2262f37243317160
Summary:
The sample module is meant for demo only, but it lives alongside other core modules in react-native repo.
For now, exclude it in the Flow-type parsing, just like `NativeUIManager.js`
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D24005108
fbshipit-source-id: 9ef524bfe2778dd983c94d1701f9ce49da5e0a68
Summary:
This compiles SampleTurboModule into RNTester Android. It also adds the NativeModule playground to show case TurboModule system to RNTester examples, just like in iOS.
{F337854369}
Changelog: [Android][TurboModule] Added TurboModule example to RNTester when `USE_CODEGEN` is set
Reviewed By: hramos
Differential Revision: D24004711
fbshipit-source-id: b682dd51fa998ee2e60f8d6ffd8c39220d13a7fe
Summary:
This is the Java/JNI impl of the NativeSampleTurboModule.js, just like on iOS. The files here are supposed to be generated by the react-native-codegen, but they are checked in to the repo for easier build integration with RNTester.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D23985746
fbshipit-source-id: 46340d778f3d964efe5b538d15ebe0f2cab04862
Summary:
Before RNTester compilation starts, it needs to wait for :ReactAndroid NDK build to finish, so that it knows where to find the exported .so files. This tells the `preBuild` task to depends on `:ReactAndroid:prepareReactNdkLibs` task. The .so files are now copied over to the local project build dir, instead of depending on :ReactAndroid's build dir.
For cleanup, the reverse ordering is needed: before `clean` removed our temp dir to store the copied .so files, make sure the ndkBuild cleanup tasks execute beforehand.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D23982989
fbshipit-source-id: 955d7c9bccb5855b6b066fca89764df2ede89f63
Summary:
The sorting function currently forms a partial ordering, not a total ordering. This can cause problems with certain sequences of immediate or conflicting mutations, leading to UI corruption or crashes.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D24002668
fbshipit-source-id: edc9b4c1e3104897cb0c5fd6da563ec43d800494
Summary:
Making this change because I see this error when compiling Internationalization
```
➜ fbsource buck build //xplat/js/RKJSModules/Libraries/Internationalization:generated_objcpp_modules-InternationalizationApple
buck-out/gen/33fbdb84/xplat/js/RKJSModules/Libraries/Internationalization/generate_module_mm-Internationalization/FBReactNativeInternationalizationSpec-generated.mm:15:9: fatal error: 'FBReactNativeInternationalizationSpec.h' file not found
#import "FBReactNativeInternationalizationSpec.h"
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
Command failed with exit code 1.
command: [/Applications/Xcode_11.6.0_fb.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++, @/Users/ramanpreet/fbsource/buck-out/bin/33fbdb84/xplat/js/RKJSModules/Libraries/Internationalization/generated_objcpp_modules-InternationalizationApple#compile-FBReactNativeInternationalizationSpec-generated.mm.o...
```
Since the header namespace is "FBReactNativeInternationalizationSpec", we can only import the header file via "FBReactNativeInternationalizationSpec/FBReactNativeInternationalizationSpec.h", according to this buck documentation: https://buck.build/rule/cxx_library.html#headers. Not entirely sure how this target compiled before.
The legacy codegen buck target also set the header namespace to "": https://fburl.com/diffusion/3p85qhf9.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D23978436
fbshipit-source-id: c9cd7c710edf94df6df10778f8603870f92275a7
Summary:
Adjust generated ObjC++ code to resolve a few build time and run time errors:
* Suppress CONSTANTS struct implementations
* Use type alias name as struct name when serializing arguments that involve a type alias
* Use actual number of arguments for a method when generating method map.
With these changes in place, RNTester can be built and run using the code that is generated by the new codegen.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D23926500
fbshipit-source-id: 88fcbb795fd71dc8155eb26348db943975e13e84
Summary:
* Removed extraneous closing brace.
* Fixed static method signature, replacing double colon with an underscore (`static facebook::jsi::Value __hostFunction_Native${moduleName}SpecJSI::${methodName}()` -> `static facebook::jsi::Value __hostFunction_Native${moduleName}SpecJSI_${methodName}()`).
* Wrap `getConstants` selector name with `selector()`.
* Pass through `getConstants` and `constantsToExport` to allow de-duping of `getConstants` method in generator output.
Note that the FBReactNativeSpec that is output by the generator still has some issues that need to be addressed before it can be used.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D23910505
fbshipit-source-id: 37d884885b8878f38d40637377c2a74a728c3a13
Summary:
Just updated the generator to work with the new RN Codegen Flow Parser types.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D23667253
fbshipit-source-id: ef94e75287d37dfd7b80f61455a1bfa34bddeb28
Summary:
Just updated the generator to work with the new RN Codegen Flow Parser types.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D23667250
fbshipit-source-id: f36b5418101c40331964d1f9ede7c6bd7924383d
Summary:
Just updated the generator to work with the new RN Codegen Flow Parser types.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D23667255
fbshipit-source-id: 40b7747aad89f6d5bbb9f42d59a4df9633060c66
Summary:
Just updated the generator to work with the new RN Codegen Flow Parser types.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D23667252
fbshipit-source-id: 34404a478ddd67446d82b5f98e1051300064e95c
Summary:
Just updating this generator to understand the new RN Codegen Module parser flow types.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D23667254
fbshipit-source-id: 558dd7ac5b4541edf40248b8ab8bb50d31fa8624
Summary:
NativeModule specs exist under `react-native-github/packages/react-native-codegen/src/__tests__/modules/fixtures`. `GenerateModuleObjCpp-test.js` runs the RN Codegen on those NativeModule specs, and saves the output inside a snapshot. For convenience, the folowing command runs the legacy codegen on the fixtures:
```
buck build fbsource//xplat/js/react-native-github/packages/react-native-codegen/src/__tests__/modules:RNCodegenModuleFixtures-flow-types-ios --show-output
```
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D23637708
fbshipit-source-id: 3319f319515eca42b4499682313fea6e0bdc2a06
Summary:
## Misc. Improvements
* We now have 95%+ flow coverage in all generator files. Henceforth, we can make changes to these files with more confidence, and trust flow to catch more errors. This should also improve the DevX of working on these files.
* Better templates: Instead of doing string replace with RegExps, we instead use functions and leverage JS template literals to generate our code. A few benefits: (1) data dependencies of templates are clearly visible, and statically checked by flow, (2) the templates are more readable in VSCode.
* Merged the GenerateModuleHObjCpp.js and GenerateModuleMm.js generators. They can share a lot of logic, so it's not a good idea to keep them separate.
* The ObjC++ module generator no longer generates “dead” structs (i.e structs that aren’t used by type-safety infra). In fact, it explicitly only supports the types in our Wiki. (I know this wasn’t the case with the legacy codegen, because we were generating native code for enums in the legacy codegen). This is a mixed bag. The test to verify correctness will be more difficult to write. However, keeping structs in the codegen needlessly complicates the parsers + generators, and creates technical debt for us to clean up later.
## Abstractions
- **StructCollector:** As we serialize NativeModule methods, when we detect an ObjectTypeAnnotation in the return type of `getConstants()` or inside a method param, we must create a Struct JS object for it. When we detect a type-alias (also in the same locations), we must look up that type-alias and create a Struct from its RHS. A Struct is basically an ObjectTypeAnnotation with a context (i.e: used in getConstants() vs as a method param), that cannot contain other ObjectTypeAnnotations.
- **serializeMethod.js** Given a NativeModule method type annotation, output the protocol method, JS return type, selector, a record of which params were structs, and which structs. Basically, this is all the information necessary to generate the declaration and implementation codegen for a partiular NativeModule method.
- **serializeStruct/*.js**: After creating all these Structs, we need to loop over all of them, and tranform them into ObjC++ code.
- **serializeStruct.js**: Depending on the struct context, calls either `serializeRegularStruct.js` or `serializeConstantsStruct.js`. Both of these files have the same layout/abstractions. They look very similar.
- **serializeModule.js:** Outputs RCTCxxConvert categories for transforming `NSDictionary *` into C++ structs. Outputs ObjCTurboModule subclass.
## Algorithm
```
for spec in NativeModuleSpecs
structCollector = new StructCollector
resolveAlias = (aliasName) => nullthrows(spec.aliases[aliasName])
methodDatas = []
for method in methods(spec)
methodData.push(serializeMethod(method, structCollector, resolveAlias))
end
structs = structCollector.getStructs()
output generateImplCodegen(methodDatas, structs)
output generateHeaderCodegen(methodDatas, structs)
end
```
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D23633940
fbshipit-source-id: 7c29f458b65434f4865ef1993061b0f0dc7d04ce
Summary:
There are two operations we do in every NativeModule generator:
- We convert the `SchemaType` into a map of NativeModule schemas
- If the type-annotation is a TypeAliasTypeAnnotation, we resolve it by doing a lookup on the NativeModuleAliasMap. This is usually followed by an invariant to assert that the lookup didn't fail.
Both procedures have been translated into utilities for use across our generators. I also deleted `getTypeAliasTypeAnnotation` which will no longer be used.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D23667249
fbshipit-source-id: 4e34078980e2caa4daed77c38b1168bfc161c31c
Summary:
In diffs below, we made several changes to the NativeModule schema. This diff just ensures that the input to our generator snapshot tests, which are module schemas, are valid.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D23633942
fbshipit-source-id: 444ccd60f6ec76e348a8e54b946260464ff3aeee
Summary:
In the future, we'll use `NativeModuleArrayTypeAnnotation` inside JS struct objects. Structs cannot contain `ObjectTypeAnnotations` anywhere. Therefore, we need the elementType of `NativeModuuleArrayTypeAnnotation`'s elementType customizable.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D23645210
fbshipit-source-id: 97abb993d59536ebd68ec08b18ce7f2801c68a2d
Summary:
We have first class support for Promises in our codegen. So, it's more appropriate to just call this PromiseTypeAnnotation, as opposed to GenericPromiseTypeAnnotation.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D23645209
fbshipit-source-id: bfc0b909750e221e18be33acf197f342a2918aa9
Summary:
We were using `$ReadOnly<NativeModuleAliasMap>` everywhere, so I figured we'd just make the type itself `$ReadOnly`.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D23645207
fbshipit-source-id: 4e018d5768f4fcfd00492def7d840a5054cb2b73
Summary:
This diff introduces a `Required<T>` generic type in CodegenSchema. Why? NativeModule aliase RHSs are basically ObjectTypeAnnotations but they have `nullable` fixed to `false`. This generic type reduces duplication in the schema flow types.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D23645208
fbshipit-source-id: da984f64fa17d8533a3ea74b132ce10aae9aa7ed
Summary:
This diff has a few changes:
- All type annotations are now declared top-level, and exported from `CodegenSchema.js`.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D23616473
fbshipit-source-id: 1509c304305e56674bd76c44bc49f755dfeaa332
Summary:
Consider this case:
```
type Animal = ?{|
name: string,
|};
type B = Animal
export interface Spec extends TurboModule {
+greet: (animal: B) => void;
}
```
The generated output for this spec is:
```
namespace JS {
namespace NativeSampleTurboModule {
struct Animal {
NSString *name() const;
Animal(NSDictionary *const v) : _v(v) {}
private:
NSDictionary *_v;
};
}
}
protocol NativeSampleTurboModuleSpec <RCTBridgeModule, RCTTurboModule>
- (void)greet:(JS::NativeSampleTurboModule::Animal &)animal;
end
```
Observations:
1. The codegen looks as though we wrote `+greet: (animal: ?Animal) => void;` as opposed to `+greet: (animal: B) => void;`
2. The generated struct is called `Animal`, not `B`.
## After this diff
Whenever we detect a usage of a type alias, we recursively resolve it, keeping a track of whether the resolution will be nullable. In this example, we follow B to Animal, and then Animal to ?{|name: string|}.
Then, we:
1. Replace the `B` in `+greet: (animal: B) => void;` with `?Animal`,
2. Pretend that `Animal = {|name: string|}`.
Why do we make all type alias RHSs required?
2. This design is simpler than managing nullability in both the type alias usage, and the type alias RHS.
3. What does it mean for a C++ struct, which is what this type alias RHS will generate, to be nullable? ¯\_(ツ)_/¯. Nullability is a concept that only makes sense when talking about instances (i.e: usages) of the C++ structs. Hence, it's better to manage nullability within the actual TypeAliasTypeAnnotation nodes, and not the associated ObjectTypeAnnotations.
## Other Changes
- Whenever we use the `Animal` type-alias, the e2e jest tests validate that the type alias exists in the module schema.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D23225934
fbshipit-source-id: 8316dea2ec6e2d50cad90e178963c6264044f7b7
Summary:
## Test Structure
- Parameter Parsing
- For type in [optional, nullable, optional and nullable, required]:
- Can parse Primitives
- Can parse Object
- Can parse Arrays
- Can parse primitive element types
- Can parse Object element types
- Can parse Array element types
- Can parse Reserved Type element types
- Can parse Type alias element types
- Can parse Object Literals
- Can parse Function
- Can parse Reserved Types (e.g: RootTag)
- Can parse Type alias
- Can parse Object Literals
- For prop type in [optional, nullable, optional and nullable, required]:
- Can parse primitive prop types
- Can parse Object prop types
- Can parse Array prop types
- Can parse Reserved Type prop types
- Can parse Type alias prop types
- Can parse Object Literal prop types
- Return Parsing
- For type in [nullable, required]:
- Can parse Promises
- Can parse Primitives
- Can parse Object
- Can parse Arrays
- Can parse primitive element types
- Can parse Object element types
- Can parse Array element types
- Can parse Reserved Type element types
- Can parse Type alias element types
- Can parse Object Literals
- Can parse Function
- Can parse Reserved Types (e.g: RootTag)
- Can parse Type aliases
- Can parse Object Literals
- For prop type in [optional, nullable, optional and nullable, required]:
- Can parse primitive prop types
- Can parse Object prop types
- Can parse Array prop types
- Can parse Reserved Type prop types
- Can parse Type alias prop types
- Can parse Object Literal prop types
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D23089925
fbshipit-source-id: 73c3b1ef33b402265c14f0ac9e364414a5d54dca
Summary:
This diff:
1. Simplifies the NativeModule schema Flow types.
2. Simplifies the NativeModule Flow parser, to accomodate the modified schema, and to reduce code duplication.
**Notes:**
- If the parser detects an unrecognized type within the context of parsing an Array's element type, it'll omit the `elementType` property of the `ArrayTypeAnnotation`. Details: T72031674. **Rationale:** Basically, when an array element type is supported, we use it in our generators. When it's unsupported, we ignore it. In the unsupported case, there's no point in trying to parse the Array element type, which is why I decided to omit the `elementType` property. Ideally, our NativeModule specs would never use unsupported types, in any context. This would allow us to always parse and use the elementType. However, that seems like a it could be a hefty migration: we have > 400 specs. Since, this isn't a battle we need to fight right now, I left a TODO at the relevant lines instead.
- The legacy codegen would generate structs for each object literal type in the file. In this re-implementation of the parser, I only insert into the aliases array when we detect a usage of a type-alias to an ObjectLiteral type annotation. With this decision, we won't be able to generate these unnecessary structs. This is good because we get rid of dead code. It's bad because it might make our migration to this codegen bit more difficult.
[WARNING] This diff produces flow failures that will be addressed in subsequent diffs.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D23201387
fbshipit-source-id: 55ce0df925a8bae0e7d5bb2a9b63167607eba461
Summary:
## Changes
- Started doing cleanup under `/parsers/flow/modules/methods.js`
- Rename `NativeModuleMethodTypeShape` -> `NativeModulePropertyShape`
- Moved optional property from `FunctionTypeAnnotation` to the `NativeModulePropertyShape`
- Introduced a nullable property inside what was once `FunctionTypeAnnotation`.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D23146050
fbshipit-source-id: 2fe97bb9c0736242682133e4923131a54bbea54b
Summary:
## Changes
- Generating the aliases was split over `parsers/flow/modules/index.js`, and `parsers/flow/modules/aliases.js`. I moved everything to the latter file.
- Generating methods was split over `parsers/flow/modules/index.js` and `parsers/flow/modules/methods.js`. I moved everything to the latter file.
- More type-safety
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D23143382
fbshipit-source-id: e11b76bee7917a7db37ae7f1af64da5f046c5d1e
Summary:
`buildSchema` delegates to two other functions: `buildComponentSchema`, or `buildComponentSchema`. Both return have a return type of *required* `SchemaType`. Therefore, `buildSchema` can have a return type of `SchemaType`.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23135499
fbshipit-source-id: f13db17549c93b965f372d9b68d06efc2a40c6cc
Summary:
Just broke down getConfigType into two separate functions: `isModule` and `isComponent`.
- Cleaned up `isComponent`, to check for the the AST node types.
- Re-implemented `isModule`
- Improved error messages.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23121896
fbshipit-source-id: 3df2b2e334c4cea8eabe2e73ecb9f1f1217e7be4
Summary:
There are two types of types we care about:
- Type aliases
- Interface Declarations
These types can be exported.
I think we should build the types dictionary from only those types. Everything else should be ignored.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D23120241
fbshipit-source-id: 9f023081d0f9c85b45407b180ae7c3e7391eb725
Summary:
Unecessary, since `NativeModuleShape` is the exact same thing.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23119784
fbshipit-source-id: 8c4aded88a97a80aa977c13cc27e32fbe68150aa
Summary:
We already support type-aliases in our NativeModule method params. This diff extends the support to NativeModule method returns.
**Note:** I need to see if I need to update the generators to handle this case. Will do that in this diff, after working through other higher priority stuff.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D22828839
fbshipit-source-id: cf5c756d3cacf067df217cdb6212946320a2d4be
Summary:
Split the two specs, so that that we don't have to use Flow unions in the merged spec.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D23800841
fbshipit-source-id: 28b67578832ebd733bd080877e4ab763c013fded
Summary:
Remove the older implementation of image instrumentation in Fabric by removing, RCTImageInstrumentationProxy, ImageInstrumentation from ImageRequest, and trackURLImageContentDidSetForRequest from RCTImageLoaderWithAttributionProtocol.
Changelog: [RN][Fabric][Image] Remove unused Fabric image instrumentation
Reviewed By: fkgozali
Differential Revision: D23990606
fbshipit-source-id: 004d04025d031af11377a73e5bfb64b1e0449962
Summary:
Changelog: [Internal]
Fabric removes components bottom up (from leafs to the root).
This means that by the time Fabric hides Modal, it has no content and therefore it appears as if Modal disappears without Animation.
To fix this, we snapshot contents of the Modal before any of its contents are removed.
Reviewed By: shergin
Differential Revision: D23976244
fbshipit-source-id: 01c13b74e97f82816e8946fd9d1add1db10340b1
Summary:
This small PR includes the following changes:
* deduplicate yarn lock file using [`yarn-deduplicate`](https://github.com/atlassian/yarn-deduplicate) package
* deduplicate script has been added as `update-lock`, let me know if you would like also to see this in [`postinstall`](https://docs.npmjs.com/misc/scripts) (to automatically optimize lock on every dependency change)
* according to the [npm docs](https://docs.npmjs.com/files/package.json#repository):
* main `package.json` repository field has been replaced with shorthand
* monorepo packages repository field has been extended by `directory`
The main goal of introducing deduplication script was to optimize the dependencies footprint while developing and speed up the initial installation process. Running `yarn-deduplicate` also increase the security in some way, because it enforces usage only of the latest version of the package. You can read more about the benefits in the deduplicate script [repository](https://github.com/atlassian/yarn-deduplicate#duplicated-packages).
## 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] [Added] - add yarn lock deduplication script
Pull Request resolved: https://github.com/facebook/react-native/pull/30044
Test Plan: `yarn install` was successful, this also should not affect yarn workspaces in any way.
Reviewed By: GijsWeterings
Differential Revision: D23959812
Pulled By: cpojer
fbshipit-source-id: e2455e3718378e1ce6206e79463d4083f8fe5d47
Summary:
Refs: [0.62 release](https://reactnative.dev/blog/#moving-apple-tv-to-react-native-tvos), https://github.com/facebook/react-native/issues/28706, https://github.com/facebook/react-native/issues/28743, https://github.com/facebook/react-native/issues/29018
This PR removes most of the tvOS remnants in the code. Most of the changes are related to the tvOS platform removal from `.podspec` files, tvOS specific conditionals removal (Obj-C + JS) or tvOS CI/testing pipeline related code.
In addition to the changes listed above I have removed the deprecated `Platform.isTVOS` method. I'm not sure how `Platform.isTV` method is correlated with Android TV devices support which is technically not deprecated in the core so I left this method untouched for now.
## 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] [Removed]** - remove most of tvOS remnants from the code:
* `TVEventHandler`, `TVTouchable`, `RCTTVView`, `RCTTVRemoteHandler` and `RCTTVNavigationEventEmitter`
* **[Internal] [Removed]** - remove `TARGET_TV_OS` flag and all the usages
* **[iOS] [Removed]** - remove deprecated `Platform.isTVOS` method
* **[iOS] [Removed]** - remove deprecated and TV related props from View:
* `isTVSelectable`, `hasTVPreferredFocus` and `tvParallaxProperties`
* **[iOS] [Removed]** - remove `BackHandler` utility implementation
Pull Request resolved: https://github.com/facebook/react-native/pull/29407
Test Plan: Local tests (and iOS CI run) do not yield any errors, but I'm not sure how the CI pipeline would react to those changes. That is the reason why this PR is being posted as Draft. Some tweaks and code adjustment could be required.
Reviewed By: PeteTheHeat
Differential Revision: D22619441
Pulled By: shergin
fbshipit-source-id: 9aaf3840c5e8bd469c2cfcfa7c5b441ef71b30b6
Summary:
Cleans up the native component configuration for `RCTText` and `RCTVirtualText`.
This //does// lead to a breaking change because `Text.viewConfig` will no longer exist. However, I think this is acceptable because `viewConfig` has already long stopped being an exported prop on other core components (e.g. `View`).
Changelog:
[General][Removed] - `Text.viewConfig` is no longer exported.
Reviewed By: shergin
Differential Revision: D23708205
fbshipit-source-id: 1ad0b0772735834d9162a65d9434a9bbbd142416
Summary:
Changes `usePressability` so that it accepts a nullable `config` argument.
This makes it possible for a component to use `usePressability` and lazily allocate the `config` and subsequent instance of `Pressability`. This can be useful for components that are commonly allocated but seldom pressed because it lets many usages of `usePressability` avoid allocating many extraneous objects.
Changelog:
[Internal]
Reviewed By: kacieb
Differential Revision: D23708206
fbshipit-source-id: 4a5063067131ce8c957fb16c49a2045e8c0b19fa
Summary:
Wrap iOS 14 SDK code in a `#if/#endif` so that the Instagram app compiles again
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D23948336
fbshipit-source-id: 67e6ee48d1951ae405c12b4ad39cf8c9817df627
Summary: Changelog: [Internal][Fixed] - When we close performance loggers (D23845307 (https://github.com/facebook/react-native/commit/aebb97b9c64a8d84cf852ae8efc5ef28b36da610)) we cannot rely that a timespan/point/extra will be in perf logger. Update types to reflect that.
Reviewed By: rubennorte
Differential Revision: D23907741
fbshipit-source-id: 63673aa69cd8c76253e4fee3463e37c86265cf7b
Summary:
Add a TextInput to RTL screen in RNTester, to test RTL languages with TextInput.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D23914627
fbshipit-source-id: 84c62efe7034c0dfa2ef21be3f085880292c3930
Summary:
Changelog: [internal]
# Why is text laid out twice in Fabric?
Layout constraints (min and max size) change during startup of Fabric surface.
1. `Scheduler::startSurface` is called with max size being {inf, inf}.
2. `Scheduler::constraintSurfaceLayout` is called with max size equal to viewport.
These are two operations that don't happen one after the other and on Android, CompleteRoot is called from JS before second operation is called. This triggers layout with max size {inf, inf} and later when second operation is called. Layout happens again now with correct size.
# Fix
Make sure `Scheduler::startSurface` is called with proper values and not {inf, inf}.
Reviewed By: JoshuaGross, yungsters
Differential Revision: D23866735
fbshipit-source-id: b16307543cc75c689d0c1f0a16aa581458f7417d
Summary:
Changelog: [Internal]
value needs to be set after minimum and maximum, otherwise it gets pinned to previous minimum/maximum.
Default minimum is 0 and maximum is 1. If we set value to 20 and maximum to 50, previously the value would get pinned to 1 (maximum value).
See [Apple Docs](https://developer.apple.com/documentation/uikit/uislider/1621346-value?language=objc) for more.
Reviewed By: JoshuaGross
Differential Revision: D23903545
fbshipit-source-id: 8e9dd49ced79d43b9591c7d24de59b9eaff5bdfd
Summary:
Blocking people didn't work in Dating Settings without the Bridge.
Changelog: [Internal]
Reviewed By: ejanzer
Differential Revision: D23904867
fbshipit-source-id: 4a68b9d99fcc812f6616783a06dc047a3bc64491
Summary:
Without this thing some stuff does not compile.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: fkgozali
Differential Revision: D23948622
fbshipit-source-id: f066ada183c0fd6a7b5eec542395d44bbbfe80a3
Summary:
Same as D20969087 (https://github.com/facebook/react-native/commit/be7867375580ed391bb10c50b768d998087e848d) but a bit more sophisticated.
We currently see a lot of errors happens because of division by zero in AnimatedDivision module. We already have a check for that in the module but it happens during the animation tick where the context of execution is already lost and it's hard to find why exactly it happens.
Adding an additional check to the constructor should trigger an error right inside render function which should make the error actionable.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: fkgozali
Differential Revision: D23908993
fbshipit-source-id: d21be9a72ec04fe4ff0740777d9ff49cf1bcde73
Summary:
Since https://github.com/react-native-community/cli/commit/e949e234b03fb65f8e4ed2706dfaa745aa59a14f#diff-d1800049b92343288bcbc1c484575058 the RN cli script returns an object with `:reactNativePath` instead of just JSON. Not super familiar with how objects / JSON works in ruby but using this syntax instead works.
## Changelog
[Fixed] [iOS] - Fix passing react native path in Podfile template
Pull Request resolved: https://github.com/facebook/react-native/pull/29285
Test Plan: Tested in a project inside a monorepo using the latest version of RN CLI that the proper react-native path is now passed.
Reviewed By: fkgozali
Differential Revision: D23941162
Pulled By: hramos
fbshipit-source-id: 0115412ec6d6bca101612d760dfc00cf89d97f1e
Summary:
If built with `USE_CODEGEN=1` flag set, RNTester now activates the TurboModule system, also using various codegen output from the previous commits.
Note that this is very early integration, and not thoroughly tested yet.
To verify:
```
console.warn('TM enabled?', global.__turboModuleProxy != null);
```
{F337454276}
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D23946944
fbshipit-source-id: 5838aeb9ded07b1cc0fcb069535d1c6fb3725973
Summary:
This provides the RNTester specific impl of the manager delegate. The class is responsible to provide module lookup during runtime for TurboModule, and the C++ impl is using the codegen-generated lookup functions from :ReactAndroid and :packages:rn-tester:android:app Gradle targets.
Note: RNTester still needs to explicitly enable TurboModule and instantiate this manager before it can activate TurboModule.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D23938537
fbshipit-source-id: 7957847ecc58fef8d9a276d9d3d477ecec36a700
Summary:
TurboModule Java files are still using the old lib name: `turbomodulejsijni`, so let's keep it that way for now.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D23946945
fbshipit-source-id: ff095ff51dca532c82e67e1c75e9a4e9be392d61
Summary:
To make it easier for hosting app or other lib to get access to the ReactAndroidNdk .so outputs, let's define common targets in a dedicated Android-prebuilt.mk. Hosting app's Android.mk just need to include the mk path.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D23938538
fbshipit-source-id: 850d690326d134212d5f040c6fa54ab50c53cb87
Summary:
This pull request fixes a potential `TypeError` in TaskQueue.js, that happens if a promise is added to the task queue, which is cancelled between the promise starting and resolving.
The exact error this resolves is
```js
TypeError: TaskQueue: Error resolving Promise in task gen1: Cannot set property ‘popable’ of undefined
167 | queueStackSize: this._queueStack.length,
168 | });
> 169 | this._queueStack[stackIdx].popable = true;
| ^
170 | this.hasTasksToProcess() && this._onMoreTasks();
171 | })
172 | .catch(ex => {
at Libraries/Interaction/TaskQueue.js:169:46
```
This specific error was also reported in https://github.com/facebook/react-native/issues/16321
## Changelog
[General] [Fixed] - Prevent TypeError in TaskQueue when cancelling a started but not resolved promise.
Pull Request resolved: https://github.com/facebook/react-native/pull/29969
Test Plan:
The added test demonstrates the error, if run without the fixed applied to TaskQueue.js.
This is a race condition error, so is difficult to replicate!
Reviewed By: yungsters
Differential Revision: D23785972
Pulled By: appden
fbshipit-source-id: ddb8d06b37d296ee934ff39815cf5c9026d73871
Summary:
in Android 11, there's an issue where Text content is being clipped. The root cause appears to be a breaking change in how Android 11 is measuring text. rounding up the layoutWidth calculation mitigates the issue.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D23944772
fbshipit-source-id: 1639259da1c2c507c6bfc80fed377577316febac
Summary:
This fixes a recently introduced crash in `colorComponentsFromColor()` (iOS implementation) caused by dereferencing a null pointer.
The fix is just a copy of a code fragment from a previous implementation.
Reviewed By: fkgozali
Differential Revision: D23944812
fbshipit-source-id: 977135dd75c4375affddfd75183e4890618ae819
Summary: In iOS when a parent UIView returns YES on [shouldGroupAccessibilityChildren](https://developer.apple.com/documentation/objectivec/nsobject/1615143-shouldgroupaccessibilitychildren), VoiceOver groups together the accessible children of the parent view, regardless of their position on screen. In iOS this defaults to NO.
Reviewed By: sammy-SC
Differential Revision: D23844265
fbshipit-source-id: eb99bf0873ccfd9fb196f8f7b6eafe055f6ae810
Summary:
iOS14 has introduced new styles for date picker. The default new calendar style breaks the old spinner type style.
This is a workaround to keep the spinner style as a default, until the calendar style is properly supported. According to [this github comment](https://github.com/react-native-community/datetimepicker/issues/285) it works well.
This will fix DatePicker for both Fabric and Paper, since Fabric uses the interop layer to render it.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D23935328
fbshipit-source-id: 1a7fadba274e0537f0ac4ced60e23e7c809d57dc
Summary:
The react-native-codegen provides Android.mk in the Android C++ output, but for RNTester (or hosting apps), we should just compile the codegen output with the rest of the app-specific C++ files. This is to simplify the build configuration, and also to not add too many additional .so libs to the APK.
With this commit, `RNTesterAppModuleProvider.cpp` should be "complete" for RNTester use-case. This TurboModule lookup function is the one described in https://github.com/react-native-community/discussions-and-proposals/issues/273.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D23913149
fbshipit-source-id: d1ca136787b87a0e8e6504318e1f0a78efef46ea
Summary:
When an animation is completed or a conflicting animation is detected, force props, state, layout, etc to update.
Currently, when a final animation mutation is queued, some attributes can be updated but not others, causing unexpected visual glitches at least on Android.
Some of these are arguably component bugs, but it's easier to just flush all attributes by tricking the platforms into updating all attributes. This will also prevent us from having to track down more of these bugs, potentially.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D23886519
fbshipit-source-id: 8e5081bbe3b7843c16c0f283fa07fdec0e211aa8
Summary:
Changelog: [Internal]
Padding needs to be rounded down (floor function), not rounded to the closest natural number.
Otherwise the content of the view might not fit.
Reviewed By: JoshuaGross
Differential Revision: D23905145
fbshipit-source-id: e84d70155b207144b98646dd0c4fea7a8c4bd876
Summary:
Changelog: [Internal]
There was a typo in condition. We need to be comparing step prop and not value. The same condition is implemented in Paper.
Reviewed By: JoshuaGross
Differential Revision: D23903493
fbshipit-source-id: 37506d0fac63f624332041602489ab1cf378bfcc
Summary:
This adds shared libraries dependencies to RNTester so that it can call `ReactAndroidSpec_ReactAndroidSpec_ModuleProvider()` C++ lookup function. That function is generated by the react-native-codegen during build time. This does not make RNTester use TurboModule yet, just the necessary setup to link the C++ libs together.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D23901952
fbshipit-source-id: fd5ee0ca266609207962adc5ceaf814956052eec
Summary:
Changelog: [internal]
If view was bridged from Paper, hit testing would return Paper view which doesn't have reference to Fabric's event emitter.
To fix this, if the bridged view is returned from hit testing, it is swapped with interop view which has reference to event emitter.
Reviewed By: shergin
Differential Revision: D23840054
fbshipit-source-id: d4aa4ee8da4e1da80d2e2b69b79ed82d726f04e3
Summary:
Changelog: [internal]
# Problem
`[RCTUITextView setDelegate]` is a public method and if something changes the delegate, appropriate events won't be called on the component (onTextChange, onSelectionChange and the others).
# Solution
Prevent setting of delegate from outside of the class. Ideally we would want to hide `setDelegate` altogether but that would require a rewrite of `RCTUITextView`.
Reviewed By: JoshuaGross, shergin
Differential Revision: D23813095
fbshipit-source-id: 8b76ac86727d262d0f9b81adfc8e75157847284c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/30014
This is the base setup to compile C++ as part of RNTester app. There is no dependencies on ReactAndroidNdk lib yet, just a bunch of ndkBuild setup in Gradle. Note: this is using Gradle's `nkdBuild` support instead of calling `ndk-build` manually like in ReactAndroid/build.gradle.
Reference: https://google.github.io/android-gradle-dsl/current/com.android.build.gradle.internal.dsl.ExternalNativeNdkBuildOptions.html
Note that `ANDROID_NDK` env var is honored to pick the right NDK version.
For now, this is gated behind `USE_CODEGEN` env variable.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D23887058
fbshipit-source-id: 7a962649461d15af46999a15b900464543e5b05c
Summary:
To represent a final state where a logger should no longer be used
Changelog: [Internal] - To represent a final state where a logger should no longer be used
Reviewed By: rubennorte
Differential Revision: D23845307
fbshipit-source-id: 4b2bfda4f7425ba6bc8e5e1233d9baea60dd8667
Summary:
Changelog: [internal]
When paper measures text, it sets `useLineSpacingFromFallbacks` flag on the Layout object. In Fabric this was missing and can cause incorrect layout.
Reviewed By: JoshuaGross
Differential Revision: D23845441
fbshipit-source-id: 538f440cdbbf8df2cba0458837b80db103888113
Summary: Adding two new ReactMarkers for start and end of bridgeless initialization. Creating new ones instead of reusing existing ones to make it easier to differentiate data from the bridge vs. bridgeless, and also because our existing markers 1) aren't very easy to understand, and 2) don't map cleanly to the new architecture.
Reviewed By: PeteTheHeat
Differential Revision: D23789156
fbshipit-source-id: 2ed10769e08604e591503a2bc9566aeb1d0563ed
Summary:
Bitcode is turned on by default in React Native and so, setting it here as well.
Changelog: [iOS] [Changed] - Upgraded JSI with a new HERMES_ENABLE_BITCODE flag
Pull Request resolved: https://github.com/facebook/hermes/pull/365
Reviewed By: tmikov
Differential Revision: D23823228
Pulled By: Huxpro
fbshipit-source-id: d43638818a733f6a87b2f4a1ecadad8ea9c7a419
Summary:
Open source this ESLint rule so that we can lint our open source NativeModule specs.
Changelog: [Internal]
Reviewed By: shergin, cpojer
Differential Revision: D23791748
fbshipit-source-id: e44444bc87eaa9dc9b7f2b3ed03151798a35e8a5
Summary:
Changelog: [Internal]
Construction of Layout will be needed in `TextLayoutManager.measureLines`, pulling it out into separate function prevents code duplication.
Reviewed By: shergin
Differential Revision: D23782905
fbshipit-source-id: 8ab817559ca154716a190ca1012e809c5fa2fd6e
Summary:
Since `dealloc` can be called from any thread, this would result `stopObserving` being called on a different thread/queue than the specified `methodQueue`. We specifically encountered this issue with a module needing the main queue having its `stopObserving` called on a background queue.
Changelog:
[iOS][Fixed] - Call [RCTEventEmitter stopObserving] on specified method queue
Reviewed By: RSNara
Differential Revision: D23821741
fbshipit-source-id: 693c3be6876f863da6dd214a829af2cc13a09c3f
Summary:
Changelog: [internal]
`LayoutableShadowNode::findNodeAtPoint` was iterating children in incorrect order and wasn't taking zIndex into accout.
Reviewed By: JoshuaGross
Differential Revision: D23814866
fbshipit-source-id: 38eee297147a5c5912304d139bb10f8b16ae2ee1
Summary:
Now that the react-native-codegen produces the Android.mk for the JNI C++ output, let's compile them into its own shared library, to be included in the ReactAndroid final deliverable: libreact_codegen_reactandroidspec.so. This is gated behind `USE_CODEGEN` env var.
Note: RNTester specific C++ spec files are not compiled here.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D23809081
fbshipit-source-id: 7a90f420a923d5d02654facac01ffe025c321e44
Summary:
This adjusted the C++ output for Android codegen (NativeModule specs) so we can compile it with ndk-build in Gradle:
* Use `#include` instead of `#import` for header files
* Added `#pragma once`
* Removed direct include of `<fb/fbjni.h>` -- this is not necessary
* Added generated Android.mk file based on library name
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D23809082
fbshipit-source-id: 11ddfea7b48c8b2eb6efe885641ace4fc327d50d
Summary:
The current calculation on versionCodeOverride is not human-readable.
Imagine if we have an android app with **versionName** `4.0` and **version code** `4`.
In the current implementation, the result of **versionCode** `4` for `armeabi-v7a` will be the seemingly arbitrary **1048580**. This makes the version code to be seemingly arbitrary and hard to read for humans. This PR proposes to change this calculation closer to google implementation of build number in Flutter (`abiVersionCode * 1000 + variant.versionCode`).
https://github.com/flutter/flutter/blob/39d7a019c150ca421b980426e85b254a0ec63ebd/packages/flutter_tools/gradle/flutter.gradle#L643-L647
With this change, our app with `versionCode 4 versionName "4.0"` for `armeabi-v7a` will have **1004** as the version code instead of the seemingly arbitrary **1048580**. As you can see adopting the flutter style implementation make the version code easier to read and debug.
**1004**
**1** - The ABI Type `["armeabi-v7a": 1, "x86": 2, "arm64-v8a": 3, "x86_64": 4]`
**004** - Our versionCode.
Hopefully, this can prevent future issues like this https://github.com/facebook/react-native/issues/29790.
## Changelog
[Android] [Changed] - Making Android versionCodeOverride for new apps using the template human-readable
Pull Request resolved: https://github.com/facebook/react-native/pull/29808
Reviewed By: sammy-SC
Differential Revision: D23804632
Pulled By: fkgozali
fbshipit-source-id: 89b2c196b3bfe01fa608dfb595db6d3314ca1d63
Summary:
In this diff I simplify index adjustment and add comments to rigorously describe what we're doing at each step of index adjustment.
I've also made unflattening detection more correct, robust, and slightly more efficient.
Bugs that existed before:
1) The reparenting detection that existed in the animations layer had some subtle bugs. I don't have proof that it results in any correctness issues or crashes, but I suspect it.
2) Correctness of index adjustment: there were cases where the Android mounting layer would crash because LayoutAnimations would try to remove a View at an index, but the index was wrong. This is why I sat down and diagrammed the relationships between all the bits of data we have for index readjustment - I believe this to be correct now.
3) Correctness of INSERT index adjustment: I had the insight that when we have batches of INSERTs to consecutive indices, we essentially want them to be treated as a single INSERT for adjustment purposes, so that they're all placed consecutively in the view layer. I added `ConsecutiveAdjustmentMetadata` to deal with this, and there are more comments in the code.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D23806163
fbshipit-source-id: cd9e94945034db8b840f2a806c6377034a91af61
Summary:
In the new Flattening differ, I experimentally verified that these two code paths are not hit (or redundant) and deleted them.
One of the branches did nothing and the other produced duplicate DELETE mutations for the same tag, that is handled elsewhere.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D23806161
fbshipit-source-id: 9ad2929e2d719a7b9b34640ed35f7a696103604b
Summary:
This is to prepare for enabling TurboModule on Android. This commit compiles in all the core files (C++) into the ReactAndroid NDK build step. This doesn't yet enable TurboModule by default, just compiling in the infra, just like for iOS.
New shared libs:
* libreact_nativemodule_core.so: The TurboModule Android core
* libreact_nativemodule_manager.so: The TurboModule manager/delegate
To be compatible with `<ReactCommon/` .h include prefix, the files had to move to local `ReactCommon` subdirs.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D23805717
fbshipit-source-id: b41c392a592dd095ae003f7b2a689f4add2c37a9
Summary:
Changelog: [internal]
In D23648430 (https://github.com/facebook/react-native/commit/a315e4cd30e4b8da841f587650146a62c868f67d) I made a mistake. I prevented calling `onTextLayout` unless there are attachments in the component. It fixed the problem because I unintentionally prevented `onTextLayout` to be called. Therefore, changes from D23648430 (https://github.com/facebook/react-native/commit/a315e4cd30e4b8da841f587650146a62c868f67d) need to be reverted.
To prevent infinite loop in `onTextLayout`, ParagraphEventEmitter checks if `linesMeasurements` have changed before dispatching it to JS.
Reviewed By: shergin
Differential Revision: D23782717
fbshipit-source-id: 0e84ae4f46d79ce0cf4c7340cd32be6f562ae179
Summary:
In a previous recent diff we changed Android's Delete mount instruction to *not* recursively delete the tree. This is fine, but because of that, we stopped calling `onDropViewInstance` when views are normally deleted.
Bring back that behaviour.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D23801666
fbshipit-source-id: 54e6b52ab51fff2a45102e37077fe41081499888
Summary:
This diff moves the code of TurboModule Core from ReactCommon/turbomodule to ReactCommon/react/nativemodule
For iOS: Pod spec name stays as "ReactCommon/turbomodule/..." for now, only the source/header location is affected. The target will be renamed/restructured closer to TurboModule rollout.
changelog: [internal] Internal
Reviewed By: RSNara
Differential Revision: D23362253
fbshipit-source-id: c2c8207578e50821c7573255d4319b9051b58a37
Summary:
Exceptions in C++ work quite differently from exceptions in other languages. To make exceptions actually work **correctly** all the code needs to be written with "exceptions in mind" (e.g., see https://www.stroustrup.com/except.pdf). In short, if the code is not "exceptions ready", throwing an exception causes memory leaks, dangling pointers, and invariant violations all over the place, which will probably cause another crashes down the road (which will be especially hard to investigate and attribute to the original issue).
Fabric Core (Layout, Props parsing, ShadowNodes management, and so on) does not use exceptions because in most (all?) the cases the exception is now recoverable. So, if a program detects some internal state invariant violation or missing some resource, *logically* it's fatal. We also don't want to pay code-size and performance tax for exception support, so that's why we don't use them. It's just not the right fit for Fabric Core.
This does not mean that exceptions don't happen though. C++ standard library can throw them... sometimes. And if our library is compiled with exceptions enabled (still the case, unfortunately), an exception can bubble to JavaScript code and losing all context down the road. And it's hard to investigate such crashes. To isolate those occasional exceptions inside C++ core we are marking all C++/JS boundaries with `noexcept` that stops the bubbling.
I hope that will give us much more informative crash reports.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D23787492
fbshipit-source-id: 0822dbf36fc680c15b02b5cd0f2d87328296b642
Summary:
See additional assertion. Tests still pass, so no other change was necessary.
Changelog: [Internal]
Differential Revision: D23775553
fbshipit-source-id: 57d3191f25dd55ab4da189207f6d201a31b175e0
Summary:
Because BatchMountItem executes many items, sometimes it's unclear which MountItem causes a crash. Catch and log the exact item.
This shouldn't cause perf regressions because we have a try/catch block in FabricUIManager where execute is called.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D23775500
fbshipit-source-id: c878e085c23d3d3a7ef02a34e5aca57759376aa6
Summary:
There are cases where we Delete+Create a node in the same frame. Practically, the new differ should prevent this, but we don't want to rely on that necessarily.
See comments for further justification on why deleteView can do less work overall.
In reparenting cases, this causes crashes because dropView removes *and deletes* children that shouldn't necessarily be deleted.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D23775453
fbshipit-source-id: c577c5af8c27cfb185d527f0afd8aeb08ee3a5fe
Summary:
The current Flipper version included in new React Native is quite old, causing some bugs to be present which have long been solved, such as freezing the UI after inspecting it.
Fixes
This fixes https://github.com/facebook/react-native/issues/29492 /
https://github.com/facebook/flipper/issues/1399
## 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][changed] - Update Flipper to 0.54
Pull Request resolved: https://github.com/facebook/react-native/pull/29787
Test Plan:
Updated the RN 0.63.2 based test project https://github.com/mweststrate/flipper-issue-1399-repo with `use_flipper!('Flipper' => '0.54.0')` (in `ios/Podspec`) / `FLIPPER_VERSION=0.52.1` in `gradle.properties` in the test project https://github.com/mweststrate/flipper-issue-1399-repo and verified that everything builds and connects correctly, and that the bug is no longer present.
Tried to run RN-tester project in this repo. For iOS this succeeded, on Android I got a build error:
```
make: Leaving directory '/Users/mweststrate/Desktop/react-native/ReactAndroid/src/main/jni/react/jni'
make: Entering directory '/Users/mweststrate/Desktop/react-native/ReactAndroid/src/main/jni/react/jni'
fcntl(): Bad file descriptor
[armeabi-v7a] Compile++ thumb: folly_json <= FileUtil.cpp
/Users/mweststrate/Desktop/react-native/ReactAndroid/build/third-party-ndk/folly/folly/FileUtil.cpp:37:14: error: no matching function for call to 'wrapNoInt'
make: Leaving directory '/Users/mweststrate/Desktop/react-native/ReactAndroid/src/main/jni/react/jni'
return int(wrapNoInt(open, name, flags, mode));
^~~~~~~~~
/Users/mweststrate/Desktop/react-native/ReactAndroid/build/third-party-ndk/folly/folly/detail/FileUtilDetail.h:34:9: note: candidate template ignored: couldn't infer template argument 'F'
ssize_t wrapNoInt(F f, Args... args) {
^
1 error generated.
make: *** [/opt/android_sdk/ndk/21.3.6528147/build/core/build-binary.mk:478: /Users/mweststrate/Desktop/react-native/ReactAndroid/build/tmp/buildReactNdkLib/local/armeabi-v7a/objs/folly_json/folly/FileUtil.o] Error 1
make: *** Waiting for unfinished jobs....
fcntl(): Bad file descriptor
make: Entering directory '/Users/mweststrate/Desktop/react-native/ReactAndroid/src/main/jni/react/jni'
[armeabi-v7a] Compile++ thumb: folly_json <= Demangle.cpp
```
No idea if it is related. I guess not since without making the change I got the same error.
Reviewed By: mweststrate
Differential Revision: D23767388
Pulled By: fkgozali
fbshipit-source-id: 35f0d3ddec41942f5bbc96cb391975d84729ef5e
Summary:
Continuing the adding of a "cause" field for logging to GCs.
This allows embedders of Hermes (such as React Native) to specify
the cause of a call to `collectGarbage`.
Notably, this allows Hermes to know when a GC is triggered by a memory warning.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D23742099
fbshipit-source-id: 99453e632328c00045b92a72f789d41c898dc518
Summary:
The `description` parameter is never used so we can simplify the API.
Changelog:
[Internal][Changed] Removed `description` option from performance logger timespans
Reviewed By: lunaleaps
Differential Revision: D23758829
fbshipit-source-id: 10900f86effc3e1f54a408cf8f9fbc9b3b52f569
Summary:
The way the performance logger is defined now is very unsafe regarding type safety, as all accesses to its properties is untyped (`any`) and it uses several `mixed` types in cases that could be more refined.
This migrates the creation of performance loggers to instances of a class to improve its type safety. If there's an impact in performance, it's expected to be positive.
Changelog:
[Internal][Changed] - Replaced object literals with class instances to create performance loggers
Reviewed By: lunaleaps
Differential Revision: D23758609
fbshipit-source-id: 0734742eb97d92a4a53f7b66a8ca45a2ae90946c
Summary:
Inside JavaTurboModule, the native `CallInvoker` is used to schedule work on the NativeModules thread. So, in ~JavaTurboModule(), I scheduled some work on the NativeModules thread. This work holds a copy of the JNI global reference to the Java NativeModule object, and when it's executed, it resets this global reference to the Java NativeModule object. This should ensure that the we don't access the JVM in ~JavaTurboModule, which could crash the program.
I also removed the redundant `quitSynchronous()` in `~CatalystInstanceImpl()`, to prevent the NativeModules thread from being deleted before we delete the `jsi::Runtime`. This shouldn't cause an issue, because we delete the NativeModules thread when we call [ReactQueueConfigurationImpl.destroy()](https://fburl.com/codesearch/p7aurwn3).
Changelog: [Internal]
Reviewed By: ejanzer
Differential Revision: D23744777
fbshipit-source-id: a5c8d3f2ac4287dfef9a4b4404a04b335aa0963d
Summary:
This enables a new state auto repeating mechanism built-in mechanism for all state updates which we already use for CK interop. This experiment is supposed to help with T74769670 and co.
This change is gated with MC.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D23762508
fbshipit-source-id: f535513c724ace9ede570177281324eb507329c5
Summary:
Use the latest published release of hermes-engine.
Changelog: [Android] [Changed] - Upgraded to Hermes 0.7.0
allow-large-files
Reviewed By: cpojer
Differential Revision: D23725129
fbshipit-source-id: 50938433147100e97699b717d77a687fbbfe892b
Summary:
Under Fabric only, we can enter an infinite layout loop where the emitted layout event oscillates between two height values that are off by a very small amount.
The cause is, in part, components that use layoutEvents to determine their dimensions: for example, using onLayout event "height" parameters to determine the height of a child. If the onLayout height changes rapidly, the child's height will change, causing another layout, ad infinitum.
This might seem like an extreme case but there are product use-cases where this is done in non-Fabric and layout stabilizes quickly. In Fabric, currently it may never stabilize.
Part of this is due to a longstanding issue that exists in Fabric and non-Fabric, that we cannot immediately fix: If in a single frame, C++ emits 100 layout events to ReactJS, ReactJS may only process 50 before committing the root. That will trigger more layout events, even though product code has only partially processed the layout events. At the next frame, the next 50 events will be processed which may again change the layout, emitting more events... etc. In most cases the tree will converge and layout values will stabilize, but in extreme cases in Fabric, it might not.
Part of this is because Fabric does not drop *stale* layout events. If 10 layout events are dispatched to the same node, it will process all 10 events in older. Non-Fabric does not have this behavior, so we're changing Fabric to drop stale events when they queue up.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D23719494
fbshipit-source-id: e44a3b3e40585b59680299db3a4efdc63cdf0de8
Summary:
LayoutAnimations: at the end of every animation, issue an update mutation - this is so that the props data on the Mounting layer/StubViewTree layer is pointer-identical to the props data on the ShadowTree.
This unblocks iOS debug mode crashes.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D23753606
fbshipit-source-id: 407e0c2746a65e6d3ee29c1cce891cd7c1013593
Summary:
iOS needs this function to be marked as static.
Changelog: [internal]
Reviewed By: shergin
Differential Revision: D23749613
fbshipit-source-id: a8c160646853450fc7d849448bdbb45e02beb964
Summary:
Currently, MountingCoordinator's RN_SHADOW_TREE_INTROSPECTION code will crash often because it assumes there is always a "new" tree to compare the old tree to. In the LayoutAnimations context this is not always the case - in fact, the majority of the time, LayoutAnimations is producing mutations for animation without a "new" tree.
Just check that the tree exists before trying to print it.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D23747289
fbshipit-source-id: a1ba22aeae32ed8915a53bc33cdc199e8ce5128a
Summary:
In MountingCoordinator override mode (used in LayoutAnimations) we must set the start and end `diff` time when no real diff happens, otherwise we will hit an assert in telemetry later.
I also ensure that the TransactionNumber is incremented in that case.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D23746684
fbshipit-source-id: b1fe3864e453fdba89d43cc827bd37434abf7a4d
Summary:
`adjustDelayedMutationIndicesForMutation` asserts that the mutation is either Remove or Insert. At one callsite, we weren't checking the mutation type before calling `adjustDelayedMutationIndicesForMutation`.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D23746617
fbshipit-source-id: 6046fec2eb4821094937b1b16f40347bbc55c20e
Summary:
This change maps the three most used colors (black, white, clear) to corresponding predefined values in UIColor. This should meaningfully reduce the overall amount of allocated UIColor/CGColor objects. In my non-scientific measures, it reduces the number of CGColor objects from ~1500 to ~1000. And... it no much at least in terms of kilobytes. However, I still think it's a good idea to implement this because I hope that can remove some work from memory allocation infra and maybe enable some optimizations that UIKit hopefully does for black and white colors. (I tend to believe that this optimization exists because UIKit even has a classes called UIDeviceWhiteColor and UICachedDeviceWhiteColor.)
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D23753506
fbshipit-source-id: 46e58dc7e6b0dcab3c83d29c7257c90ffbd95246
Summary:
Finally, this diff changes the internal implementation of SharedColor to be `optional<int>`.
Initially, when we started working on the new renderer, it seemed like a good idea to allocated CGColor objects ahead of time and store them with Props. Now, this idea does not look so good, especially because:
* Having `SharedColor` as a `shared_ptr` is a quite big perf overhead for copying this thing. And the size of the object is not small.
* Having `SharedColor` as a `shared_ptr` creates huge interconnectedness among pieces of the core and rendering. E.g. improper releasing a pointer in some component view can cause a crash somewhere in the core (because both places might use the same shared `blackColor`.
On Android, we already use simple `int` as a representation of a color, and this works great. And this diff implements something very similar to Android, but a bit differently: here we use `optional<int>` instead of custom class with a single `int` field and some magic value that represents "empty value".
This approach should fix T75836417 because now we don't have allocation and deallocation when we simply assign color values.
If this solution works fine on iOS, I will do unify all implementations among all platforms.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D23753507
fbshipit-source-id: 42fd6cee6bf7b39c92c88536da06ba9e8cf4d4db
Summary:
This diff changes the implementation of `RCTCreateCGColorRefFromSharedColor` and `RCTUIColorFromSharedColor` in such a way that they don't rely on the fact that SharedColor is actually a `shared_ptr<CGColorRef>`. Instead, the methods just extract color components from SharedColor and create UIColor and CGColorRef objects on demand.
This allows us to change the implementation of SharedColor without worrying much about the rest of the system, which will do in the next diff.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D23753510
fbshipit-source-id: 340127527888776ebd5d241ed60c7e5220564013
Summary:
Even though we have wonderful helper functions converting SharedColor to UIColor and CGColorRef, in many places we still use some hardcoded things. This diff fixes that; it will be important for the next diff.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D23753508
fbshipit-source-id: 09d280b132266252753526c2735ab3e41b96c8d5
Summary:
This diff removes `RCTCGColorRefUnretainedFromSharedColor` function because it's not compatible with future changes we plan to make.
Converting SharedColor to unretained CGColorRef is actually quite dangerous because... it's an unowned pointer.
Reviewed By: JoshuaGross
Differential Revision: D23753509
fbshipit-source-id: df030ade69b63cbb872d6bdbde51575eedc6a4a6
Summary:
Added an explicit NDK version to the Android template. This allows tooling to detect which NDK version to install automatically.
## 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
-->
[Android] [Added] - Add an explicit NDK version to Android template
Pull Request resolved: https://github.com/facebook/react-native/pull/29403
Test Plan: Template builds as it should. NDK version gets installed with initial Android set up.
Reviewed By: passy
Differential Revision: D23752007
Pulled By: fkgozali
fbshipit-source-id: 31c33f275f94a4a62338a61e79b31c4b996969bf
Summary:
We don't need a shared_ptr here and without it the code will be faster and simpler.
This change is aligned with any clone-line callbacks we have in the Core which accepts a `const &` and return `shared_ptr<>`.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross, sammy-SC
Differential Revision: D23725687
fbshipit-source-id: 1cd959f4273913175d342302e2f12752f0114768
Summary:
Previously, to get a current root shadow node for a shadow tree, we called `tryCommit` method and stole a pointer from this. That was not a very straightforward method to get things done, and most importantly we need to do this to change the shape of the ShadowTreeCommitTransaction signature (remove a shared pointer from the callback) to make it simpler, faster and allow future improvements (see the next diff).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross, sammy-SC
Differential Revision: D23725689
fbshipit-source-id: 51950b843a0e401828b6c6a38e5e2aaaf21ec166
Summary:
Instead of storing tree separate instance variables, we now store a single object that contains them. We will need it to be able to postpone the mounting stage (we save all info we need for mounting inside the new instance variable).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D23725690
fbshipit-source-id: 09dd4a0912c6f5b34d805636b62f73ca12287329
Summary:
The implementation of this class is too complex for the purpose it serves. Making it simpler will make the code simpler and faster.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D23725688
fbshipit-source-id: 5e1ecddb0dd3c4c4f94786e2ba0af9b67e7426ce
Summary:
Changelog: [internal]
# Problem
Default padding for TextEdit is top: 26, bottom: 29, left: 10, right: 10 however the default values for LayoutMetrics.contentInsets is {0, 0, 0, 0}.
If you try to construct TextEdit with padding 0, Fabric will drop padding update because padding is already 0, 0, 0, 0.
# Fix
To fix this, I added a special case to `Binding::createUpdatePaddingMountItem`, if the mutation is insert, proceed with updating padding.
Reviewed By: JoshuaGross
Differential Revision: D23731498
fbshipit-source-id: 294ab053e562c05aadf6e743fb6bf12285d50307
Summary:
An experiment where we use `LayoutMetrics::overflowInset` to optimize performance of hit-testing algorithm.
In my measurements enabling this feature drastically (2x) reduced amount of calls to `hitTest:withEvent:` method.
Reviewed By: sammy-SC
Differential Revision: D23669091
fbshipit-source-id: ac6dadc90b6a2fbb45e41e0d4a113bd5ae8f1218
Summary:
Right now nested Text components are not accessible on Android. This is because we only create a native ReactTextView for the parent component; the styling and touch handling for the child component are handled using spans. In order for TalkBack to announce the link, we need to linkify the text using a ClickableSpan.
This diff adds ReactClickableSpan, which TextLayoutManager uses to linkify a span of text when its corresponding React component has `accessibilityRole="link"`. For example:
<Text>
A paragraph with some
<Text accessible={true} accessibilityRole="link" onPress={onPress} onClick={onClick}>links</Text>
surrounded by other text.
</Text>
With this diff, the child Text component will be announced by TalkBack ('links available') and exposed as an option in the context menu. Clicking on the link in the context menu fires the Text component's onClick, which we're explicitly forwarding to onPress in Text.js (for now - ideally this would probably use a separate event, but that would involve wiring it up in the renderer as well).
ReactClickableSpan also applies text color from React if it exists; this is to override the default Android link styling (teal + underline).
Changelog: [Android][Fixed] Make nested Text components accessible as links
Reviewed By: yungsters, mdvacca
Differential Revision: D23553222
fbshipit-source-id: a962b2833d73ec81047e86cfb41846513c486d87
Summary:
Since Prettier 2.0, the default for the `arrowParens` option has changed from `avoid` to `always`.
In preparation for upgrading Prettier in Xplat to 2.1, add `arrowParens: 'avoid'` explicitly to configurations that were missing it so that we do not have a change of behaviour when upgrading.
Changelog: [Internal]
Reviewed By: bolinfest
Differential Revision: D23666397
fbshipit-source-id: 665f20d1419d0d664a6ef5cddc46f441b20eeb51
Summary:
Disabling Fast Refresh won't be persisted when restarting the app.
I believe this regressed with https://github.com/facebook/react-native/commit/824e1711172d14a9373209bbae63d1ae50601625. In this commit `HMRClient.setup` will always be called with `enabled` being set true. This PR loads the _enabled_ state from the user defaults (as it was done before).
## Changelog
[iOS] [Fixed] - Enable Fast Refresh gets persisted across app launches
Pull Request resolved: https://github.com/facebook/react-native/pull/29880
Test Plan:
Without this change Fast Refresh is enabled on every app restart.
Tested with this change:
- Disabling Fast Refresh
- Restarting App -> Fast Refresh still disabled
- Enabled Fast Refresh again
- Restarting App -> Fast Refresh still enabled again
Reviewed By: sammy-SC
Differential Revision: D23686435
Pulled By: PeteTheHeat
fbshipit-source-id: 42c31b22060d3dc4b1d4cb8f41792b303fc7fce8
Summary:
Fix a typo in the invariant message presented when ActionSheetManager does not exist (typo was found in 2 places)
## Changelog
[General] [Fixed] - Fix typo in invariant message
Pull Request resolved: https://github.com/facebook/react-native/pull/29913
Test Plan: Run ActionSheetIOS.showActionSheetWithOptions(...) on an Android emulator to get this invariant message to appear.
Reviewed By: hramos
Differential Revision: D23691048
Pulled By: appden
fbshipit-source-id: 469db65a42bf547c7818b45729befa214b5791f2
Summary:
It's more correct and we will rely on this in the future.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D23681508
fbshipit-source-id: 5fef0ea164e8a400e6ca9a67947252b47ce6d44e
Summary:
This diff allows specifying the preemptive compilation threshold via CompileFlags.
Users get a toggle in CLI and RuntimeConfig that allows choosing between 1. fully eager, 2. fully lazy, 3. use default thresholds ("smart"). The default is #3.
However, since we use `-O` by default, it overrides any lazy compilation when
using the `hermes` binary.
ChangeLog: [Internal] Inspector updated to use new RuntimeConfig laziness control
Reviewed By: tmikov
Differential Revision: D23356463
fbshipit-source-id: 508b7b2e6a218346c69acfec97e7891e388f0e9b
Summary:
This pull request tweaks the build script for `jsiruntime` to ensure that `RN_FABRIC_ENABLED` is defined when building for Android with Fabric enabled, and using the JavascriptCore JS engine. Without it, the `createWeakObject` and `lockWeakObject` methods in `JSCRuntime.cpp` will throw an exception.
## Changelog
[Internal] [Changed] - Android: Ensure RN_FABRIC_ENABLED is defined when building with Fabric
Pull Request resolved: https://github.com/facebook/react-native/pull/29939
Test Plan: RNTester with JSC now builds and runs on Android with Fabric enabled.
Reviewed By: hramos
Differential Revision: D23671070
Pulled By: fkgozali
fbshipit-source-id: 27e69364a9f709615543be7c20b72b5536443cd8
Summary:
This fixes TextInput measurement caching. Previously we were not setting the correct Spannable in the cache; we needed to additional Spans to it to indicate font size and other attributes.
This brings Fabric closer to how non-Fabric was measuring Spannables for TextInputs (see ReactTextInputShadowNode.java).
This should fix a few crashes and will be most noticeable with dynamically-sized multiline textinputs where the number of lines changes over time.
This also allows us to transmit less data from C++ to Java in the majority of cases.
Changelog: [Internal]
Differential Revision: D23670779
fbshipit-source-id: cf9b8c848b9e0c2619e01766b72b074248466825
Summary:
Every time we measure a TextInput we allocate a JNI local array and weren't cleaning it up, leading to JNI table exhaustion.
Changelog: [Internal]
Differential Revision: D23670780
fbshipit-source-id: 2ecf9770c8593eeadd70a248be58037fefdca61e
Summary:
Changelog: [Internal]
There was a key mismatch between what Java and C++.
cacheIdMap was incorrectly initialised.
Differential Revision: D23652342
fbshipit-source-id: 66f54dc887a011afeead9420bda093e9a0c9a8ca
Summary:
One of the operations we do in `Scheduler::stopSurface()` is committing an empty tree to free up `ShadowNode` objects and "disable" `EventEmitter`s associated with them. Before this change, we had a gap in time between a moment when we commit an empty tree and remove the tree from the registry. During this time gap, JavaScript (or native, actually) can commit another tree and mount another new state on the screen. To prevent this, we remove the tree from the registry first and only then commit an empty tree to a uniquely owned tree.
Note that the deleted comment says that we actually have to have a tree in the registry for committing an empty tree, I don't think it's true now.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D23667882
fbshipit-source-id: 387052e9f3e78e7d4446f36baed50f9caa831133
Summary:
When `TouchableHighlight` was migrated to use `Pressability`, a bug was introduced due to `onLongPress` being unconditionally supplied as a callback. This bug leads to `onPress` not firing if the element is pressed for longer than 500ms, even when `onLongPress` is not supplied.
Closes#29040.
Changelog:
[General][Fixed] - TouchableHighlight fires `onPress` when pressed for >500ms, when `onLongPress` is not supplied.
Reviewed By: TheSavior
Differential Revision: D23664365
fbshipit-source-id: 3a0e92e276871eedd303888346a13433be15ac47
Summary:
Changelog: [Internal] Log image-requested QPL point for Fabric images
* See D23450649 for the full lifecycle
Reviewed By: fkgozali
Differential Revision: D23448179
fbshipit-source-id: 0a78dae2d4f1e6322bbeee3574b10abe1efb30ef
Summary: Changelog: [Internal] Add IGviewpoint to get image visibility callbacks for when an UIImageView is in or out of view
Reviewed By: fkgozali
Differential Revision: D23428528
fbshipit-source-id: 87e4cee8fbe3c6b7da5153f87bbb530b2f990d96
Summary:
* Create `ImageTelemetry` as a property of ImageRequest to pass image metadata from the ImageShadowNode into RCTImageComponentView
* ImageRequest is a object in the ImageShadowNode::ConcreteState
Reviewed By: fkgozali
Differential Revision: D23239664
fbshipit-source-id: db0f08bb889af8ce63fbe1abe88744edddb86150
Summary:
This function replaces the usage of an Objective-C `#import` statement with `#include` in `react/renderer/scheduler/SynchronousEventBeat.cpp`.
Clang seems to have no problems with `#import` being used in CPP files, but it was causing errors in MSVC. ([it has a different purpose](https://docs.microsoft.com/en-us/cpp/preprocessor/hash-import-directive-cpp?view=vs-2019) on Windows)
## Changelog
Changelog: [Internal][Changed] - Fabric: Replace #import statement in SynchronousEventBeat
Pull Request resolved: https://github.com/facebook/react-native/pull/29885
Test Plan: This CPP file now compiles in MSVC
Reviewed By: sammy-SC
Differential Revision: D23591933
Pulled By: shergin
fbshipit-source-id: ee2cb8152f37e5ee09500af621a57b59d5a18400
Summary:
Changelog: [internal]
# Problem
onTextLayout was called even if there was no change to text layout. This can cause an infinite loop with onTextLayout triggering commit which triggers onTextLayout.
# Fix
Do not call onTextLayout if there is nothing to layout.
Reviewed By: yungsters
Differential Revision: D23648430
fbshipit-source-id: 055dc34a9aca0edf2c78a5812b35b80df32c9e3e
Summary:
This is *another* attempt to solve a failed state update problem.
Unfortunately, some applications are inherently not compatible with the "let's recommit the update on the application side in case it failed" approach. The problem is that if we call `updateState` on the application side, we miss the original event window. E.g. if we need to deliver some state update with AsyncBatched priority and if the update fails, we lose the opportunity to commit it on time. These issues can be critical for some complex use-cases as ComponentKit interop.
This diff adds implementation for `updateState` that does the work a bit differently. For all failed state updates it tres to recommit them asap using `ShadowTree::commit` and calling lambda on every attempt. With this approach the update might fail in two cases:
The node disappeared from the tree, so there is no way to update it.
The lambda returned `nullptr` indicating that the update is no longer needed.
We need this for the ComponentKit interoperability layer that is very sensitive for missing state updates.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D23603958
fbshipit-source-id: a3b8c09fb2f1c8302583aa5880b48fc0840224e3
Summary:
We need it to stop repeating to commit new shadow tree in `ShadowTree::commit` when a transaction cancels the commit.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross, sammy-SC
Differential Revision: D23603959
fbshipit-source-id: d279fb3bf4190e860740a6450595d6f2fc3117f7
Summary:
Move the directory creation logic to the CLI. This needs to be processed by RNCodegen.js eventually.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D23618550
fbshipit-source-id: e7dc4f5fc37e5ad12b5c6ae8ea31fc9ef16d74b9
Summary:
The TurboModule system requires a lookup function to map the spec name (name used in JS) to the C++ TurboModule subclass. This is a pure C function. For now, generate one lookup function per set of modules found in the codegen schema.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D23618281
fbshipit-source-id: 889e07bdd4f2e5e93c4d14e60225f5b0c6683917
Summary:
Remove `enableFabricStartSurfaceWithLayoutMetrics` and treat as `true` always from now on.
Changelog: [Internal]
Differential Revision: D23633198
fbshipit-source-id: 5b7455b87e578ffa97d80746fa901cd2b50d3ea9
Summary:
Currently any component using `Pressability` is quickly tapped and released (i.e. responder grant followed only by reponder release), we fire `onPressIn` and `onPressOut` immediately to ensure that any visual feedback for the interactive element is momentarily visible.
Currently, we were mistakenly skipping this logic if `onPress` was null.
This fixes it so that we fire `onPressIn` and `onPressOut` consistently, even if `onPress` is null.
Changelog:
[General][Fixed] - Pressability now consistently fires `onPressIn` and `onPressOut`, even without an `onPress`.
Reviewed By: lunaleaps
Differential Revision: D23613254
fbshipit-source-id: e316707cbb2a4814262dea4eb1ddf6e3780268d1
Summary:
Adds a new `unstable_pressDelay` prop to `Pressable`.
This is intended to be used to experiment with adding a delay for when `onPressIn` fires. The intended purpose of this delay is to prevent `Pressable` elements from activating (i.e. `onPressIn` firing) if a touch gesture is immediately canceled by an enclosing native component (e.g. `ScrollView`).
Changelog:
[General][Added] - Added `unstable_pressDelay` prop to `Pressable`.
Reviewed By: lunaleaps
Differential Revision: D23604581
fbshipit-source-id: 5ce5d15a996c8a7aabaa465aa02fa8bad1044227
Summary:
Removes the default press delay from `Pressability`, which was introduced in 0.63 and affected `Pressable`. Fixes#29376.
In a subsequent commit, I will bring it back as an `unstable_pressDelay` prop.
Changelog:
[General][Changed] - Removed default 130ms delay from Pressability and Pressable.
Reviewed By: lunaleaps
Differential Revision: D23604582
fbshipit-source-id: c21c72bf8b59fed028f5905ca4f805bb3fa79399
Summary:
This pull request adds a call to `std::move` on the lambda capture in `Element::stateData`.
On Windows/Visual Studio 2017, this fixes a failure in the test `LayoutableShadowNodeTest.contentOriginOffset` where the error `std::bad_function_call` was being thrown. This was narrowed down to the callback being empty when called in `Element::stateData`.
https://github.com/facebook/react-native/blob/7e899348c74238a4a042380f86a8fe0d7e05511b/ReactCommon/react/renderer/element/Element.h#L98
Making sure the callback survives with `std::move` allows that test to pass under Windows.
## Changelog
Changelog: [Internal][Changed] - Fabric: Use std::move on callback in Element::stateData
Pull Request resolved: https://github.com/facebook/react-native/pull/29897
Test Plan: The Fabric test suite passes on Windows after this change is made. I also tested it under macOS and Linux built with Clang and they both pass with this change made.
Reviewed By: sammy-SC
Differential Revision: D23591969
Pulled By: shergin
fbshipit-source-id: e5c88bb0e94641e5128c4d49dd2f9dbfa49e9cfa
Summary:
In `StateReconciliationTest`, the way initializer lists are used to create null `ShadowNode`s causes this error on Visual Studio 2017 on Windows:
```cpp
auto result = (ShadowNode const *){nullptr};
```
---
```
StateReconciliationTest.cpp(35): error C4576: a parenthesized type followed by an init
ializer list is a non-standard explicit type conversion syntax
```
This change allows this test to compile in Visual Studio 2017, and the effected tests successfully compile and pass on Windows. They also compile and pass on Linux and macOS (both built with Clang)
## Changelog
Changelog: [Internal][Changed] - Fabric Tests: Change null ShadowNode creation in StateReconciliationTest
Pull Request resolved: https://github.com/facebook/react-native/pull/29899
Test Plan: The Fabric test suite passes on Windows after this change is made. I also tested it under macOS and Linux built with Clang and they both pass with this change made.
Reviewed By: sammy-SC
Differential Revision: D23592007
Pulled By: shergin
fbshipit-source-id: 7c6131736d478a0bf29d6c9475ef9149b7602dd6
Summary:
This pull request changes the default constructor in the `TestProps` class in `react/renderer/core/tests/TestComponent.h`
`using ViewProps::ViewProps;` was causing problems in Visual Studio 2017 - changing it to ` TestProps() = default;` allowed dependent CPP files to compile on MSVC and caused no regressions in the Fabric test suite.
## Changelog
Changelog: [Internal] [Changed] - Fabric Tests: Change default constructor in TestComponents' TestProps
Pull Request resolved: https://github.com/facebook/react-native/pull/29898
Test Plan: The Fabric test suite passes on Windows after this change is made. I also tested it under macOS and Linux built with Clang and they both pass with this change made.
Reviewed By: sammy-SC
Differential Revision: D23591986
Pulled By: shergin
fbshipit-source-id: 132e1c2e38fa74aa4f2c8746054d6152f30035e9
Summary:
RCTTurboModuleManager can be deallocated on a non-JS thread. This could create a race, when `__turboModuleProxy` is called from JS after cleanup has started. It's safer to just let `__turboModuleProxy` retain the TurboModuleManager.
In the future, we should clarify the ownership model for TurboModuleManager, so that we can explicitly delete RCTTurboModuleManager by nullifying a singular reference to it. For now, I'd like to land this change to potentially fix/narrow down the cause of T74825789.
Right now, a few objects can own RCTTurboModuleManager:
- FBReactModule, as the creator of RCTTurboModuleManager
- RCTCxxBridge, as an `id<RCTTurboModuleRegistry>` to supplement NativeModule lookup
- NativeModules that need to look up other NativeModules
- **New:** `__turboModuleProxy`
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D23608187
fbshipit-source-id: c14c8157e7670a8e32b7cd0d4c1ad5e2ab6d8abe
Summary:
This log was necessary to get to the bottom of the TurboModule Fb4a eager init crash. It's no longer necessary, plus it's okay for TurboModules to be null, so we'll remove it for now.
Changelog: [Internal]
Differential Revision: D23607208
fbshipit-source-id: 083b00abe6bdefc5986f842cd6f9438f47cce1ce
Summary:
Right now you can scroll a horizontal ScrollView with TalkBack even if you've disabled scrolling in JS, because our HorizontalScrollView component doesn't prevent the accessibility scroll event (this doesn't seem to happen with vertical ScrollViews for some reason...) This diff adds an accessibility delegate to both of the Android ScrollView components to make sure they're not scrollable if scrolling has been disabled in JS.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D23582689
fbshipit-source-id: b670bdb462ab9c963c7125597d60ca97c7d88a9c
Summary:
This pull request adds an include statement including the header `<algorithm>` to `react/renderer/graphics/Rect.h`.
It is needed for building with MSVC because of the use of the `std::max` function. It seems that this header is included as a side effect of some other header that's being used when building with Clang, and for some reason it is not included when being built with MSVC.
## Changelog
Changelog: [Internal][Added] - Fabric: Explicitly include algorithm in Rect.h
Pull Request resolved: https://github.com/facebook/react-native/pull/29884
Test Plan: Files that include this header now successfully compile on MSVC.
Reviewed By: sammy-SC
Differential Revision: D23591910
Pulled By: shergin
fbshipit-source-id: d8367bbdd94bc66c05d8fa308ed46c7aca24a68a
Summary:
With the upgrade to React Native 0.63, we started running into nullability warnings that were breaking our build. This PR fixes those nullability warnings as well as a few other warnings in React-Core.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[iOS] [Fixed] - Fix xcodebuild warnings in React-Core
Pull Request resolved: https://github.com/facebook/react-native/pull/29622
Test Plan:
- Nullability annotations should only affect compilation, but even though RNTester compiles, I'm not fully convinced that this won't break projects downstream. It would be good to get another opinion on this.
- The change in `RCTAllocateRootViewTag` is the only real logic change in this PR. We throw an exception if the root view tag is not in the correct format, so this change seems safe after some basic manual testing in RNTester.
Reviewed By: shergin
Differential Revision: D23386678
Pulled By: appden
fbshipit-source-id: a74875195a4614c3248e8f968aa98602e3ee2de0
Summary:
Right now, when two threads require two NativeModules, both threads fight for the same `std::mutex`. Why? Because NativeModule require can read from/write to the shared `std::unordered_map<std::string, TurboModuleHolder*>`.
**A Few Thoughts:**
- All threads should be able to read from the TurboModule cache concurrently, without issue. Only writes into the cache require exclusive access. *With our current setup, both reads and writes acquire exclusive access.*
- During the lifetime of an application, there will only be tens of NativeModule create events (i.e: writes into the TurboModule cache). However, there may be hundreds, if not thousands of TurboModule cache lookups. *We don't need to serialize those hundreds/thousands of TurboModule cache reads.*
This is a potential optimization opportunity for the TurboModule infra.
## Changes
This diff introduces a `std::shared_mutex` inside `RCTTurboModuleManager`. We use either the regular `std::mutex` or the `std::shared_mutex`, depending on whether `RCTTurboModuleSharedMutexInitEnabled()` is `YES`.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D23413118
fbshipit-source-id: 0880413c691b141db98a2715648f0c3e05983307
Summary:
Fix a issue that RCTModalHostView can't be dismissed while being presented
Steps To Reproduce
A native modal presented view controller is being dismissed before the first screen shows.
A RCTModalHostView is presented when the first screen shows.
The RCTModalHostView will be dismissed after an asynchronous callback.
If the callback was called before the completion of the presenting animation, the RCTModalHostView will not be dismissed.
## Changelog
[iOS] [Fixed] - Fix that RCTModalHostView can't be dismissed while being presented
Pull Request resolved: https://github.com/facebook/react-native/pull/29745
Reviewed By: shergin
Differential Revision: D23566487
Pulled By: sammy-SC
fbshipit-source-id: bd95f200b79fa75e2387e402091d58c0f538759c
Summary:
We need this to make crash logs more actionable. For now we know that those asserts fire so we should make them actionable.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D23580103
fbshipit-source-id: 8532e33b016e738a4f128c9b547c33d204610bcc
Summary:
Introduces support for `onPressIn` and `onPressOut` on the `TextInput` component.
This makes it possible to add visual feedback when users touch interact with `TextInput` components.
Changelog:
[General][Added] - TextInput now supports `onPressIn` and `onPressOut`.
Reviewed By: TheSavior
Differential Revision: D23514333
fbshipit-source-id: 1790e977b78f1c293d5476aef8613547f27d6731
Summary:
When we catch an Objective-C exception and convert it to NSError we need to somehow represent the call stack from NSException instance in NSError instance. For now, we just attach the stack trace to `message` field.
The next step would be to figure out how to pass the Objective-C stack trace to error reporting infra to help it to display the stack trace nicely in the web interface.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D23557600
fbshipit-source-id: a080c2e186e719e42dcfc01bb12f5811e3c5b2e6
Summary:
Fixes iOS builds failing with the following error in certain setups:
```
/~/Pods/React-RCTBlob/Libraries/Blob/RCTBlobPlugins.mm:14:9: fatal error: 'RCTBlobPlugins.h' file not found
#import "RCTBlobPlugins.h"
^~~~~~~~~~~~~~~~~~
1 error generated.
```
## 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] - "'RCTBlobPlugins.h' file not found" when building iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/29684
Test Plan:
- Existing builds should not fail
- Tested this change internally where we are seeing this build failure
cc hramos
Reviewed By: fkgozali
Differential Revision: D23581090
Pulled By: appden
fbshipit-source-id: 89d2088c362bfbd22df5cd098b110a43d76e784f
Summary:
Changelog: [Internal]
In https://fburl.com/diffusion/3705cj0i we assert that view which is about to be recycled, has no superview.
This is a problem in Legacy interop layer which is nested within another interop layer. This originally wasn't considered.
Removing views in `finalizeUpdates` like it has been done until now is not enough because when a component is deleted, `finaliseUpdates` isn't called.
Reviewed By: shergin
Differential Revision: D23572999
fbshipit-source-id: f007dfe293b7d27d56253656c02529163304f83c
Summary:
Changelog: [internal]
[NSString UTF8String] is nullable. Therefore, we need to check if it isn't nil before passing it to std::string constructor which crashes if it's nil.
Reviewed By: shergin
Differential Revision: D23572652
fbshipit-source-id: 59e7f5e918b2e5c69333bfb687371f856555d8e0
Summary:
The standard says that zIndex should only be defined for non-`static` positioned views. This diff implements it.
For now, it actually enables zIndex for all views in RN because there is no way to specify `position: static` but we will give that ability by changing Flow definitions in future diffs in a couple of weeks (to ensure OTA safety).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D23559447
fbshipit-source-id: 20ea10c9349de2c5b1adea5735324a8f57150695
Summary:
Fabric Core does not support exception safety, so technically exceptions are unrecoverable and binaries should be built without exception support.
While it's not the case, some exceptions might bubble to JavaScript realm and be caught as JavaScript exceptions. In this case, we lose the stack trace. To prevent that and to investigate one particular error we have we add this try-catch block in this diff.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D23529233
fbshipit-source-id: 7ac7fb26ac08ad26af8790172de471ac178c3a37
Summary:
This argument for the `onResponderGrant` event callback on `Text` is extraneous.
Changelog:
[General][Fixed] - Remove extraneous argument for `onResponderGrant` Flow type on `Text`.
Reviewed By: TheSavior
Differential Revision: D23513190
fbshipit-source-id: c4057cf534f4cdf73967e4324db64acc8cf323d0
Summary:
The nested `.gitattributes` file in `packages/react-native-codegen/android/` caused some confusion on Linux and macOS, causing Git to show `packages/react-native-codegen/android/gradlew.bat` as modified (CRLF removed, LF added).
Instead of relying on repo-local `.gitattributes` files to convert endings in the working directory, the files should be committed to source control with the correct line endings in the first place. There is no reason to convert LF endings in .sh and many other file to CRLF on Windows (maybe this was an issue a long time ago, but unless Notepad is used this won't be a problem for practically all modern editors).
Also fixed the line endings of `scripts/launchPackager.bat` which was incorrectly committed as LF.
## Changelog
[Internal] [Fixed] - Line endings and .gitattributes
Pull Request resolved: https://github.com/facebook/react-native/pull/29792
Test Plan: Clone repo on Linux, macOS, and Windows, and make sure no modified files show up.
Reviewed By: fkgozali
Differential Revision: D23546135
Pulled By: mdvacca
fbshipit-source-id: 1572fcb959212f212b137066f1aa66f0bb6e86c3
Summary:
It looks like this config in gradle.properties caused the :packages:rn-tester:android:app:dependencies task to fail. This was reported here: https://github.com/gradle/gradle/issues/9645#issuecomment-530746758 -- it's likely related to using Kotlin build.gradle.kts?
For now comment these out.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23521954
fbshipit-source-id: 9997f4950d89e5fc57036b05db5518b39d47737b
Summary:
Replaces the `listeners()` method on `EventEmitter` with a `listenerCount()` method.
Changelog:
[General][Removed] - Removed `listeners()` from `DeviceEventEmitter` and `NativeEventEmitter`.
[General][Added] - Added `listenerCount()` to `DeviceEventEmitter` and `NativeEventEmitter`.
Reviewed By: cpojer
Differential Revision: D22204156
fbshipit-source-id: 15029525aeef55de9934a4f319910e666ecbe1d8
Summary:
The Circle CI iOS jobs are failing when installing Watchman:
```
#!/bin/bash --login -eo pipefail
HOMEBREW_NO_AUTO_UPDATE=1 brew install watchman >/dev/null
Error: The `brew link` step did not complete successfully
Exited with code exit status 1
CircleCI received exit code 1
```
The commit associated with the job where this issue first appeared did not make any changes to Watchman, but it did change the VM used by Circle CI for these jobs. Flushing the homebrew cache might help.
## 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]
Pull Request resolved: https://github.com/facebook/react-native/pull/29843
Test Plan: Run on Circle CI. Watchman install step succeeded: https://circleci.com/gh/facebook/react-native/166160?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link
Reviewed By: fkgozali
Differential Revision: D23495409
Pulled By: hramos
fbshipit-source-id: 56a68bba3afc1350d4fc409d65f9229e3f38f467
Summary: Changelog: [Changed] Used scoped performance logger to mark the beginning and end of the call to the renderer, instead of using `GlobalPerformanceLogger`.
Reviewed By: lunaleaps
Differential Revision: D23240784
fbshipit-source-id: 7099f1a4b5da3f29596fcee289a715d295ae0a65
Summary:
This type makes more sense as an interface, given a class would be a common implementation (and object types aren't supported in that case).
It also adds the names of the parameters so it's easier to understand for implementers.
Changelog:
[General][Changed] - Changed type definition of IPerformanceLogger from object to interface
Reviewed By: lunaleaps
Differential Revision: D23449816
fbshipit-source-id: be872748827b123587f3f397da20f5545b0aae07
Summary:
When we render a text input that already has a text value (<TextInput value="123" />), its selection (cursor) is automatically set to the end of the text. However, when you swipe to focus the text input with TalkBack, Android decides it needs to clear the selection, which moves the cursor back to the beginning of the text input. This is probably not what you want if you're editing some text that's already there. Ideally we would just keep the selection at the end, but I don't know how to prevent this from happening - it seems to be part of how TextView handles the accessibility focus event? So instead I'm just explicitly setting the selection to the end of the text in our handler for accessibility click.
Changelog: [Android][Fixed] Move selection to the end of the text input on accessibility click
Reviewed By: mdvacca
Differential Revision: D23441077
fbshipit-source-id: 16964f5b106637e55a98c6b0ef0f0041e8e6215d
Summary:
SoLoader fixed crash on Android 4.1, and includes many improvements and fixes https://github.com/facebook/SoLoader/releases/tag/v0.9.0. Also Fresco 2.3.0 depends on it, and will create a PR soon to bump Fresco.
## Changelog
[Android] [Changed] - Bump SoLoader to 0.9.0
Pull Request resolved: https://github.com/facebook/react-native/pull/29821
Test Plan: CI is green
Reviewed By: fkgozali
Differential Revision: D23477538
Pulled By: mdvacca
fbshipit-source-id: d2d982d5c5c84fc173dc66dfe069713ca90711a8
Summary:
After monitoring scuba for a few days, previous fixes(D23301714 D23331828 (https://github.com/facebook/react-native/commit/07a597ad185c8c31ac38bdd4d022b0b880d02859)) don't work as expected.
I managed to test this issue on a Xiaomi device, the crash didn't happen but the there was a popup "Frequetly used email" on top of email edit text:
{F317216473}
Getting rid of the popup probably be the right fix.
For more context see https://github.com/facebook/react-native/issues/27204
Changelog: [Android] - Set caretHidden to true to fix the Xiaomi crash
Reviewed By: mdvacca
Differential Revision: D23451929
fbshipit-source-id: 521931422f3a46a056a9faa4b10fe93cf4732db0
Summary:
This PR tries to remove the code duplication between `RNTesterApp.ios.js` and `RNTesterApp.android.js`. The common code has been moved to `RNTesterAppShared.js`.
This PR also refactors the state architecture and simplifies it to use just one single `useReducer` hook to manage the app's state.
It also adds the visibility hack to make the screen change a little bit faster and removed the unneeded test files.
Pull Request resolved: https://github.com/facebook/react-native/pull/29777
Reviewed By: cpojer
Differential Revision: D23349302
Pulled By: rickhanlonii
fbshipit-source-id: ce0d7b03e6ef65b1655bcb744817b73c5144438b
Summary:
`-all` is the **default** for projects generated by Android Studio, and it provides **additional sources** helpful for debugging. It's also much more likely to already exist on a developer's machine (which has built other Android projects), avoiding additional downloads and saving disk space.
`-all` has also been the variant used in `react-native` for all versions prior to 5bc67b658e.
Follow-up to https://github.com/facebook/react-native/issues/29613
## Changelog
[Android] [Changed] - Use Gradle Wrapper 6.6 (-all variant)
Pull Request resolved: https://github.com/facebook/react-native/pull/29793
Test Plan: No test needed since versions are the same.
Reviewed By: fkgozali
Differential Revision: D23406546
Pulled By: mdvacca
fbshipit-source-id: b74dbbfc0317bccf1940b1e5062d866e50aed28a
Summary:
This diff optimizes the caching of Spannable objects managed by the TextLayoutManager class.
Previously, these objects were cached using unsing a String representation of the RedableMap (creating this string adds a non trivial cost), this diff improves the caching performance relying on the equals / hashcode methods of the ReadableNativeMap class
I created a MC just to have a killswitch
Motivation: I was analysing another bug and I found this non performant code
changelog: [internal] internal
Reviewed By: shergin
Differential Revision: D23429365
fbshipit-source-id: 59e5ad0b1b95da992ac393aecfe029da68a8df97
Summary:
Changes the order of `RCTBorderColors` field designators to match their declaration order, fixing one case of `-Wreorder-init-list` when compiling the RN codebase with Xcode 12.
Changelog: [Internal]
Reviewed By: MichaReiser
Differential Revision: D23447685
fbshipit-source-id: f04a3841187f0869d2efb60e81ce075c45f27f3c
Summary:
Fixes https://github.com/microsoft/react-native-windows/issues/5867
ScrollResponder has logic so that the first tap exiting out of a soft keyboard is captured instead of leaking to its children. This state is checked by testing if `TextInputState.currentlyFocusedInput()` is non-null. This also fires in cases a soft keyboard is not present (e.g. on Desktop where a physical keyboard is in use). This presents to users as clicks/taps not being registered when moving from a TextInput to something esle.
Instead of checking TextInputState to see if the softKeyboard is open, check `this.keyboardWillOpenTo`, which is tied to keyboard open and close events.
## Changelog
[General] [Fixed] - Prevent ScrollView From Stealing Responder Capture When Using Physical Keyboard
Pull Request resolved: https://github.com/facebook/react-native/pull/29798
Test Plan: Validated that on react-native-windows, ScrollView will capture responder events when tapped and a soft-keyboard is open, but will not capture events when clicking from a TextView to a child of a ScrollView and no soft keyboard is open.
Reviewed By: kacieb
Differential Revision: D23426786
Pulled By: TheSavior
fbshipit-source-id: 7138ef0bc4508aaec5531f455b022b105b5d858a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/29800
I changed this line in D23272735 (https://github.com/facebook/react-native/commit/700960c9f1a27a12d703b4f0a17673690799f019), to conform to normal ObjC semantics: impl files can import their header by file name.
I forgot that their's some special linking logic happening in this directory that doesn't allow for this import type.
This diff just reverts one line to fix CircleCI builds.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D23399893
fbshipit-source-id: 976199c659522effd632aaeb38616d0d6c962f1f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/29794
Per title - need to declare deps of attrs that we are using (soon Buck will enforce this).
Changelog: declare dependencies of all attributes that are used in the resource target.
Reviewed By: jiawei-lyu
Differential Revision: D23388058
fbshipit-source-id: b395d153188f75f8c0d4a6d69302812a56b23925
Summary:
`#import` is non-standard C++ extension which is AFAIK part of Objective-C. I am surprised that it even compiles on Android.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23407689
fbshipit-source-id: 2861138cbcce33674e118a1ad816e33bbf8f30fe
Summary:
This diff creates the new TransparentImmersiveReactActivity in FB4A, the intention is to help integrate TransparentReactActivity with Fb4A
Changelog: [Deprecated][Android] Deprecated method UIManagerModule.getUIImplementation. This method will not be part of the new architecture of React Native.
Reviewed By: stashuk
Differential Revision: D23324543
fbshipit-source-id: 35395fe410790a9611a4637361b888678eb0a836
Summary:
This updates okhttp to the newest compatible version with a couple of fixes and improvements. See https://github.com/square/okhttp/commits/okhttp_3.12.x
## Changelog
[Android] [Changed] - Update Okhttp to version 3.12.12
Pull Request resolved: https://github.com/facebook/react-native/pull/29741
Test Plan: Current tests should pass.
Reviewed By: shergin
Differential Revision: D23406613
Pulled By: mdvacca
fbshipit-source-id: b0b4ec52a6a8345f1c36e18e384761386096f1d8
Summary:
We have password components which allow visibility to be toggled by
setting both the keyboardType and secureTextEntry props. The order in
which those updates are executed is determined by iterating a NativeMap
of props, and the iteration order of a NativeMap is implementation
dependent.
With libc++ as our STL, we observe that setSecureTextEntry is called
before setKeyboardType. This results in the following sequence of input
type flag settings when toggling the component to visible and then back
to hidden:
* The field starts out with TYPE_TEXT_VARIATION_PASSWORD (0x80).
* When we toggle to visible, setSecureTextEntry is called with password
being false, which clears TYPE_TEXT_VARIATION_PASSWORD.
setKeyboardType is then called with the visible-password keyboard
type, which sets TYPE_TEXT_VARIATION_VISIBLE_PASSWORD (0x90).
* When we toggle back to hidden, setSecureTextEntry is called with
password being true, which sets TYPE_TEXT_VARIATION_PASSWORD but
doesn't clear TYPE_TEXT_VARIATION_VISIBLE_PASSWORD. setKeyboardType is
then called with the default keyboard type and additionally sets
TYPE_CLASS_TEXT, but TYPE_TEXT_VARIATION_VISIBLE_PASSWORD remains and
the password field remains visible.
The fix is to clear TYPE_TEXT_VARIATION_VISIBLE_PASSWORD when
setSecureTextEntry is called with password being true, to ensure the
password gets hidden.
Changelog:
[Android][Fixed] - Fix secure text entry setting to always hide text
Reviewed By: shergin
Differential Revision: D23399174
fbshipit-source-id: a81deec702e768672e2103b76ab50ec728dac229
Summary:
Changelog:
Sometimes a port different than kRCTBundleURLProviderDefaultPort (8081) can be specified to RCTBundleURLProvider for packager checking or requesting resources through saving them in JSLocation, this adds support for that rather than always falling back to kRCTBundleURLProviderDefaultPort
Reviewed By: PeteTheHeat
Differential Revision: D23395548
fbshipit-source-id: b7a6f0816d1f226a2e3fb82bf2dc0ab9e79ef966
Summary:
Removes `fbjs` dependency from `react-native` because it is no longer referenced.
Changelog:
[General][Changed] - Removed `fbjs` dependency from `react-native`.
Reviewed By: cpojer
Differential Revision: D23358201
fbshipit-source-id: 1945590d2e7ea853434c716a151fc1058718d471
Summary:
Shadow tree introspection was disabled for a while, now we need it back working. This diff also restructures the logic of `MountingCoordinator::pullTransaction()` splitting it into two sections, first one for the base case and the second for the overriding case.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D23374948
fbshipit-source-id: 0b5f1c598975bceb3dcb6a0eaee67ff58ef9dda1
Summary:
Just renaming, nothing more.
The idea of MountingTelemetry already grown to something bigger than just mounting telemetry, so we are renaming it.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D23374947
fbshipit-source-id: f60ce38b75d1ce77498b84688e59598314c69a78
Summary:
Long term fix in native for Error: android_crash:java.lang.NullPointerException:android.widget.Editor$SelectionModifierCursorController.access$300
For more detail please see T68183343 D23301714
Changelog:
[Android][Changed] - Fix Xiaomi TextInput crash in native
Reviewed By: mdvacca
Differential Revision: D23331828
fbshipit-source-id: 914f2d431772f49711b940d47a2b3ef57ab82cdc
Summary:
This diff fixes the initial render of RN Android TextInput. The problem was that "attributedString" was not serialized until an event was sent from native side.
Changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D23383969
fbshipit-source-id: 86601434b1fbaa9f712bdb79b013a1d004bc55a4
Summary:
Make sure to check incoming state values before calling SetState, or we call back and forth forever.
Changelog: [internal]
Reviewed By: mdvacca
Differential Revision: D23389355
fbshipit-source-id: 9cf6110cf654fe93f555a6fbfd9b20f112214e0a
Summary:
See title.
This feature makes LayoutAnimations less stable and isn't needed generally; will be deleted soon.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23382973
fbshipit-source-id: f633f482d463b3ee3e4625b30544a33cd6e36119
Summary:
My goal in this diff is to make LayoutAnimations more stable, and more resilient to challenging situations. Namely, LayoutAnimations already works fine with:
1) Reorders
2) Flattening/unflattening
3) Deletion and recreation of the same hierarchy
4) Updates conflicting with an existing animation
However, what if /all/ of those things are combined? Handling update conflicts with multiple ongoing animations, repeatedly flattening/unflattening the same layer of hierarchy and reordering both parents and children, etc .
This diff does not make LayoutAnimations perfect, but it does make LayoutAnimations much more resilient to situations it was not able to handle before.
My primary method of testing was to use two Playground examples: one just repeatedly queues up mutations (some animated, some not) that create, update, and delete in the same hierarchy layer. The second, more complex one, mutates between random view hierarchies that involve a lot of flattening and unflattening as well as reordering, over a depth of 5. It also exercises animations over TextInlineViews, which is more challenging.
LayoutAnimations works best with the new "Flattening Differ" for now, because the Flattening Differ produces a much smaller, nearly minimal set of instructions in cases of flattening-unflattening. I would like that to not be a hard requirement for using LayoutAnimations, but it's a good starting-point for now.
As part of this work, I also developed a lot of debugging and logging mechanisms that are handy for detecting inconsistencies and debugging crashes. Some are included in this diff behind `#define` statements that are disabled by default, and the rest will be published separately and likely cannot be landed permanently, as they're more invasive changes that are only helpful in debugging.
# Followups:
- Automate testing: write a suite of C++ tests that mutates between random diffs and guarantees that all mutations in a StubViewTree are sensible
- Construct a set of minimal repros that catalogues all remaining crashes and inconsistency issues (these seem to be extremely marginal cases and are very hard to repro - so I think it's fine to run this in prod for now, but I will follow-up as soon as I'm back to catalogue and fix all remaining issues)
- This diff focuses on *not crashing*, but it is still possible to construct a sequence of complex mutations that results in (for example) views having some opacity between 0 and 1 if animations are interrupted repeatedly. Although this is easy enough to prevent in product code - the types of scenarios I'm running in tests are very unlikely to ever happen in production - it would be nice to be *sure* that LayoutAnimations will always converge to a sensible View hierarchy with up-to-date props.
- In general, the index adjustment logic is complicated. I don't know if there's a great way around it, so I need to at least catalogue and test all edge-cases as mentioned above.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23382975
fbshipit-source-id: f379d9aa2a4b9c33fa2ba8fa07870c9e31fad5e7
Summary:
In some cases (BottomSheet?) the parent/ViewManager removes all children of the View before Fabric gets a chance to remove the children.
Apparently prior to D23368229 (https://github.com/facebook/react-native/commit/d344fb4e29a827d1e7d233672a3efe3b2b981a8a) (landed just today!) this sequence of operations happened and just noop'ed. Since we've been doing that happily as long as Fabric
has existed, we'll keep doing that for now.
I suspect that on *some* versions of Android this crashes and others it doesn't, based on logviews and my inability to repro certain crashes.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23387044
fbshipit-source-id: 88a46191adef4f6816bd7babd9103d103ddcef33
Summary:
Cleans up the documentation and types for `ImageSource`.
The only material changes here are:
- `ImageSource`'s array variant will now be `$ReadOnlyArray` instead of `Array`.
- `ImageURISource.headers` is now an object of string properties.
Changelog:
[General][Changed] - Refined `ImageSource` Flow type for array-variant and headers.
Reviewed By: kacieb
Differential Revision: D23355812
fbshipit-source-id: c3407db037dfb1d3514a028d1a237eb76ee6fedd
Summary:
We disabled animations on Android because native driver animations weren't working yet. After recent changes in NativeAnimatedModule, animations are now working as expected. This diff re-enables animations for bridgeless mode on Android.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22605612
fbshipit-source-id: 7a7078bf23bb88e7745fc899e1a5ff551425dbad
Summary:
If we try to delete a view and find the wrong one, when we crash, try to log the *actual* index of the view in question.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23368229
fbshipit-source-id: 7f9835fd07cfe4924d05c7e37b42b9bcdffff4a9
Summary:
Now we store a revision number of a Shadow Tree that leads to a transaction for which the concrete instance of MountingTelemetry corresponds. This is useful to understand how many actual transactions were skipped during a mounting phase (a mounting transaction does not directly correspond to a commit operation).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D23364663
fbshipit-source-id: 32b86bcdfc1ae97d8fff3b97a8615cc5a5b4d4a9
Summary:
With this change, we now collect the number of text measurements that we perform during the layout phase of the commit. Text measurements are the most expensive layout operations which pretty much responsible for the vast majority of time spent in the layout phase.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D23364664
fbshipit-source-id: 19514b93166b4053c2f3be37e79507f2c5248000
Summary:
Previously this was crashing only in debug, but that's too noisy and isn't giving us any value for now.
Changelog: [Internal]
Differential Revision: D23338800
fbshipit-source-id: bf1535cdda231ccf30af6d00509eec1499a552a1
Summary:
Simplifying the StopSurface flow. Before we would still attempt to execute MountItems, but only the "Delete" operations. This was... well, frankly, overcomplicated. Instead we can just ignore all future MountInstructions for that Surface and delete all views recursively from the root.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23338752
fbshipit-source-id: 6e7ab29ad85572782bfc6a39845a8a619f001559
Summary:
Microsoft’s RN for macOS fork supports the Hermes engine nowadays https://github.com/microsoft/react-native-macos/pull/473. As a longer term work item, we’ve started moving bits that are not invasive for iOS but _are_ a maintenance burden on us—mostly when merging—upstream. Seeing as this one is a recent addition, it seemed like a good candidate to start with.
As to the actual changes, these include:
* Sharing Android’s Hermes executor with the objc side of the codebase.
* Adding a CocoaPods subspec to build the Hermes inspector source and its dependencies (`Folly/Futures`, `libevent`).
* Adding the bits to the Xcode build phase script that creates the JS bundle for release builds to compile Hermes bytecode and source-maps…
* …coincidentally it turns out that the Xcode build phase script did _not_ by default output source-maps for iOS, which is now fixed too.
All of the Hermes bits are automatically enabled, on macOS, when providing the `hermes-engine-darwin` [npm package](https://www.npmjs.com/package/hermes-engine-darwin) and enabling the Hermes pods.
## Changelog
[General] [Added] - Upstream RN macOS Hermes integration bits
Pull Request resolved: https://github.com/facebook/react-native/pull/29748
Test Plan:
Building RNTester for iOS and Android still works as before.
To test the actual changes themselves, you’ll have to use the macOS target in RNTester in the macOS fork, or create a new application from `master`:
<img width="812" alt="Screenshot 2020-08-18 at 16 55 06" src="https://user-images.githubusercontent.com/2320/90547606-160f6480-e18c-11ea-9a98-edbbaa755800.png">
Reviewed By: TheSavior
Differential Revision: D23304618
Pulled By: fkgozali
fbshipit-source-id: 4ef0e0f60d909f3c59f9cfc87c667189df656a3b
Summary:
Changelog: [Internal]
# Problem
`RCTModalHostViewComponentView` reuses the same UIViewController between recycles. This can be a problem if dismissal of the modal is animated as the UIViewController is still presented while it is being dismissed. That's when "Application tried to present modally an active controller" exception can happen.
# Solution
Deallocate UIViewController when `RCTModalHostViewComponentView` is recycled.
Reviewed By: PeteTheHeat
Differential Revision: D23345711
fbshipit-source-id: da540571184afcb88b52758c4a1f0b4ec5874eb1
Summary:
I noticed when porting my iOS app to macOS via Catalyst that the text rendering was somewhat different on the two platforms. Text looked blurry and over-weight on macOS, even when disabling the Catalyst scaling transform.
I hazily remembered that I'd seen this problem before in my old Cocoa development days: this kind of blurring occurs when rendering text with sub-pixel anti-aliasing into an offscreen buffer which will then be traditionally composited, because when the SPAA algorithm attempts to blend with the underlying content (i.e. in the offscreen buffer), there isn't any. SPAA is disabled on iOS, so the issue wouldn't appear there. On macOS, typical approachs to displaying text (e.g. `CATextLayer`) normally disable SPAA, since it's been incompatible with the platform's compositing strategy since the transition to layer-backed views some years ago. But React Native uses `NSLayoutManager` to rasterize text (rather than relying on the system render server via `CATextLayer`), and that class doesn't touch the context's font smoothing bit before drawing.
This change makes macOS/Catalyst text rendering consistent with iOS text rendering by disabling SPAA.
It appears that the code I've modified is in the process of being refactored (for Fabric?). It looks like [this](https://github.com/facebook/react-native/blob/8d6b41e9bcede07fb627d57cf6c11050ae590d57/ReactCommon/react/renderer/textlayoutmanager/platform/ios/RCTTextLayoutManager.mm#L111) is the corresponding place in the new code (sammy-SC, is that right?). I'm happy to include a change to the new renderer in this patch if someone can point me at how to test that change.
## Changelog
[iOS] [Fixed] - Improved text rendering on macOS Catalyst
Pull Request resolved: https://github.com/facebook/react-native/pull/29609
Test Plan:
1. Prepare RNTester for running on macOS (or apply [this patch](https://gist.github.com/andymatuschak/d0f5b4fc1a28efc4f860801aa1deddcd) to handle parts 1 and 2, but you'll still need to do part 3):
1. Open the workspace, navigate to the `RNTester` target's configuration, and check the "Mac" checkbox under "Deployment Info.
2. Flipper doesn't yet compile for Catalyst (https://github.com/facebook/react-native/issues/27845), so you must disable it by: a) commenting out `use_flipper!` and `flipper_post_install` in the Podfile, then running `pod install`; and b) removing the `FB_SONARKIT_ENABLED` preprocessor flags in the Xcode project.
3. macOS has different signing rules from iOS; you must set a development team in the "Signing & Capabilities" tab of the `RNTester` target configuration pane. Unfortunately, you must also do this in the `Pods` project for the `React-Core-AccessibilityResources` target ([this is an issue which CocoaPods must fix](https://github.com/CocoaPods/CocoaPods/issues/8891)).
2. Run RNTester with and without the patch. You'll see that the font hinting is overweight without the patch; see screenshots below (incorrect rendering above, correct rendering below; note that fonts still remain slightly blurred because of Catalyst's window scaling transform, but that's removed on Big Sur).
Reviewed By: PeteTheHeat
Differential Revision: D23344751
Pulled By: sammy-SC
fbshipit-source-id: 1bbf682b681e381a8a90e152245d9b0df8ec7697
Summary:
For some reason, these got out of sync again.
This diff modifies the Java Codegen to sort all the methods.
build-break
overriding_review_checks_triggers_an_audit_and_retroactive_review
Differential Revision:
D23363410
Oncall Short Name: fbandroid_sheriff
Ninja: master broken
fbshipit-source-id: 257d85f92017528e64ced31bc7be011acb333186
Summary:
Changelog: [internal]
According to React Native docs, the default value for `autoCapitalize` is `sentences`.
Fabric's TextInput default value does not align with this.
[Source](https://reactnative.dev/docs/textinput#autocapitalize)
Reviewed By: JoshuaGross
Differential Revision: D23344479
fbshipit-source-id: f9e6f2aa6e1fbba2b08cb4aff23b842e49fa8c21
Summary:
This diff deletes the activityindicator buck module because these files are created by the code gen.
changelog: [internal]
Reviewed By: PeteTheHeat
Differential Revision: D23227860
fbshipit-source-id: 133315a44c9181be3263e0c6227884ed15487c1f
Summary:
This feature has been in [experimental mode since 0.59.0](https://reactnative.dev/blog/2019/03/12/releasing-react-native-059#-faster-app-launches-with-inline-requires). The feature seems quite beneficial.
Most people won't know to look for the inline requires flag, and it's been existing in React Native as an experiment for months. This defaults the flag to true as the next step towards utilizing this optimization for React Native devs initiating brand new projects.
## 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] [Breaking] - Enable `inlineRequires` by default. Gives a performance benefit but slightly different JS execution order
Pull Request resolved: https://github.com/facebook/react-native/pull/29770
Reviewed By: cpojer
Differential Revision: D23338113
Pulled By: TheSavior
fbshipit-source-id: 1b8ff41418c81a324335782d4b4109d89594ccbf
Summary:
The change in the hermes repository fixes the security vulnerability
CVE-2020-1911. This vulnerability only affects applications which
allow evaluation of uncontrolled, untrusted JavaScript code not
shipped with the app, so React Native apps will generally not be affected.
This revision includes a test for the bug. The test is generic JSI
code, so it is included in the hermes and react-native repositories.
Changelog: [Internal]
Reviewed By: tmikov
Differential Revision: D23322992 (https://github.com/facebook/react-native/commit/0dee0e60366645c962848a73bbaf0fc7c49912d0)
fbshipit-source-id: 4e88c974afe1ad33a263f9cac03e9dc98d33649a
Summary:
Changelog: [Internal]
# Problem
The problem was setting `_backedTextInputView.attributedText` to nil inside `[RCTTextInputComponentView prepareForRecycle]`.
Ordinarily this isn't a problem becase `UIManager::updateState` drops the update if the ShadowNode no longer exists. But in certain cases the ShadowNode can exist, empty string being set as its value
# Fix
Fix is trivial, invalidate state before nullifying `_backedTextInputView`. This prevents the state update from being dispatched.
# Discussion
We should go over all other components and make sure state is invalidated as first thing in `[RCTViewComponentView prepareForRecycle]`.
Reviewed By: shergin
Differential Revision: D23324929
fbshipit-source-id: 9568e920d99683ad95f965ef4b63c529f50f3283
Summary:
Deletes `Animated/polyfills` which is no longer necessary (and only creates extra configuration burden).
Changelog:
[Internal]
Reviewed By: cpojer
Differential Revision: D22451963
fbshipit-source-id: 7a9a48b96b3783f2f6340226bdafd2eaa43f32e7
Summary:
Removes the legacy `react-animated` package configuration and collapses the `Animated/src/` directory into `Animated/`.
Also, reconfigures all references to `Animated/src/` to just be `Animated/`.
Changelog:
[Internal]
Reviewed By: cpojer
Differential Revision: D22450848
fbshipit-source-id: 9fd4861e9f357d817d82e9fec71967a2936a3830
Summary:
Replaces `fbjs/warning` call sites in React Native with `console.warn`. A few warnings will now log as warnings without the "Warning:" prefix.
Changelog:
[General][Changed] - Some warnings changed to use `console.warn` without the "Warning:" prefix.
Reviewed By: TheSavior, cpojer
Differential Revision: D22445946
fbshipit-source-id: 96b01e1bdee52b89ff3b808bc9d6cd494f6787f5
Summary:
This implements the full NativeModuleResolvedType for each NativeModule spec, producing .java spec files in the output directory. The output files are now compiled during build time for :ReactAndroid and :packages:rn-tester:android:app.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23312858
fbshipit-source-id: c521b9d6602677fd275891cf44329740c6bd7387
Summary:
For each resolved type, define how to process its own type and whether it should produce generated code/file, minus the NativeModuleResolvedType (will be in the next commit).
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23307961
fbshipit-source-id: 87af09867aace7a5ff060a33a00b141048630eda
Summary:
This is the base setup for ResolvedType. Each Type needs to be resolved to its final representation, which knows what Java type it needs, and what standalone Java code (e.g. class) it needs to produce. Individual resolved types are not yet implemented, this commit provides the flow to pass the parsed structure (from schema) to the resolution logic.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23288208
fbshipit-source-id: 18535d5fae8ca15f6d9374bdba38f57dfd4300e8
Summary:
Instead of recreating the schema structure, the generator only needs to collect the list of types that it needs to generate for. So instead, let's just add each parsed type into a map using TypeId as the key. This means every inner types in the schema needs its own unique TypeId. This was a change from the previous commit where we didn't assign unique names to the types. Here's the reasoning:
* In Java, any generated class needs to be in its own file.
* If a NativeModule spec defines a few aliases, and or inner types (function args, return type shape, etc) that needs representation with a dedicated class, we need to track them as well for code generation.
* This means, the schema format is no longer relevant for the code generation step, so let's produce a structure that's more efficient for code generation
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23287818
fbshipit-source-id: 7caf4e95aeafe5c8ba336af290179b85bf87ad6d
Summary:
Changelog: [Internal]
This was set to screensize in D13104172 (https://github.com/facebook/react-native/commit/346c9d5f2c0fd99d6f05828d594d05bfaeed902f) to work around issues at that time.
The issues might not be around anymore.
Reviewed By: PeteTheHeat
Differential Revision: D23298723
fbshipit-source-id: 4f33a2cc65ae4fe5ba20b0b2b270b135878c339f
Summary:
I'm removing an ill-informed "optimization" that resulted in some StateUpdates being dropped. For some components (including TextInput) we rely on State updates to request a layout from the ShadowNode layer.
In the past we were performing an optimization that didn't update the View layer if the data contained in the State container is identical, but in the case of TextInput and other components, we simply pass an opaque
object with no meaningful data to trigger the layouts. In those cases, it could cause a permanent rift between the View layer's StateWrapper and the most recent state object from the C++ perspective.
In the case of TextInput this didn't cause tangible bugs because you can always update state using an out-of-date State object, but it's better this way anyway.
The other issue is that for some components, we want to know when there's a State update from the Cxx layer. This optimization broke certain logic in those components.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23306222
fbshipit-source-id: 8ef83149b814de50776674b5fd22406be1db14ba
Summary:
This crash was introduced in D22962320 (https://github.com/facebook/react-native/commit/ffdfbbec08b1afb1970d2cfe75a78a203d4a79a4), which landed 8/17 and went into 8/23 cut. I plan to pick this diff into that release.
I can't repro this, but there must be a scenario (in bridged mode), where we try to flush event queue while bridge is tearing down. I plan to consider this scenario going forward.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D23306445
fbshipit-source-id: 285d4b94a17423c3b08d83e7041c4ee04b7e6d0c
Summary:
This diff ties the stack together. It completes the long chain of RCTSurfacePresenter ownership:
`FBReactModule` -> `RCTNativeAnimatedTurboModule` (this diff and D23272746)
`RCTNativeAnimatedTurboModule` -> `RCTNativeAnimatedNodesManager` (this diff)
`RCTNativeAnimatedNodesManager` -> `RCTPropsAnimatedNode` (D23272735)
It completes animations working without the bridge.
Changelog: [Internal]
Differential Revision: D23272755
fbshipit-source-id: 137f7ff89993a2cb644bd67869eb685afcec4068
Summary:
`RCTPropsAnimatedNode` uses the bridge to access it's current surface presenter to perform animations.
In bridgeless mode, the surface presenter is not owned by the bridge. Instead, pass the surface presenter through the ownership chain:
`RCTNativeAnimated*Module` -> `RCTNativeAnimatedNodesManager` -> `RCTPropsAnimatedNode`
`RCTSurfacePresenter` should not be strongly held by any of these animation internals. If it gets destroyed at a higher level, animations should not be completed.
Changelog: [Internal]
Differential Revision: D23272735
fbshipit-source-id: ce08ee3b59ac2ba70e31cebb7ba8e9f3a644c848
Summary:
The animated native module relies on `setBridge` to perform generic setup which doesn't rely on the bridge at all. This diff refactors that setup code to an `init` function.
Changelog: [Internal]
Differential Revision: D23272427
fbshipit-source-id: 0c9c5522c9044283f4db25360010465ff42aba25
Summary:
Extracts `ScrollViewContext` so that other components can use it without requiring `ScrollView` as a dependency.
Changelog:
[Internal]
Reviewed By: kacieb
Differential Revision: D22670035
fbshipit-source-id: 7f902697ad2a60cd1869438e9a2b77e479a18065
Summary:
# What is this?
For a very long time, we've discussed the possibility of detecting Node Reparenting in the Fabric Differ. Practically, from the developer perspective, ReactJS and React Native do not allow reparenting: nodes cannot be reparented, only deleted and then recreated with entirely new tags.
However, Fabric introduced the idea of View Flattening where views deemed unnecessary would be removed from the View hierarchy entirely. This is great and improves memory usage, except for one issue: if a View becomes unflattened, or becomes flattened, the entire tree underneath it must be rebuilt.
In a past diff we introduced a mechanism to detect sibling reordering cleverly, and produce a minimal instruction set. This diff is very similar: we know the invariants around flattening and unflattening of views and we take advantage of them to produce an optimal set of instructions efficiently.
# What's different from previous attempts?
No global maps! Those are slow!
This seems to work and (hopefully) might even improve performance, since way less work is being done on the UI thread in cases when views are (un)flattened.
This *only* does extra work when flattening/unflattening happens, which gives product engineers a little more control over perf.
# So, how's it work?
This algorithm is intuitively simple (I think) but tricky to pull off, because there are lots of edge-cases.
In short: In the past, that information was hidden from the Differ: the differ didn't know if views were being reparented, it would see them
as entirely new views or as views being deleted if a View was flattened or unflattened. We very subtly change the information given to the differ:
all nodes are visible to the differ, but marked as Flattened or Unflattened. Thus, when the differ compares two nodes in the "old" and "new" tree,
it can tell not just if there are updates to the node but if it has been unflattened or flattened as well.
For example, take this tree, where * indicates that a View is flattened:
```
A
+
+----+---+
B* X
+ +
| |
+---+--+ +
E F Y
```
When the Differ asks for the children of A, in the past it would get a list `[E, F, X]`. That is, B* and X are both its children, but since B is flattened, it is omitted entirely from the list and
its children are substituted.
Now, when the Differ asks for the children of A, we give it this list instead: `[B*, E, F, X]`. That is: we give it a list which includes B, but B is marked as flattened.
Another wrinkle: A node `X` could have its children flattened, but still be a concrete view: so flattening/unflattening is a different operation from making a view "concrete" or "unconcrete", which can change independently of flattening.
There is one additional wrinkle: because of zIndex/stacking order, the children of `B` might not actually appear after `B` in the list. Depending on zIndex, a tree that looks like this:
```
A
+
+------+------+
B* C*
+ +
| |
+--+--+ +--+--+
D E F G
```
Could actually be linearized as: `[D G B* F C* E]` (as an extreme example; but basically all permutations as possible).
This is the reason, and the *only* reason that the inner Flattener/Unflattener
## The cases we need to handle
There are 7 cases/edge-cases of flattening and unflattening that we need to handle. Practically, all cases of reordering + flattening/unflattening, and taking recursive cases into account:
1. View A and A' (A in the old tree, A' in the new tree) are matched in the differ, and A* has been flattened or unflattened. These two cases are the easiest to handle.
2. View A' has been reordered with its siblings, and has been flattened or unflattened. These cases are slightly trickier to handle.
3. While flattening or unflattening, we encounter a child that has also been unflattened or flattened. So we need to handle four cases here in total: Flatten-Flatten, Flatten-Unflatten, Unflatten-Flatten, and Unflatten-Unflatten.
Other things to think about, also covered above:
1. Ordering. Views can be reordered and flattened/unflattened at the same time.
2. zIndex ordering: children in a certain order from the ShadowNode perspective may be stacked differently from a View perspective. We use the zIndex ordering for everything in the differ, and this prevents us from performing certain optimizations (see above: we cannot assume that children come after their parent in a list; they may come before, may be interwoven with children from other parents, etc).
# Perf Implications?
Practically, there should be very little negative overhead. There is some overhead in actually performing a flattening/unflattening operation, but... not much more than before. We don't use global maps, so the cost of flattening/unflattening is basically `O(number of nodes reparented)` - note that that's direct nodes reparented, *not* descendants.
tl;dr the perf hit should be similar to reordering, which is non-zero, but close to zero, and zero-cost for any diff operations on parts of the tree that don't involve flattening/unflattening. AFAICT this is very close to an ideal solution for that reason (but I wish it was simpler overall).
# In Summary?
I hope this works out and I think it could improve a number of things downstream: perf, LayoutAnimations, Bindings, certain crashes because of platform assumptions about mutations, etc.
Is it worth it? This new implementation is substantially harder to reason about, harder to read, and harder to understand. This is an important consideration. All I can say there is that I trust the test suite I've been using, but
the decreased readability is a big negative. Hopefully we can improve this in the future.
The rest is fiddly implementation details that I sincerely hope can be improved and simplified in the future.
# Followups?
The part that makes this algorithm the most expensive is that because of zIndex ordering, we cannot assume that children are linearized after their parents and so we rely more heavily on maps for the flattening/unflattening. Our TinyMap implementation should make these `find` operations fast enough unless trees' children are constantly being reordered, but it's still worth thinking of ways to make this even faster.
Changelog: [Internal]
Reviewed By: shergin, mdvacca
Differential Revision: D23259341
fbshipit-source-id: 35d9b90caf262d601a31996ea2cb37e329c61ffc
Summary:
1. When testing major changes to the differ, it can be useful to have more verbose logging.
2. On Android, since asserts don't fire yet, I log which asserts are failing.
Should have no impact on any builds unless you manually set the macro here, and it will have no impact on production builds regardless.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D23257859
fbshipit-source-id: 94a8e74ece8023064de0f2203db6074975f8f1f0
Summary:
Simplify the TextInput measurement mechanism.
Now, data only flows from JS->C++->Java and from Java->JS. C++ passes along AttributedStrings from JS if JS updates, and otherwise Java maintains the only source of truth.
Previously we tried to keep all three in sync. This was complicated, slow, and even lead to some crashes.
This feels a bit hacky but I believe it's the simplest way to achieve this short-term. Ideally, we would use something like `AttributedStringBox` and pass that to State from Java,
but currently everything passed through the State system from Java must be serializable as `folly::dynamic`. So, instead, we just cache one Spannable per TextInput component and
use ReactTag as the cache identifier for lookup.
An interesting side-effect is that `measure` could race with TextInput updates, but the race condition favors measuring the latest text, not outdated values.
Followups:
- Can we do this without copying the EditText Spannable on every keystroke? Maybe this approach is too aggressive, but I don't want a background thread measuring a Spannable as it's being mutated.
- Do we need to support measuring Attachments?
- How can we clean up this API? It should work for now, but feels a little hacky.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23290230
fbshipit-source-id: 832d2f397d30dfb17b77958af970d9c52a37e88b
Summary:
Changelog: [Internal]
# Problem
In D22274782 (https://github.com/facebook/react-native/commit/fb2b49d2982399f26b93ac02b2197c0b3813a4a9) I removed integration between Paper and Fabric. However this integration was still used by `RCTLegacyViewManagerInteropComponentView` for view commands dispatch.
Fix is to use `[RCTUIManager viewForReactTag:viewTag]` instead of viewRegistry.
Reviewed By: shergin
Differential Revision: D23291567
fbshipit-source-id: 35c50716fd8b86ae25b1534e4d8aa688c8e6e129
Summary:
Changelog: [internal]
# What is Teller?
Teller is a bank's employee who deals with the customer on behalf of the bank. In Fabric's scenario it is a class that on behalf of the view deals with State.
# Why do we need it?
Dealing with `ConcreteState` can be complicated and patterns are often repeated among different component views. `ConcreteStateTeller` aims to resolve these issues. Examples:
- You can call teller's methods without checking for nullptr (we have had crashes because of this before).
- Methods are save to be called on any thread.
- Mechanism to retry state update if it fails is built in.
It is designed to be used from ComponentView so views don't have to talk directly to `ConcreteState`.
Reviewed By: JoshuaGross, shergin
Differential Revision: D23216865
fbshipit-source-id: 90a50702e036eac084f89743ebab687a67182dc0
Summary:
On windows it is required to explicitly specify what symbols need to be exported from a DLL to make them accessible (using `__declspec(dllexport)`). I have added and expanded on existing macros to do this and added exports that were previously missing.
Changelog:
[Internal][Changed] - Allow Hermes to be compiled to a single DLL on windows
Reviewed By: mhorowitz
Differential Revision: D23084343
fbshipit-source-id: 832cb17b9e637e4c04dad479aae6c1fc190f968e
Summary:
Changelog: [Internal]
If `ConcreteShadowNode::setStateData` is called and the node is cloned before it is mounted, the cloned node will have old state before `setStateData` was called.
To solve this, simply call `setMostRecentState` on the family inside `ConcreteShadowNode::setStateData`.
Reviewed By: JoshuaGross
Differential Revision: D23283560
fbshipit-source-id: f9822fb69e4234f776d512fc02fe13ea7de64897
Summary:
This is the JS side of D23010844 (https://github.com/facebook/react-native/commit/73242b45a9f7f9ecce8f5124ac3d1665f575be74).
In the past I tried a few heuristics to guess when a batch of Animated Operations were ready, and none of these were super reliable. But it turns out we can safely allow JS to manage that explicitly.
Non-Fabric still uses the old behavior which seems fine.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23010937
fbshipit-source-id: 4a513672c166ceaa8b6daa387e46a2a95b60ce53
Summary:
In MountingManager.java in Fabric, if we drop a view with any attached views, we also drop all children. If verbose logging is turned on, log all instances of that happening.
This has no impact unless you switch the flag on manually in debug mode.
Changelog: [Internal]
Differential Revision: D23257749
fbshipit-source-id: fce4476aa47cc1b7137cd9fd2fd0241af1593288
Summary:
Instead of invoking JavaGenerator when the task is registered, do it when the task actually executes. This way, it will wait until the other task it depends on to finish executing.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23276359
fbshipit-source-id: 6aea98d97121f2dcfd83b299e38debc767f08240
Summary:
This diff moves AndroidSwitch C++ files to make them compatible with RN OSS Build
Changelog: [Internal] internal
Reviewed By: PeteTheHeat
Differential Revision: D23227861
fbshipit-source-id: 8f23c2eb266a47cb9af82f4159f64b987c14141b
Summary:
Fix a failure in running a single command to clean and rebuild with Hermes (e.g. `./gradlew clean :RNTester:android:app:installHermesDebug`).
From my limited understanding of Gradle, the failure was caused by the fact that the `clean` task could end up running after `prepareHermes`, and therefore delete the shared library after it had been copied. This change updates the `prepareHermes` task to impose the proper order.
In investigating this failure, I also updated inconsistent use of the `$thirdPartyNdkDir` variable.
Changelog: [Internal][Fixed] Fix a failure in running a single command to clean and rebuild ReactAndroid with Hermes
Reviewed By: mdvacca
Differential Revision: D23098220
fbshipit-source-id: 822fa8ac9874d54a3fdd432ad8cbee78295228ee
Summary:
This diff moves Android Slider C++ files to make them compatible with RN Tester OSS build
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D23227862
fbshipit-source-id: 7a5ed1bdc03cbe715467eddd4aad9af82761d4f0
Summary:
This diff moves AndroidDialogPicker C++ files to make it compatible with RN OSS build system.
changelog: [internal]
Reviewed By: fkgozali
Differential Revision: D23198857
fbshipit-source-id: 8fd4b7081f5f573946a6b9cd3fdc408488f91e13
Summary:
RCTKeyboardObserver only uses the bridge to avoid sending events during a reload. See D6573855 (https://github.com/facebook/react-native/commit/d9c658566a14ce8767d87435264997aa18dd08e4) for reference.
In bridgeless mode, the bridge is expected to always be nil, as the module uses `invokeJS` block to send events instead.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D23176990
fbshipit-source-id: 7946c9c2684d7d9ea0a606bad375309a5530a719
Summary:
This adds all the packages we use to the workspace in open source, which means we can change our publish scripts to also publish the packages from the repo every time we publish the main repo. I'll work with somebody from the community on that part.
Note: We do not use `eslint-config-react-native-community` internally and it pulls in a lot of packages we don't need. It is part of the React Native repo because it is used in the RN app template but we may want to choose to move it out into a separate repo at some point.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D23208695
fbshipit-source-id: 02d401721dfdc8bbb2305f8ac3381f1e98c18f1d
Summary:
Changelog:
Some callsites may rely on the assumption that address return by this method does not contain port information. JSLocation saved in NSUserDefault might contain port information, removing it here can prevent the issue for callsites.
Differential Revision: D23240495
fbshipit-source-id: a2edf4abb086fd951dd089331407bd659aad1729
Summary:
This diff updates the directory hierarchy of AndroidTextInput C++ files to be compatible with Android OSS build system
changelog: [internal] Internal
Reviewed By: PeteTheHeat
Differential Revision: D23179390
fbshipit-source-id: 1c52e4f882853799a58d44876cadd392b4a35050
Summary:
This comment shouldn't be committed, and should just be part of the template that generates new BUCK files.
Changelog: [Internal]
Differential Revision: D23225700
fbshipit-source-id: a1728e1a4ac0f3f94c4d1330d489bfae7a76a82d
Summary:
## 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
-->
This PR aims to migrate the RNTester App to `packages` directory. But is currently, open to inspect the CI issues and resolve the merge conflicts.
Currently done
- Working on iOS
- Working on Android
- Detox Tests working on iOS
Need to work on
- Errors generated by the CI builds
[General] [Changed] - Migrated the RNTester App to the packages directory.
Pull Request resolved: https://github.com/facebook/react-native/pull/29567
Test Plan: It runs on both ios and android for now and the detox iOS builds are working.
Reviewed By: cpojer
Differential Revision: D23034761
Pulled By: rickhanlonii
fbshipit-source-id: e04bb06e1c7ef15d340206090d1575a871b9e6f5
Summary:
`accessibilityElementsHidden` property hides a subtree starting from the node with this prop from VoiceOver and TalkBack, so the node with this prop should form the stacking context (otherwise the children will mount as siblings and the property will not have an effect).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D23202220
fbshipit-source-id: d87dfab5f791219551c1eb90cdf3b3fa86f9c51f
Summary:
This diff flattens the hierarchy of Text C++ files.
This is required to integrate Text into RN OSS
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D23173556
fbshipit-source-id: ce90000cae147460aa4ddad55b7c90369fa734a2
Summary:
Partial backout of D23123575 (https://github.com/facebook/react-native/commit/1e4d8d902daca8e524ba67fc3c1f4b77698c4d08). It's causing some crashes and there is a more efficient way of doing it, which I will land in a future diff.
Leaving unused feature-flags in place for now, they'll be used shortly.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23198625
fbshipit-source-id: 6e9cbc6b39898a604b8f4dfccf5a6dd238511a68
Summary:
This diff filters the iOS C++ friles that are generated by the oss-android-codegen script
Also, as part of this diff I'm inlcuding .cpp files into the output.
These files are only used and compiled in Android
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D23169268
fbshipit-source-id: 404607f3cd6e59197291ea67701774c9c492a282
Summary:
Logbox inside bridgeless surfaces was crashing and not able to open, this diff should fix it.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D23043773
fbshipit-source-id: 6e584f97e53e626b9bfedd6dc997ba6ba8c08b8f
Summary:
Twilight doesn't have TMPerfLogging enabled. However, the TurboModule infra uses the TMPerfLogger java class everywhere, which loads the turbomodulejsijni library on class load. For some reason, this class load doesn't work, and causes Twilight prod to crash.
To mitigate that crash, this diff delays the so load until it's absolutely necessary, which is by the time we call jniEnableCppLogging. This should never be called in Twilight, because it doesn't have TMPerfLogging enabled. Therefore, the crash should disappear on Twilight.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23192072
fbshipit-source-id: b73ece580e4345dbf835b0fc2f7d43b90f202411
Summary:
This parses the JSON schema's aliases and reserved function valye types. It also assigns TypeId correctly now:
* TypeId is an identifier for a specific type, that can be referred by others
* This means only aliases should have TypeId.typeName. Properties' names are not typeNames
* NativeModule spec's typeName is hardcoded to `Spec`, see T71955395
This way, whenever we encounter an `AliasType`, we can just lookup the actual Type by a quick Map lookup with TypeId as the key.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23181432
fbshipit-source-id: 9d0ea17dbf601589d8f3fc1955e0c9406a80e244
Summary:
Every single RN iOS application is initializing this native module on first bundle load, regardless if it is used or not. This wrapperModule makes it lazy.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D23175668
fbshipit-source-id: 0424a62d6c0b4fe7d5ce95f6c96e641a03b5fb2c
Summary:
This diff extends test-react-native-oss-android-legocastle to test the build of RNTester with fabric enabled in Sandcastle
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D23141524
fbshipit-source-id: 396dae1c0a23ce03db1053de1627eacb09a6df94
Summary:
This diff reintroduces the CoreComponentsRegistry class to register core components in the RN Tester app.
This class was previously deleted as part of D23091020 (https://github.com/facebook/react-native/commit/7fb1afae7f4b78970463e272b7d4f3230e84887d). Different from a past approach, this diff doesn't use inheritance for Hybrid classes (which seems to bring problems in Android 4 devices)
I'm planning to land this diff after I verify that D23091020 (https://github.com/facebook/react-native/commit/7fb1afae7f4b78970463e272b7d4f3230e84887d) fixed RC (maybe I will wait until sunday's cut)
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D23109856
fbshipit-source-id: 5220e522e197f701c782ab5089f9f1036ec90c19
Summary:
This parses the output JSON schema into Java Type's, without any alias resolution. Some parts of the schema have incomplete information, hence a bunch of TODOs in the code expressing the issues.
Notes:
* The type structure here could be implemented in other codegen generators as well (including the RNCodegen.js' generators) for better type safety and correctness. With this exercise, I was able to catch a few issues mentioned above.
* This commit does not produce any Java code with JavaPoet yet, just parsing the schema.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23152891
fbshipit-source-id: 9f774dd98975f7202d3faf11c3fbfb83d4c97f5a
Summary:
Migrating DrawerLayoutAndroid component to use ES6 import
Slowly migrate each file to use es6 import/exports to make this discussion happen
react-native-community/discussions-and-proposals#201 (comment)
## Changelog
[General] [Changed] - Use ES6 import/export syntax for DrawerLayoutAndroid component
Pull Request resolved: https://github.com/facebook/react-native/pull/29639
Test Plan: Manual RNTester for Android
Reviewed By: TheSavior
Differential Revision: D23110137
Pulled By: mdvacca
fbshipit-source-id: a43b4f3981335c9f532185cec8957e46f35aac7b
Summary:
Changelog: [Internal]
This lint is now an error by default, so we no longer need to manually specify it as such in the flowconfig
Reviewed By: gkz
Differential Revision: D23145523
fbshipit-source-id: 6c104563793fbc67c8b15b7310e96d1750d21df3
Summary:
These files or directories no longer exist, so they don't need to be listed as files to be published to npm. The only file that was removed that does exist is the `.flowconfig` file, which should not actually be shipped to npm as projects using Flow would have their own `.flowconfig` file.
Changelog: [Internal]
Reviewed By: GijsWeterings
Differential Revision: D23132479
fbshipit-source-id: dc656d8215c9dac11025902b403c3f6560e62e37
Summary:
Changelog: [internal]
Original commit changeset: 5cb78a3a75a7
In D23151218 (https://github.com/facebook/react-native/commit/dffec8bc7bee4d05b72d19b4efe4aeab980f4cd5) we switched from `ShadowTree::tryCommit` to `ShadowTree::commit` inside `UIManager::updateState`.
It fixes update state being dropped but can cause an infinite loop inside `ShadowTree::commit` because the shadow node that triggered `UIManager::updateState` can been removed before the `updateState` call is dispatched..
Reviewed By: JoshuaGross
Differential Revision: D23155228
fbshipit-source-id: f3339a4e4798880972366d6f894c14a58be1b9b2
Summary:
Changelog: [internal]
In D22940187 (https://github.com/facebook/react-native/commit/774dec1e17f6f250172a6d4d944121b82fa36efb) we introduced a mechanism to retry failed state updates from view layer.
The mechanism fixes an issue where state update is occasionally dropped with background executor enabled.
# Why is state dropped?
The state is dropped because with background executor enabled, it is possible to enter `ShadowTree::tryCommit` for the same tree from 2 different threads at once. One of thread changes `_rootShadowNode` causing the other commit to fail.
The code goes like this:
```
{
Lock mutex
grab reference to `rootShadowNode_` and call it `oldRootShadowNode`
Unlock mutex
}
State reconciliation
Trigger layout
`rootShadowNode_` is untouched in this section.
{
Lock mutex
Check if `oldRootShadowNode` is equal to `rootShadowNode_`, if not, return false signalling failure. Now this is what happens when
state update fails.
..... not relevant
Unlock mutex
}
..... not relevant
```
However, in D22940187 (https://github.com/facebook/react-native/commit/774dec1e17f6f250172a6d4d944121b82fa36efb), we have taken another path. Instead of retrying to commit transaction, client is informed about the failure and it is left up to them to retry. This is correct and works. But I think it is unnecessary to this retry can be done inside UIManager::updateState.
In this diff I call `ShadowTree::commit` (version with retries) in case no `stateUpdate.failureCallback` is provided.
This makes sure that we do retry if state update fails but if Android implements `stateUpdate.failureCallback`, it is left up to view layer to retry.
Eventually we might decide to converge these two approaches.
Reviewed By: shergin
Differential Revision: D23151218
fbshipit-source-id: 5cb78a3a75a754429a8e33bd7736e683e9ed34d4
Summary:
# Summary
In previous diffs earlier in 2020, we made changes to detect and optimize reordering of views when the order of views changed underneath the same parent.
However, until now we have ignored reparenting and there's evidence of issues because of that. Because Fabric flattens views more aggressively, reparenting is also marginally more likely to happen.
This diff introduces a very general Reparenting detection. It will work with view flattening/unflattening, as well as tree grafting - subtrees moved to entirely different parts of the tree, not just a single
parent disappearing or reappearing because of flattening/unflattening.
There is also another consideration: previously, we were generating strictly too many Create+Delete operations that were redundant and could cause consistency issues, crashes, or bugs on platforms that do not handle that gracefully -
especially since the ordering of the Create+Delete is not guaranteed (a reparented view could be created "first" and then the differ could later issue a "delete" for the same view).
Intuition behind how it works: we know the cases where we can detect reparenting: it's when nodes are *not* matched up with another node from the other tree, and we're either trying to delete an entire subtree, or create an entire subtree. For perf reasons, we generate whatever set of operations comes first (say, we generate all the Delete and Remove instructions) and take note in the `ReparentingMetadata` data-structure that Delete and/or Remove have been performed for each tag (if ordering is different, we do the same for Create+Insert if those come first). Then if we later detect a corresponding subtree creation/deletion, we don't generate those mutations and we mark the previous mutations for deletion. This incurs some map lookup cost, but this is only wasteful for commits where a large tree is deleted and a large tree is created, without reparenting.
We may be able to improve perf further for certain edge-cases in the future.
# Why can't we solve this in JS?
Two things:
1. We certainly can avoid reparenting situations in JS, but it's trickier than before because of Fabric's view flattening logic - product engineers would have to think much harder about how to prevent reparenting in the general case.
2. In the case of specific views like BottomSheet that may crash if they're reparented, the solution is to make sure that the BottomSheet and the first child of the BottomSheet is never memoized, so that lifecycle functions and render are called more often; and that in every render, the BottomSheet manually clones its child, so that when the Views are recreated, the child of the BottomSheet has a tag and is an entirely different instance. This is certainly possible to do but feels like an onerous requirement for product teams, and it could be challenging to track down every specific BottomSheet that is memoized and/or hoist them higher in the view hierarchy so they're not reparented as often.
Reviewed By: shergin
Differential Revision: D23123575
fbshipit-source-id: 2fa7e1f026f87b6f0c60cad469a3ba85cdc234de
Summary:
This diff unifies the type and value of USE_FABRIC env variable exposed in Gradle with the USE_CODEGEN env variable
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D23145658
fbshipit-source-id: 9575f6b50c7a977254e364037d1417b3b1cdb607
Summary:
Changelog: [Internal]
This lint is now an error by default, so we no longer need to manually specify it as such in the flowconfig. This also gets us ready to remove the lint entirely from Flow.
Reviewed By: gkz
Differential Revision: D23134689
fbshipit-source-id: 683a414bb399b823c65b7f687d25344d3e3ba980
Summary:
This diff fixes an issue in `TextInput` where `TextInputState.currentlyFocusedInputRef` could maintain a ref to a view that no longer exists. This issue was exposed when upgrading React, where cleanups for passive effects are deferred. This change means that `inputRef.current` would no longer reference the host view *to be* destroyed; it would be null because the view was *already destroyed*.
There are two fixes here that would independently fix the bug and fix the issue better together.
First, we convert `useEffect` to `useLayoutEffect`. `useLayoutEffect` is intended to fire synchronously after all host view mutations, and the cleanup function is intended to fire synchronously before the host view is destroyed, similar to the behavior assumed before. This change is now the correct function to use semantically. However, if we made this change without the second then any change in the order the effects fire would surface the same bug.
So second, move the `inputRefValue).blur()` call to the same effect as unregistering. This is because we currently require the `blur` effect to be called to null out `currentlyFocusedInputRef` in addition to calling `unregisterInput`. That makes the semantic ordering of effects in `TextInput` meaningful. Instead, when a TextInput is unregistered we should always `blur` to clear the `currentlyFocusedInputRef`, which will prevent dispatching events to a view that doesn't exist. If we made this change without the first then there's would be a race condition between calling blur on a TextInput and when that TextInput has been unregistered.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D23035358
fbshipit-source-id: ab686b8046d85e2becd8b879b0b4b7e69e672754
Summary:
Motivation:
`Invariant Violation: Module AppRegistry is not a registered callable module (calling runApplication).` is an error that happens rarely, and most SO answers end up recommending to use `react-native bundle` to work around. I stumbled upon this error the other day and it took me a while to figure out that the error was caused by the fact that my `entryFile` path was pointing to an existing but invalid file. I figured it would be nice to mention this because I believe this will be a frequent cause of the error.
## 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] [Changed] - improve "not a registered callable module error message"
Pull Request resolved: https://github.com/facebook/react-native/pull/28913
Test Plan:
tested locally with RNTester, prints
```
[Sun May 17 2020 18:15:55.396] ERROR Invariant Violation: Module AppRegistry is not a registered callable module (calling runApplication). This can happen when the application entry file path is incorrect.
On Android, verify 'getJSMainModuleName()' in 'MainApplication.java' and 'project.ext.react.entryFile' in 'android/app/build.gradle'.
On iOS, verify '- (NSURL *)sourceURLForBridge:(RCTBridge *)bridge' in 'AppDelegate.m' and 'ENTRY_FILE' env. variable passed to 'react-native-xcode.sh' (if any) in 'Build Phases' -> 'Bundle React Native code and images'.
```
in metro logs
Reviewed By: mdvacca
Differential Revision: D23107228
Pulled By: fkgozali
fbshipit-source-id: 0712ed7e593ba96b041578bafdbefcd09a3994b7
Summary:
This new buck target will execute the code gen and copy C++ files to the output directory. This will be used to integrate these files into RN Tester
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D23115538
fbshipit-source-id: de4135be697c36cd559edf416986299511c31744
Summary:
JavaGenerator is a Java-based implementation for generating codegen output from the parsed schema file. Right now the output is a hardcoded Java file. In the next commits, proper JavaGenerator impl will be added.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23100171
fbshipit-source-id: 1bef23e3dba4d8c222ebdece0edeb4435d388cd4
Summary:
This diff removes the CoreComponentsRegistry class that was recently created to expose Fabric components in OSS
changelog: [internal] internal
Reviewed By: JoshuaGross, shergin
Differential Revision: D23091020
fbshipit-source-id: 9d851608ed0eddb98367265b5e346d5298f5f732
Summary:
This diff deletes the Fabric flavour from RNTester gradle configuration, replacing this by the ENV VAR: USE_FABRIC
- When USE_FABRIC is set to "true", gradle will build Fabric C++ code it will enable Fabric in RN Tester
- When USE_FABRIC is set to "false", gradle WON'T build Fabric C++ code it will disable Fabric in RN Tester
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D23085883
fbshipit-source-id: 2324f4a2cea4073b45b15805e69828d5dd70b365
Summary:
This diff adds a new mechanism to enable or disable the build of Fabric in RN OSS
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D23084586
fbshipit-source-id: b7b0b842486392ec4ccb91ad1e6441ba3a1f48b2
Summary:
Instead of applying configs from gradle scripts, this introduces a proper Gradle plugin to enable Codegen in an application or library project. In the build.gradle, one enables it by:
```
plugins {
id("com.android.application")
id("com.facebook.react.codegen") // <---
}
// ...
react { // <--- the new plugin extension
enableCodegen = System.getenv("USE_CODEGEN")
jsRootDir = file("$rootDir/RNTester")
reactNativeRootDir = file("$rootDir")
}
```
The plugin supports `react` plugin extension as demonstrated above. Adding this:
* automatically generates all TurboModule Java files via react-native-codegen **before the `preBuild` Gradle task**
* automatically adds the files to the `android {}` project configuration
* is done per project (build.gradle)
This will be the foundation for future React Native gradle plugin beyond just for react-native-codegen.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23065685
fbshipit-source-id: 4ea67e48fab33b238c0973463cdb00de8cdadfcc
Summary:
This diff removes the ndk.moduleName configuration from build.gradle. This seems to be unnecessary
The motivation is to reduce confusion and extra configuration that is not being used by the build system
changelog: [internal] internal change to cleanup ndk configuration in gradle
Reviewed By: fkgozali
Differential Revision: D23068404
fbshipit-source-id: 07bb68906286531efaa9dc0036704c4b3ee1faf5
Summary:
Changelog: [internal]
Restore text value from state when re-initialising RCTTextInputComponentView
Reviewed By: shergin
Differential Revision: D22844624
fbshipit-source-id: b47e3fe890793f8de429b637535d641262c42be2
Summary:
Changelog:
[Internal] - Fix the frame issue for truncated text.
When double tapping to expand/truncate the text, the rect of the element always moves to the top and then come back to the original place.. This seems because after truncating/expanding the text, the view would re-render and the container would be destroyed. I used the API accessibilityFrameInContainerSpace to set the frame before. And the frame was not updated properly. Converting the bound to the screen coordinates and set accessibilityFrame directly fixed it.
Reviewed By: PeteTheHeat
Differential Revision: D23040295
fbshipit-source-id: 1b449c39c79007d5321ff7b565c170f6d3fab8a4
Summary:
Previously `reset` was not doing anything about configured callbacks, and after unmount (especially in Fabric) it was possible for callbacks to be called on unmounted nodes due to race conditions.
Changelog: [Internal]
Reviewed By: lunaleaps
Differential Revision: D23041046
fbshipit-source-id: eb9ebc8e99a0d244a2033e97178bf8ede8b5c7b2
Summary:
In D22801173 (https://github.com/facebook/react-native/commit/9e6ba9ddb8608d4e3a4a80d0138600130b766d4c) I introduced a mechanism to queue Animated operations on the JS side until all mounting effects were finished. I also added an unnecessary check that the NativeAnimated module is loaded, and it seems like if it's called too early, before the NM is initialized, it will crash.
It's not necessary in these two methods, so we just delete the invariant check.
Changelog: [Internal]
Reviewed By: lunaleaps
Differential Revision: D23040331
fbshipit-source-id: e70ec887695b9abefa0f01408a4a1c2749946d1c
Summary:
There are a few places where we cast JSI values to objects without much validation and without proper error logging, and in some places the crashes aren't symbolicated well. To make debugging easier in the short-term, I'm adding some additional logs.
Changelog: [Internal]
Reviewed By: mdvacca, RSNara
Differential Revision: D23033222
fbshipit-source-id: 9343d693a441f0af728e560a0c245bcc4eb97869
Summary:
This diff adds a new flavor into the RN Tester gradle system.
The "fabric" flavor is going to be used in the future to:
- determine if Fabric should be enabled or not (at runtime)
- include or exclude fabric C++ code at compile time
I decided to temporarily reuse the "vm" dimension in order to reduce friction while I'm still iterating on the implementation.
If I created another dimension, then it will force developers to compile RN tester using two flavors:
```
./gradlew :RNTester:android:app:installHermesFabricDebug
```
I'm planning to refactor this in the near future (T71370706)
changelog: [Internal] Internal
Reviewed By: JoshuaGross
Differential Revision: D23012445
fbshipit-source-id: 1ea6a707ea2bfaca1be567f43b08860407124c17
Summary:
Changelog: [Internal]
Fabric's UIManager.measureInWindow didn't take viewport's offset into account. This diff fixes it by including viewport's offset in `LayoutContext`.
Reviewed By: JoshuaGross
Differential Revision: D23021903
fbshipit-source-id: 9106a8789d66fe19d8cb0a9378ee5bc8f2c83005
Summary:
Changelog: [internal]
RCTSurface and RCTFabricSurface are two distinct classes that need to have the same interface otherwise the program crashes. This diff ties their interfaces through a protocol, triggering a build time error if they diverge.
Reviewed By: PeteTheHeat, JoshuaGross
Differential Revision: D23021837
fbshipit-source-id: 09ce345298ec2b45ac5a3fd2e0d3f5fa757a174f
Summary:
Changelog: [internal]
Use `Element<>` in `LayoutableShadowNodeTests`. It makes the tests cleaner and easier to understand.
Reviewed By: JoshuaGross
Differential Revision: D23028341
fbshipit-source-id: f7a2255581bdde667db0f68c222228a5b405b22f
Summary:
Changelog: [Internal]
Previous interface `Element<>.state` wasn't usable because creating ConcreteState requires ownership of component descriptor and family. Family isn't created until later and it isn't accessible to the caller.
To work around this shortcoming, we create `stateData` rather than state.
Reviewed By: JoshuaGross
Differential Revision: D23028296
fbshipit-source-id: fba35ea8e6986b77379b1dddaa37012f4234f86e
Summary:
Changelog: [Internal]
# Problem
## Step 1
JS clones a node that has size {100, 100} and changes props that cause the node to increase size to {200, 200}. JS holds pointer to this node.
Now, the size (stored in LayoutableShadowNode.layoutMetrics_) changes after Yoga layout is triggered.
However, the node gets cloned inside State Reconciliation before Yoga layout phase. The JS pointer points to a node with size {100, 100}, not to a node with size {200, 200}.
## Step 2
Again, JS clones node (with old reference, therefore gets old layoutMetrics_ with size {100, 100}) and it changes props that cause the node to decrease its size back to {100, 100}.
We go all the way to Yoga layout and looking for nodes that have been affected by the node. The node, affected by the layout because it went from {200, 200} to {100, 100}, will be evaluated as not affected. This causes onLayout event to not be fired.
# Fix
We can safely remove the frame equality check (please see below). This can be done because we already check for equality before dispatching onLayout. It happens here:
https://www.internalfb.com/intern/diffusion/FBS/browsefile/master/xplat/js/react-native-github/ReactCommon/react/renderer/components/view/ViewEventEmitter.cpp?commit=881853eb0c42625fd0812bd2652bf36fcbd614ee&lines=43
As far as I know, `affectedNodes` isn't used for anything else besides dispatching onLayout.
# Discussion
This problem manifests itself only when a node has two different sizes that it flips between. To better understand this, please watch the video in Test plan labelled "before". Notice how the text has 2 different values that it flips between.
Here is a code that was affected by it https://fburl.com/diffusion/3hwo0iy5
If you inspect it closely, you will notice that it depends on `onLayout` to return correct value to calculate offset from left.
Reviewed By: JoshuaGross
Differential Revision: D22999891
fbshipit-source-id: e2d0f5771c1bf3cd788e5e9da0155c92e33fb84e
Summary:
In the past I tried a few heuristics to guess when a batch of Animated Operations were ready, and none of these were super reliable. But it turns out we can safely allow JS to manage that explicitly.
Non-Fabric still uses the old behavior which seems fine.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23010844
fbshipit-source-id: 4c688d3a61460118557a4971e549ec7457f3eb8f
Summary:
This diff extends fabric module to compile in OSS
NOTE: As a side effect of this diff, Fabric will be included into "reactnativejni" which is used by RN OSS.
I'm planning to remove this dependency in the near future - T71320460
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D22991877
fbshipit-source-id: 0ab3ee410dd448bbd87130114bec27c6e6bc65c6
Summary:
This diff introduces the class CoreComponentsRegistry that is responsible of registering core components in fabric.
This is required to make RN Tester to work in Fabric, in the future we'll extract this registry into another module (once we figure it out what's the best way to do this)
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D22991876
fbshipit-source-id: 15e85e15aac5dd981161d9eae35eb2cee4fa66b6
Summary:
This diff refactors the ComponentFactoryDelegate class. It also introduces a new class called ComponentRegistry that will be used to register components into fabric
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D22985313
fbshipit-source-id: e33a3d4fcb3a1c509b80c6ff1f43889480b1c2c3
Summary:
This diff extends the 'textlayoutmanager' module to compile in OSS
As part of this diff I also moved Android files in order to make the module compatible with Android.mk system
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D22963706
fbshipit-source-id: 14a7309f589fe12c21131c7d5cef02b4323d4a93
Summary:
This diff refactors the class Runnable into a struct to make it work in OSS
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D22963704
fbshipit-source-id: 2212c8f1e4a62b2bcad5c061709e29b247454fc1
Summary:
This ties the stack together, utilizes new TM functionality to avoid using the bridge in `RCTEventDispatcher`.
Changelog: [Internal]
Differential Revision: D22962320
fbshipit-source-id: de4e001a4a6ce232c37d7feed1e0c0d1d70a80f8
Summary:
To get `RCTNativeAnimatedModule` working bridgeless, I need to get `RCTEventDispatcher` working bridgeless.
To get `RCTEventDispatcher` working bridgeless, I need to support 2 new bridge methods:
- `- (void)enqueueJSCall:(NSString *)moduleDotMethod args:(NSArray *)args`
- `- (void)dispatchBlock:(dispatch_block_t)block queue:(dispatch_queue_t)queue;`
For (1) I copied the bridge impl exactly. For (2), the bridge only dispatches to JS thread, else uses `dispatch_async`. I only added support for dispatching to JS thread, callers can `dispatch_async` themselves if they want to.
Changelog: [Internal]
Differential Revision: D22962292
fbshipit-source-id: e34d15aee72f80dffcaa945bfda05ea415f66df7
Summary:
This should fix https://github.com/facebook/react-native/issues/29082 and https://github.com/facebook/react-native/issues/10471
Currently when an alert is being shown while a modal is being dismissed, it causes the alert not to show and In some cases it causes the UI to become unresponsive. I think this was caused by using RCTPresentedViewController to try and display the Alert the currently presented view. The View the Alert was going to be shown on is dismissed and the modal doesn't show. I implemented a new RCTAlertController to show the alert on top of the view, the modal being dismissed should now not interfere with the alert being shown.
## Changelog
[iOS] [Fixed] - Fixed showing Alert while closing a Modal
Pull Request resolved: https://github.com/facebook/react-native/pull/29295
Test Plan:
To recreate the bug:
1. npx react-native init Test --version 0.63.0-rc.1
2. Paste the following code into App.js
```javascript
/**
* Sample React Native App
* https://github.com/facebook/react-native
*
* format
* flow strict-local
*/
import React from 'react';
import {
SafeAreaView,
StyleSheet,
View,
Text,
StatusBar,
Modal,
Alert
} from 'react-native';
const App: () => React$Node = () => {
const [visible, setVisible] = React.useState(false)
const onShowModal = () => {
setVisible(true)
}
onCloseBroken = () => {
setVisible(false)
Alert.alert('Alert', 'Alert won\'t show')
}
onCloseWorking = () => {
setVisible(false)
setTimeout(() => Alert.alert('Alert', 'Works fine'), 10)
}
return (
<>
<StatusBar barStyle="dark-content" />
<SafeAreaView style={styles.container}>
<Text onPress={onShowModal}>Show modal</Text>
</SafeAreaView>
<Modal animationType="fade" visible={visible} onRequestClose={onCloseWorking} >
<View style={styles.container}>
<Text onPress={onCloseBroken}>Close modal immediately</Text>
<Text onPress={onCloseWorking}>Close modal with delay</Text>
</View>
</Modal>
</>
)
}
const styles = StyleSheet.create({
container: {
flex: 1,
alignItems: 'center',
justifyContent: 'space-around',
},
})
export default App
```
3. cd Test && npx react-native run-ios
4. Show the modal and click the `Close modal immediately` button
The first button doesn't show the alert, the second does because it gets rendered after the modal view is dismissed. After this commit, the alert always shows on top of every view properly. You can test by pointing the react native package to my branch by modifying the package json file like this
```
"react-native": "https://github.com/devon94/react-native.git#fix-ios-modal"
```
I was unable to reproduce the case where it causes the UI to be responsive in the test app but was able to reproduce it in our react native app at work. I can provide a video later if needed but the code is too complex to simplify into a test case.
Reviewed By: sammy-SC
Differential Revision: D22783371
Pulled By: PeteTheHeat
fbshipit-source-id: 3e359645c610074ea855ee5686c59bdb9d6b696b
Summary:
Changelog:
[Internal][Add] - Build the basic RCTLocalizationProvider
RCTLocalizationProvider is to enable the localization in fabric. But I'd start with internal apps now.
Reviewed By: PeteTheHeat
Differential Revision: D22704051
fbshipit-source-id: 845693a131c325f3c3d92b2ff491d5421966ad3e
Summary:
Use the latest published release of hermes-engine.
Changelog: [Android] [Changed] - Upgraded to Hermes 0.6.0
allow-large-files
Reviewed By: cpojer
Differential Revision: D22915617
fbshipit-source-id: a10d1db23e41084ce04ba94911ec28423ff5e230
Summary:
Changelog:
[Internal] - Add default value for accessibilityState "checked" and handle unhandled states.
It is also work for the case that accessibilityRole = "switch" and accessibilityState is set.
Reviewed By: sammy-SC
Differential Revision: D22914427
fbshipit-source-id: 4767a21f3bd109019b57bc09918758a38fbdea93
Summary:
New mechanism to soft-crash, or crash, and collect diagnostics in the mounting layer.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D22971260
fbshipit-source-id: 860cde3effa4a187f10f5dd1488dd41ace65e363
Summary:
Make react/core module to compile in OSS
This is necessary to make fabric compile in OSS
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D22908222
fbshipit-source-id: a37b87d02ecf77bb25693ce32cd0f3432be5daa7
Summary:
This diff creates the Android.mk file for the fabric graphics module
This is necessary to enable fabric in RN OSS
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D22908219
fbshipit-source-id: 70ef1d06053b0ca07a71c0a2d36e4edd617b2a25
Summary:
This diff creates the Android.mk file for the fabric debug module
This is necessary to enable fabric in RN OSS
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D22908220
fbshipit-source-id: f970fa1d8534a6043f60f362740bfc3e5199b511
Summary:
This diff creates the Android OSS build system for the module react/renderer/components/view
As part of this diff I had to remove inner folders of react/renderer/components/view
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D22881703
fbshipit-source-id: afb56b4f7660d000d2abb8ade0ccb60d1adfb371
Summary:
This diff creates the Android OSS build system for the module react/renderer/graphics
As part of this diff I also moved android specific files to the folder react/renderer/graphics/platform/cxx/react/renderer/graphics folder
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D22880975
fbshipit-source-id: 6899c3bb5ebce3a93d8487f49f1c253925a518e7
Summary:
Update FabricViewStateManager so that the caller can bail out of updates by returning null.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22966024
fbshipit-source-id: 31cd9ec8a9a9918fbb94844e30ed1a2fcc61997d
Summary:
This diff creates the Android OSS build system for the module react/utils
As part of this diff I also moved the module to react/utils folder
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D22877265
fbshipit-source-id: 717487aacb392d0f08530763a16a638b8021d501
Summary:
Migrate ScrollView component to use ES6 import
motivation: trying to slowly migrate each files to use es6 import/exports to make this discussion happen
https://github.com/react-native-community/discussions-and-proposals/issues/201#issuecomment-588454552
## Changelog
[General] [Changed] - Use es6 import/export syntax for ScrollView component
Pull Request resolved: https://github.com/facebook/react-native/pull/29184
Test Plan:
Test on RNTester for iOS
currently having trouble starting up RNTester on Android, but will update when I'm able to check on Android
Reviewed By: TheSavior
Differential Revision: D22959782
Pulled By: PeteTheHeat
fbshipit-source-id: c909bddda3b5b2edd26a526eedaa67fadd4c2b51
Summary:
I've used this while debugging LayoutAnimations a few times. It compiles out to nothing when the define is not set.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22962113
fbshipit-source-id: 88b7bb1c20a07a7d804e5c81d31cf871d58bee92
Summary:
Consolidated a few places where index adjustment was happening with nearly identical code. There was also one remaining case where index adjustment should be happening, but was not previously.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22962115
fbshipit-source-id: 732c026b5a3c60bb0eadb8d49826ffd6367f7f62
Summary:
Improve logging slightly.
One issue I ran into is that the "after" view hierarchy looks identical to "before" unless you schedule for the next UI tick.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22962116
fbshipit-source-id: c7a1e16e26d2aebefa3baf3acfef4e133b8fde70
Summary:
This change makes the behavior of providing a null value to onEndReachedThreshold match the behavior of not providing the prop at all.
## Changelog:
[General] [Changed] - Adjusted VirtualizedList's onEndReachedThreshold default value when null is provided
Reviewed By: olegbl
Differential Revision: D22870445
fbshipit-source-id: 29cbf0550702244007689759846ae0356f06b48d
Summary:
as title. The output of Buck suggested I add this, so I did and it let me build.
Changelog:
[Internal][Fixed] - Added iOS 10 method compatibility macro
Reviewed By: PeteTheHeat
Differential Revision: D22955013
fbshipit-source-id: 6aa03b164adca480e7c6f661b221c9bd3ee6c4f1
Summary:
Changelog: [Internal]
`SafeAreaViewShadowNode` we made incorrect assumption that setting `style` on YGNode and then copying it, always copies the style.
This is incorrect, style is only copied once `YGNodeCalculateLayout` has been called on either the node or its parent.
Reviewed By: JoshuaGross
Differential Revision: D22945677
fbshipit-source-id: 9c063c2dfe4d2390cf2fd10a96d2de418fa69376
Summary:
iOS will need to be implemented separately, but the shared C++ bits are in place.
Explanation: there is currently no way for the View layer to /know/ if an UpdateState call has succeeded or failed. Generally we just assume it succeeds, but if it fails we have no way of knowing or retrying.
This can cause some UI bugs. To mitigate this, I'm introducing a "failure" notification callback mechanism. The JNI bridging for this is a little complicated to avoid passing Runnable across the JNI, but it
should be much simpler on iOS.
In development this seems to make View components much more reliable.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22940187
fbshipit-source-id: 917f2932ae22d421f91fe8f4fca3f07dc089f820
Summary:
Using the same copies from react-native root dir.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22936067
fbshipit-source-id: 8484991f26d51085c6c45405a940e94624b35e06
Summary:
With BackgroundExecutor+State Reconciliation, it is pretty common to have races where View layer UpdateState calls are thrown away.
Theoretically this is /always/ possible since C++ doesn't retry failed UpdateStates, we just try once and then bail. This is part 1 of improving our mechanisms for ensuring that State stays up-to-date from the View layer.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22933927
fbshipit-source-id: 77b3b87402f772e3f149be0f9200e673bbed7b57
Summary:
Changelog:
[Internal] - Add UIContentSizeCategoryDidChangeNotification to re-render text
We don't need to restart the app to re-render text now, but we still need to swipe the screen or click on buttons to force to refresh. We may address this in the future.
Reviewed By: PeteTheHeat
Differential Revision: D22867293
fbshipit-source-id: 4747a45adc2bdc638cf7ef9c07a9484e48600583
Summary:
Making error more explicit to assist in debugging.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D22929047
fbshipit-source-id: 4f26668a96868e7c5865a587142c3bcd10a26c90
Summary:
Fixes https://github.com/MLH-Fellowship/react-native/issues/34
The PR is part of an effort to update the code comments to match the current documentation on the React Native website. The project is a part of the MLH Fellowship program and involves the automatic generation of the website docs from code comments and flow types as the end result.
To learn more about the project you can visit the project wiki:
- [Project Details](https://github.com/MLH-Fellowship/0.4.x-projects/wiki/React-Native-Flowtype-API-Docs-Generator)
- [RN Docs Standards](https://github.com/MLH-Fellowship/react-native/wiki/RN-Docs-standards)
Link to the documentation(the source of truth):
- [activityindicator.md](https://github.com/MLH-Fellowship/react-native-website/blob/master/docs/activityindicator.md)
## Changes
* Update the title and prop description from docs.
* Remove unnecessary `*` from the code comments.
* Add Snack player example specified in the docs to the code comments as JSDoc.
* Add `type` annotation to parse supported datatype by the prop.
* Add `platform` annotation to specify platforms supported by a prop.
* Add `default` annotation to parse default value of prop.
## Changelog
[Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/29523
Test Plan:
All changes are made to the code comments and thus there is no need for testing.
Reviewed by jevakallio
Reviewed By: cpojer
Differential Revision: D22921419
Pulled By: motiz88
fbshipit-source-id: 3701bf3e3f4e0762529c8a5597263354d5243f07
Summary:
Fixes https://github.com/MLH-Fellowship/react-native/issues/60
The PR is part of an effort to update the code comments to match the current documentation on the React Native website. The project is a part of the MLH Fellowship program and involves the automatic generation of the website docs from code comments and flow types as the end result.
To learn more about the project you can visit the project wiki:
- [Project Details](https://github.com/MLH-Fellowship/0.4.x-projects/wiki/React-Native-Flowtype-API-Docs-Generator)
- [RN Docs Standards](https://github.com/MLH-Fellowship/react-native/wiki/RN-Docs-standards)
Link to the documentation(the source of truth):
- [switch.md](https://github.com/MLH-Fellowship/react-native-website/blob/master/docs/switch.md)
## Changes
* Update the title and prop description from docs.
* Remove unnecessary `*` from the code comments.
* Add Snack player example specified in the docs to the code comments as JSDoc.
* Add `type` annotation to parse supported datatype by the prop.
* Add `platform` annotation to specify platforms supported by a prop.
* Add `default` annotation to parse default value of prop.
## Changelog
[Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/29546
Test Plan:
All changes are made to the code comments and thus there is no need for testing.
Reviewed by jevakallio
Reviewed By: cpojer
Differential Revision: D22921438
Pulled By: motiz88
fbshipit-source-id: eaab1e04252c15d7d3dd18a2b162fa97a4478dd6
Summary:
Fixes https://github.com/MLH-Fellowship/react-native/issues/33
The PR is part of an effort to update the code comments to match the current documentation on the React Native website. The project is a part of MLH fellowship program and involves automatic generation of the website docs from code comments and flow types as the end result.
To learn more about the project you can visit the project wiki:
- [Project details](https://github.com/MLH-Fellowship/0.4.x-projects/wiki/React-Native-Flowtype-API-Docs-Generator)
- [RN Docs Standards](https://github.com/MLH-Fellowship/react-native/wiki/RN-Docs-standards)
Link to the documentation(the source of truth):
- [button.md](https://github.com/MLH-Fellowship/react-native-website/blob/master/docs/button.md)
## Changes
* Update the title and prop description from docs.
* Remove unnecessary `*` from the code comments.
* Add default value to props.
* Specify the default value of a prop in the code comments with `default` annotation.
* For multiple defaults (different devices) use `default {platform android/ios}`.
* Update platforms in props.
* Use comma separated string with `platform` decorator.
* Add Snack player example specified in the docs to the code comments with `example` annotation.
## Changelog
[Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/29155
Test Plan:
All changes are made to the code comments and thus there is no need for testing.
[Reviewed by jevakallio](https://github.com/MLH-Fellowship/react-native/pull/18)
Reviewed By: cpojer
Differential Revision: D22767877
Pulled By: motiz88
fbshipit-source-id: ccad8d58dc2888d44d34fdbb94b3c187542e9f2b
Summary:
Instead of sourcing-in a .gradle file to setup codegen tasks in Gradle, let's define a proper `com.facebook.react.codegen` Gradle plugin, so that any Gradle project (lib/app) can include it via:
```
plugins {
id 'com.facebook.react.codegen'
}
```
The idea (not yet implemented in this commit) is to then allow those projects to add this section in the projects:
```
codegen {
enableCodegen = ...
jsRootDir = ...
}
```
This is more scalable and less hacky.
Important notes:
* The Gradle plugin should be prepared during the build, we're not going to publish it to Maven or other repo at this point.
* This setup is inspired by composite build setup explained here: https://ncorti.com/blog/gradle-plugins-and-composite-builds
* All android specific setup is added under `packages/react-native-codegen/android/` dir, but long term, we may want to move it up to `packages/react-native-codegen/` along side setup for other platforms.
* As part of this setup, the plugin will have an option (to be validated) to produce Java specs using https://github.com/square/javapoet
* This is the same library already used for React Native Android annotation processors
* This generator will not deal with parsing Flow types into schema, it will just takes in the schema and produce Java code
* We're evaluating whether JavaPoet is a better choice for Java code generation long term, vs building it in JS via string concatenation: https://github.com/facebook/react-native/blob/master/packages/react-native-codegen/src/generators/modules/GenerateModuleJavaSpec.js
* This commit produces a sample Java code, not the actual codegen output
Changelog: [Internal]
To try this out, run this Gradle task:
```
USE_CODEGEN=1 ./gradlew :ReactAndroid:generateJava
```
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D22917315
fbshipit-source-id: 0b79dba939b73ff1305b4b4fd86ab897c7a48d53
Summary:
This diff creates the Android OSS build system for the module react/config
As part of this diff I also moved the module to react/config folder
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D22877264
fbshipit-source-id: 5b3c42580d2b1d73dc0abb48bcf4ff063b2f581f
Summary:
The implementation of RuntimeExecutor must execute all provided callbacks. However, the implementation of RCTRuntimeExecutorFromBridge cannot guarantee it because it relies on Bridge to make the call. In this diff, we wrap the callback into a callable that asserts if it's not being called before destruction.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D22810439
fbshipit-source-id: f11932019ab6ccbab7e65db5919e0c64dcaf37ed
Summary:
The implementation of RuntimeExecutor must execute all provided callbacks. However, the implementation has some branches that lead to such cases. To understand if this happens and when we need to add some asserts.
Changelog: [Internal] Fabric-specific internal change.
Differential Revision: D22810440
fbshipit-source-id: 7c29b765045b644fe0ad9d56b4c253dfe9395c31
Summary:
Hook up onSuccess and onFailure callbacks to LayoutAnimations.
Note that in non-Fabric RN, onSuccess is not known to work in Android. I could not find any uses of onFailure and it's not documented, so for now, it is only called if the setup of the animation fails.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D22889352
fbshipit-source-id: 4306debb350388dd2b7a2cbfe295eb99723988e2
Summary:
There's currently a hidden parameter passed to the LayoutAnimation engine for "failure". It's not been used anywhere, ever, since it's a hidden parameter... and it's probably not called from the native side in non-Fabric. But it's been added to the native side of Fabric for feature-completeness and we might as well expose it, the cost seems minimal.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D22889455
fbshipit-source-id: 73322776ed21e58a370500ccfde89285f07a9d50
Summary:
Fabric's Telemetry uses `std::chrono::steady_clock::time_point`s to represent the exact moments in time when some events happen. This is the same clock that pretty much any performance tracker use (and should use), QPL included.
However, different trackers use different serializable representations of that timepoints. This diff adds functions that convert the timepoint value to UNIX Timestamp and to a number of seconds from the `steady_clock` epoch start.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D22887632
fbshipit-source-id: 2b51acddccee9af8071a34797b5015d6fd008394
Summary:
Now SurfaceTelemetry records the last 16 full transaction telemetries. We will use it info to report to our trackers.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D22887633
fbshipit-source-id: 0d88adff757e4bc5a701b51d4d06d85e1f51f10f
Summary:
This diff removes the inner folder of react/renderer/core, moving all its files into react/renderer/core
This is necessary to simplify the compilation of Fabric in OSS
More details: https://fb.quip.com/amaRA631DX3K
changelog: [internal] Internal
Reviewed By: fkgozali, JoshuaGross
Differential Revision: D22875854
fbshipit-source-id: e2d969c3ec67eab1bbdc9288e5a4285c740fa944
Summary:
This diff removes the fb/xplat_init dependency from fabric onLoad class
This is necessary to make RM compile in OSS
changelog: [Internal] Internal
Reviewed By: RSNara
Differential Revision: D22875531
fbshipit-source-id: cc4cd2af875fe7eadfb3a8f4a9f16acf5fa415d8
Summary:
This diff removes the fb/xplat_init dependency from fabric onLoad class
This is necessary to make fabric compile in OSS
changelog: [Internal] Internal
Reviewed By: RSNara
Differential Revision: D22874850
fbshipit-source-id: 0c61a366e09ab072215ba2fe651f96ef4c2e455a
Summary:
EZ refactor in ReactViewBackgroundDrawable to remove an unnecessary class variable
changelog: [internal] Internal
Reviewed By: RSNara
Differential Revision: D22874851
fbshipit-source-id: 16808809b196cba0dab5c9972359d7786939a7ce
Summary:
It is now required to call RCTBridge.setRCTTurboModuleRegistry for turbo modules to work properly on iOS.
## Changelog
[Internal] [Fix] - Fix RNTester TurboModules loading
Pull Request resolved: https://github.com/facebook/react-native/pull/29538
Test Plan: Tested that images in RNTester now loads properly and Redbox module missing warning are gone.
Reviewed By: JoshuaGross
Differential Revision: D22884163
Pulled By: fkgozali
fbshipit-source-id: daf2fccdb518ec4a382b80b7f7b02004405a7564
Summary:
Introduced `architecture.gradle` that sets up pluggable build-time codegen steps for Gradle so that:
* Libraries, including core ReactAndroid, can produce the new architecture codegen (NativeModule **Java** specs in this diff) during build time
* Hosting app (e.g. RNTester) can produce its own set of codegen specs separately
**Please note that this is still work in progress, hence app templates have not been updated to use it yet.**
In order to activate this setup, the env variable `USE_CODEGEN=1` must be set. Eventually, this var will be removed from the logic.
With this change, RNTester:
* Will see all the generated specs populated in the Gradle build dir, which should be equivalent to the currently [**checked in version**](https://github.com/facebook/react-native/tree/master/ReactAndroid/src/main/java/com/facebook/fbreact/specs).
* The specs will compile, but **have not been validated** vs the existing NativeModule .java classes through out the core -- that will be the next step
* The specs are under `com.facebook.fbreact.specs.beta` namespace, which will be configurable in the future. `.beta` is added to avoid conflict with the existing files in the repo.
### Is this all we need to enable TurboModule in Android?
No. There are a few more pieces needed:
* C++ codegen output for JNI layer for each NativeModule spec
* The C++ module lookup for TurboModule Manager
* The JNI build setup in Gradle for these C++ output
* Toggle to enable TurboModule system in the entire app
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D22838581
fbshipit-source-id: d972e2fbb37bdbd3354e72b014fc8bb27a33b9ac
Summary:
This builds on the previous commit and complete all current NativeModule spec support for React Native Android:
* method param (nullable) typing
* promise return support
* sync method
* getConstants() special Android runtime validation
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22862422
fbshipit-source-id: abc6d46fb8ce5863677910de1acc8bb6a927e7da
Summary:
* Allow generate-native-modules-specs-cli.js to generate Android specific files
* Add stub impl for Java spec generation (the output are still incomplete, see the next diffs for missing impl + tests)
* Adjust the CLI to only produce modules stuffs, there's no need to produce components code
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22860936
fbshipit-source-id: 38aae390189f143f6c6216995437ac1ff15a1788
Summary:
Sometimes mobile build systems just needs to provide the JS root dir to scan for NativeModules + NativeComponents, so let's support that directly in the CLI. This way, each build system doesn't have to do its own grep/crawling/filtering of files.
This will be needed for CocoaPods/Gradle integration.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22850011
fbshipit-source-id: fe202fa5e5a490af6d76fd10e761c9c3805fc11f
Summary:
`babel-plugin-codegen` will run the NativeModules codegen on each NativeModule spec, and inline the generated schema into the spec's `TurboModuleRegistry.get(Enforcing)?` call. This diff will forward that schema to `__turboModuleProxy` function (i.e: the TurboModule C++ infra).
**Note:** Both this and D2280384 can't be landed until D22743294 (https://github.com/facebook/react-native/commit/650c0f64f1262d26a31b61d2a7576c485f3efa13) hits production (1-2 weeks).
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D22832730
fbshipit-source-id: aecaf9943f9b01be805ff6b90249a6cbc6abdd20
Summary:
If `__turboModuleProxy` is called with a second argument, we'll now forward that `jsi::Value` to TurboModuleManager on iOS and Android, so that the TurboModuleManager can eventually use this `jsi::Value` to read data required to perform method invocation on the TurboModule object.
**Note:** This diff is basically a no-op right now.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D22828838
fbshipit-source-id: 19db2adcae6a58b4885fcd11bef23f9d5882bfce
Summary:
This diff:
- Moves the NativeModule flow types to the bottom of `CodegenSchema.js`.
- Re-organizes the NativeModuel flow type declarations based on when they're first used. Essentially, we start off by declaring a giant 'NativeModuleShape' type, which uses smaller undeclared types. Then we declare all the undeclared children of `NativeModuleShape`, and on and on. This way, you know where to start reading the types, and you can easily tell how every type relates to every other type.
Changelog: [Internal]
Differential Revision: D22828840
fbshipit-source-id: 5b4b9466a41b9bcb92a1de159bcbc12e4dc01df3
Summary:
Unfortunately, the new codegen doesn't allow us to import types from other files. Therefore, I've inlined the interface specification of NativeAnimatedModule into NativeAnimatedTurboModule.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D22858790
fbshipit-source-id: 759bb960240afaba6b70c2730c3359b7e8c46c83
Summary:
This diff moves fabric C++ code from ReactCommon/fabric to ReactCommon/react/renderer
As part of this diff I also refactored components, codegen and callsites on CatalystApp, FB4A and venice
Script: P137350694
changelog: [internal] internal refactor
Reviewed By: fkgozali
Differential Revision: D22852139
fbshipit-source-id: f85310ba858b6afd81abfd9cbe6d70b28eca7415
Summary:
This diff updates the minsdkversion of RN OSS template to API level 19
changelog: [Android][Deprecated] Deprecate support of Android API levels 16 to 18. The new minSDK version will be 19+ moving forward
Reviewed By: JoshuaGross
Differential Revision: D22874852
fbshipit-source-id: 1df98e422dc9debd40ab2021aafc7b165312d14b
Summary:
This babel plugin will also take care of the JS TurboModule Codegen. Therefore, we should rename this into something more generic.
Changelog:
[General][Changed] Rename babel-plugin-inline-view-configs to react-native/babel-plugin-codegen
Reviewed By: rickhanlonii, cpojer
Differential Revision: D22803209
fbshipit-source-id: 416c97fea6fa0820d25bbc91033a0cbbbbbff825
Summary:
This instruments the following marker:
- MODULE_CREATE
**Note:** This marker isn't necessary to test the JS TurboModule codegen, since the JS codegen should only affect the C++ portion of the TurboModule infra. However, I implemented this while I was in this area of the code, for completeness.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D22679888
fbshipit-source-id: aa04822bd5a7c889813fcd13ca23c0b7a1d8444a
Summary:
The async NativeModule method call event can fail if something goes wrong when we're about do dispatch the method call.
Changelog: [Internal]
Reviewed By: ejanzer
Differential Revision: D22609410
fbshipit-source-id: 699eeb78edfbefa85e417fd82318ae8e4f6f7d90
Summary:
In D17480605 (https://github.com/facebook/react-native/commit/689233b018bd533a7eecd38e38a7fb84b849cf88), I made all methods with void return types dispatch to the NativeModules thread. This diff makes the same change to methods with promise return types.
**Note:** The changes are disabled for now. I'll add an MC so that we can test this in production in a later diff.
Changelog:
[Android][Fixed] - Make promise NativeModule methods dispatch to NativeModules thread
Reviewed By: PeteTheHeat
Differential Revision: D22489338
fbshipit-source-id: d5b030871f9f7b3f48eb111225516521493cb05e
Summary:
Android's `VibrationModule` uses deprecated `vibrate(long milliseconds)` and `vibrate(long[] pattern, int repeat)` methods. Deprecation notes: [[1]](https://developer.android.com/reference/android/os/Vibrator#vibrate(long)) [[2]](https://developer.android.com/reference/android/os/Vibrator#vibrate(long[],%20int)).
Changes in this pull request use recent `Vibrator` API for devices with API Level >= 26 (since mentioned methods were depreceted in API Level 26).
## 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
-->
[Android] [Internal] - Use non-deprecated `Vibrator` API in `VibrationModule`
Pull Request resolved: https://github.com/facebook/react-native/pull/29534
Test Plan: API is the same as before, but it uses recent `Vibrator` API.
Reviewed By: makovkastar
Differential Revision: D22857382
Pulled By: mdvacca
fbshipit-source-id: 6793a7d165fa73d81064865861ed55af2de83d52
Summary:
This diff cleansup unused code on AccessibilityInfoModule class
changelog: [Android][Deprecated] Remove code used by deprecated Android API levels
Reviewed By: JoshuaGross
Differential Revision: D22771912
fbshipit-source-id: f32808fa93f75c10324e8875b85fe4e541b284b8
Summary:
This diff removes code that was used to support android APIs < kitkat
changelog: [Android][Deprecated] Remove calls to Android API < Kitkat
Reviewed By: JoshuaGross
Differential Revision: D22771913
fbshipit-source-id: b9bba9e94fbc8e18889b821050dcd6eace4c202d
Summary:
Changelog: [Internal]
Since D22098586 (https://github.com/facebook/react-native/commit/476ab7481e23070fc4db3f584e45a95eb2f9f7e1) zIndex is only applied to views with position other than static.
Sticky header however needs to have its zIndex applied otherwise it goes below the content.
Reviewed By: mdvacca
Differential Revision: D22843134
fbshipit-source-id: d2e3a21441795b82c44b6d4245ccf89620fd9a8e
Summary:
This diff upgrades react-native-github Android to support API level 19+
changelog: [Android][Deprecated] Deprecate support of Android API levels 16 to 18. The new minSDK version will be 19+ moving forward
Reviewed By: JoshuaGross
Differential Revision: D22734208
fbshipit-source-id: b052721c8cfb44f8d74cf4bbb5b7a769e544d1d9
Summary:
To help reflect how we've collectively been thinking about partnership and engagement on React Native, this change moves Facebook into the Partners list alongside other partners like Expo, Microsoft, and others. This change helps establish that the React Native teams across Facebook & Microsoft are one big happy family :)
## 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] [Changed] - Updated ECOSYSTEM.md to reflect partnerships between Facebook, Microsoft, and others
Pull Request resolved: https://github.com/facebook/react-native/pull/29527
Test Plan: N/A - document change
Reviewed By: cpojer
Differential Revision: D22845420
Pulled By: TheSavior
fbshipit-source-id: b3393c8749efc924b27d101d0513ae55eba55270
Summary:
Changelog:[Fabric][iOS] Add full support for AccessibilityState
Since the AccessibilityState checked, busy or expanded only exist in Android and they don't have corresponding AccessibilityTrait to set, so we could just ignore the implementation in RCTViewComponentView.mm. What I did is to update the AccessibilityState values in AccessibilityPrimitives.h and accessibilityPropsConversions.h in order to enable further implementation in Android.
Reviewed By: shergin
Differential Revision: D22807584
fbshipit-source-id: f3ef048055d11314bc833357d8ca061e0fe219a4
Summary:
Changelog: [Internal][Added] Support for toggling all breakpoints in Chrome debuggers
This implements the Debugger.setBreakpointsActive CDP message, allowing
users in Chrome to toggle all exceptions on and off.
As with V8/Chrome, setting a breakpoint will automatically re-activate
all breakpoints.
#utd-hermes-ignore-android
Reviewed By: avp
Differential Revision: D22825209
fbshipit-source-id: bda2cc59aba04443280bca46126c19bb0cdb58d7
Summary:
After D22801173 (https://github.com/facebook/react-native/commit/9e6ba9ddb8608d4e3a4a80d0138600130b766d4c) has landed, the native mechanisms in NativeAnimated to delay queued items from immediate execution are no longer necessary.
Fabric and non-Fabric animations both look smooth after deleting this code.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22807906
fbshipit-source-id: 9241fff84376f6aa9a35049cc40dfd6561effaa1
Summary:
As a followup to D22743723 (https://github.com/facebook/react-native/commit/d53fc8a3cd44c7ec7e6eade985daf3d4feb2d736) on the iOS side, I implement a BackgroundExecutor that can be used from C++ to schedule layouts on their own thread, off the JS and UI thread.
This is a potential perf improvement that we will experiment with.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22826795
fbshipit-source-id: 899bd67fe1b86f52910951e9536b59a1414a304c
Summary:
In Fabric, there are two subtle differences in Animated:
1) On the native side, queued NativeAnimated operations are executed more frequently
2) On the JS side there seems to be a bigger gap between AnimatedNodes being set up, and the final `componentDidMount`/`componentDidUpdate` that results in `_attachNativeEvents` being called.
This results in some visual glitching for certain features like StickyScrollViewHeader and other animations that are frequently rerendered. Rerendering an animated component relies on sync-like behavior
(new animations must be set up in the same frame that old animations are torn down, and the UI must flush any updates in the same frame). This sync-like behavior is trickier to achieve in Fabric, so
we introduce this mechanism, in Fabric only, to queued operations more aggressively on the JS side and only flush them when `componentDidMount`/`componentDidUpdate` have been called on all relevant nodes.
This seems to resolve longstanding issues with animations in Fabric on Android.
There are unrelated issues on iOS that make this difficult to test currently, so I'll keep the new path Android-only for now.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D22801173
fbshipit-source-id: 3db2235483636c9074df941cfac0a30f3f97545a
Summary:
This PR allows the use_flipper! helper function to be used in projects that
have more than just Debug/Release configurations. For example, a project
may have DevDebug, DevRelease, ProdDebug, and ProdRelease configurations.
These projects can now do:
```ruby
use_flipper!(configurations: ['DevDebug', 'ProdDebug'])
```
## Changelog
[iOS][Added] Ability to set which configuration to enable flipper for when using use_flipper!
Pull Request resolved: https://github.com/facebook/react-native/pull/29074
Test Plan:
I don't know how to run code in this repository, so I copy and pasted this function into the Podfile of an existing project. My complete Podfile is as below:
```ruby
# Uncomment the next line to define a global platform for your project
platform :ios, '10.0'
require_relative '../node_modules/react-native-community/cli-platform-ios/native_modules'
project 'marketplace',
'Dev.Debug' => :debug,
'Dev.Release' => :release,
'Prod.Debug' => :debug,
'Prod.Release' => :release
def use_flipper!(versions = {}, configurations: ['Debug'])
versions['Flipper'] ||= '~> 0.33.1'
versions['DoubleConversion'] ||= '1.1.7'
versions['Flipper-Folly'] ||= '~> 2.1'
versions['Flipper-Glog'] ||= '0.3.6'
versions['Flipper-PeerTalk'] ||= '~> 0.0.4'
versions['Flipper-RSocket'] ||= '~> 1.0'
pod 'FlipperKit', versions['Flipper'], :configurations => configurations
pod 'FlipperKit/FlipperKitLayoutPlugin', versions['Flipper'], :configurations => configurations
pod 'FlipperKit/SKIOSNetworkPlugin', versions['Flipper'], :configurations => configurations
pod 'FlipperKit/FlipperKitUserDefaultsPlugin', versions['Flipper'], :configurations => configurations
pod 'FlipperKit/FlipperKitReactPlugin', versions['Flipper'], :configurations => configurations
# List all transitive dependencies for FlipperKit pods
# to avoid them being linked in Release builds
pod 'Flipper', versions['Flipper'], :configurations => configurations
pod 'Flipper-DoubleConversion', versions['Flipper-DoubleConversion'], :configurations => configurations
pod 'Flipper-Folly', versions['Flipper-Folly'], :configurations => configurations
pod 'Flipper-Glog', versions['Flipper-Glog'], :configurations => configurations
pod 'Flipper-PeerTalk', versions['Flipper-PeerTalk'], :configurations => configurations
pod 'Flipper-RSocket', versions['Flipper-RSocket'], :configurations => configurations
pod 'FlipperKit/Core', versions['Flipper'], :configurations => configurations
pod 'FlipperKit/CppBridge', versions['Flipper'], :configurations => configurations
pod 'FlipperKit/FBCxxFollyDynamicConvert', versions['Flipper'], :configurations => configurations
pod 'FlipperKit/FBDefines', versions['Flipper'], :configurations => configurations
pod 'FlipperKit/FKPortForwarding', versions['Flipper'], :configurations => configurations
pod 'FlipperKit/FlipperKitHighlightOverlay', versions['Flipper'], :configurations => configurations
pod 'FlipperKit/FlipperKitLayoutTextSearchable', versions['Flipper'], :configurations => configurations
pod 'FlipperKit/FlipperKitNetworkPlugin', versions['Flipper'], :configurations => configurations
end
# Post Install processing for Flipper
def flipper_post_install(installer)
installer.pods_project.targets.each do |target|
if target.name == 'YogaKit'
target.build_configurations.each do |config|
config.build_settings['SWIFT_VERSION'] = '4.1'
end
end
end
end
target 'marketplace' do
# Comment the next line if you're not using Swift and don't want to use dynamic frameworks
#use_frameworks!
pod 'FBLazyVector', :path => '../node_modules/react-native/Libraries/FBLazyVector'
pod 'FBReactNativeSpec', :path => '../node_modules/react-native/Libraries/FBReactNativeSpec'
pod 'RCTRequired', :path => '../node_modules/react-native/Libraries/RCTRequired'
pod 'RCTTypeSafety', :path => '../node_modules/react-native/Libraries/TypeSafety'
pod 'React', :path => '../node_modules/react-native/'
pod 'React-Core', :path => '../node_modules/react-native/'
pod 'React-CoreModules', :path => '../node_modules/react-native/React/CoreModules'
pod 'React-Core/DevSupport', :path => '../node_modules/react-native/'
pod 'React-RCTActionSheet', :path => '../node_modules/react-native/Libraries/ActionSheetIOS'
pod 'React-RCTAnimation', :path => '../node_modules/react-native/Libraries/NativeAnimation'
pod 'React-RCTBlob', :path => '../node_modules/react-native/Libraries/Blob'
pod 'React-RCTImage', :path => '../node_modules/react-native/Libraries/Image'
pod 'React-RCTLinking', :path => '../node_modules/react-native/Libraries/LinkingIOS'
pod 'React-RCTNetwork', :path => '../node_modules/react-native/Libraries/Network'
pod 'React-RCTSettings', :path => '../node_modules/react-native/Libraries/Settings'
pod 'React-RCTText', :path => '../node_modules/react-native/Libraries/Text'
pod 'React-RCTVibration', :path => '../node_modules/react-native/Libraries/Vibration'
pod 'React-Core/RCTWebSocket', :path => '../node_modules/react-native/'
pod 'React-cxxreact', :path => '../node_modules/react-native/ReactCommon/cxxreact'
pod 'React-jsi', :path => '../node_modules/react-native/ReactCommon/jsi'
pod 'React-jsiexecutor', :path => '../node_modules/react-native/ReactCommon/jsiexecutor'
pod 'React-jsinspector', :path => '../node_modules/react-native/ReactCommon/jsinspector'
pod 'ReactCommon/callinvoker', :path => '../node_modules/react-native/ReactCommon'
pod 'ReactCommon/turbomodule/core', :path => '../node_modules/react-native/ReactCommon'
pod 'Yoga', :path => '../node_modules/react-native/ReactCommon/yoga', :modular_headers => true
pod 'DoubleConversion', :podspec => '../node_modules/react-native/third-party-podspecs/DoubleConversion.podspec'
pod 'glog', :podspec => '../node_modules/react-native/third-party-podspecs/glog.podspec'
pod 'Folly', :podspec => '../node_modules/react-native/third-party-podspecs/Folly.podspec'
pod 'Intercom', '~> 6.0.0'
pod 'RNDeviceInfo', :path => '../node_modules/react-native-device-info'
pod 'react-native-netinfo', :podspec => '../node_modules/react-native-community/netinfo/react-native-netinfo.podspec'
pod 'BugsnagReactNative', :podspec => '../node_modules/bugsnag-react-native/BugsnagReactNative.podspec'
pod 'rn-fetch-blob', :podspec => '../node_modules/rn-fetch-blob/rn-fetch-blob.podspec'
use_native_modules!
pod 'react-native-intercom', :path => '../node_modules/react-native-intercom'
pod 'react-native-image-resizer', :path => '../node_modules/react-native-image-resizer'
pod 'RNVectorIcons', :path => '../node_modules/react-native-vector-icons'
pod 'react-native-camera', :path => '../node_modules/react-native-camera'
pod 'RNCPushNotificationIOS', :path => '../node_modules/react-native-community/push-notification-ios'
pod 'RNDateTimePicker', :path => '../node_modules/react-native-community/datetimepicker'
# Enables Flipper.
#
# Note that if you have use_frameworks! enabled, Flipper will not work and
# you should disable these next few lines.
use_flipper!(configurations: ['Dev.Debug', 'Prod.Debug'])
post_install do |installer|
flipper_post_install(installer)
installer.pods_project.targets.each do |target|
# The following is needed to ensure the "archive" step works in XCode.
# It removes React & Yoga from the Pods project, as it is already included in the main project.
# Without this, you'd see errors when you archive like:
# "Multiple commands produce ... libReact.a"
# "Multiple commands produce ... libyoga.a"
targets_to_ignore = %w(React yoga)
if targets_to_ignore.include? target.name
target.remove_from_project
end
end
end
end
```
I then ran `pod install`:
```
nico:ios/ (dev*) $ pod install [20:14:43]
Adding a custom script phase for Pod RNFBApp: [RNFB] Core Configuration
Detected React Native module pods for BVLinearGradient, RNCAsyncStorage, RNCPicker, RNCPushNotificationIOS, RNDateTimePicker, RNFBApp, RNFBAuth, RNFBDatabase, RNFBDynamicLinks, RNFBFirestore, RNFBStorage, RNSVG, RNVectorIcons, ReactNativeNavigation, react-native-camera, react-native-cameraroll, react-native-config, react-native-flipper, react-native-get-random-values, react-native-image-resizer, and react-native-intercom
Analyzing dependencies
Downloading dependencies
Generating Pods project
Integrating client project
Pod installation complete! There are 73 dependencies from the Podfile and 88 total pods installed.
[!] use_native_modules! skipped the react-native dependency 'react-native-photo-view'. No podspec file was found.
- Check to see if there is an updated version that contains the necessary podspec file
- Contact the library maintainers or send them a PR to add a podspec. The react-native-webview podspec is a good
example of a package.json driven podspec. See
https://github.com/react-native-community/react-native-webview/blob/master/react-native-webview.podspec
- If necessary, you can disable autolinking for the dependency and link it manually. See
https://github.com/react-native-community/cli/blob/master/docs/autolinking.md#how-can-i-disable-autolinking-for-unsupported-library
[!] use_native_modules! skipped the react-native dependency 'detox'. No podspec file was found.
- Check to see if there is an updated version that contains the necessary podspec file
- Contact the library maintainers or send them a PR to add a podspec. The react-native-webview podspec is a good
example of a package.json driven podspec. See
https://github.com/react-native-community/react-native-webview/blob/master/react-native-webview.podspec
- If necessary, you can disable autolinking for the dependency and link it manually. See
https://github.com/react-native-community/cli/blob/master/docs/autolinking.md#how-can-i-disable-autolinking-for-unsupported-library
```
Reviewed By: cpojer
Differential Revision: D22795421
Pulled By: passy
fbshipit-source-id: 89ba555eadc4918e9ac464a19a318198b237e01e
Summary:
Discovered when debugging a React Native app in Chrome. The function `performanceNow` was recently changed, so that in Chrome it now refers to `performance.now()` method. However, `now()` cannot be called standalone without a context.
Reproduced by a synthetic example in Chrome:
```
const performanceNow = window.performance.now;
performanceNow();
Uncaught TypeError: Illegal invocation
at <anonymous>:1:1
```
Changelog:
[General] [Fixed] - Fix failure when debugging code in a browser; was caused by `performanceNow()` function.
Reviewed By: cpojer
Differential Revision: D22739176
fbshipit-source-id: f89b8a215b7b4c430ffd72a1d23539c4f1b31d24
Summary:
Using RCTFabricSurface in bridgeless mode, this comment seems incorrect to me.
`[_surface start]` needs to be called after initialization, or else the stage and `SurfacePresenter` registration never happen.
Maybe this comment used to be true, but it is misleading with the current implementation.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D22800934
fbshipit-source-id: c396cbd3fc1749b8e7ab571c9e7bc05cd352fc14
Summary:
In the next react sync we removed the `displayName` from forwardRef and useMemo components ([PR here](https://github.com/facebook/react/pull/18495 )).
This means we need to manually add the displayName in the mock.
Changelog: [General] [Fixed] Fix test renderer mocks to use the displayName more often.
Reviewed By: TheSavior
Differential Revision: D22775470
fbshipit-source-id: 1390dc325e34f7ccea32bbdf1c6a8f6efea3a080
Summary:
This diff adds some integration tests that throw read React errors and asserts on the LogBox data.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D22752147
fbshipit-source-id: eb2e1542524d67558f2450130015164acd4d6093
Summary:
In the next version of React they've changed the format of component stacks from a custom format to the same format as call stacks. This diff adds handling (and test) for the new format.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D22752034
fbshipit-source-id: 38d74bffd9ed623cbdd71e70103d66d8f0765fd9
Summary:
Changelog: Fix [TypeError: Network request failed] on file upload
# Problem
In https://github.com/facebook/react-native/commit/31980094107ed37f8de70972dbcc319cc9a26339 I made method `loadImageForURL` blocking and nil returning since it was no longer cancellable.
However inside `[RCTNetworkTask validateRequestToken]` was a logic counting on request token being non nil.
This diff removes this check and adds `nullable` to `[RCTImageURLLoader loadImageForURL]` making it explicit.
Reviewed By: PeteTheHeat
Differential Revision: D22767174
fbshipit-source-id: 04d5562e381912233b9c14e8156cbf145288f063
Summary:
Only add Sec-WebSocket-Protocol header if has _requestedProtocols.
## 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] - when Sec-WebSocket-Protocol header is empty vaulue, IIS server will return error 502.
Pull Request resolved: https://github.com/facebook/react-native/pull/29419
Reviewed By: cpojer
Differential Revision: D22782867
Pulled By: PeteTheHeat
fbshipit-source-id: d588997a345929b0c11c554d4452e612a336901a
Summary: As part of our usage color detection that relies on precise values of colors, it appears that the ration used was 256, but RBGA scale is 0-255
Reviewed By: shergin
Differential Revision: D22785378
fbshipit-source-id: 87a6f9b4611ceaadbbbb75a4566f4cf9b8285b68
Summary:
This diff fixes the rendering of ART Shapes that uses null paths
changelog: [internal] internal fix
Reviewed By: JoshuaGross
Differential Revision: D22780163
fbshipit-source-id: 2aded726ad47fce243ec1c28fbd4c39dd71820ef
Summary:
See title. Basically during stopSurface a single BatchMountInstruction can contain both the Create and Delete MountItem for a single view, which will cause *only* the deletion to be executed.
There isn't really a way to prevent this and we're just trying to clean up as aggressively as possible, so we can safely ignore this.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22779189
fbshipit-source-id: c44fd736835b04c5de776346ec3d34afa4860199
Summary:
This exception will be more disruptive during development than necessary.
This can be upgraded again if there's a reasonable root-cause, but right now this error isn't actionable enough, is too common, and the repercussions aren't obvious.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22775734
fbshipit-source-id: 2cd9449f5b78025f7a230fbbd5f2e87bce183d04
Summary:
Changelog:
[Internal] - Add additional tests to cover other features in RCTParagraphComponentView.
I mainly test the correctness of attributedString and fragments in the RCTParagraphComponentView.
Reviewed By: shergin
Differential Revision: D22668022
fbshipit-source-id: 6879eb6b6a6ace9e6e05f1486d4e4034ebfd73bc
Summary:
Changelog:
[Internal] - Build the basic RCTParagraphComponentViewTests. Add the content of tests.
I mainly test the cases of text with multiple links inside, text with link which crosses multiple lines and truncated text with link.
Reviewed By: shergin
Differential Revision: D22607097
fbshipit-source-id: c98b8d4c5424a3e51e2869f50bc5038f969e45e8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/29470
Changelog:
[Internal] - Build the framework of the RCTParagraphComponentViewTests and do some setup.
I built a shadowNode tree here for future tests.
Reviewed By: shergin
Differential Revision: D22536626
fbshipit-source-id: c74b63b3319693b90c9d64b7f782a1a922b0d499
Summary:
The Animated native module cannot be converted to a TM because it has perf regressions when used in conjunction with Paper renderer. Instead of fixing these complicated perf issues (which will disappear when Fabric ships this half), temporarily fork the native module. The new fork is converted to a TM, and only used to unblock bridgeless mode testing.
Changelog:[Internal]
Reviewed By: RSNara
Differential Revision: D22651010
fbshipit-source-id: 912123ef38ac8c66025b7bba34a65ec6d98f330d
Summary:
Changelog:
[Internal][Added] - Change signature of `addTimestamp` for IPerformanceLogger and rename old implementation to addTimeAnnotation
Adding this because there is no current ability to add a timespan to our perf logging with pre-defined start and end timestamps. The naming is a bit confusing because the current implementation of `addTimespan` in FB doesn't add a timespan, it adds an annotation of duration. We rename the old implementation to `addTimeAnnotation/s` and update `addTimespan` to suit our needs.
Reviewed By: rubennorte
Differential Revision: D22633202
fbshipit-source-id: 0e32099241f1f3835257cbb4ad108a4f437869e6
Summary:
I want to be able parse error stacks in contexts where I have a call stack string but no error object.
This diff changes parseErrorStack to only accept the stack, instead of a whole error object.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D22752048
fbshipit-source-id: b4b1cd58802eefe736130d48a82bc091241a11ee
Summary:
Changelog: Fix possible race condition inside `KeyboardAvoidingView`
Fabric has different order of events
In Fabric, `keyboardWillChangeFrame` event is fired before `onLayout`, but in Paper it is the other way around.
`KeyboardAvoidingView` depends on the order of events to function properly. Inside `_relativeKeyboardHeight` 0 is returned if `this._frame` is null.
To fix this, `bottom` margin is recalculated whenever `keyboardWillChangeFrame` or `onLayout` is triggered.
Reviewed By: shergin
Differential Revision: D22764192
fbshipit-source-id: 591ac59af4395a4d43c4e78e4fbc0ff118b292f8
Summary:
Enable registerSegment in Venice and verify bundle splitting works for Pokes with Venice.
Changelog: [Internal]
Reviewed By: ejanzer
Differential Revision: D22666115
fbshipit-source-id: 74ef830b802634b1019d4371873aba599438de37
Summary:
The standard says that zIndex should only be defined for non-`static` positioned views. This diff implements it.
For now, it actually enables zIndex for all views in RN because there is no way to specify `position: static` but will will give that ability by changing Flow definitions in future diffs in a couple of weeks (to ensure OTA safety).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D22098586
fbshipit-source-id: 77dacbee0fe887f667ba81640b8bd759e1df11fd
Summary:
In W3C standard, `zIndex` prop can have `auto` value which is the default.
In classic React Native and in Fabric before this diff, the default value was `0`. The only difference between `auto` and `0` is that nodes with `auto` do not form stacking context whereas nodes with `0` (or any other numeric value) do. This worked fine in pre-Fabric RN where every view always formed staking context but in Fabric we need to finally implement it right.
https://developer.mozilla.org/en-US/docs/Web/CSS/z-indexhttps://stackoverflow.com/a/57892072/496389
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D22403383
fbshipit-source-id: 6532d180a00f22bde763e3ebadd6683b344a0672
Summary:
Due to subtle differences in lifecycle on the native side, as well as in JS, Fabric constructs partial graphs more frequently than non-Fabric RN did.
We still crash if we detect a cycle, which we check for more explicitly now; and we still always crash in non-Fabric. But if we detect a partial graph in Fabric,
we warn instead of crashing. We also print the state of the graph before crashing/warning, to assist in debugging in production.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D22752291
fbshipit-source-id: f452892678fbe7b5a49f93644d39d3b6ae5bda75
Summary:
This is an implementation of `BackgroundExecutor` on iOS.
In case if the experiment is successful, we will make it mandatory for all platforms.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D22743722
fbshipit-source-id: 7756d2947e962720b9970d48c74929ab407c0440
Summary:
In the current Fabric model, we compute layout during the commit phase on the caller thread synchronously. Even though, in general, it's by design the correct way to do it, there are cases where it's *not* a requirement. In such cases, it's more optimal to yield early and continue execution of the commit process on a different thread asynchronously.
One of such cases potentially is `completeRoot` call. There we don't need to return anything and can resume JavaScript execution immediately.
The performance implications of that are not clear but there is a hope that it can free up to ~100ms of JavaScript execution time which is currently spent waiting for layout calculation (and other aspects of the commit phase).
This is an implementation in the core. The plan is to test that on iOS first and then, in case if the results of the experiment are positive, to implement it on Android as well.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D22743723
fbshipit-source-id: 846a13152c5a419de0eaef0e6283ea4277c907dc
Summary: For the JS TurboModule Codegen, we'll have to have `__turboModuleProxy` accept an additional argument: information containing what methods are supported on the TurboModule object. This diff makes calling `__turboModuleProxy` with two arguments valid.
Reviewed By: shergin
Differential Revision: D22743294
fbshipit-source-id: fd0050fc0373b43dc7089695c8e341137cad21f1
Summary:
Cleaning up the test for switching to the shared RuntimeExecutor, and removing the jsContext arg from Fabric's Android APIs entirely.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22026752
fbshipit-source-id: df70faa70eaa2a04717ae89e8ad3216dfd486a35
Summary:
Unfortunately LayoutAnimations index adjustment is a bit tricky. There was one (hopefully only one!) remaining issue where a specific series of delayed removes, inserts, and removes would trip up index adjustment. Namely in this case: Preexisting delayed removes, and then a later animated commit with immediate inserts followed by higher-index removes.
This case is now resolved and I took time to test and verify other index adjustment paths.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22709915
fbshipit-source-id: 16ba5bb358608d384f44628dbb6cc691deb8164a
Summary:
This notification was never used, I'd rather not have someone start relying on it, and need to figure out how to migrate them in bridgeless mode.
Changelog:[Internal]
Reviewed By: cpojer, RSNara
Differential Revision: D22513602
fbshipit-source-id: 80b179af8408abc6646a73380b4a66cade3f75f2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/29453
Problem Statement: A native module needs to call a function on `ReactInstance` (in this case `loadScript`). Typically, this is handled by the bridge.
Current Bridgeless Solution: Create a new protocol (in this case `RCTJSScriptLoaderModule`) which lets a block be passed in TM init to forward the method call to `ReactInstance`. This is the best thing I could think of right now.
Changelog:[Internal]
Reviewed By: RSNara
Differential Revision: D22512748
fbshipit-source-id: e6559279b6e299e17d1199407129ad3902c41e6b
Summary:
Passes the `globalPrefix` option from the Metro config object into `metro-babel-transformer`. This currently has no effect in OSS.
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D22594663
fbshipit-source-id: 668b71cd6bec988313e9286b316f9006d61ad871
Summary:
The max heap size currently is 512 MB for OSS apps using Hermes on Android.
Some users (see https://github.com/facebook/hermes/issues/295) are experiencing
long pauses when reaching this ceiling.
Increasing this limit to 1 GB should reduce the frequency of these pauses occurring
for apps where the expected heap usage is near 512 MB.
Changelog: [Internal] Set Hermes's default max heap size to 1 GB
Reviewed By: mhorowitz
Differential Revision: D22577343
fbshipit-source-id: 2d7d688e38e95a082692dca52d010d0449a6e64b
Summary:
This template for new projects isn't configured with exact objects by default, which could cause issues with code in react-native assuming this option is enabled.
Changelog: [Changed] Enabled exact_by_default in Flow for new projects using the template
Reviewed By: cpojer
Differential Revision: D22571745
fbshipit-source-id: da5affe903114484384764be2142e1c46244bfac
Summary:
Cleaning up a bunch of legacy JS (var) and removing some variable names for stuff that is just used once.
Changelog: [Internal]
Reviewed By: GijsWeterings
Differential Revision: D22627397
fbshipit-source-id: 783af84b17cbf37df3b8e2ae10bb39d50dd8180d
Summary:
Changelog:
When the JSLocation is nil, checking whether the address is running is unnesarry and wasting time, adding a JSLocation length check to mitigate that.
Reviewed By: cpojer
Differential Revision: D22644574
fbshipit-source-id: c51fc1a8976ebc25cba2653581e1bfa479a1d70d
Summary:
This could help somewhat with solving crashes in production.
Changelog: [internal]
Reviewed By: mdvacca
Differential Revision: D22631593
fbshipit-source-id: 2caebf1d6611d98764bccf5a6608040e5c892614
Summary:
This diff fixex a NoSuchMethodException when calling DisplayMetricsHolder.initDisplayMetrics in Android API level <= 16.
changelog: [Android][Fixed] Fix NoSuchMethodException when calling DisplayMetricsHolder.initDisplayMetrics in Android API level <= 16
Reviewed By: fkgozali
Differential Revision: D22630603
fbshipit-source-id: d2a95445beb5745a89ee1eefdf0d24ce3e0b8893
Summary:
Changelog: [Internal] Fabric-specific internal change.
This diff introduces a new value for `YGPositionType`: `YGPositionTypeStatic`.
No part of Yoga, RN, Litho or CK uses this value yet. `relative` and `static` values behave the same way for now. We also do not change any defaults. So, it should be fine.
Reviewed By: SidharthGuglani
Differential Revision: D22386732
fbshipit-source-id: 39cd9e818458ac2a91efb175f24a74c8c303ff08
Summary:
This PR is to fix https://github.com/facebook/react-native/issues/29279, which image cannot show in iOS 14
As https://github.com/facebook/react-native/issues/29279#issuecomment-658244428 mention, this issue can be fixed by calling ` [super displayLayer:layer];` it it is still image, to let `UIImageView` handle still image rendering
## Changelog
[iOS] [Fixed] - Fix image cannot show in iOS 14
Pull Request resolved: https://github.com/facebook/react-native/pull/29420
Test Plan:
Image can be shown in iOS 14 build with Xcode 12 beta, using
```js
<Image source={require('./images/some_local_image.jpg')}/>
```
It may also need to test gif image is render correctly
```js
<Image source={{uri: 'https://some_remote_gif_image.gif'}}/>
```
Reviewed By: p-sun
Differential Revision: D22619448
Pulled By: shergin
fbshipit-source-id: f4d0ad83af945a6b8099d4eaea5a5f1933c7bfd2
Summary:
As a part of the "Lean Core" effort we are moving many React Native open source modules into React Native. Through this task, we reduced the app size of all React Native applications!
For this task, I moved the ART iOS files to Facebook internal.
Changelog:
[iOS][Changed] - Moved ART iOS files from React Native to Facebook internal
Reviewed By: PeteTheHeat
Differential Revision: D22560856
fbshipit-source-id: 4ed982b0361fef3e875374b6c3df0204037c2bfa
Summary:
When stopSurface is called, Fabric might be processing a commit and performing measurements even as the context is being removed from the FabricUIManager map.
Just return a 0 from `measure` if we can't get a context. This prevents crashes during teardown for measured views that will never be visible anyway.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22604716
fbshipit-source-id: 67be8d272afd35fc4c2b51b371939c5623e97f73
Summary:
This diff fixes a ConcurrentModificationException that is thrown when registering events in React Native.
This bug was introduced by D22483508 (https://github.com/facebook/react-native/commit/80f13412e548c8666b6ad770e6d3d5c54a717bc2), before event listeners were registered in the NativeModule Thread, now they are registered in the UI Thread.
As part of this diff I change the type of mListeners variable to use CopyOnWriteArrayList instead of ArrayList because this variable is accessed from different threads. This will prevent the exception to happen, but additionally we need to verify if the change of threading made in D22483508 (https://github.com/facebook/react-native/commit/80f13412e548c8666b6ad770e6d3d5c54a717bc2) will cause any other issue (e.g. events not being delivered becuase the listeners are registered too late in the UI Thread)
changelog:[Internal]
Reviewed By: JoshuaGross
Differential Revision: D22599747
fbshipit-source-id: 5c5e46710c4a559badbd713f536e6e6e464fda23
Summary:
Apparently it's possible for `!isEmpty()` to be true and `peek` to be non-null, but for `poll()` to be false. It doesn't really make sense to me, and I don't have a repro, but that's what logs are showing.
I suspect a teardown race condition or /maybe/ a Fabric/non-Fabric handoff race condition. Neither of those make a ton of sense, though.
The mitigation is fairly straightforward: we are just much more cautious with how we treat the queue and assume everything could be null.
This impacts Fabric and non-Fabric equally.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D22593924
fbshipit-source-id: 7748121951a64941fa6da2bd25ebf070be6dc89c
Summary:
This appears to be the only usage of whitelist/blacklist in react-native-github, let's use some more inclusive language.
Changelog: [JS][Internal]
Reviewed By: kacieb
Differential Revision: D22539431
fbshipit-source-id: 21d4cd54a5a2a676996ccec7b02ef15c421efee1
Summary:
This diff refactors the destruction of the ReactInstanceManager when the app is experiencing low memory.
As part of this refactor, I setup an experiment to understand at what level of memory pressure is convenient to destroy the RN bridge.
The experiment is divided in six levels described in the following table:
https://pxl.cl/1dzx8https://www.internalfb.com/intern/qe2/fb4a_react_native_memory/android_fb4a_instance_unload_pressure_v2/setup
changelog: [internal] Internal
Reviewed By: JoshuaGross
Differential Revision: D22577553
fbshipit-source-id: 37f8f561099a1ba6239795f5907090ced3b5dd18
Summary:
This diff changes the InitialLifeCycleState used when initializing RN in FB4A from BEFORE_RESUME to BEFORE_CREATE.
The value of this field is used during the teardown of RN to determine if RN is actually running or not
The intention of this change is to represent the right behavior of RN during initialization, also this will allow RN to be turn down in case of memory pressure when the bridge has been initialized but before the user has navigated to a RN screen (preloading)
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D22577555
fbshipit-source-id: e54ef596cfe4429745611fe6022eb000051a93d0
Summary:
When a native module registers itself as a lifecycle event listener, ReactContext will immediately call `onHostResume` if the activity is already in a resumed state. We rely on this behavior for things like NativeAnimatedModule, which only enqueues the frame callback in onHostResume. However, ReactContext only does this if `hasActiveCatalystInstance()` returns true - which makes sense, because we don't want to notify listeners if the instance has been destroyed. But in bridgeless mode, `hasActiveCatalystInstance` returns false, and we never call `onHostResume` in this case.
This diff fixes an issue where native driver animations don't work the first time you navigate to a screen with bridgeless mode enabled.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22560314
fbshipit-source-id: 1a60cb482896308e21d6e438eb9a7314f580ad04
Summary:
Changelog:
[Internal] - Add an condition to exclude accessibilityRole that not currently used
Since I've added all the possible values in accessibilityRole enum, it is necessary to gate what needs to be an accessibilityElement. SO I add a condition to exclude accessibilityRole that not currently used.
Reviewed By: shergin
Differential Revision: D22559136
fbshipit-source-id: 910d59132984872b5a9816b8e390117b7b1e2e71
Summary:
Chrome recently changed schema from 'chrome-devtools' to just 'devtools',
this change updates Hermes inspector cli tool usage string to reflect that change
Changelog: Minor fix in Hermes Inspector cli tool help message
Reviewed By: dulinriley
Differential Revision: D22557806
fbshipit-source-id: 95ec9cbaac445e105e7e92aec2b6c4e5a7d7924f
Summary:
Here we use `TelemetryController` to instrument mounting transactions in RCTMoutingManagers and wire that with RCTMountingTransactionObserving protocol. Now, performance trackers (flags) that we use can obtain this information and report to some server-side infrastructure. (Which will be implemented in future diffs.)
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D22490581
fbshipit-source-id: 37695560437ae0e27845c3bda2030fe6fa4c6735
Summary:
This diff implements TelemetryController, a small tool that can be used to instrument mounting transactions. It abstracts the logic of merging telemetry data of multiple transactions in a thread-safe manner.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D22490580
fbshipit-source-id: 3f3425b88d38fddb555c1390fd8f1ff3ef1c475a
Summary:
SurfaceTelemetry data structure represents telemetry data associated with a particular running Surface. We need it to aggregate data from multiple mount transaction.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D22490579
fbshipit-source-id: e087aa9bc236af4da7010d67941f9ac93ad6da97
Summary:
There are potential race conditions in the old implementation that could result in operations being executed out-of-order when the user transitions between Fabric/non-Fabric screens.
Specifically, if the non-Fabric path queues up a batch of operations to execute on the next UI tick, it is possible that Fabric lifecycle events fire /before/ that next UI tick and synchronously execute a batch of animation operations on the UI thread, before their predecessors have executed.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22564633
fbshipit-source-id: 91c24547d5a682e61fc0c433302667330349a5f1
Summary:
`UIManagerHelper.getUIManager()` relies on the bridge (CatalystInstance) to get the proper UIManager depending on which renderer is being used. Unfortunately, this means it will always return null in bridgeless mode, where the CatalystInstance doesn't exist. This diff replaces the implementation of `BridgelessReactContext.getJSIModule()` to return the FabricUIManager from the ReactHost/Instance.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22480968
fbshipit-source-id: 640e3f22a5b39b315ed2f0397be3cba39e80529a
Summary:
In Fabric if you use a Pressable or PressableBackground and only provide an `onPress` but don't provide background color or anything else, the View might be flattened away and with it the event handlers.
We assume that if the product engineer is using a Pressable, they want it to do something in the View hierarchy, so force it to never be flattened.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D22557026
fbshipit-source-id: 171c5b51e8d828fbb2816685d188286179a10af9
Summary:
Changelog:
[Internal][Fixed] - Fix the accessibilityRole crash
I only assigned three values that would be used for embedded links inside text (button, link, image). But the accessibilityRole has a lot of values that may be applied in other places. (https://reactnative.dev/docs/accessibility) To avoid this crash, need to add all possible values to the enum.
Reviewed By: JoshuaGross, shergin
Differential Revision: D22549264
fbshipit-source-id: dbaacf1965624e1d2eabe193b46168c6c8740f46
Summary:
1, Fix the redbox on Pokes route when running Metro with Venice enabled.
2, Fix CrashReactRoute stucking with the loading indicator issue.
Changelog: [Internal]
Reviewed By: ejanzer
Differential Revision: D22477500
fbshipit-source-id: 65e908ac360e031e5f3562a21c09cb0d7ddaf7a0
Summary:
Changelog:
[Internal] - Revert "Change the accessibilityRole from a string to an enum."
Original commit changeset: b46ce0bd156c
Reviewed By: PeteTheHeat
Differential Revision: D22540391
fbshipit-source-id: df4a62c7bb4525782121dea2c70a9101cf0d8e9f
Summary:
Now Yoga.cpp does not use the `YGPositionTypeRelative` value/constant, it uses `YGPositionTypeAbsolute` instead.
Now `YGPositionType` can only be `YGPositionTypeRelative` or `YGPositionTypeAbsolute`, so expressions `x == YGPositionTypeRelative` and `x != YGPositionTypeAbsolute` are equivalent.
The reasoning behind the change is that in all cases we actually check a node to be (or not to be) `absolute`, not `relative`. This will make a difference in the coming diffs in the stack when we will introduce a new value for the type: `static`.
We need to differentiate `static` and `relative` values t implement the `stacking context` feature in the W3C-compliant way (to fix bugs and avoid developer confusion). Read more here:
https://developer.mozilla.org/en-US/docs/Web/CSS/position
Changelog: [Internal] Internal change in Yoga.
Reviewed By: SidharthGuglani
Differential Revision: D22386733
fbshipit-source-id: 8e2c2b88b404660639f845783c8f93f0c62c0fbb
Summary:
…eption
This is a minor change in `DebugCorePackage.getModule()` method that corrects the `IllegalArgumentException`'s error message, which was probably copy-pasted from `CoreModulePackage`.
## 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
-->
[Android] [Fixed] - Fixed error message in DebugCorePackage.getModule
Pull Request resolved: https://github.com/facebook/react-native/pull/29304
Test Plan: No tests needed.
Reviewed By: RSNara
Differential Revision: D22521091
Pulled By: mdvacca
fbshipit-source-id: 19205f9beb0fc26249985ce2c865e284c4a4add1
Summary:
During setup, TurboModules may synchronously dispatch to the main queue, if they require main queue setup. This is dangerous because it could cause the app to deadlock during TurboModule require. This is why D21654637 (https://github.com/facebook/react-native/commit/e206e34175c091a753c0e733abeda41b662241d4) added a warning aginst this. However, this diff had a mistake. We only want to display the warning if TurboModule eager initialization is enabled, because then, we can eagerly initialize the TurboModules before the bridge starts to avoid the problem. D21654637 (https://github.com/facebook/react-native/commit/e206e34175c091a753c0e733abeda41b662241d4) instead showed the warning if TurboModule eager init **wasn't** enabled. This isn't useful, because there's no way to avoid the problem with TurboModu eager initialization off.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D22529780
fbshipit-source-id: 15238483758b66b1a6addcad948203c64dca96ad
Summary:
This fixes https://github.com/facebook/react-native/issues/28481. As explained in [this comment](https://github.com/facebook/react-native/issues/28481#issuecomment-645546195), the flipper network plugin pulls a more recent version of okhttp (3.14), but only versions of okhttp up to 3.12 works on Android API 21 and less.
This prevented being able to run the app in debug mode, it was still working fine in release mode.
## 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
-->
[Android] [Fixed] - Fix unable to run in debug mode on Android API < 21
Pull Request resolved: https://github.com/facebook/react-native/pull/29260
Test Plan:
Using `yarn react-native run-android` the app would instantly crash with this error in `adb logcat`:
```
E/AndroidRuntime( 5079): java.lang.RuntimeException: Unable to create application com.awesometsproject.MainApplication: java.lang.RuntimeException: Requested enabled DevSupportManager, but DevSupportManagerImpl class was not found or could not be created
E/AndroidRuntime( 5079): at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4154)
E/AndroidRuntime( 5079): at android.app.ActivityThread.access$1300(ActivityThread.java:130)
E/AndroidRuntime( 5079): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1255)
E/AndroidRuntime( 5079): at android.os.Handler.dispatchMessage(Handler.java:99)
E/AndroidRuntime( 5079): at android.os.Looper.loop(Looper.java:137)
E/AndroidRuntime( 5079): at android.app.ActivityThread.main(ActivityThread.java:4745)
E/AndroidRuntime( 5079): at java.lang.reflect.Method.invokeNative(Native Method)
E/AndroidRuntime( 5079): at java.lang.reflect.Method.invoke(Method.java:511)
E/AndroidRuntime( 5079): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:786)
E/AndroidRuntime( 5079): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:553)
E/AndroidRuntime( 5079): at dalvik.system.NativeStart.main(Native Method)
E/AndroidRuntime( 5079): Caused by: java.lang.RuntimeException: Requested enabled DevSupportManager, but DevSupportManagerImpl class was not found or could not be created
E/AndroidRuntime( 5079): at com.facebook.react.devsupport.DevSupportManagerFactory.create(DevSupportManagerFactory.java:90)
E/AndroidRuntime( 5079): at com.facebook.react.ReactInstanceManager.<init>(ReactInstanceManager.java:238)
E/AndroidRuntime( 5079): at com.facebook.react.ReactInstanceManagerBuilder.build(ReactInstanceManagerBuilder.java:281)
E/AndroidRuntime( 5079): at com.facebook.react.ReactNativeHost.createReactInstanceManager(ReactNativeHost.java:87)
E/AndroidRuntime( 5079): at com.facebook.react.ReactNativeHost.getReactInstanceManager(ReactNativeHost.java:39)
E/AndroidRuntime( 5079): at com.awesometsproject.MainApplication.onCreate(MainApplication.java:47)
E/AndroidRuntime( 5079): at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:999)
E/AndroidRuntime( 5079): at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4151)
E/AndroidRuntime( 5079): ... 10 more
E/AndroidRuntime( 5079): Caused by: java.lang.reflect.InvocationTargetException
E/AndroidRuntime( 5079): at java.lang.reflect.Constructor.constructNative(Native Method)
E/AndroidRuntime( 5079): at java.lang.reflect.Constructor.newInstance(Constructor.java:417)
E/AndroidRuntime( 5079): at com.facebook.react.devsupport.DevSupportManagerFactory.create(DevSupportManagerFactory.java:80)
E/AndroidRuntime( 5079): ... 17 more
E/AndroidRuntime( 5079): Caused by: java.lang.NoClassDefFoundError: java.util.Objects
E/AndroidRuntime( 5079): at okhttp3.CertificatePinner.withCertificateChainCleaner(CertificatePinner.java:231)
E/AndroidRuntime( 5079): at okhttp3.OkHttpClient.<init>(OkHttpClient.java:238)
E/AndroidRuntime( 5079): at okhttp3.OkHttpClient$Builder.build(OkHttpClient.java:1015)
E/AndroidRuntime( 5079): at com.facebook.react.devsupport.DevServerHelper.<init>(DevServerHelper.java:132)
E/AndroidRuntime( 5079): at com.facebook.react.devsupport.DevSupportManagerImpl.<init>(DevSupportManagerImpl.java:183)
E/AndroidRuntime( 5079): ... 20 more
W/ActivityManager( 1456): Force finishing activity com.awesometsproject/.MainActivity
```
With this fix, the app launch successfully in debug mode, without having to remove flipper altogether from our config.
Reviewed By: passy
Differential Revision: D22521109
Pulled By: mdvacca
fbshipit-source-id: 3c0263642438bd7c0d09b045e15a933bd8a26734
Summary:
Changelog:
[Internal] - Reword the guide words to make it more generic.
Considering the case that some languages are RTL so swiping right cannot guarantee to move to the link. iOS can handle the order of the words and accessibilityElements according to the language. But the accessibilityHint we hardcoded would be an issue. So we decided to reword it to be more generic.
Reviewed By: PeteTheHeat
Differential Revision: D22422498
fbshipit-source-id: 175711317961663d0b0b47e04d2ab600f63446fe
Summary:
Changelog:
[Internal] - Change the accessibilityRole from a string to an enum.
The change aims to save storage especially when scaling. Also, the enum makes it more difficult to input wrong because it gets checked when compiling.
Reviewed By: sammy-SC
Differential Revision: D22396351
fbshipit-source-id: b46ce0bd156c7705020ef5b061d8ac29e2cf3948
Summary:
Changelog:
[Internal] - Add a `accessibilityHint` to the first accessibilityElement so that it will tell user double tap to expand or truncate the text after reading the whole text. Also add the `accessibilityRole` in `FBTextWithEntities` when shouldTruncated is true, which allow us to specially distinguish the shouldTruncated text.
Reviewed By: sammy-SC
Differential Revision: D22339875
fbshipit-source-id: ce22fe9d86eeba5a2750022acd2cdd2c06a1dc79
Summary:
Refs https://github.com/facebook/react-native/issues/28711
This PR moves Hermes badge component from the template to the `NewAppScreen` library. The main motivation behind this change was to simplify a bit template code.
I assumed that it is not important to expose `global.HermesInternal` to the template users:
* If this assumption is true, I think that there are no other reason to leave this component inside `App` in comparison to other `NewAppScreen` components,
* If this assumption is false, I can adjust this PR and move `HermesInternal` check from the badge component to the `App`.
I was trying to avoid calling `useColorScheme` when Hermes is disabled, but placing hook inside the conditional branch causes ESLint warning (react-hooks/rules-of-hooks).
This PR includes also small style tweaks for the badge - since there are no background padding can be omitted and spacing can be added adjusted tweaking `top` and `left` properties and `fontSize` has been adjusted just for the readability.
In the last commit, I have gone a bit further and moved `HermesBadge` to the `Header` component and I have also changed slightly the `Header` title (React -> React Native) and it's styling.
> I'm not sure if after this change `HermesBadge` export in `NewAppScreen` components list is still required, but maybe this badge will be useful for someone. If it's a mistake I can update the PR and remove this export.
## Changelog
[Internal][Changed] move Hermes badge from the template to the NewAppScreen library
Pull Request resolved: https://github.com/facebook/react-native/pull/28783
Test Plan:
Template app do not redbox on Android emulator with and without Hermes enabled.
## Preview
Android with Hermes enabled and adjusted header:
iOS with adjusted header:
Reviewed By: GijsWeterings
Differential Revision: D22493822
Pulled By: cpojer
fbshipit-source-id: 3440e10f2d59f268ca8851a6e002f0ff23fa839c
Summary:
The `eslint-plugin` package intent notice at the top of the README mistakenly refers to itself, it should instead refer to `react-native-community/eslint-config`
## Changelog
[Internal] [Fixed] - Fix typo in `eslint-plugin` README
Pull Request resolved: https://github.com/facebook/react-native/pull/29337
Test Plan: 1. ensure link works properly
Reviewed By: GijsWeterings
Differential Revision: D22493834
Pulled By: cpojer
fbshipit-source-id: 16b8173d3c2add7a85e142eac4ab36aef685062b
Summary:
Changelog: [Internal]
When calling "measure" on ScrollView's children, origin needs to be adjusted for ScrollView's content offset.
For this scrollView uses `getTransform` to adjust frames of its children.
This is wrong because transform is applied to ScrollView as well.
Example:
ScrollView is scrolled 900 points and its origin is {0, 0}, if you call "measure" on the ScrollView, our current measure infra will report its origin being {0, 900}.
Reviewed By: shergin
Differential Revision: D22456266
fbshipit-source-id: 6fd54661305ad46def8ece93fcf61d66817b3e01
Summary:
Fixed tests related to changing Jest's fake timer behavior.
And some of the test code in LogBoxData-test.js itself was incorrect so I am fixing it.
LogBoxData-test.js fails when I try to build a new local development environment and fork the React Native source to run a JavaScript test.
The error message is:
runAllImmediates is not available when using modern timers
After checking, runAllImmediates could not be used with the following modification.
https://github.com/facebook/jest/commit/71631f6bf9ccf8937f02a5ecfb64b62712b86c19
## Changelog
[Internal] [Fixed] - Test fixes related to changes in Jest's Fake Timer behavior
Pull Request resolved: https://github.com/facebook/react-native/pull/29011
Test Plan: Ran JavaScript Tests locally.
Reviewed By: cpojer
Differential Revision: D22494991
Pulled By: rickhanlonii
fbshipit-source-id: 4deeaf82b5092ff8b60c4606eb45549beb452a5f
Summary:
TurboModuleManager can emit the following events:
- JS Require Beginning
- JS Require Ending
- Module Create (for C++-only TurboModules)
This diff instruments JS Require beginning, and JS Require ending. It also serves as a good stopgap to verify that TurboModule perf logging is set up correctly.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22485529
fbshipit-source-id: a41b88b56627ad2bbcaadac87bf9d530bf07ae81
Summary:
We need to instrument the following markers for TurboModules in Java:
- **Java:** moduleDataCreate
- **Java:** moduleCreate
**Problem:** Perf-logging can be on or off in production. This means that we have to guard every perf-logger call, which can be a bit tedious. Therefore, this diff introduces a Java class called `TurboModulePerfLogger`, which:
1. Enables perf-logging by accepting a `NativeModulePerfLogger` `jni::HybridObject` in its `enableLogging` method.
2. Exposes static methods that call into the `NativeModulePerfLogger`'s Java part, when perf-logging is enabled.
We actually have C++ markers as well:
- **C++:** moduleJSRequireBeginning
- **C++:** moduleJSRequireEnding
- **C++:** syncMethodCall
- **C++:** asyncMethodCall
- **C++:** asyncMethodCallExecution
Therefore, `TurboModulePerfLogger.java` also calls its native method `jniEnableCppLogging` to setup C++ TurboModule perf-logging.
TurboModule C++ logging is done via a similar setup (to Java), using `TurboModulePerfLogger.cpp`. The `jniEnableCppLogging` native method calls into `TurboModulePerfLogger::enableLogging` with the C++ part of `NativeModulePerfLogger`. Then, the TurboModules C++ infra uses the static methods on `TurboModulePerfLogger.cpp` to start/end markers.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D22444246
fbshipit-source-id: 66f191056cdcf5d7932ff1916a1de70b82e5f32b
Summary:
## Description
This diff introduces `NativeModulePerfLogger.java`, the Android extension (a `jni::HybridClass`) to `NativeModulePerfLogger`.
### Why is this a Hybrid class?
Because we have C++ and Java markers, and the perf-logger has both a Java and a C++ interface that the application must implement. `jni::Hybrid` classes are a convenient solution for these constraints.
Changelog:
[Android][Added] - Introduce JNativeModulePerfLogger
Reviewed By: ejanzer
Differential Revision: D21318052
fbshipit-source-id: 2f43853b243fa2a629068bb4aced1e3f12f038ba
Summary:
See videos. In some cases when an `Animated.timing` animation was triggered, there are not necessarily any corresponding Fabric commits. This causes the animations to be queued up but never execute... until there's some Fabric commit at a distant point in the future.
We can't immediately flush all animation operations (see inline comments) but we also shouldn't wait forever. Thus, we wait 2 frames and then flush.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22490650
fbshipit-source-id: 1669bfed00f2a92b50f9558fc7ccaf71dc636980
Summary:
Expose `resolveCustomDirectEventName` from UIManager interface for Bridgeless Mode+NativeAnimatedModule.
We cannot remove the interface from the Non-Fabric UIManagerModule yet, as it would break downstream open-source dependencies, so I just marked it deprecated.
Note that this still doesn't totally fix issues with Bridgeless mode: generally I have to navigate to a Bridgeless surface, exit it, and then navigate back, and only on the 2nd navigation does everything seem to work properly...
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22483508
fbshipit-source-id: 685126e7e51aa5d0fd60ad5d4ecc44e8c6c3029d
Summary:
The previous assumption was that any animations would result in `addAnimatedEventToView` being called. That's not true in all cases, so sometimes we never subscribed to Fabric lifecycle events, preventing animations from working on some screens and for Venice.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22483509
fbshipit-source-id: c97576675902b4b9e1d4e659c7c1e24c5fe92946
Summary:
Replace react-test-renderer/shallow with react-shallow-renderer.
We should follow up with teams to remove these tests because they will no longer be supported. I would have just removed them but test like `BillingReauthorizeCreditCardContainer-test` seem important.
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D22225642
fbshipit-source-id: a6bd559311422cb14576a574165ed7dc0279919d
Summary:
Disabling Detox tests on Circle CI as the `test_ios_detox*` tests have been broken for a while.
Changelog:
[Internal]
Test Plan: Verified these no longer trigger on Circle CI
Reviewed By: cpojer
Differential Revision: D22476861
Pulled By: hramos
fbshipit-source-id: 3d46786cd7d088d363409e4d35a327e3e997a227
Summary:
Changelog: [Internal]
Add view hierachy drawings to tests to make it easier to picture view hierarchy.
The sketches do not reflect sizing but relationship among the views.
I removed unnecessary reset of transform value to identity matrix.
Reviewed By: JoshuaGross, shergin
Differential Revision: D22456267
fbshipit-source-id: 480d0b938ffd0281fc94148570c412b0fcc22f42
Summary:
BubblingEventTypes are inconsistent between AndroidTextInputViewConfig.js and ReactTextInputManager.java, this diff fixes this inconsistency
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D22470096
fbshipit-source-id: 3940dcc0ae67a42ac070c06ec2d54bc365eab6b7
Summary:
Commits can happen during navigation/teardown which creates mount items. If we throw an exception during
teardown because we expect the Context to still be around, we crash too often. Instead, I will rely on
logic in FabricUIManager to ignore queued MountItems if we try to execute them after the surface has been torn down;
and we move the IllegalStateException to actual execution of the mount item in case there's an edge-case we're missing.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22470102
fbshipit-source-id: ad98c03994969a3c3f300d6551e90b6516ed2d8b
Summary:
TurboModule eager initialization is a bit dangerous if we get it wrong, which we did (twice): T69449176.
This diff gates TurboModule eager init behind a MC, so that we can control (i.e: turn off/on, and do gradually rollout of) TurobModule eager initialization in isolation from the larger TurboModules experiment.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D22460359
fbshipit-source-id: 3b8dce0529f1739bd68b8b16d6a28aa572d82c2c
Summary:
Replaces `fbjs/performanceNow` call sites in React Native with `performance.now`.
We did not originally polyfill this in `InitializeCore`, but now we do (and back it with a proper `nativePerformanceNow` implementation). Also, added the missing polyfill to our Jest setup.
Changelog:
[Internal]
Reviewed By: cpojer
Differential Revision: D22445948
fbshipit-source-id: dcfd9867c050617f6e2a3d0a1eb6f48a44771dda
Summary:
When you call `LogBox.ignoreAllLogs()` it should ignore logs.
This fixes a bug that made this equivalent to `LogBox.ignoreAllLogs(false)`
## Changelog
[General] [Fixed] - LogBox.ignoreAllLogs() should ignore logs
Pull Request resolved: https://github.com/facebook/react-native/pull/29310
Test Plan: Added tests
Reviewed By: TheSavior
Differential Revision: D22448436
Pulled By: rickhanlonii
fbshipit-source-id: 6ba12b9d9c1f29cf3ac503946ac5ca0097425a7a
Summary:
When you require a TurboModule on thread that isn't the main thread, but the TurboModule requires main queue setup, we are forced to `dispatch_sync` the set up to the main queue. This is hazardous, because it can lead to deadlocks. Therefore, I'm migrating over a warning from the legacy infra that warns against this use-case.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D21654637
fbshipit-source-id: 99dc45708c533603d2111fe6163d40e807d2a513
Summary:
This PR adds support for the `shadowColor` style on Android.
This is possible as of Android P using the `setOutlineAmbientShadowColor` and `setOutlineSpotShadowColor` View methods. The actual rendered color is a multiplication of the color-alpha, shadow-effect and elevation-value.
## Changelog
`[Android] [Added] - Add support for shadowColor on API level >= 28`
Pull Request resolved: https://github.com/facebook/react-native/pull/28650
Test Plan:
- Only execute code on Android P
- Added Android `BoxShadow` tests to RNTester app
Reviewed By: mdvacca
Differential Revision: D21125479
Pulled By: shergin
fbshipit-source-id: 14dcc023977d7a9d304fabcd3c90bcf34482f137
Summary:
The changes in this diff are inconsequential. Just thought it was weird that TurboModuleManager was responsible for assigning itself to the bridge. Seems like that should be done by an entity that owns both the bridge and the TurboModuleManager.
Changelog:
[Internal]
Reviewed By: PeteTheHeat
Differential Revision: D22406172
fbshipit-source-id: cb32f097f4d377a3b85a6d165b7b06be8e6a185b
Summary:
## Why?
1. RCTTurboModuleLookupDelegate sounds a bit nebulous.
2. In JS and Java, we use a `TurboModuleRegistry` interface to require TurboModules. So, this diff will make JS, Java, and ObjC consistent.
Changelog:
[Internal]
Reviewed By: PeteTheHeat
Differential Revision: D22405754
fbshipit-source-id: 30c85c246b39d198c5b8c6ca4432a3196ca0ebfd
Summary:
## Context
1. In FBReactModule jsExecutorForBridge, we asynchronously initialize a list of TurboModules on the main queue: https://fburl.com/diffusion/i56wi3px
2. After initializing the bridge, we start executing the JS bundle, here: https://github.com/facebook/react-native/blob/e23e9328aa164d0a70fe4f16042c982e7801d924/React/CxxBridge/RCTCxxBridge.mm#L414-L417. Since bridge initialization knows nothing about TurboModule eager initialization, this happens concurrently with 1, and starts requiring NativeModules/TurboModules on the JS thread.
## The Race
1. Both the main thread and the JS thread race to create a TurboModule that requires main queue setup.
2. The JS thread wins, and starts creating the TurboModule. Meanwhile, the main thread blocks, waiting on a signal here, in RCTTurboModuleManager: https://github.com/facebook/react-native/blob/e23e9328aa164d0a70fe4f16042c982e7801d924/ReactCommon/turbomodule/core/platform/ios/RCTTurboModuleManager.mm#L430
3. The JS thread tries to dispatch_sync to the main queue to setup the TurboModule because the TurboModule requires main queue setup, here: https://github.com/facebook/react-native/blob/e23e9328aa164d0a70fe4f16042c982e7801d924/ReactCommon/turbomodule/core/platform/ios/RCTTurboModuleManager.mm#L402
4. We deadlock.
## The fix
Succinctly, NativeModule eager initialization finishes before execute the JS bundle, but TurboModule initialization doesn't. This diff corrects that mistake.
The changes in this diff:
1. The RN application via the TurboModuleManager delegate can now optionally provide the names of all eagerly initialized TurboModules by implementing two methods `getEagerInitModuleNames`, `getEagerInitMainQueueModuleNames`.
2. The TurboModuleManager grabs these two lists from the delegate, and exposes them to its owner via the `RCTTurboModuleRegistry` protocol.
3. The RCTCxxBridge, which already owns a `id<RCTTurboModuleRegistry>` object, uses it to eagerly initialize the TurboModules in these two lists with the correct timing requirements.
This is exactly how we implement eager initialization in Android.
**Note:** Right now, phase one and two of TurboModule eager initialization happen after phase one and two of NativeModule eager initialization. We could make the timing even more correct by initializing the TurboModules at the exact same time we initialize the NativeModules. However, that would require a bit more surgery on the bridge, and the bridge delegate. I think this is good enough for now.
Changelog:
[iOS][Fixed] - Fix TurboModule eager init race
Reviewed By: PeteTheHeat
Differential Revision: D22406171
fbshipit-source-id: 4715be0bceb478a8e4aa206180c0316eaaf287e8
Summary:
`RCTModuleData gatherConstants` is [used by `RCTModuleData exportedConstants` to compute and return the constants exported to JS](https://fburl.com/diffusion/ssg4jbeu). However, `RCTModuleData gatherConstants` is also [used by `RCTCxxBridge` to pre-compute NativeModule constants during bridge startup](https://fburl.com/diffusion/nfmjc1ke). Therefore, since `RCTModuleData gatherConstants` can be used outside the context of a JS require, we cannot start the JSRequireEnding marker inside `RCTModuleData gatherConstants` directly.
This diff moves the body of `RCTModuleData gatherConstants` into `gatherConstantsAndSignalJSRequireEnding:(BOOL)startMarkers`:
- `RCTModuleData gatherConstants` calls `RCTModuleData gatherConstantsAndSignalJSRequireEnding:NO`
- `RCTModuleData exportedConstants` calls `RCTModuleData gatherConstantsAndSignalJSRequireEnding:YES`. **Note:** This is okay, because `RCTModuleData exportedConstants` is only called inside `RCTNativeModule::getConstants()`.
This should make sure that we don't start the JSRequireEnding marker outside of a JS require.
Reviewed By: PeteTheHeat
Differential Revision: D22371889
fbshipit-source-id: de17b857259572fb0f840a22072a16b5e465cabd
Summary:
Currently the `remove` API returns an owned unique_ptr of the removed ShadowTree but it's not used anywhere, so we can simplify the API.
Because of that change, we can make the API safe even if the SurfaceId has already been removed.
For context, on Android there is a race between RootView.unmountReactApplication and C++ teardown which removes all SurfaceIds. This currently causes a crash, but after this diff the 2nd call to `remove` for a given SurfaceId will noop.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D22416471
fbshipit-source-id: dbba44c276aab8e81097b92a89e0becdcb7b28ba
Summary:
This diff inlines all mount-instruction functions into a single one - RCTPerformMountInstructions.
The main purpose is to reduce the number of calls to `RCTComponentViewRegistry` for some instructions. E.g., before the change, the `Insert` (or `Update`) instruction had seven identical calls to the registry. That's not a huge deal but there is no need to pay for it either. Maybe it can save us a couple of milliseconds during TTI.
The code of those functions is quite straight-forward, so this change probably even improves readability.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D22402987
fbshipit-source-id: 043a4114ba42622e9ed226f4d5e41ed45c1b066c
Summary:
We are about to add several additional functions to this file, so we need to split it to keep it manageable. All changes in this diff are cosmetical.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D22384429
fbshipit-source-id: d22592fba17ef04edb44388b4e1ff22112e9c020
Summary:
This moves ios CameraRoll files from React Native open source into FB internal as part of the Lean Core effort.
Changelog: [Breaking][ios] Remove CameraRoll from React Native
Reviewed By: cpojer
Differential Revision: D22208352
fbshipit-source-id: 894d6aff34ece94648dad68060c13b44974c93bb
Summary:
Changelog:
[Internal] - Add `accessibilityRole` to `RCTAttributedTextUtils`. AccessibilityRole was in `TextAttributes` which is a Fabric's abstraction so cannot be detected when enumerating attributedString. Mapping accessibilityRole from `TextAttributes` to `NSAttributedString` could provide the attributeName when iterating over attributedString and then successfully find the range of the fragment whose `accessibilityRole` has value @"link".
Reviewed By: shergin
Differential Revision: D22286747
fbshipit-source-id: eb039d6a35e77d1860f86ba287391ccb56fbe7b5
Summary:
Changelog:
[iOS][Added] - `getRectWithAttributedString()` aims to get the rect of the fragment with embedded link, which is necessary when building the `accessibilityElement`. In this function, we first enumerate attributedString to find the range of fragments whose `accessibilityRole` is @"link". Then we calculate the rect of the fragment and send to the block and we would define what to do in the block in `RCTParagraphComponentAccessibilityProvider`.
Reviewed By: shergin
Differential Revision: D22286733
fbshipit-source-id: 4d11cb54375a4e9e72869e646fcb484de089b14b
Summary:
Changelog:
Adding packager running check when RCTBundleURLProvider is returning JSLocation, this prevents an invalid address from being returned which might cause various issues.
Reviewed By: cpojer
Differential Revision: D22390156
fbshipit-source-id: a20dbf63103158a34cbf6dc0ae8349b2f9e5b0a8
Summary:
This refined algorithm now takes a zoom/scale into account and deals with `contentInset` properly.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D22382482
fbshipit-source-id: 7e9d34d3bababf68e624c045c308957e7e5c9d84
Summary:
Changelog: [Internal]
When JS Inspector is activated, ScrollView is unmounted and then mounted again with same state.
ScrollView's content offset was being set to 0 inside `[RCTScrollViewComponentView prepareForRecycle]` during unmount but when it is mounted again, we ignored value inside state.
Reviewed By: shergin
Differential Revision: D22333125
fbshipit-source-id: f232dc95b695605f4819f29d8e0bf14b2f3e9150
Summary:
Pet Peeve: Metro is a brand name. You don't say "the Metro server" just like you don't say "the iPhone phone". This is a leftover from when it used to be called "the packager server".
Note: It makes sense to refer to "the Metro server" when talking about it in the context of Metro's features, like if you are discussing "Metro's bundling" and "Metro's server". However, when talking about the tool itself, just Metro is enough.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D22330966
fbshipit-source-id: 667618363c641884df543d88cac65d1e44956ad3
Summary:
ART has been moved out of OSS, but I created the fabric implementation in github repo, this diff migrates the Fabric ART implementation to FB repository again
changelog: [Internal]
Reviewed By: shergin
Differential Revision: D22352930
fbshipit-source-id: 1125d3f27b98be783529134de0d3fbcf1b01a6f4
Summary:
Changelog:
[Internal] - The accessibilityRole will be used to specially distinguish normal fragments and fragments with embedded link, which is helpful when building accessibilityElement.
According to this document: https://reactnative.dev/docs/accessibility, the accessibilityRole is a common accessibility props that could be inherited, and this is why I add accessibilityRole to the TextAttributes.
Reviewed By: sammy-SC
Differential Revision: D22249140
fbshipit-source-id: 408b4415bf44539d8671d3d98f1ec06f8035baf6
Summary:
Changelog: [Internal]
FindNoteAtPoint takes transformations into account. There is however a problem with how transformation in ScrollView. In ScrollViewShadowNode, getTransform is overriden. In the override we apply `Transform::Translate(-contentOffset.x, -contentOffset.y, 0)`, this means that ScrollView has moved by {-x,-y}. However this is only true for its children, not for scroll view itself. This trips off findNodeAtPoint and if you scroll more than than screen's height, point will not be evaluated as inside ScrollView.
Until we can figure out how to deal with this properly, I think it is better to disable it as usage of JS Inspector is more common in ScrollViews than it is with transformed views.
Reviewed By: shergin
Differential Revision: D22332779
fbshipit-source-id: f48c9ae67a595e6954c2b70fb287db7f8c74378b
Summary:
Changelog:
[iOS][Added] - This is the first step to build RCTParagraphComponentAccessibilityProvider. The main idea of RCTParagraphComponentAccessibilityProvider is to provide an array of accessible elements for the AttributedString in PCTParagraphComponentView.
Reviewed By: sammy-SC
Differential Revision: D22214855
fbshipit-source-id: 69d47555e86452620f89a4b2e21ed6065c8e669c
Summary:
This was an experiment that never shipped. In the meantime we built Fast Refresh which obviates the need to complicate how we load and store bundles on device.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D22330994
fbshipit-source-id: 5a623b2611dd2622f17dd83ed35ef05c3100e40d
Summary:
**Motivation:**
Match the old codegen's behavior when generating structs for type alias derived objects.
**Problem description:**
Take, for example, the following spec:
```
export type MyTypeAlias = { /* ... */ }
export interface Spec extends TurboModule {
// ...
+myMethod: (paramName: MyTypeAlias) => void;
// ...
}
```
The codegen needs to generate a struct to expose the properties of the type alias object. The codegen was producing the following output:
```
- (void)myMethod:(JS::MyModule::SpecMyMethodParamName &)paramName;
```
...which does not match the output from the original codegen:
```
- (void)myMethod:(JS::MyModule::MyTypeAlias &)paramName;
```
The original codegen generates a struct using the type alias name, while the new codegen was generating a struct that uses a combination of the property and parameter names.
Now that type alias names are exposed in the schema, the new codegen can match the original codegen's behavior.
**De-duplication of structs:**
Prior to these changes, type aliases were expanded into regular object types. This meant that any spec that used a type alias more than once would lead to redundant structs getting created. With these changes, we only generate the one struct per type alias, matching the old codegen.
**Expansion of type aliases:**
A new type was introduced in D22200700 (https://github.com/facebook/react-native/commit/e261f022fe6a7653b79330f878fed143725f5324), TypeAliasTypeAnnotation:
```
export type TypeAliasTypeAnnotation = $ReadOnly<{|
type: 'TypeAliasTypeAnnotation',
name: string,
|}>;
```
This type may now appear in several locations where a `{| type: 'ObjectTypeAnnotation', properties: [] |}` otherwise would have been used. A `getTypeAliasTypeAnnotation` function is introduced which, given an alias name and an array of aliases provided by the module, will produce the actual object type annotation for the given property parameter.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D22244323
fbshipit-source-id: 125fbf0d6d887bd05a99bf8b81b30bdda4f1682b
Summary:
Build `FBReactNativeSpec.h` and `FBReactNativeSpec-generated.mm` using the new codegen script whenever the workspace is created using CocoaPods if the `USE_CODEGEN` envvar is set to 1.
Effectively makes use of the new codegen integration in CocoaPods opt-in.
The `USE_CODEGEN` envvar check should be removed when the generated files are removed from source control, at which point use of the new codegen in CocoaPods will be necessary.
```
cd RNTester
USE_CODEGEN=1 pod install
```
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D22250128
fbshipit-source-id: 8f06bf1424ca2e003ecfd032ec03d7896569f9bd
Summary:
This introduces a new shadow node trait (`Hidden`) which disables emitting ShadowVides for such nodes and all their descendants.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D22134220
fbshipit-source-id: 8ea1fc3186019005ad687eacaca0ba4a4d8343dc
Summary:
The change contains a bunch of additional asserts that verify some assumptions on which mounting relies on. Working on the previous diffs I realized that it's very easy to broke those and then spend hours trying to understand what exactly went wrong.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D22324087
fbshipit-source-id: 1152c40248885d02bde62a493a574868c3732273
Summary:
In RN 0.62 support for `fontVariant` was added on Android.
Using that prop crashes the app on Android below KitKat (4.3 and below)
To reproduce just add any Text with the `fontVariant` styling prop in the app:
```js
<Text style={{fontVariant: ['tabular-nums']}}>This will crash</Text>
```
It will crash any device running Android below KitKat with the error:
This is caused by `java.utils.Objects` only being available on Android 4.4+
## Changelog
[Android] [Fixed] - Fix font variant crash on Android < 4.4
Pull Request resolved: https://github.com/facebook/react-native/pull/29176
Test Plan:
[TextUtils.equals](https://developer.android.com/reference/android/text/TextUtils#equals) was added as soon as API level 1, so no compatibility issue here.
Tested on Emulator running Android 4.1, no crash anymore.
I've searched for other occurences of `java.utils.Objects` in the project, and this was the only one, so no need to remove other occurences ✅
Reviewed By: JoshuaGross
Differential Revision: D22337316
Pulled By: mdvacca
fbshipit-source-id: 5507b21b237a725d596d47b5c01e269895b16d4a
Summary:
This is the first implementation stage of on-demand child views mounting for <ScrollView> feature.
It works this way. When mounting layer requests mounting of a subview of <ScrollView>, the component does not mount it immediately. Instead, it stores it in an internal collection, and then after the transaction finishes use that to mount views that are in a visible area.
Then we re-evaluate which child views are should be mounted and unmounted on every significant onScroll event. We use some leeway to do it not so often to save CPU cycles on scrolling.
This feature already works fine but to make it shippable we need to integrate it with an `overflow inset` feature to make it 100% reliable in complex cases when some views have overflow content.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D22304012
fbshipit-source-id: be4ae21378d9d1c457cad2826da7d8c8d6395be5
Summary:
In https://github.com/facebook/react-native/commit/0b63c9464872fed9ff3eb388e32850f2f8c69561, I shipped "Early ViewCommand Dispatch" everywhere but didn't provide a good summary in the commit message.
Here it is:
The "Early ViewCommand Dispatch" experiment was a success, leading to improved UI responsiveness and fewer overall crashes.
Ship to all Fabric and non-Fabric users, and clean up the code a bit.
# Context: what?
ViewCommands are now used in React Native to do things like scroll ScrollViews to a certain position; focus or blur a TextInput; control the value of controlled TextInputs; and much more. These used to be done using setNativeProps, but we're moving everything to ViewCommands, and most of that migration has already finished.
# Context: Why?
Because Fabric does not support setNativeProps, there has been an effort to move all setNativeProps callsites to ViewCommands. Since these callsites are in JS where we can't tell if we're running in Paper or Fabric, both Paper and Fabric callsites are being migrated (mostly already done) to ViewCommands. One such example is Android TextInput, which has been using ViewCommands instead of setNativeProps for several months.
This migration was largely without issues, except TheSavior and I noticed early on that certain things were just... slower with ViewCommands. It was definitely noticeable, but we determined it to be acceptable and moved on.
Recently, it became clear to me that the perf regression may not be acceptable, but there might be an "easy" solution.
# Why are ViewCommands slower than SetNativeProps?
So, a couple things. SetNativeProps on Paper would actually cause a layout pass; the same is not true for ViewCommands, so they should actually be much faster. But they're not! The reason is that ViewCommands are treated as regular mount items, and they are queued up /after/ all other mount items. That means if you're trying to interact with the UI while some part of it is updating, your ViewCommands must wait for portions of the screen to finish rendering before they execute.
In some cases, those views may even disappear before the ViewCommand executes, causing increased exceptions as well as speed degredations.
# Proposal
This experiment that ran with successful results was: to execute ViewCommands /before/ all other types of mount instructions (by maintaining a separate queue). That means if you tap on a TextInput to focus it while the screen is doing some heavy rendering, the next time the UIManager executes a batch of instructions, it will execute the focus operation out-of-order, at the very beginning. From a user perspective this is actually quite noticeable, and works much better than the older behavior.
# Why it's Not That Dangerous
* Is it possible that we'll execute instructions after the corresponding view has disappeared? This was already possible, and is actually less likely now, since it's more likely that the ViewCommand will execute before the Delete instructions executes.
* Is it possible we'll execute instructions BEFORE the view is created? Yes, this is possible and I actually found a repro for it. My solution: allow ViewCommands to be retried, exactly once. If they throw an exception the first time, we requeue which will cause the command to be executed after the current batch of mount items. Interestingly, this seems to be unnecessary in Fabric, so the logic there is a bit simpler (probably because on Android we do view preallocation under Fabric, so views are created way before they're inserted into the view hierarchy, and apparently before ViewCommands have a chance to execute).
* ViewCommands are already an imperative feature that exists outside of the normal React commit cycle. So they're already dangerous. This doesn't change that, but it does make dangerous code *faster*, so that's good.
Changelog: [Android][Changed] ViewCommands on Android now execute earlier, as a perf optimization.
Reviewed By: mdvacca
Differential Revision: D22343648
fbshipit-source-id: 310d94977ac8ca3140ee8aa272272f660efafa36
Summary:
Changelog: [Internal]
I had to update the types-first flags in the giuthub flowconfigs because they are removed in 0.128. I updated the snapshot test as well
allow-large-files
Reviewed By: mroch
Differential Revision: D22336797
fbshipit-source-id: ebeb0c05479d2dac69a66645d042d5671453f5e8
Summary:
The current parser behavior flattens out any object type aliases into ObjectTypeAnnotations. Generators can treat these as regular objects and generate the applicable native code. This, however, can lead to repetition whenever an object type alias is re-used in the same native module.
I propose we treat these as a special case, using a TypeAliasTypeAnnotation to denote them as type aliases. Generators can look up the actual signature for a given object alias by referring to the "aliases" array that is provided in the schema.
**Proposed schema change:**
Adds an "aliases" key to each module in the schema:
```
export type NativeModuleShape = $ReadOnly<{|
properties: $ReadOnlyArray<NativeModuleMethodTypeShape>,
aliases: $ReadOnlyArray<{|
name: string,
typeAnnotation:
| $ReadOnly<{|
type: 'ObjectTypeAnnotation',
properties: $ReadOnlyArray<ObjectParamTypeAnnotation>,
|}>
| $ReadOnly<TypeAliasTypeAnnotation>,
|}>,
|}>;
```
Example:
```
{
modules: {
SampleTurboModule: {
nativeModules: {
SampleTurboModule: {
aliases: [],
properties: [],
},
},
},
},
}
```
Method parameters will now support the new 'TypeAliasTypeAnnotation' wherever a param might have used a 'ObjectTypeAnnotation':
```
export type TypeAliasTypeAnnotation = $ReadOnly<{|
type: 'TypeAliasTypeAnnotation',
name: string,
|}>;
```
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D22200700
fbshipit-source-id: 15684620783c752f2fb482ba4b88d1fd1cc07540
Summary:
(1) As soon as we know we can StopSurface, stop executing all mountitems by clearing out the root tag.
(2) If a surface has been stopped and there's a batch of MountItems to execute against it, execute only the "delete" operations to clear views from memory.
Both of these should reduce memory usage and improve speed slightly around navigation pops.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22321389
fbshipit-source-id: 96a8292a8442528f1bba50d35208885cc4168170
Summary:
While in theory we should never delete views before removing them from the hierarchy, there are some exceptions:
(1) Some mysterious cases that don't seem like bugs, but where the child still seems to keep a reference to the parent:
(2) When deleting views as part of stopSurface.
On #1: in the past we had issues when we assumed that ViewManager.getChildCount() would return an accurate count. Sometimes it's just... wrong. Here, I've found at least one case where a View still has a parent after it's removed from the View hierarchy. I assume this is undocumented Android behavior or an Android bug, but either way, there's nothing I can do about it.
On #2: there are valid cases where we want to delete a View without explicitly removing it from the View hierarchy (it will eventually be removed from the hierarchy when the Root view is unmounted, but it may still be "in" a View hierarchy when it's deleted).
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22321374
fbshipit-source-id: 9667bbe778c418f0216550638dc26ca48a58e5fa
Summary:
The Hermes inspector always logged the message for `console.assert`.
It instead should check the first argument, and only if that argument
is false should it log.
Also remove the polyfill code that tried to avoid this situation.
Changelog: [Internal]
Reviewed By: mhorowitz
Differential Revision: D22299186
fbshipit-source-id: cdf4f8957d4db3d171d6673a82c7fc32b7152af3
Summary:
Splits the codegen script into functions, and makes use of $YARN_BINARY for portability (defaults to `yarn` if not provided).
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D22148360
fbshipit-source-id: 9e86b3e0f7f77bf3a635bf6be204170333dd5e65
Summary:
Moving property handling functions to their own properties.js file. No changes other than adding types to params.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D22208243
fbshipit-source-id: 4a7d2c6e19c151954da793d399af9a256a4a40b7
Summary:
These flags haven't been used in months. They were useful to uncover some race conditions, but will not be iterated further. The Venice project will obviate the concerns that sparked these experiments in the first place.
These flags have been hardcoded to false for a while.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22319204
fbshipit-source-id: 09415f3bb1ca56e15f357210e966d0483ff384f2
Summary:
According to our experiments it's not better than "stop surface on unmount" in any way, and might regress some metrics. Unclear why, but if it's not necessary and doesn't seem to help, it doesn't make sense to continue this experiment.
We still have a mechanism on the C++ side to stop outstanding surfaces on teardown that does the same thing.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22318864
fbshipit-source-id: 7e678c63e4884382e57d996a7f4c4b7b24c8193a
Summary:
Changelog: [Internal]
Do not log warning for "Invalid view set to be the JS responder".
{F242140509}
Fabric doesn't store views in view registry, therefore this warning would be shown to the developer everytime `[RCTUIManager setJSResponder]` is called.
Reviewed By: shergin
Differential Revision: D22309447
fbshipit-source-id: cac8985cdc79ab2d03a246cc2d9377472a64a683
Summary:
motivation: I was just checking out https://github.com/facebook/react-native/commit/30cc158a875a0414cf53d4d5155410eea5d5aeea
and noticed that the commit, I believe, is missing logic for when `contentOffset` is actually `null`.
That is, consider you render `ScrollView` with `contentOffset` { x: 0, y: 100 } and then change that to null / undefined. I'd expect the content offset to invalidate (set to 0 - hope that's the default).
## 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
-->
[Android] [Fixed] - ScrollView, HorizontalScrollView: do not ignore `null` `contentOffset` prop
Pull Request resolved: https://github.com/facebook/react-native/pull/28760
Test Plan:
Tested locally within RNTester
<details><summary>code</summary>
<p>
```js
const Ex = () => {
let _scrollView: ?React.ElementRef<typeof ScrollView> = React.useRef(null);
const [offset, setOffset] = React.useState({x: 0, y: 20});
setTimeout(() => {
setOffset(undefined);
}, 2000);
return (
<View>
<ScrollView
ref={_scrollView}
automaticallyAdjustContentInsets={false}
onScroll={() => {
console.log('onScroll!');
}}
contentOffset={offset}
scrollEventThrottle={200}
style={styles.scrollView}>
{ITEMS.map(createItemRow)}
</ScrollView>
<Button
label="Scroll to top"
onPress={() => {
nullthrows(_scrollView.current).scrollTo({y: 0});
}}
/>
<Button
label="Scroll to bottom"
onPress={() => {
nullthrows(_scrollView.current).scrollToEnd({animated: true});
}}
/>
<Button
label="Flash scroll indicators"
onPress={() => {
nullthrows(_scrollView.current).flashScrollIndicators();
}}
/>
</View>
);
};
```
</p>
</details>
Reviewed By: shergin
Differential Revision: D22298676
Pulled By: JoshuaGross
fbshipit-source-id: e411ba4c8a276908e354d59085d164a38ae253c0
Summary:
The method does not do anything besides calling a super method. Even if this method does nothing special, overriding it can have negative performance implications.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D22309895
fbshipit-source-id: bd8237d15df20017629223f278b1b6ac628b0cc7
Summary:
It's a Yoga specific feature that does not need to exposed as LayoutableShadowNode.
Removing this we save many virtual calls and add simplicity.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D22304717
fbshipit-source-id: f2dda8309dd86b78cd2775971721d29e5317ffd5
Summary:
`Overflow inset` is a field in LayoutMetrics that describes the external bounding box that covers area formed by all descendants of the view (that might stick out of the frame of the view).
This information can be used for various optimizations across all rendering pipeline. Here is some of them:
Improving hit-testing performance.
Implementing a robust "remove invisible native views" feature.
Improving `clipToBounds` performance.
Improving View Flattening versatility.
Most importantly, we need this for improving <ScrollView> performance (and memory footprint) which we have to do to match parity with Paper's `removeClippedSubviews` feature.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D22297325
fbshipit-source-id: cb238f0505d11ccabbe9db26f36a98b3172c70db
Summary:
onAssetDidLoad is defined as bubbling event in iOS, change it to bubbling event and adde it to bubblingEventTypes to fix "missing: topAssetDidLoad" error in Viewpoints iOS.
Changelog: [Internal]
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D22209406
fbshipit-source-id: 5da779d9d1d62c70d85d84ad80807ff688e29e2f
Summary:
After years of trying to design a somehow decomposed and universal layout API, I think we chased a wrong goal. None of the solutions that I tried helped with simplicity, composability, performance, or readability. Besides that, a bunch of execution primitives we use (e.g. `setHasNewLayout`) are heavily influenced by Yoga and are far from being commonly applicable. Finally, we ended up with a situation where the current design does not allow us to implement the features we want (more about that in coming diffs).
The diff changes that. Now we have only one method that implements layout - `layout()`; all possible implementations are free to implement it in any way that makes sense for a particular approach. And, I think, even for the base case - Yoga powered layout - things are much simpler and faster now: it's easy to comprehend how a single method works and now we don't have two loops and an expensive call to `getLayoutableChildNodes`.
But most importantly, after this change will be able to implement the `Inset Overflow` feature quite easily.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D22297317
fbshipit-source-id: f8662b7e8e3b522bdd6e5b2b0ac6a06efb45be6d
Summary:
Changelog: [Internal]
Introducing InputAccessoryView.
There is one big difference between Fabric's implementation and Paper's implementation.
Fabric searches for text input from InputAccessoryView, unlike Paper where it is the other way around.
Reviewed By: shergin
Differential Revision: D22160445
fbshipit-source-id: 55313fe50afeced7aead5b57137d711dd1cfd3ae
Summary:
View elevation is an Android-only prop, and it's a float, not an int. https://www.codota.com/code/java/methods/android.view.View/setElevation
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D22298431
fbshipit-source-id: 91edc3aa64e7254a5c4a4cb33f26e64ebae89b8d
Summary:
After animation has been finished using Native driver there is no final value passed from the native to JS side. This causes a bug from https://github.com/facebook/react-native/issues/28114.
This PR solves this problem in the same way as `react-native-reanimated` library. When detaching it is calling native side to get the last value from Animated node and stores it on the JS side.
Preserving animated value even if animation was using `useNativeDriver: true`
Fixes https://github.com/facebook/react-native/issues/28114
## 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] [Fixed] - Save native Animated node value on JS side in detach phase
Pull Request resolved: https://github.com/facebook/react-native/pull/28841
Test Plan: Unit tests for added getValue method passed. Green CI
Reviewed By: mdvacca
Differential Revision: D22211499
Pulled By: JoshuaGross
fbshipit-source-id: 9a3a98a9f9a8536fe2c8764f667cdabe1f6ba82a
Summary:
Here is why:
* It was with us from the very beginning but we never use it.
* The main purpose of this - snap-to-pixel layout - was moved to Yoga, where it should be.
* The current implementation has a bug.
* It's not really correct conceptually because the value becomes incorrect when an immutable subtree is being reused as part of a new tree.
* It over-complicates a new feature I am working on.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D22284645
fbshipit-source-id: c4c2df8d24e8fe924725b465e04e8154d097d226
Summary:
A function in graphics/geometry which adjusts a rectangle by the given edge insets.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D22284644
fbshipit-source-id: ad78abd7889b4457c450b2cc43fb73054aef2c79
Summary:
Early ViewCommand dispatch: ship the experiment everywhere on Android.
Since ViewCommands are totally divorced from the commit cycle currently, and since they are inherently unsafe, we can create a separate queue for them
and retry them if they fail with a specific category of exceptions.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22173050
fbshipit-source-id: 494b7c6b5dfd2aec8ba77ae35d0d58d4d727b9b4
Summary:
This diff avoids accessing window and activities object that has dissapear
changelog: [Android][Fix] Fix crash when updating RN dialog props after the activity disappeared
Reviewed By: JoshuaGross
Differential Revision: D22264672
fbshipit-source-id: 89c9895c8c6b6fec383a0e160847e5059616e265
Summary:
Changelog: [Internal]
In D8552360 (https://github.com/facebook/react-native/commit/48b9a6f887c09f78944053a6658106a01dc20fea) an experimental integration between old and new UIManager has been introduced.
It isn't needed anymore.
I did some measurements and it is the slowest part of `[RCTComponentViewDescriptor dequeueComponentViewWithComponentHandle]`.
{F241943384}
Reviewed By: shergin
Differential Revision: D22274782
fbshipit-source-id: 799ba047f1c57f68f00b0b6fa7c58782874991bc
Summary:
Need to publish a new version now that we want to not publish Flow code
Changelog: [Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: kacieb
Differential Revision: D22265050
fbshipit-source-id: a9a0d03b1e2c1ec72e642b0af070ba48426825f8
Summary:
The docs suggest that TouchableNativeFeedback [inherits `TouchableWithoutFeedback` props](https://reactnative.dev/docs/touchablewithoutfeedback#props) but `accessibilityHint` was missing.
## Changelog
[Android] [Added] - Add accessibilityHint to TouchableNativeFeedback
Pull Request resolved: https://github.com/facebook/react-native/pull/29154
Test Plan: Not sure how this should be tested, but I'm happy to implement what others may suggest
Reviewed By: kacieb
Differential Revision: D22109459
Pulled By: TheSavior
fbshipit-source-id: 573267a26414a97ba23a1a7995bff1608f9ba34f
Summary:
PlatformColorExample RNTester page crashes when running on platforms other than iOS/Android.
Changed some very minor logic to take into account that platforms other than iOS/Android exist.
## Changelog
[Internal] [Fixed] - PlatformColorExample RNTester page crashes when running on platforms other than iOS/Android.
Pull Request resolved: https://github.com/facebook/react-native/pull/29120
Reviewed By: sahrens
Differential Revision: D22109188
Pulled By: TheSavior
fbshipit-source-id: 853bea0ac4ea5c67f35d89d1a2bf55f5c89823b4
Summary:
Provide a mocked `DevSettings` implementation for jest.
## 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] [Added] - Add mock for `DevSettings` to jest preset
Pull Request resolved: https://github.com/facebook/react-native/pull/29223
Test Plan: None
Reviewed By: cpojer
Differential Revision: D22279962
Pulled By: TheSavior
fbshipit-source-id: 667cecb0a558a4267564702ee9d30380756bdd92
Summary:
Changelog: [Internal]
The methods were out of order, this diff reorders them.
Reviewed By: shergin
Differential Revision: D22233255
fbshipit-source-id: ea66bc701c4d021ec5721e191bc0d3413b3d36ae
Summary:
In an effort to simplify and clean up the `EventEmitter` abstractions in React Native, this removes `once()` and `removeCurrentListener()`. Across the Facebook codebase, there were only two callers of `once()` and no callers of `removeCurrentListener()`.
The same behavior can be achieved using:
```
const subscription = emitter.addListener('event', () => {
subscription.remove();
// ...
});
```
Changelog:
[General][Removed] - Removed `once()` and `removeCurrentListener()` fom `DeviceEventEmitter` and `NativeEventEmitter`.
Reviewed By: cpojer
Differential Revision: D22196474
fbshipit-source-id: 06ced186fd812e91d5c57f6580e647c100505807
Summary:
https://github.com/facebook/react-native/issues/27264 changed stylesheet validation to avoid enumerating properties on the prototype of a style. It introduces a secondary behavior change, where null/undefined styles used to be tolerated but now lead to an exception. This is because `for in undefined` will noop where `for of Object.keys(undefined)` will throw.
This scenario of undefined/null styles seems to actually show up in practice and was previously well tolerated. E.g. `Button.js` has code that looks like this:
```jsx
const styles = StyleSheet.create({
button: Platform.select({
ios: {},
android: {
elevation: 4,
// Material design blue from https://material.google.com/style/color.html#color-color-palette
backgroundColor: '#2196F3',
borderRadius: 2,
},
}),
```
For non ios/Android platforms, that creates a style object which looks like:
```js
{
button: undefined,
...
}
```
This previously meant that the component would be unstyled if created, but now means out-of-tree platforms throw if the builtin Button component is required.
This change restores the previous `for in` loop but adds a `hasOwnProperty` check to avoid properties on prototypes.
## Changelog
[General] [Fixed] - Restore Previous Behavior for StyleSheet Validation of Null/Undefined Styles
Pull Request resolved: https://github.com/facebook/react-native/pull/29171
Test Plan: Validated that importing Buttons will no longer cause an exception, and that invalid properties are still caught.
Reviewed By: JoshuaGross
Differential Revision: D22118379
Pulled By: TheSavior
fbshipit-source-id: 650c64b934ccd12a3dc1b75e95debc359925ad73
Summary:
Attempt to fix T68951888 where (1) ComponentHandle is zero, and/or (2) ComponentHandle is missing in the registry. Either will cause a crash and both should be trivial to work around. I was able to repro once accidentally in about 1/200 sessions, so I am not 100% sure if this fixes the root cause.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D22216030
fbshipit-source-id: b6986adee6fe739ce58579a2b031a2d252e73e35
Summary:
Previously, we tried to take a Transform matrix, decompose it into parts, and then interpolate between those parts. This will always be risky at best, and in some cases ambiguous or unsolvable. For example, a scale of -1 is identical to a rotation of 180 degrees.
Another issue is that when decomposing a matrix, it is impossible to tell the sign of scaleX, scaleY, scaleZ. This is a problem - flipping a View over an axis via scale then becomes a non-animatable operation.
This caused a number of issues.
To resolve it, we accumulate the "operations" resulting in a particular transform. This allows us to easily interpolate between two Transform matrices without actually decomposing the matrix, since we have the "path" that resulted in each particular matrix.
This will make LayoutAnimations over transforms, including Skew transforms, look and work much better, and more reliably.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D22204559
fbshipit-source-id: 0d88ae77e4399a7ea333afbf6062beea977b854a
Summary:
Move to Utils for reuse, and change parameter to take a property object.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D22146669
fbshipit-source-id: e028821cdb11361a45226de0247aa4551b5ade1d
Summary:
Changelog: [Internal]
When Paper loads images. it calls with with `clipped` being set to NO.
https://github.com/facebook/react-native/blob/master/Libraries/Image/RCTImageView.mm#L346
We should do the same in Fabric as it can result in different images being loaded.
Reviewed By: JoshuaGross, shergin
Differential Revision: D22185286
fbshipit-source-id: 04afafee67fdfac53e9d17f5edeaf9b9317c7a22
Summary:
Renames `EventSubscription.js`, `EmitterSubscription.js`, and `EventSubscriptionVendor.js` to `_EventSubscription.js`, `_EmitterSubscription.js`, and `_EventSubscriptionVendor.js`, respectively.
This is to indicate that those files are implementation details and should not be directly referenced. Instead, the `EventSubscription` type exported from `EventEmitter.js` should be used.
The remaining stragglers that are importing `_EmitterSubscription.js` and `_EventSubscriptionVendor.js` after this commit will be cleaned up when `RCTDeviceEventEmitter` is refactored.
Changelog:
[Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: cpojer
Differential Revision: D22182310
fbshipit-source-id: 82be685f231395bd7b8e9986141b5df1367bec71
Summary:
Changes dependents of `EmitterSubscription` to instead import the `EventSubscription` type from `EventEmitter.js`.
Changelog:
[Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: cpojer
Differential Revision: D22182309
fbshipit-source-id: 575f4c59248ef50182ddb33911f1e6f3ba88ec07
Summary:
Changes dependents to import the `EventSubscription` interface type from `EventEmitter` instead of `EventSubscription.js`.
Changelog:
[Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: cpojer
Differential Revision: D22182313
fbshipit-source-id: 31448ea5ee3038f806a417f23597da1edd4e4e9b
Summary:
Changes `EventEmitter.js` to be Flow-typed so that it can export an interface for `EventSubscription`. In order to retain the untyped-ness of `EventEmitter.js`, I moved the entire definition into an untyped `_EventEmitter.js` file (which I hope no one will try importing from).
This new interface will be used to replace all the current type imports of `EventSubscription` and `EmitterSubscription`.
Changelog:
[Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: cpojer
Differential Revision: D22182311
fbshipit-source-id: c604a371a91963116621e89ca63f5a82167090b9
Summary:
Upgrades dependents of `EventEmitter`, `EventSubscription`, `EventSubscriptionVendor`, and `EmitterSubscription` to use `import` instead of `require`.
Changelog:
[Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: cpojer
Differential Revision: D22182312
fbshipit-source-id: e9444aa2728d89d52f577725f688871f7dbfba8a
Summary:
This diff avoids calling to the method setStateListAnimator for users running in Android API < 21 (This method did not exist in Android API < 21)
changelog: [Android][Fix] Fix crash while measuring ReactSlider in Android API < 21
Reviewed By: lunaleaps
Differential Revision: D22164574
fbshipit-source-id: 8163f99eeb78302fc75e2c4938330c699ca8d363
Summary:
Searching for details and maybe a fix for T68843308 crashing in disconnectFromView, "Attempting to disconnect view that has not been connected with the given animated node".
May be related to recent refactoring but it's not clear. Change logic slightly and add more diagnostic information.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D22153179
fbshipit-source-id: b95dbaf01ae8bca154c61442898b0f9d3aebb4de
Summary:
This diff refactors the theme management for text input in order to avoid extra state updates.
changelog:[Internal]
Reviewed By: JoshuaGross
Differential Revision: D22149754
fbshipit-source-id: 8a6dbe63c8d532986dbf785c7b16323e0a980669
Summary:
Index adjustment is complicated since we defer REMOVE operations. This diff solves some remaining (hopefully final!) bugs found when queueing several conflicting LayoutAnimations repeatedly (this is sort of an "extreme" case since we're continuously re-queueing additional LayoutAnimations instead of allowing any to complete, while reordering and deleting, so it exercises the most extreme LayoutAnimations use-cases).
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22150085
fbshipit-source-id: db1381bef3ba8bb5ec82dab791f69162d46d23f0
Summary:
This is a useful debugging tool that will not be compiled by default, and we have some protection to only compile it in Debug builds so it's less likely to accidentally slip into production.
This has been useful for debugging C++ LayoutAnimations, since Remove/Insert mutations are delayed and fiddled around with a little.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22148853
fbshipit-source-id: 05609507cdf06b73fd3edf5cf7bc95e124ff1135
Summary:
There's a race when RCTNativeAnimatedModule is a TurboModule that breaks animations. More details here: T68603674. Even though this is a bit edge-casey, I think it's best to make this NativeModule a non-TurboModule until this problem is resolved.
Changelog: [iOS][Fixed] - Make RCTNativeAnimatedModule a regular NativeModule to unbreak animations with TurboModules on
Reviewed By: yungsters
Differential Revision: D22149179
fbshipit-source-id: 6bf9f0d5eab7c99a82b21ec07e76359181dcedd2
Summary:
This will prevent views from becoming out-of-order as view removals are delayed and there are inserts at the same level.
There is at least one additional issue that crops up if many animations are queued up at the same time, that will be resolved separately.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D22130185
fbshipit-source-id: d8041c6afdcd729939dd392c9e2c23fe8ec1b706
Summary:
It is possible (most recently, if there are bugs in LayoutAnimations, but also in general) to issue a `removeViewAt` MountItem that removes the incorrect view if, for whatever reason, the View hierarchy has become "corrupt"
and Views are out of order. I added two heuristics to catch if that happens: check the tag of the View being removed if possible, and ensure that all deleted views do not have a parent. This will turn weird visual glitches into
hard crashes, which we want once the UI has become corrupt.
My only concern here is with perf; maybe we could put these behind a debug-only flag or something, but it's probably not a huge deal.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22130186
fbshipit-source-id: 0942b019c3449d68edfb9db1fe8130ea351d1d8f
Summary:
Changelog: [Internal]
Order of events dispatched to JS matter. If we remove duplicate events, we shouldn't change order of types.
So If we have order of events
A -> B -> C
and inserting a new event A for the same target, we shouldn't delete the first A, as there might be logic that depends on event B being preceded by A.
What we can do though, is delete previous event of the same type and target in queue if we would be adding subsequent event.
So when we have events
A -> B -> C
and we are about to add event C to the queue which goes to the same target, we can delete the first C before inserting the new one.
Reviewed By: shergin
Differential Revision: D22135931
fbshipit-source-id: 1dadd1688516330be07c4251f446f77ca08eaa87
Summary:
Refs: [0.62 release](https://reactnative.dev/blog/#moving-apple-tv-to-react-native-tvos), https://github.com/facebook/react-native/issues/28706, https://github.com/facebook/react-native/issues/28743
Support for the tvOS with the 0.62 release has been moved out to the `react-native-tvos` package. This PR removes the legacy flag related to the tvOS in the RNTester app examples.
Since Android TV support is still included in the Core I assume that the TV platform check cannot be removed completely.
## Changelog
[Internal] [Removed] - remove 'supportsTVOS' flag from the RNTester examples
## Test Plan
I have used the local working copy of `react-native` repo and test the changes in the RNTester app build from this code. Flow and List checks passed (but there is one, unrelated Prettier issue in the `AlertExample.js` file).
Pull Request resolved: https://github.com/facebook/react-native/pull/29018
Reviewed By: kacieb
Differential Revision: D22109549
Pulled By: TheSavior
fbshipit-source-id: d0f71f3d5f5f89d554972ec194ebf2801386fcff
Summary:
When asking for the data of a JSBigFileString, check that the instance satisfies some basic invariants.
This is meant to catch any corruption issues as early as possible.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22125436
fbshipit-source-id: e0a84752c86151d56b7e7cbed3b95650d8ba1f75
Summary:
## Changelog:
[Internal][Changed] - Prevent symbolicating stacktrace and no logbox when running in express route
Context:
ExpressRoute doesn't support some things (like promises) due to the limited initialization we do.
Right now the app will crash when trying to evaluate those entrypoints in express route if they depend on such initialization. Ideally a redbox would warn the developer that express route would break if they modify their express-route compatible entrypoint. Displaying a redbox seems to require a bit of refactoring as it can't easily be triggered from native/express-route -- something more to investigate. Occasionally one does appear (when trying the attached test plan) but it is inconsistent and seems dependent on timing of bridge, express route initialization.
The plan:
* Since we are going to roll out an opt-in for each surface (note there are two flags, `fetchWithExpressRouteIfAvailable` and `useExpressRouteIfInitialized` - the former being for using `getPreloadProps` to parallel fetch and the latter as a flag to get route information) we have more control of the roll out of express route.
Things still to improve:
* It's obviously not great that we don't get better errors -- something to address if that is really the next blocker to rolling out ExpressRoute
Reviewed By: sahrens, ejanzer
Differential Revision: D22026444
fbshipit-source-id: 7698109f5921f82a2d0bc9a8346e12b67defca27
Summary:
Adjusts the behavior of `blurRadius` for `Image` on Android so that it behaves more closely to other platforms (web and iOS).
Changelog:
[Android][Changed] - Effect of `blurRadius` now more closely matches other platforms.
Reviewed By: shergin
Differential Revision: D22118680
fbshipit-source-id: c6d14aef29b4a086e43badfa78407bfa07f9fee2
Summary:
If the entry file has been renamed (e.g., to `index.ts`), the script currently fails silently and prints out that the bundle file does not exist.
This change will print the correct error message instead.
## Changelog
[iOS] [Fixed] - Better error message when missing entry file
Pull Request resolved: https://github.com/facebook/react-native/pull/29012
Test Plan: N/A
Reviewed By: hramos
Differential Revision: D22109657
Pulled By: TheSavior
fbshipit-source-id: edd7b6f88becc954ee41ed01ae43efb4481adc95
Summary:
Without this the RNTester app on iOS can’t be built in a folder that has a space in the path.
## 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] - RNTester app builds in a path that contains a space
Pull Request resolved: https://github.com/facebook/react-native/pull/29160
Test Plan:
1. Clone react-native into a folder where the path has a space
2. Follow the instructions at https://github.com/facebook/react-native/blob/master/RNTester/README.md to get the RNTesterPods.xcworkspace
3. Open the workspace and build the project. Path to workspace was /Users/richard/UX Cam/Code/Test Projects/ReactNative/react-native/RNTester/RNTesterPods.xcworkspace
4. See error message - '/Users/richard/UX' is the first part of my path before the space
/Users/richard/Library/Developer/Xcode/DerivedData/RNTesterPods-ctjcmrlwzntpssgmcjydmovoztwl/Build/Intermediates.noindex/RNTesterPods.build/Debug-iphonesimulator/RNTester.build/Script-68CD48B71D2BCB2C007E06A9.sh: line 3: /Users/richard/UX: No such file or directory
Reviewed By: RSNara
Differential Revision: D22118259
Pulled By: TheSavior
fbshipit-source-id: 1213d88f66fd47dd052eaeb5f26da9056887f5ea
Summary:
Changelog: [Internal]
# Why we crash?
`cStringUsingEncoding` returns `char *`, not `std::string`. Compiler uses implicit conversion to construct and copy `char *` into `std::string`. Maybe optimiser does something unexpected there? Maybe something weird happens there? I think it is worth trying to be more explicit about it and construct std::string there explicitly. Also if you do a google search, this seems to be a go to strategy when converting `NSString` to `std::string`.
This is all just an assumption, I can't repro the crash
# Why get rid of 2nd argument in RCTStringFromNSString
2nd argument is `NSStringEncoding`. It isn't being used, we always use default value.
Also, if you pass in `NSUTF16StringEncoding` or `NSUTF32StringEncoding`, you get undefined behaviour.
Check https://developer.apple.com/documentation/foundation/nsstring/1408489-cstringusingencoding?language=objc# section "Special Considerations"
Reviewed By: shergin
Differential Revision: D22089694
fbshipit-source-id: d449b383c61983c3822bc589c0a01fa97c0b6e64
Summary:
Add tooltip to the list of components supported with the legacy view manager, so that it will work in Fabric.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D21917137
fbshipit-source-id: 1ab6c7cdd0a10a496531d2ea8fbcae7e427ec647
Summary:
Changelog: [Internal]
Add support for dynamic font size.
New class `ThreadStorage` is introduced, which is used to pass LayoutContext to `YogaLayoutableShadowNode::yogaNodeMeasureCallbackConnector`.
## Shortcoming
This implementation doesn't cause re-render, if user changes font size and comes to the app without restarting it, it will show old font size. I believe this is fine for now as most people set their font size before they use the app and keep the same setting for a long time.
Reviewed By: shergin
Differential Revision: D22043728
fbshipit-source-id: 7453d165c280a2f4bcb73f4ee6daf9e64b637ded
Summary:
Changelog: [internal]
Rename `LayoutableShadowNode::measure` to `LayoutableShadowNode::measureContent` and add LayoutContext as parameter.
Pass `LayoutConstraints` by reference rather than value.
Reviewed By: shergin
Differential Revision: D22043727
fbshipit-source-id: b668240c45b658db5b114630b73d7407d35482aa
Summary: This diff updates the loading banner text and color on Android to match its style on iOS.
Differential Revision: D22066823
fbshipit-source-id: 7f8d6cf1a6c4c48babe919995044978d7a81c674
Summary:
If UIManager disappears, it's likely due to (1) teardown due to memory pressure, (2) teardown due to crash, (3) normal teardown.
In all of those cases, I would just want NativeAnimatedModule to stop executing and fail silently ASAP.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22079209
fbshipit-source-id: 21650abdfdb119a6f4abccd6962d0c09f7c7c6cd
Summary:
Adds support for the `onProgress` event on `Image`, for Android.
Since Fresco does not provide a progress listener on `ControllerListener`, this uses a forwarding progress indicator `Drawable` to pass along values from `onLevelChange`.
Caveat: The ratio between `loaded` and `total` can be used, but `total` is currently always 10000. It seems that Fresco does not currently expose the content length from the network response headers.
Changelog:
[Android][Added] - Adds support for the `onProgress` event on `Image`
Reviewed By: mdvacca
Differential Revision: D22029915
fbshipit-source-id: 66174b55ed01e1a059c080e2b14415e7d268bc5c
Summary:
Changes the `onLoad` and `onError` events on `Image` to be consistent with each other and with the `ImageSource` type.
Changelog:
[Android][Breaking] - On `Image`, `onLoad` and `onError` event objects will no longer have an extra `uri` property.
[Android][Breaking] - On `Image`, `onLoad` event objects' `source.url` is now renamed to `source.uri`.
[iOS][Breaking] - On `Image`, `onLoad` event objects' `source.url` is now renamed to `source.uri`.
Reviewed By: mdvacca
Differential Revision: D22023565
fbshipit-source-id: 5ea7904c697f87e01118bdb81ed50ab0a5aecdce
Summary:
Cleans up `ImageLoadEvent` to minimize constructor confusion and to make the dispatching logic more predictable.
Changelog:
[Internal]
Reviewed By: mdvacca
Differential Revision: D22023141
fbshipit-source-id: 17e66de867f51121a3f9a6b782dbad700a54231a
Summary:
Currently, the codegen supports `$ReadOnly` values, but not `$ReadOnly` properties on objects. This adds support for those (by pretty much ignoring them).
Changelog:
[General][Added] - Support `$ReadOnly` in object properties when defining native event types
Reviewed By: TheSavior
Differential Revision: D22023142
fbshipit-source-id: 7167852050925bf31392607923576f023e729f5f
Summary:
This function is unused. (Followup to D21941946)
Changelog: [iOS] Deprecate calculateChildFrames from RCTScrollView
Reviewed By: sammy-SC
Differential Revision: D22071415
fbshipit-source-id: 0c996ab02df1431ee9cfa082bc99681a2ec7118c
Summary:
Changelog: [Internal]
Paper views are not designed to be recycled, that's why a new view is created each time legacy interop layer is used.
However paper view was not deallocated immediately after it was used, it was still being strongly referenced by `self.contentView`.
This doesn't cause an immediate issue because eventually when legacy interop layer does get reused, it will create a new paper view and replace the old one inside `self.contentView`, triggering deallocation of the old one. But we were retaining the paper view beyond what was necessary.
Reviewed By: mdvacca
Differential Revision: D22066022
fbshipit-source-id: 17c3b81468f50ebcc05f1a7cdf4d4b9b00965fc3
Summary:
Changelog: [Internal]
A long time ago we experimented with JSC bytecode. We are not experimenting with JSC bytecode any more. This code can be removed.
Reviewed By: mhorowitz
Differential Revision: D22017374
fbshipit-source-id: 6fe3fb7ad7966f92a5cd103605ac5c0bd1f17a8e
Summary:
Since we were not busting the `surfaceActiveForExecution` cache, it is very possible (likely, even!) that a surfaceId is invalidated in between UI ticks but we keep executing items for that surface at the next tick.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22055303
fbshipit-source-id: 351c13535e85b30e00684fe35fc4aa79ccb5961c
Summary:
Fix crashes in LayoutAnimations:
1) It is valid to omit create, update, delete configs
2) When extracting SRT from a matrix, ignoring skew properties
3) Provide valid telemetry from LayoutAnimations transactions
Unrelated to crashes: to help debugging and until onSuccess/onError callbacks are working, log any configuration parsing errors.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22050736
fbshipit-source-id: e59418ecad0f9bfd20a2b4976557e39020c2d101
Summary:
This diff fixes a race condition that caused a flicker during initial rendering of TextInput in Fabric
The root cause is that the TextInput's State is sometimes initialized with no information from the Theme, this causes text input to be rendered with 0 padding. Later ReactTextInput manager updates TextInput state with theme data and the TextInput is re-rendered with the correct padding information.
changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D22034849
fbshipit-source-id: a2fa91f34a8340878f2ec8d231ef6c86cee08f05
Summary:
This diff changes the order of execution for the "updatePadding" mount item
Padding mountItems must be executed before layout props are updated in the view. This is necessary to ensure that events (resulting from layout changes) are dispatched with the correct padding information.
This fixes a 'flickering' bug in Marketplace Vehicles (see test plan)
changelog:[internal]
Reviewed By: JoshuaGross, sammy-SC
Differential Revision: D22034850
fbshipit-source-id: 222fa9412dd01f65a1a034f53e1eb0e7b774ec1f
Summary:
Similar to D21756178, we cannot rely on childCount since it can return zero when there are actually valid children. This both causes more exceptions than necessary when the operation would work, and pollutes error messages since the information is not strictly reliable.
Instead, we just try to get a View and thrown an exception when it's null, or in loops, loop until we hit a null child. `getChildAt` doesn't throw exceptions, it just returns null when we're out-of-bounds.
This can impact custom ViewGroups like BottomSheets, and other ViewGroups that might do interesting/weird things with children, including ReactClippingViewManager.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22035569
fbshipit-source-id: 43e98d81178faaf720face98fc84e78743f292c3
Summary:
telling native that `selected` is the new selection is basically ignoring the most recent user input and resetting it back to the previous value. the reason it flips back and forth is that by the next time `onSelect` is called, the above code has updated the value of `selected` (line 63)
Changelog:
[Android] [Fixed] Picker - fix usage of setNativeSelectedPosition in onSelect
Reviewed By: mdvacca
Differential Revision: D22022456
fbshipit-source-id: fe51f9cbd712b5578e9fd9ea2992bd12d48f4ec4
Summary:
This pull request updates the Podspecs to reflect recent changes to Fabric, so they build with Fabric enabled again.
In `React-Fabric.podspec`, subspecs for the views `legacyviewmanagerinterop`, `safeareaview`, `textinput`, and `unimplementedview` are added. A minor tweak to the subspec for `rncore` was added blacklisting two codegen-generated files that have issues building, but are not actually needed yet and are empty.
In `React-graphics.podspec`, the header paths for Boost were added.
This is partially a retread of https://github.com/facebook/react-native/issues/26805, which had to be backed out due to issues with the changes to the Yoga podspec.
## Changelog
[Internal] [Fixed] - Fixed building Fabric with the Cocoapods
Pull Request resolved: https://github.com/facebook/react-native/pull/28584
Test Plan: RNTester can now compile.
Reviewed By: shergin
Differential Revision: D20966065
Pulled By: hramos
fbshipit-source-id: 73931be63b72fcb52705643f81c0f787e571eb76
Summary:
In particular, NativeAnimatedModule relies on having some signal of when there's a commit from ReactJS. In Fabric, this is the only reliable signal. Failing to call scheduleMountItems even when there's no changes to the tree will result in certain animation operations being delayed way longer than necessary.
I pass nullptr instead of empty arrays in some cases to hopefully improve perf.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22008981
fbshipit-source-id: 6bdeb46e03b5138dbfa5b077952ec0fa3dfe1eb3
Summary:
Fabric will crash if Inf/NaN values are passed to the native side, so just pass zero to native in those cases. It's an equally (in)valid value and we're already logging the error.
Also, debounce the error so we don't spam the LogBox/console.
This should potentially be changed to a warning.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22008980
fbshipit-source-id: 1aef33a13febed04311557718f05ef79bbbcca93
Summary:
Switch between "Fabric" and "Non-Fabric" modes based on which types of native Views are being attached to animations. Don't allow non-Fabric to drive Fabric animations and vice-versa.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21985411
fbshipit-source-id: fb9bef1e38375b384430b4e0275e7b6d62eda7a4
Summary:
The initialScrollIndex in VirtualizedList contains a performance optimization to start rendering the list at the index provided.
ContentOffset does not contain this optimization and there is currently no way to specify the first item in the list to start rendering without contentOffset being ignored.
This change makes it so that if both initialScrollIndex and ContentOffset are provided, the list will start rendering at the initialScrollIndex but ContentOffset will still be used to set the scroll position.
initialScrollIndex functionality will remain the same if ContentOffset is not provided.
Changelog: [Changed] VirtualizedList will use contentOffset for scroll position instead of initialScrollIndex if both are provided
Reviewed By: sahrens
Differential Revision: D21980172
fbshipit-source-id: 36d2d2bc360845ef02329d2b95a2cf14b91c2b0b
Summary:
Fixes some comment typos, moves hit testing and accessibility code so it's beside each other.
No functionality changes.
Changelog:[Internal]
Reviewed By: RSNara
Differential Revision: D22003047
fbshipit-source-id: 0e785364d7e1a080034d24c9676a56acb45686bb
Summary:
Changelog: [Internal]
Round calculated text size to closest larger pixel size.
In Paper we do this as well in https://fburl.com/diffusion/w2pj6ea0
Why do we need this?
For example, we calculate height of the text to be 16.707235, yoga takes this value and assigns text to have height 17 anyway.
I assume Yoga uses this extra 0.3 points of height to move other things around a little bit because Yoga doesn't deal with exact values.
Reviewed By: shergin
Differential Revision: D21999032
fbshipit-source-id: 73923dc3e27fa110adb3f76cfa635e0bfdc672d4
Summary:
There is no good reason why they are `const` and `private`, in the future diffs we will need to mutate them.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D21992197
fbshipit-source-id: f8aee8db9ea1ff8282b38fbe3a966911678ee2c4
Summary:
Changelog: [Internal]
There is no need for custom dealloc, let's get rid of it.
We also prefer east const over west const.
Reviewed By: shergin
Differential Revision: D21997545
fbshipit-source-id: aa017f99aa26421fc59b353d0012687cb38fac08
Summary:
Changelog: [Internal]
Here is what I believe happens.
We have an instance of `RCTSliderComponentView` which has green thumb tint color.
It gets reused, in prepareForRecycle we call `setThumbTintImage:nil` on its UISlider which internally sets an ivar to `nil`.
Next time `RCTSliderComponentView` gets used without explicit thumb tint color, we assign nil to UISlider's thumb tint color.
Internally this nil gets compared to nil that it saved during `prepareForRecycle` and concludes that the value is already sets and exists early.
Since we don't have access to `UISlider` I can't prove this but here is a short video where I showcase this behavior
{F239923204}
The code in video is here P133083862.
Reviewed By: shergin
Differential Revision: D21997324
fbshipit-source-id: 28a11ed817cc863a313217c475042918ee726011
Summary:
Changelog: [internal]
We were not reseting value of slider when recycling, this would result in wrong value being displayed once slider gets reused.
Reviewed By: shergin
Differential Revision: D21996786
fbshipit-source-id: 3beac4936d0719c4ac5ac0499209300a912f6986
Summary:
This diff refactors ReactTextView to use uiManager.receiveEvent instead of ReactEventEmitter. ReactEventEmitter.class should be replaced for uiManager.receiveEvent.
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D21982548
fbshipit-source-id: 4ed5825f62c761564aa533f4e8bb1155036df7e2
Summary:
This diff migrates usages of RCTEventEmitter.class to EventDispatcher.dispatchEvent.
RCTEventEmitter is not compatible with Fabric, now we need to use EventDispatcher.dispatchEvent instead.
changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D21982549
fbshipit-source-id: 9ea2d9a00f063a03c2e401fc1e328ce26bcf48df
Summary:
This diff exposes receiveEvent on the UIManager class. This is necessary to support backward compatibility between Fabric and classic RN
changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D21979687
fbshipit-source-id: 1ec75896687d55e699f79c520e21f05fac368ee6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/29090
Moving the logic for calling into JS to handle errors into ErrorUtils, where it can be reused outside of the bridge.
Reviewed By: RSNara
Differential Revision: D21939254
fbshipit-source-id: 0d8f3bd2503720be7619ed8dc8b2389f544049f3
Summary:
Because of the previous diffs there's an increased chance of race conditions between JS executing and queuing up PreAllocateViewMountItems for surfaces that are stopped. Make sure those are ignored if they're queued up and a surface has been stopped.
Currently stopSurface only happens on the UI thread; PreAllocateViewMountItems can be queued from any thread, but are only executed on the UI thread. So once a batch of items starts executing, there's no race between teardown and execution: we just need to make sure we check that the surface is still running initially.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21965839
fbshipit-source-id: 0241dc171022cc923b7e38dcd110d664096dde79
Summary:
In the past, in Fabric (Android), we never called stopSurface. Ever! This is bad for memory and can cause other issues, so... let's not do that.
Instead, when the ReactRootView is being torn down, we check the View ID to see if it's a Fabric RootView, and if it is, we call Fabric's stopSurface method.
Fabric stopSurface only has impact on (1) Fabric mount instructions being executed after that point and (2) tells JS to stop running the surface, on the JS thread, asynchronously.
Anecdotally it looks like all the MountItems involved in deleting and removing views from the hierarchy are executed before stopSurface is called.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21965837
fbshipit-source-id: 5169c5a1e339fd9e016ae1234d8389b2bd30be70
Summary:
Restore legacy support for mixed union types.
These are not type safe and modules should use a different type, but we have a precedent for supporting these in the existing Linking native module. The new codegen will generate native code for these, and show a warning to encourage use of a better type.
Generate native code for elements in arrays of objects.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D21848260
fbshipit-source-id: 0b8cbf25e7a02791b4d77e349227a2b0744854f4
Summary:
In Fabric, some uses of the ScrollViewStickyHeader don't work after scrolling because even though the UI correctly reflects the translateY that the StickyHeader should be at, the underlying C++ Fabric ShadowTree doesn't have the updated parameters.
1. We add a mechanism to pass static props through to animated nodes; these get passed to the platform through the normal commit-diff process. This is to allow passing props to the platform that are also controlled by the animation. This mechanism could be reused elsewhere.
2. In ScrollViewStickyHeader, listen to updates for the translateY value and pass them to the platform when it stops changing - for Fabric only. This noops for non-Fabric since it's not necessary.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21948830
fbshipit-source-id: b203ecde466732203dd12a86e2339e81f66b27e7
Summary:
This has caused SEVs because the warning has gone unnoticed, so upgrading to error which should be much harder to miss or ignore.
https://fb.workplace.com/groups/rn.core/permalink/2680043542227367/
# Changelog
[Internal] update nested VList warning to error
Reviewed By: TheSavior
Differential Revision: D21945364
fbshipit-source-id: 88a9a9ab0b51e0afcf9b25be9854f65a61f419af
Summary:
Changelog:
[iOS][Removed] - Removed DEPRECATED_sendUpdatedChildFrames prop to ScrollView component because there are no callsites of it anymore
Reviewed By: shergin
Differential Revision: D21941946
fbshipit-source-id: 0b7d6d0986ddff4b250e70e0450a6f7e166b41f4
Summary:
While I was investigated the previous issue (T59430348) I found this place where we manipulate managed pointers manually. So, to make it error-prone this diff changes it to use `wrapManagedObject`.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D21943010
fbshipit-source-id: ecaeffb419ae8d4880187027ca7ec9563e0dfd46
Summary:
ManagedObjectWrapper (`wrapManagedObject`) is used to pass pointers managed by Objective-C runtime object thought C++ parts of the framework. The wrapper consists of a shared pointer to an object with a custom deleter that calls `CFRelease`.
Apparently, there is a caveat here: shared ptr implementation always calls a deleter even if the object points to `nullptr`. It's usually fine because in C++ calling `delete` on a nullptr is a no-op, not an error. But it's an error from the `CFRelease` perspective, which checks the pointer and crashes if it's nullptr.
More info:
https://stackoverflow.com/questions/1135214/why-would-cfreleasenull-crashhttps://stackoverflow.com/questions/50201967/why-unique-ptr-with-custom-deleter-wont-work-for-nullptr-while-shared-ptr-does
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D21943011
fbshipit-source-id: 442ad5e274a146de112e6bd8f3c2d20f0225bf77
Summary:
Changelog: [Internal]
`CFRelease` crashes app if `cf` is `NULL`, `CGColorRelease` doesn't.
From:
https://developer.apple.com/documentation/coregraphics/1586340-cgcolorrelease?language=objc#
Even though this hasn't happened yet, we had a similar crash in D21943011. Also `CGColorCreate` returns nullable so it could happen.
In order to prevent this in the future, let's switch to `CGColorRelease` which doesn't crash if `cf` is `NULL` and also is semantically correct.
Reviewed By: shergin
Differential Revision: D21953404
fbshipit-source-id: 8b969ee345c2507fcba2442fa20e3fdaf2235d8c
Summary:
Changelog: [Internal]
View gets flattened even though it has `display: none` and therefore it and its children do not get hidden.
Reviewed By: shergin, mdvacca
Differential Revision: D21929033
fbshipit-source-id: 994a79fb64fbe66273a70218ebe8056d92cd3cd4
Summary:
Changelog: [Internal]
RCTScheduler was storing Scheduler as `shared_ptr`, but `RCTScheduler` is sole owner of it.
`unique_ptr` better expresses this ownership.
Reviewed By: JoshuaGross
Differential Revision: D21923573
fbshipit-source-id: e382f2d6e0a4875e1441b6063c1ad7056b338e29
Summary:
From the header of `RCTSurfaceHostingProxyRootView`:
This is a RCTRootView-compatible implementation of RCTSurfaceHostingView.
Use this class to replace all usages of RCTRootView in the app for easier migration
I need to do exactly this, but for a bridgeless mode callsite. This proxy class only uses the bridge for some perf logging, which we're fine with not having right now.
Reviewed By: shergin
Differential Revision: D21893522
fbshipit-source-id: 3547cff6143f44714e39e4104d03336010081e2e
Summary:
This dependency upgrade ensures that this eslint config now supports the latest TypeScript syntaxes.
## Changelog
[General] [Fixed] - Upgrade dependencies.
Pull Request resolved: https://github.com/facebook/react-native/pull/29048
Test Plan: Try this new version of the plugin on your project.
Reviewed By: GijsWeterings
Differential Revision: D21879997
Pulled By: cpojer
fbshipit-source-id: cb54c2b56361f7c20994d981c61826f7f50350de
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/29087
D21908523 added an implicit dependency on `jsi.h` to use functions like `asObject`, etc. For some reason this doesn't break the build with BUCK (??) but it does with cocoapods. Adding the dep to the cxxreact podspec and regenerating offline mirrors to unbreak CircleCI. Also adding the BUCK dep and include statement for good measure.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21924592
fbshipit-source-id: 295c0670c6499e1195ba3c3a3320c6aee13bc025
Summary:
Changelog: [Internal]
The crash is caused by dereferencing invalid pointer.
This can happen because `UIManager` can outlive `RCTScheduler` and `Scheduler`.
Here we make sure when `Scheduler` is being deconstructed, UIManager's pointer is invalidated.
I don't think this is ideal solution but it should fix the crash.
Ideally we want the owner of animation delegate to invalidate the pointer.
Reviewed By: JoshuaGross
Differential Revision: D21922910
fbshipit-source-id: b2a56c1104574cecebaffad1bcbcbff82c1fa0cf
Summary:
This diff disables the state list animator from the ReactSlider object used to measure ReactSlider.
The motivation is to fix T63030542, which it seems to be caused by the state list animator being accessed and modified from different threads
We don't have a way to reproduce, but based on my analysis this diff will fix T63030542.
I would like to land this diff and then keep tracking production data for the crash reported on T63030542
Changelog:
[Android][Fixed] Fix intermittent crash of ReactSlider on Android
Reviewed By: fkgozali
Differential Revision: D21920698
fbshipit-source-id: 54af388043d5041c4bf981c81364780d3f52d818
Summary:
Call into our existing JS error handling logic from C++ using JSI in the RuntimeExecutor used by the bridge.
Changelog: [Internal]
Reviewed By: lunaleaps
Differential Revision: D21908523
fbshipit-source-id: ae41196443781b9f2673dcb7bbcb5b5aa8aa2528
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/28875
Update Fabric's Android binding to use a RuntimeExecutor instead of the `jsContext`, which is actually just the runtime pointer. This diff uses the RuntimeExecutor from CatalystInstanceImpl (in the previous diff) which uses the bridge under the hood.
Changelog: [Android][Changed] Modified Fabric's public-facing API on Android
Reviewed By: mdvacca
Differential Revision: D21051975
fbshipit-source-id: 9c17ad1986f90c12af457d88a5035553e0e7ceb0
Summary:
Introduce SurfaceId to the BatchMountItem. Do not execute it if the associated Surface has gone away.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21895452
fbshipit-source-id: 5df56720ce9b4293693884ebe105bda1dc87700e
Summary:
As a simple refactor, I want to 1) have `synchronouslyUpdateViewOnUIThread` only catch exceptions for the specific MountItem being synchronously executed, 2) not assume that scheduleMountItem will always cause synchronous execution.
I think this makes the logic here a little more clear and it scopes how we swallow exceptions, which could be swallowing too many errors right now actually.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21911804
fbshipit-source-id: 1b1a465cadd60c72c69b556469276c9ee6b2dfcc
Summary:
Changelog: [Internal]
# Problem
`MountingCoordinator` holds a pointer to instance of `MountingOverrideDelegate` which becomes invalid.
# Solution
Use `std::weak_ptr` instead of raw pointer so it is possible to tell whether the pointer is expired.
Reviewed By: JoshuaGross
Differential Revision: D21905351
fbshipit-source-id: c7bf9635742a6ec086a03ba83202e46e1f1f373f
Summary:
This diff adds support elevation prop in Fabric core, additionally it adds this prop as non collapsable on the view flattening algorithm
changelog: [Internal] internal change in fabric to support elevation prop
Reviewed By: JoshuaGross
Differential Revision: D21896465
fbshipit-source-id: e0854acc0b2ac30eaf3f82d615aab1cf378cc530
Summary:
Changelog: Move collapsable to Shared View props
I'm researching why `collapsable` isn't passed to Fabric UIManager in production build, I discovered that collapsable was Android only prop but in Fabric we use it in iOS as well.
This doesn't fix the collapsable not being passed through but I think this makes code semantically correct.
Reviewed By: mdvacca
Differential Revision: D21862770
fbshipit-source-id: 492c6a15955b907dbbeb8530c81f6a868cf379c3
Summary: TurboModules doesn't cache invocations of getConstants(). This diff looks at which NativeModules' getConstants() methods gets repeated called in Marketplace, and caches those invocations in JS.
Reviewed By: fkgozali
Differential Revision: D21874123
fbshipit-source-id: a44b98b3ac8621f67c9c0f3b7c4003a561d1e15d
Summary: TurboModules doesn't cache invocations of getConstants(). This diff looks at which NativeModules' getConstants() methods gets repeated called in Marketplace, and caches those invocations in JS.
Reviewed By: fkgozali
Differential Revision: D21874124
fbshipit-source-id: 03d2318e1b6d00236ef707f9f19a640bf8c08786
Summary:
Noticed this hanging around when reading MessageQueue, delete it.
Changelog: [internal]
Reviewed By: fkgozali
Differential Revision: D21874609
fbshipit-source-id: 627c6a18cdb859a1aaf2eb596f8744156d18393c
Summary:
JSError creation can lead to further errors. Make sure these cases
are handled and don't cause weird crashes or other issues.
This solution has a few parts:
* include a ScopedNativeDepthTracker in checkStatus
* If an exception object message or stack property is already a String, don't
call JS String ctor on it
* Verify that a jsi::Value is a String before calling getString on it.
* Add more tests for JSError construction
Changelog: [Internal]
Reviewed By: dulinriley
Differential Revision: D21851645
fbshipit-source-id: 2d10da0e741ad4ede93cd806320f68ad512e5138
Summary:
There are two ways to make a NativeModule method execute synchronously:
- Declare the NativeModule method to be synchronous (i.e: use `RCT_EXPORT_BLOCKING_SYNCHRONOUS_METHOD`).
- Make the NativeModule synchronous (i.e: make its method queue `RCTJSThread`). This way, all its methods are synchronous.
`RCTNativeModule` executes all synchronous methods on the JS thread:
- Executing an async methods on a sync module: https://git.io/JfRPj
- Executing a sync method: https://git.io/JfRXe
However, in TurboModules we block the JS thread, execute the method on the NativeModule's method queue, and then unblock the JS thread. While this approach is thread-safe, and arguably the correct way to dispatch sync methods, it's also much slower than the alternative. Therefore, this diff migrates the legacy behaviour to the TurboModule system.
## Special Case: getConstants()
When an ObjC NativeModule requires main queue setup, and it exports constants, we execute its `constantsToExport` method on the main queue (see: [RCTModuleData gatherConstants](https://github.com/facebook/react-native/blob/c8d678abcf93fd3f6daf4bebfdf25937995c1fdf/React/Base/RCTModuleData.mm#L392-L402)). I replicated this behaviour with TurboModules.
Changelog:
[iOS][Fixed] - Execute ObjC TurboModule async method calls on JS thread for sync modules
Reviewed By: fkgozali
Differential Revision: D21602096
fbshipit-source-id: 42d07b7ad000abeac27091dc3ec440e3836d2eae
Summary:
## Context
- If a NativeModule requires main queue setup, its `constantsToExport` method is executed on the main queue.
- In the TurboModule system, `constantsToExport` or `getConstants` is treated like a regular synchronous NativeModule method. Therefore, it's always executed on the JS thread.
This difference in behaviour is dangerous when we're A/B testing the TurboModule infra: One could write a NativeModule that requires main queue setup, and have it expose constants that access objects/state only accessible on the UI thread. This NativeModule would work fine in the legacy infra, which could be the case if the NativeModule author is testing locally. But once it ships to prod, it may run with the TurboModule system, and crash the application. To mitigate this risk, I'm removing this special main queue execution of `constantsToExport` from the legacy infrastructure.
## Consequences
- If a NativeModule's `constantsToExport` method accesses objects/state only accessible on the UI thread, it must do so by explicitly scheduling work on the main thread. I wrote up a codemod to fix this for our OSS modules: D21797048.
- Eagerly initialized NativeModules that required main queue setup had their constants calculated eagerly. After the changes in this diff, those NativeModules will have their constants calculated lazily. I don't think this is a big deal because only a handful of NativeModules are eagerly initialized, and eagerly initialized NativeModules are going away anyway.
Changelog:
[iOS][Removed] - Main queue execution of constantsToExport in NativeModules requiring main queue setup
Reviewed By: fkgozali
Differential Revision: D21829091
fbshipit-source-id: df21fd5fd2ef45a291c07400f360bba801ae290f
Summary:
If a NativeModule requires main queue setup, its `getConstants()` method must be executed on the main thead. The legacy NativeModule infra takes care of this for us. With TurboModules, however, all synchronous methods, including `getConstants()`, execute on the JS thread. Therefore, if a TurboModule requires main queue setup, and exports constants, we must execute its `getConstants()` method body on the main queue explicitly.
**Notes:**
- The changes in this diff should be a noop when TurboModules is off, because `RCTUnsafeExecuteOnMainQueueSync` synchronously execute its block on the current thread if the current thread is the main thread.
- If a NativeModule doens't have the `requiresMainQueueSetup` method, but has the `constantsToExport` method, both NativeModules and TurboModules assume that it requires main queue setup.
## Script
```
const exec = require("../lib/exec");
const abspath = require("../lib/abspath");
const relpath = require("../lib/relpath");
const readFile = (filename) => require("fs").readFileSync(filename, "utf8");
const writeFile = (filename, content) =>
require("fs").writeFileSync(filename, content);
function main() {
const tmFiles = exec("cd ~/fbsource && xbgs -n 10000 -l constantsToExport")
.split("\n")
.filter(Boolean);
const filesWithoutConstantsToExport = [];
const filesWithConstantsToExportButNotGetConstants = [];
const filesExplicitlyNotRequiringMainQueueSetup = [];
tmFiles
.filter((filename) => {
if (filename.includes("microsoft-fork-of-react-native")) {
return false;
}
return /\.mm?$/.test(filename);
})
.map(abspath)
.forEach((filename) => {
const code = readFile(filename);
const relFilename = relpath(filename);
if (!/constantsToExport\s*{/.test(code)) {
filesWithoutConstantsToExport.push(relFilename);
return;
}
if (!/getConstants\s*{/.test(code)) {
filesWithConstantsToExportButNotGetConstants.push(relFilename);
return;
}
if (/requiresMainQueueSetup\s*{/.test(code)) {
const requiresMainQueueSetupRegex = /requiresMainQueueSetup\s*{\s*return\s+(?<requiresMainQueueSetup>YES|NO)/;
const requiresMainQueueSetupRegexMatch = requiresMainQueueSetupRegex.exec(
code
);
if (!requiresMainQueueSetupRegexMatch) {
throw new Error(
"Detected requiresMainQueueSetup method in file " +
relFilename +
" but was unable to parse the method return value"
);
}
const {
requiresMainQueueSetup,
} = requiresMainQueueSetupRegexMatch.groups;
if (requiresMainQueueSetup == "NO") {
filesExplicitlyNotRequiringMainQueueSetup.push(relFilename);
return;
}
}
const getConstantsTypeRegex = () => /-\s*\((?<type>.*)\)getConstants\s*{/;
const getConstantsTypeRegexMatch = getConstantsTypeRegex().exec(code);
if (!getConstantsTypeRegexMatch) {
throw new Error(
`Failed to parse return type of getConstants method in file ${relFilename}`
);
}
const getConstantsType = getConstantsTypeRegexMatch.groups.type;
const getConstantsBody = code
.split(getConstantsTypeRegex())[2]
.split("\n}")[0];
const newGetConstantsBody = `
__block ${getConstantsType} constants;
RCTUnsafeExecuteOnMainQueueSync(^{${getConstantsBody
.replace(/\n/g, "\n ")
.replace(/_bridge/g, "self->_bridge")
.replace(/return /g, "constants = ")}
});
return constants;
`;
writeFile(
filename,
code
.replace(getConstantsBody, newGetConstantsBody)
.replace("#import", "#import <React/RCTUtils.h>\n#import")
);
});
console.log("Files without constantsToExport: ");
filesWithoutConstantsToExport.forEach((file) => console.log(file));
console.log();
console.log("Files with constantsToExport but no getConstants: ");
filesWithConstantsToExportButNotGetConstants.forEach((file) =>
console.log(file)
);
console.log();
console.log("Files with requiresMainQueueSetup = NO: ");
filesExplicitlyNotRequiringMainQueueSetup.forEach((file) =>
console.log(file)
);
}
if (!module.parent) {
main();
}
```
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D21797048
fbshipit-source-id: a822a858fecdbe976e6197f8339e509dc7cd917f
Summary:
These logs are no longer necessary, because data indicates that the TurboModule eager init crash was fixed.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D21852743
fbshipit-source-id: ddeefd6396283ee5e15980a33fb006cb83a81532
Summary:
I was doing some bundle inspection and noticed the LogBox module was included. It does amount to around 15kb so I think it is worth making sure it is not there.
To fix it I moved some imports to require inside __DEV__ blocks to make sure metro is able to remove these imports.
## Changelog
[General] [Fixed] - Make sure LogBox is not included in production bundles
Pull Request resolved: https://github.com/facebook/react-native/pull/28984
Test Plan: Tested using react-native-bundle-visualizer and made sure nothing from LogBox was included in the bundle after these changes.
Reviewed By: TheSavior
Differential Revision: D21794466
Pulled By: rickhanlonii
fbshipit-source-id: 6cb0c0a89633e9850019bd61478c35e9c21638dc
Summary:
Remove usage of the legacy context API in Modal in favor of the new context API. Closes https://github.com/facebook/react-native/issues/28103
Pull Request resolved: https://github.com/facebook/react-native/pull/29002
Test Plan: Run RNTester app and test the Modal example. Also add a `console.warn` to make sure we get the correct context value.
Differential Revision: D21793993
Pulled By: TheSavior
fbshipit-source-id: de2a30cbd46507bfa73a563d2429c5a7f0e320c9
Summary:
Changelog: [Internal]
# Problem
JS inspector overlay gets flattened, therefore `onResponderMove` callback isn't called. JS inspector depends on `onResponderMove` because that's how it knows where on screen user has tapped.
https://our.intern.facebook.com/intern/diffusion/FBS/browse/master/xplat/js/react-native-github/Libraries/Inspector/InspectorOverlay.js?commit=2e9ab04b039a&lines=58
# Workaround
This is just a hack to get it working, setting nativeID forces stacking context to be created and therefore view not being flattened.
Reviewed By: mdvacca
Differential Revision: D21816513
fbshipit-source-id: 83aedbfaecdce22cfe202241cbe91cecb914ed6b
Summary:
At some early stages of Instance initialization, it does not have a `nativeToJsBridge_`. At the same time, `handleMemoryPressure` can be called at any point in time, so we should check the pointer for not being null before calling on it.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D21798522
fbshipit-source-id: 6384da88784cceb493cf9810408cbb47777d3f4b
Summary:
This change is especially important for Fabric when a lot of objects (mostly ShadowNodes) have shared ownership. Without this change, JSVM could not know that bunch of natively allocated objects should be deallocated.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D21798527
fbshipit-source-id: f2051721b074b99660cdfd6c5b75679b9792403e
Summary:
Removing logs related to T62192299 that we don't need anymore.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21773629
fbshipit-source-id: d16c01f87be3ed7512fe90b6e261b4c7efbd3068
Summary:
just a minor change - uses the [count api](https://reactjs.org/docs/react-api.html#reactchildrencount)
> Returns the total number of components in children, equal to the number of times that a callback passed to map or forEach would be invoked.
## Changelog
not needed I think
Pull Request resolved: https://github.com/facebook/react-native/pull/28991
Test Plan: tested locally
Differential Revision: D21794081
Pulled By: TheSavior
fbshipit-source-id: bf6d11b2bc854d938aed7268911f89a00bb3f596
Summary:
Changelog: [Internal]
# Problem
Before every update, restoreDefaults is called on animated nodes. In paper this makes sure no stale properties are on animated nodes. In paper it works fine because restoreDefaults is called before mounting and animations are triggered after mounting within single commit.
Details: https://github.com/facebook/react-native/pull/11819
In Fabric however it is called outside of other mounting operations and it applies default values to the view and then re-applies animated values.
Reviewed By: JoshuaGross
Differential Revision: D21786765
fbshipit-source-id: a2cb6d6d9cbd39d4c403c97c2f51e7d92078102f
Summary:
All ReactViewPager functionality should now be possible by using a ScrollView.
Changelog: [Internal] ReactViewPager has been deprecated on Android and was removed from core as part of LeanCore
Reviewed By: mdvacca
Differential Revision: D21751774
fbshipit-source-id: 292475b9ffe7788b745329d13fd88dc3b613819e
Summary:
After the experiment in D21198302 ships to 100% and that code is deleted, we no longer need ViewPagerAndroid anywhere in FB so it can be deleted.
This is distinct from deleting the native side of the component, which resides in open-source.
Changelog: [Internal]
Differential Revision: D21211134
fbshipit-source-id: 610e09792b079d34acbfcec836fde58a0b3648a7
Summary:
This diff reverts the workaround added as part of D21432793, now that D21432793 is released in production for FB4A / FBiOS
changelog:
[Internal]
Reviewed By: JoshuaGross
Differential Revision: D21772129
fbshipit-source-id: 3b39738cb8fc871ec85d87f347c7f0ef408ccc3e
Summary:
This diff extends the measurement of Text components in order to support empty strings.
This is required for parity with Paper.
I created a follow up task to analyze support of empty string as part of the Text infrastructure of Fabric in the future.
changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D21761171
fbshipit-source-id: d2aa074052b09732af5d35723f19014090fcabbf
Summary:
`getStackTracesTreeNodeForAlloc` only works for memory that was tracked with `newAlloc`.
For now, that is only memory that goes through GC APIs.
Various places were calling this function on native memory which was allocated
with `malloc`, not GC memory. This led to SIGSEGV on nullptr when trying to take heap profiles
of these objects.
`newAlloc` could, in theory, work with native memory as well. But building out support for that
is outside the scope of this fix.
Changelog: [Internal]
Reviewed By: jbower-fb
Differential Revision: D21667842
fbshipit-source-id: 8403a6668e5ec607972ce6819f78fedb89da3f37
Summary:
This diff updates our RCTKeyCommands code to be more resilient by copying the [FLEX strategy for key commands](https://github.com/Flipboard/FLEX/blob/master/Classes/Utility/Keyboard/FLEXKeyboardShortcutManager.m).
This strategy swizzles UIApplication handleKeyUIEvent which is further upstream than our UIResponder. It also allows for single key hotkeys like pressing just `r` instead of `cmd+r`. It does this without interfering with typing input by checking the first responder first.
I've also updated our hotkey handling to support using just the keys like `r` in addition to `cmd+r`. In addition to brining these hotkeys more in line with other iOS tools, they're also easier to use and do not suffer the same issues hotkeys with modifiers like `cmd` have where keys are dropped.
Changelog: [iOS] [Added] Allow hotkeys to be used without command key
Reviewed By: shergin
Differential Revision: D21635129
fbshipit-source-id: 36e0210a62b1f310473e152e8305165024cd338b
Summary:
As a followup to D21750097 and D21735940, it seems that ANY uses of childCount will be incorrect as they are "often" reported, incorrectly, as just 0.
This is likely due to exotic cases like (1) the ViewManager childCount being overridden, or (2) special ViewManagers like BottomSheet where the childCount may actually be 1/0 even though many children are inserted.
Anyway, as a more generic fix, let's only rethrow an existing Exception with additional diagnostics instead of trying to detect when this /would/ crash.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21756178
fbshipit-source-id: 17ffb2ed531978bae8d4db19d7b87ec62397e44b
Summary:
We cannot call `parentView.getChildCount()` directly, we must get the child count through the ViewManager:
A simple `Log.e` call shows:
```
MountingManager: parentView.getChildCount(): 0 // viewGroupManager.getChildCount(parentView): 7
```
This difference does not occur for ALL views, but it occurs for... enough that this will crash on basically ~every screen, at least on navigation when all views are removed.
Theory about why this is happening: some ViewGroup types compute childCount differently, especially if we do some sort of custom child management for some view type? By coercing to `T` which the ViewManager does, we call getChildCount on the correct class type. This is just a hypothesis, though. But the failing views are all `View`s and it does look like `ReactClippingViewManager` has custom `getChildCount` logic, so that's likely the answer.
There's no such thing as an easy diff!
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21750097
fbshipit-source-id: 3d87d8f629a0c12101658050e57e09242dfc2a8c
Summary:
When a property returns an array type, use the actual element type when generating structs and inlines.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D21651351
fbshipit-source-id: 14cadf209c38a301c9c65fcaadd8a292c1936349
Summary:
I have a theory that T53114059 can be caused by (1) other crashes, and/or (2) reloads. Clear out the ID of a RootView when it is detached.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21732066
fbshipit-source-id: 5e607f34cf42ca26bdf199d5d3024fd49a60dc1e
Summary:
This changes how we access the EventDispatcher from the FabricUIManager in bridgeless mode.
Currently, we have implemented a similar API to what we use for Fabric (used in UIManagerHelper): `BridgelessReactContext.getJSIModule(UIManager).getEventDispatcher()`. However, `getJSIModule` does not have a nullable return type, which means that we have to throw an exception if the UIManager can't be found - if, for example, the instance is not initialized yet (or has been destroyed). This is causing crashes when a view tries to access the EventDispatcher before the instance is initialized, which takes longer for Venice because we include JS bundle loading as part of initialization (we may need to revisit that).
Ideally, we'd like to create a first-class API for `getEventDispatcher()`, and make sure that it never crashes if the instance is destroyed, because we don't care if JS events aren't delivered at that point. However, there are some obstacles to making this change for the bridge - mostly related to avoiding circular dependencies between the bridge module and the uimanager module. (Also, this might be a behavior change for the bridge, because I think we currently start queueing events before it's initialized? and product code might be relying on that).
Reviewed By: mdvacca
Differential Revision: D21672949
fbshipit-source-id: a38e96cd40c6f70124b7ca2a5c9722988fe7fcf4
Summary:
See https://github.com/babel/babel/releases/tag/v7.10.0 for changes
It includes a change I asked the Babel team for as they have been wrapping object spread calls with lots of extends call for spec compliance, but that only matters when you have side-effectful getters that affect the rest of the objects in the spread call and are order dependent. We should not be depending on such behavior in FB code so we can use loose mode and benefit from the app size wins.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D21738344
fbshipit-source-id: 5eeff47481e474bb41183119d990692b31751dd5
Summary:
Error messages like P131885276 don't help debugging, even when all mount instructions are logged to logcat. This log would help identify the incorrect mount instruction.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21735940
fbshipit-source-id: 16ff315c11ccafdd75d0ad9c7c60b7be2cd73202
Summary:
This was added in D3343907 June 1st 2016, disabled in D3428043 June 16, 2016 and never re-enabled.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D21635227
fbshipit-source-id: db51dfb6271359bea7da34b4e2a71931fc7c2a63
Summary:
This diff adds a new swizzling method for replacing instance methods with blocks.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D21635131
fbshipit-source-id: c8061817bed66dad160efffee5a13c8714134540
Summary:
Index adjustment doesn't work if virtual views are inserted, because those don't actually result in the view hierarchy being mutated, as such.
Add an Android-specific check to solve the crash.
I don't love adding platform-specific checks here, so I'm considering wrapping this logic in a platform-specific class, so that logic lives outside of the core of LayoutAnimations and entirely in platform code.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21727805
fbshipit-source-id: 5af2cf479beaa4d0e9d94ea16ac989c4268920f8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/28983
Creating an interface for EventDispatcher so I can implement it from a dummy/no-op EventDispatcher to use in bridgeless mode when the instance isn't alive.
Changelog: [Android] [Changed] Renamed EventDispatcher to EventDispatcherImpl and created EventDispatcher interface; calls to EventDispatcher contstructor need to be updated
Reviewed By: makovkastar
Differential Revision: D21695401
fbshipit-source-id: 46066a467efcf03a5f484bb9fb58c662d46a2c4e
Summary:
property and type are optional params according to Flow, so we should treat as such.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21725746
fbshipit-source-id: 3c48a8cef8fa5911c195f582556de6dad871c4f1
Summary:
This is the second part of a rewrite of D15390384, which allows Animated timing to be driven by Paper or Fabric.
The intuition is: we don't care which one drives the animation. We will expect one or both of them to issue a callback that operations are about to be executed, and the first one wins. The blocks will only execute once, the second time will be a noop.
I don't think there's a 100% safe way of reimplementing Native Animated Module for Fabric/Venice (without a new API and implementing in C++) since it's inherently disconnected from the commit process and the tree. This gets us slightly closer to visual functionality, though.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21698192
fbshipit-source-id: c11d3cebd12cfc8acf4b63c87ccbe62cdbd8b672
Summary:
This is (part of) a rewrite of D15390384.
This implements the lifecycle interface only for Fabric to signal to NativeAnimatedModule when preOperations are about to run / operations are about to be dispatched.
We will likely want to remove this mechanism entirely and rewrite NativeAnimatedModule in C++ for Fabric/Venice, but for now, I'm not sure of a better solution to unblock.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21698193
fbshipit-source-id: a13d445073911fd63d896202a7a1bfbe1167038a
Summary:
A key difference in WeakRefs with the Hades GC is that they are mutable,
in the sense that reading the value of a WeakRef while a GC is active might
clear the WeakRef.
For this reason, attempting to lock the WeakObject might mutate the backing
reference.
I preferred to communicate this change in behavior via the API rather than
`const_cast` it away inside the implementation.
Changelog: [Internal] Change jsi::WeakObject to be mutable in lockWeakObject
Reviewed By: mhorowitz
Differential Revision: D21485758
fbshipit-source-id: 3618928be8f8791aed56cb20673896ff5b786ded
Summary:
Simple diff to add ART components into Catalyst app Android
changelog: [Internal] Internal changes to add support of ART for Fabric
Reviewed By: JoshuaGross
Differential Revision: D21621479
fbshipit-source-id: d957c25f447d19d8f349c69aa20f5f19237d867a
Summary:
Here I'm implementing equality methods for ARTGroup, ARTShape and ARTText and I'm using these methods to update the state only when it is necessary.
This will improve perf in rendering of ART
changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D21695127
fbshipit-source-id: b438ddea4c34bd7a0bdf26a6aac4fd62a9f78b49
Summary:
Element, Shape, Group, Text are too generic, we are renaming these classes to ARTElement, ARTBGroup, ARTShape...
changelog: [Internal] internal changes to support ART in android
Reviewed By: JoshuaGross
Differential Revision: D21681878
fbshipit-source-id: f6b35443486a3db210f61dcaf91bd32df47fbc66
Summary:
This diff adds support for Text in ART Fabric Android
changelog: [Internal] internal changes to fully support ART in Fabric
Reviewed By: JoshuaGross
Differential Revision: D21681877
fbshipit-source-id: c92e642cff56b71f8ee8f4eb9af6eea6c490f6c7
Summary:
This diff implements the serialization of Text components to send data from C++ to java
changelog: [Internal] internal changes to support ART in fabric
Reviewed By: JoshuaGross
Differential Revision: D21681875
fbshipit-source-id: eba31f35c95e0a2d3226ec70421832719083d7fa
Summary:
This diff refactors the types of ART Text classes, this is necessary on the next diffs of the stack
closeoncommit
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D21681876
fbshipit-source-id: ea438e89df6d860b3ff8bbdae657ca123b417a1b
Summary:
While we build react native 0.62.2 via our Bazel build system, encountered those following errors due to lack of appropriate imports:
```
external/React-Core/React/Base/RCTUtilsUIOverride.h:8:33: error: cannot find interface declaration for 'NSObject', superclass of 'RCTUtilsUIOverride'
interface RCTUtilsUIOverride : NSObject
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^
external/React-Core/React/Base/RCTUtilsUIOverride.h:12:37: error: expected a type
+ (void)setPresentedViewController:(UIViewController *)presentedViewController;
^
```
Add the appropriate imports `<Foundation/Foundation.h>` and `<UIKit/UIKit.h>` fix those errors.
Honestly I dont know how it's supposed to work without those imports. Also all the siblings files have the correct imports. e.g. [RCTUtils.h](https://github.com/discord/react-native/blob/15a5f3624c40624d8dd0307bbcc1f2b2aba15a1b/React/Base/RCTUtils.h)
## Changelog
[iOS] [Fixed] - Fix imports in `RCTUtilsUIOverride.h`
Pull Request resolved: https://github.com/facebook/react-native/pull/28946
Test Plan: RN tester iOS app runs fine.
Differential Revision: D21700030
Pulled By: shergin
fbshipit-source-id: 9ef806b8f656bdad289fbdd3d84ecefb0dea6afb
Summary:
When `minPressDuration` was introduced to `Pressability`, all of the legacy Touchable components inherited the new default.
This restore the former behavior for these legacy components so that only `Pressable` gets the new `minPressDuration` default value.
Changelog:
[General][Fixed] - Revert `minPressDuration` effect on legacy Touchable components
Reviewed By: fkgozali
Differential Revision: D21682764
fbshipit-source-id: b71a61843fae7f0f726155876a064fabd3ba1c64
Summary:
Changelog: [Internal]
`BatchedEventQueue::enqueueUniqueEvent` goes over event queue and deletes previous event of the same type and same target.
This is useful for ScrollView for example where only the latest event is relevant.
This only affects ScrollView scroll event, other events take the original code path.
Reviewed By: mdvacca
Differential Revision: D21648906
fbshipit-source-id: a80ad652058fd50ebb55e24a87229cdc1764b591
Summary:
Changelog: [Internal]
Separates EventQueues from an array into 4 ivars.
EventQueues are of different type, in the future we will want to call different methods on different kind of EventQueue.
Reviewed By: shergin
Differential Revision: D21648905
fbshipit-source-id: 90ae65edb8a9276eecfea9770f554d8c56804797
Summary:
Changelog: [Internal]
# Problem
We were recording mount child component calls with its arguments and the replaying them inside `finalizeUpdates`.
However we store the events in NSDictionary where `key` was index at which the child should be added.
Then in `finalizeUpdates` we iterated over this NSDictionary and added those views into our paper view.
`NSDictionary` is unordered, it isn't guaranteed what was first inserted into it, will be first iterated over.
# Solution
Use `NSMutableArray` instead which guarantees order.
Reviewed By: shergin
Differential Revision: D21685993
fbshipit-source-id: 3b933f05125130eef175d7a8a56f29012ee76bb3
Summary:
Changelog: [Internal]
# Problem
Yoga internally uses address of owner to determine whether a node should be cloned or it shouldn't.
During layout, it traverses the tree and looks whether current parent is equal to child's owner. If it isn't it means the yoga node is shared between 2+ trees and need to be cloned before mutated. Parent in yoga is stored as reference to the parent.
We can run into an issue where yoga node is shared between 2+ trees, but its current parent is equal to child's owner. This is because we reallocate new parent at address where its previous parent lived. This happens over few iterations, the old parent is first deallocated.
This is known as ABA problem.
# Solution
When we are cloning node, we loop over all children to see whether any of the is not using address of new `yogaNode_` as its owner. At this point we know this is accidental and set its owner to `0xBADC0FFEE0DDF00D`.
We chose `0xBADC0FFEE0DDF00D` because when someone is debugging this in LLDB and prints this address, it will hint them that it was artificially set and can string search for it in the codebase.
Reviewed By: shergin
Differential Revision: D21641096
fbshipit-source-id: c8b1b4487ea02b367f5831c1cdac055bce79c856
Summary:
This diff serializes ART state into folly::dynamic. this is necessary to send this data to Android
changelog: [Internal]
Reviewed By: shergin
Differential Revision: D21657608
fbshipit-source-id: 6c1b69af7d1dbe7de15e509f83c508a38294d89e
Summary:
This diff replaces the usage of int to represent the type of elements for an Enum
changelog: [Internal] Internal change to support ART in fabric
Reviewed By: shergin
Differential Revision: D21657706
fbshipit-source-id: 7bda0210d50136477f0524695d5406e35074f09c
Summary:
This diff integrates ART state into ARTSurfaceViewShadowNode
changelog: [Internal]
Reviewed By: shergin
Differential Revision: D21657611
fbshipit-source-id: 06bd4d610e2c52e0ef3bca423b93c9ad2318e8df
Summary:
This diff creates the internal state of ART based on its shadow nodes
changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D21657607
fbshipit-source-id: 0a15e90ee7465bf3a2b1001ff9d3198eb22fd708
Summary:
This diff introduces a set of classes that are going to be used to represent the internal State of ART nodes
changeLog: [Internal][Android] Internal change to support ART in Fabric
Reviewed By: JoshuaGross, shergin
Differential Revision: D21657612
fbshipit-source-id: ea6d94b06807ff02d222dfa129a1cae384dceeaa
Summary:
## Motivation
We got this crash T67304907, which shows a `EXC_BAD_ACCESS / KERN_INVALID_ADDRESS` when calling this line:
```
NativeModulePerfLogger::getInstance().asyncMethodCallBatchPreprocessStart();
```
There are no arguments in that call, so I figured the only error could be when we try to invoke `getInstance()` or `asyncMethodCallBatchPreprocessStart()`.
This diff:
1. Removes the `NativeModulePerfLogger::getInstance()` bit. Now NativeModulePerfLogger is used via regular static C functions. So, there's no way that simply invoking one of the logging functions crashes the application: there's no vtable lookup.
2. Inside each logging function, when perf-logging is disabled, the global perflogger should be `nullptr`. This diff makes it so that in that case, we won't execute any code in the control group of the perf-logging experiment.
## Changes
**How do we enable NativeModule perf-logging?**
- Previously:
- `NativeModulePerfLogger::setInstance(std::make_shared<FBReactNativeModulePerfLogger>(...))`
- `TurboModulePerfLogger::setInstance(std::make_shared<FBReactNativeModulePerfLogger>(...))`.
- Now:
- `BridgeNativeModulePerfLogger::enableLogging(std::make_unique<FBReactNativeModulePerfLogger>(...))`
- `TurboModulePerfLogger::enableLogging(std::make_unique<FBReactNativeModulePerfLogger>(...))`
**How do we do NativeModule perf-logging now?**
- Previously:
- `NativeModulePerfLogger::getInstance().command(...args)`
- `TurboModulePerfLogger::getInstance().command(...args)`.
- Now:
- `BridgeNativeModulePerfLogger::command(...args)`
- `TurboModulePerfLogger::command(...args)`.
The benefit of this approach is that each method in `BridgeNativeModulePerfLogger` is guarded with an if check. Example:
```
void moduleCreateConstructStart(const char *moduleName, int32_t id) {
NativeModulePerfLogger *logger = g_perfLogger.get();
if (logger != nullptr) {
logger->moduleCreateConstructStart(moduleName, id);
}
}
```
Therefore, we don't actually execute any code when perf-logging is disabled.
Changelog:
[Internal]
Reviewed By: fkgozali
Differential Revision: D21669888
fbshipit-source-id: 80c73754c430ce787404b563878bad146295e01f
Summary:
1. Split out the prop interpolation function out of the View ComponentDescriptor, into an inline'd function that can be used elsewhere.
2. Call it from View and from Paragraph component descriptors.
This causes animations including Text to look normal on iOS.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21675804
fbshipit-source-id: c34a317749fd6c108aef072d47f3dcb14ce8aa5c
Summary:
Implement a real Transform interpolation. It uses quaternions/Slerp to interpolate rotations. This allows us to interpolate scale, rotation, and translation simultaneously.
See caveats in code. Because of the way transform matrices work, there isn't much (anything?) we can do about skew, and certain values will look nonsensical. This seems to be true for any variant of this algorithm.
This is a big step up from Classic RN which didn't support this in LayoutAnimations at all.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21675805
fbshipit-source-id: a33494cc02c73102ca67c1d562efc4b2a7308a4a
Summary:
The LayoutAnimationStatusDelegate exists so that platforms can get a signal when animations are starting or have all completed.
This signal is meant to be used ONLY for driving animations at 60fps, or stopping that process, on the platform side.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21675807
fbshipit-source-id: e89ba524ea43c266556199c8854e8228869755e3
Summary:
Implement EaseIn, EaseOut, EaseInOut, and Spring with SpringDamping.
Note this does not yet implement Keyboard-type animation for iOS (coming soon), and the spring interpolator is VERY naive. We likely want to replace it with a "real" spring animation ASAP. The spring animation is identical to what Android does today, but would likely be a downgrade for iOS. I will do both in a followup.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21675810
fbshipit-source-id: ac98554ebc81f0b81fdacefd6d848e3566e424c0
Summary:
This is the V1 implementation of Fabric Core LayoutAnimations.
The intention is to structure this in such a way that it's easy for each platform to customize the "AnimationDriver" class (to do platform-specific optimizations) without changing the KeyFrameManager at all.
In the future, this structure and architecture should allow us to iterate faster on new animation APIs.
Changelog: [Internal] Support for LayoutAnimations in Fabric
Reviewed By: mdvacca
Differential Revision: D21675808
fbshipit-source-id: b3ef44729bb8b6217f90760aec9737276c9601d1
Summary:
Use transpiled `react-native-codegen` scripts. By avoiding use of flow-node, we no longer need to upgrade flow-remove-types in order to run the native modules codegen script.
The interface for the script remains the same:
```
./scripts/generate-native-modules-specs.sh [optionalOutputDir]
```
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D21629705
fbshipit-source-id: 7714a67e36c8151a3b0b49285b6a6c93a525d7bc
Summary:
1. Split out the prop interpolation function out of the View ComponentDescriptor, into an inline'd function that can be used elsewhere.
2. Call it from View and from Paragraph component descriptors.
This causes animations including Text to look normal on iOS.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D21635473
fbshipit-source-id: 470f43fd24a6e80d8696ee2f2a09d9e693b7f280
Summary:
Implement a real Transform interpolation. It uses quaternions/Slerp to interpolate rotations. This allows us to interpolate scale, rotation, and translation simultaneously.
See caveats in code. Because of the way transform matrices work, there isn't much (anything?) we can do about skew, and certain values will look nonsensical. This seems to be true for any variant of this algorithm.
This is a big step up from Classic RN which didn't support this in LayoutAnimations at all.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21615829
fbshipit-source-id: da6cb931ce857107d4b3d20108fb9bbecbf4f898
Summary:
Turn on Fabric LayoutAnimations on iOS.
I will gate this change behind a QE before landing.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D21583932
fbshipit-source-id: 0e0f988b44af37eb6fb22cccb48b0c7aa5020ca7
Summary:
Turn on Fabric LayoutAnimations on Android.
I will gate this change behind a QE before landing.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21583122
fbshipit-source-id: 82eacb7192f7c59d2809a67a619cb950293aaace
Summary:
The LayoutAnimationStatusDelegate exists so that platforms can get a signal when animations are starting or have all completed.
This signal is meant to be used ONLY for driving animations at 60fps, or stopping that process, on the platform side.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21583109
fbshipit-source-id: 234496841bde226fcd6623c74c1a500e5cd00d99
Summary:
Implement EaseIn, EaseOut, EaseInOut, and Spring with SpringDamping.
Note this does not yet implement Keyboard-type animation for iOS (coming soon), and the spring interpolator is VERY naive. We likely want to replace it with a "real" spring animation ASAP. The spring animation is identical to what Android does today, but would likely be a downgrade for iOS. I will do both in a followup.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21587648
fbshipit-source-id: 246ab7fd40397a4231bb6b18d2f29602788a1bd2
Summary:
This is the V1 implementation of Fabric Core LayoutAnimations.
The intention is to structure this in such a way that it's easy for each platform to customize the "AnimationDriver" class (to do platform-specific optimizations) without changing the KeyFrameManager at all.
In the future, this structure and architecture should allow us to iterate faster on new animation APIs.
TODOs:
- Use std::chrono for timekeeping
Changelog: [Internal] Support for LayoutAnimations in Fabric
Reviewed By: shergin
Differential Revision: D17486030
fbshipit-source-id: 95c72cf9fc2b4bf3fe652fbd249cf2ad113033c7
Summary:
Changelog: [Internal]
If you look at implementation of hit testing in `RCTViewComponentView`
```
- (BOOL)pointInside:(CGPoint)point withEvent:(UIEvent *)event
{
if (UIEdgeInsetsEqualToEdgeInsets(self.hitTestEdgeInsets, UIEdgeInsetsZero)) {
return [super pointInside:point withEvent:event];
}
CGRect hitFrame = UIEdgeInsetsInsetRect(self.bounds, self.hitTestEdgeInsets);
return CGRectContainsPoint(hitFrame, point);
}
```
you will notice that we use `UIEdgeInsetsInsetRect` to calculate hitFrame. The input for this function is bounds and `hitTestEdgeInsets`. `hitTestEdgeInsets` is our hitSlop.
Look at documentation of `UIEdgeInsetsInsetRect`, it says "Adjusts a rectangle by the given edge insets.".
So if you give it a positive edge insets, it will make the rect smaller.
That's why we need to reverse values of hitSlop to negative before assigning it to `hitTestEdgeInsets`.
Paper does the same thing here https://github.com/facebook/react-native/blob/d0871d0a9a373e1d3ac35da46c85c0d0e793116d/React/Views/RCTViewManager.m#L304-L305
Reviewed By: mdvacca
Differential Revision: D21661894
fbshipit-source-id: c3dd6c55b68e4fdef8589ca8f0484e2837b4136c
Summary:
The combination of `eslint` (v7.0.0), `react-native-community/eslint-config` (v1.1.0), and `flow-typed` (v3.1.0) causes the following error (`ESLint couldn't find the plugin "eslint-plugin-prettier"`) because `flow-typed` (v3.1.0) depends on `prettier: ^1.19.1` (c.f. https://github.com/flow-typed/flow-typed/blob/master/cli/package.json#L38).
To deal with the error, developers should install `prettier` (v2.x) directly in `devDependencies`.
```
Oops! Something went wrong! :(
ESLint: 7.0.0
ESLint couldn't find the plugin "eslint-plugin-prettier".
(The package "eslint-plugin-prettier" was not found when loaded as a Node module from the directory "/Users/exkazuu/Projects/test".)
It's likely that the plugin isn't installed correctly. Try reinstalling by running the following:
npm install eslint-plugin-prettier@latest --save-dev
The plugin "eslint-plugin-prettier" was referenced from the config file in ".eslintrc.js » react-native-community/eslint-config".
If you still can't figure out the problem, please stop by https://gitter.im/eslint/eslint to chat with the team.
```
## Changelog
[Internal] [Changed] - `react-native-community/eslint-config` README recommends developers to install prettier directly
Pull Request resolved: https://github.com/facebook/react-native/pull/28930
Test Plan: This PR changes only README, so tests are not required.
Differential Revision: D21659672
Pulled By: cpojer
fbshipit-source-id: 67c775e664d539815fa78e12574d73eaa1942de1
Summary:
There are a few places in `Pressability` where we asynchronously consume the `event` object.
Most places do not encounter any problems because the actual properties on `event` are seldom used.
Nonetheless, we should fix these gaps.
Changelog:
[General][Fixed] - Fix invalid `event` objects from `onPressOut` in certain cases
Reviewed By: rickhanlonii
Differential Revision: D21657126
fbshipit-source-id: e28d825b85d25602427beaf0bd603d22eaa5960a
Summary:
Flow is deprecating this config option, so we are removing it in preparation.
Changelog:
[Internal]
Reviewed By: gkz
Differential Revision: D21642915
fbshipit-source-id: cb2abff067b8702b37d5fdbdd63556f464e2a4a5
Summary:
Changelog: [Internal]
`SafeAreaViewShadowNode.alreadyAppliedPadding` was always {0, 0, 0, 0} because value of previous shadow node was never copied over to new shadow node during clone.
Reviewed By: shergin
Differential Revision: D21617361
fbshipit-source-id: 6d6c91b19ff60271bf7c48145d85faaee0321680
Summary:
Changelog: [Internal]
# Problem
We call `_state->updateState` anytime safe area insets changes.
Once that is called, `_state` still holds old value, so when we check whether there is big enough of a difference, we are actually checking it against old value of state until `updateState` is called from MountingManager.
This causes `_state->updateState` to be called dozens of times (I measured 47, with this diff it fell to 22) when displaying a safe area view inside Modal.
# Solution
Create new ivar `_lastPaddingStateWasUpdatedWith` where we store last padding that was sent through `_state->updateState` and compare new inset with this value instead of last value stored in state.
Reviewed By: shergin
Differential Revision: D21596367
fbshipit-source-id: b9249b8ef444ea532ec8b86a15a32c733eb6f987
Summary:
When a `Pressable` has a configured (or the default) `delayPressIn` and no (or the default) `delayPressOut`, tapping very quickly can lead to intantaneous invocation of `onPressIn` and `onPressOut`. The end result is that users may never experience any intended visual press feedback.
This changes `Pressable` to accept (and be preconfigured with a default) **minimum press duration**. The minimum press duration ensures that even if the press is released before `delayPressIn` has elapsed, `onPressOut` will still wait the remaining time up to `minPressDuration` before firing.
Note that setting a non-zero `delayPressOut` is insufficient because if a user holds down on a `Pressable` for longer than `delayPressIn`, we still want `onPressOut` to fire immediately when the press is released.
Changelog:
[General][Changed] - Added `minPressDuration` to `Pressable`.
Reviewed By: TheSavior
Differential Revision: D21614708
fbshipit-source-id: 502f3d8ad6a40e7762435b6df16809c8798dd92c
Summary:
While working on recent PRs regarding ripple radius in TouchableNativeFeedbaack and ripple support in Pressable I noticed `ReactDrawableHelper` uses a [discouraged](https://developer.android.com/reference/android/content/res/Resources#getIdentifier(java.lang.String,%20java.lang.String,%20java.lang.String)) way to obtain resources.
The attribute names (strings) `'selectableItemBackground'` and `'selectableItemBackgroundBorderless'` are used here
https://github.com/facebook/react-native/blob/4a48b021d63a474f1570e92616988384957d4273/Libraries/Components/Touchable/TouchableNativeFeedback.js#L105
And passed to `context.getResources().getIdentifier()` in `ReactDrawableHelper`. Since we know the attribute names beforehand I figured we can obtain the resources by id (fast) instead of by name (slow). I made it so that the slow code path is taken in case the attribute name does not match what is expected, as a fallback.
Note that I did not do any measurement of the effect of this, I'm just offering this as a PR. You'll notice that this PR relies on the fact that the string in JS is the same as the string in Java (it is duplicated). While I could export the strings from Java and use them in JS, I wasn't sure where to export them. But note that even before, the JS code depended on the `'selectableItemBackground'` and `'selectableItemBackgroundBorderless'` strings to exist on the native side, in the android SDK, I just made the dependency explicit.
## 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
-->
[Android] [Changed] - get ripple drawables by id
Pull Request resolved: https://github.com/facebook/react-native/pull/28600
Test Plan: tested manually in RNTester
Differential Revision: D21241773
Pulled By: shergin
fbshipit-source-id: 1b8314f99616095cb6ed557c62095cf3200f53b6
Summary:
LocalData was fully replaced by State, this diff removes dead code thas was previously used to update local Data
changelog: [Internal] Internal cleanup on Fabric Android code
Reviewed By: shergin
Differential Revision: D21621481
fbshipit-source-id: a3e38300a54a85adff9145cdeea1e89dad09103f
Summary:
Basic implementation of ARTText (shadow node, props and component descriptor)
changelog: [Internal] Internal changes to support art in Fabric
Reviewed By: shergin
Differential Revision: D21621483
fbshipit-source-id: d0886dc149520af13faa1bb936dfcccab1798c37
Summary:
Basic implementation of ARTGroupProps (shadow node, props and component descriptor)
changelog: [Internal] Internal changes to support art in Fabric
Reviewed By: shergin
Differential Revision: D21621480
fbshipit-source-id: 367a479568b8c1a290f3e0f633cc4052a9c95b87
Summary:
Create basic implementation of Shape (shadow node, props and component descriptor)
changelog: [Internal] Internal changes to support art in Fabric
Reviewed By: shergin
Differential Revision: D21621482
fbshipit-source-id: e5b9bb2812ee92bce625301b7521f0578eaca0ff
Summary:
Using of the new API makes clear that we don't need to calculate the newest descendant node.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D21480202
fbshipit-source-id: c54998573baffe4a05726e3402da027f052b049a
Summary:
This diff simplifies the implementation of `LayoutableShadowNode::getRelativeLayoutMetrics`.
It fixes a small bug but the most important change is the new interface.
Now the function that does measurements accepts a node and a family instead of two nodes. It prevents misuse and misinterpretation of what the function does. The function needs two things to perform measurement:
* an ancestor node that defines the tree is being measured and the base node of measurement;
* a family of some descendant node being measured relative to the ancestor node.
An API that accepts two nodes is misleading because it implies that the given descendant node will be measured (which is not true).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D21480200
fbshipit-source-id: 9fddc361417fee47bbf66cc7ac2954eb088a3179
Summary:
One small test was added.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D21480201
fbshipit-source-id: fd6c050143fcdf27d345ee62e74c4368266e6ce0
Summary:
Adds support for the debug overlay (enabled via the Inspector) that the legacy touchable components supported.
Changelog:
[General][Added] - Added Inspector overlay support for Pressable
Reviewed By: TheSavior
Differential Revision: D21614412
fbshipit-source-id: b884e04f8dba1bfd35e61de25d33d6d47bc34b03
Summary:
This is an addition to an automatic emergency clean-up algorithm that we have in Scheduler. In addition to committing empty surfaces, we also remove those surfaces from the registry making calling stuff on them impossible. Removing surfaces waits for all commits in flight to be finished, so it theoretically can deadlock (so we gated that).
If we won't face deadlocks in a coming couple of weeks, I would remove gating.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D21610683
fbshipit-source-id: 71feeaa0ee4521a0180cdfba6e3a271e7f7d9401
Summary:
This diff uses a new MC to Start Fabric surfaces using layoutMetrics or not.
The motivation is to verify if the new initialization of fabric surfaces is regressing in production
changelog: [Internal] Internal change in fabric
Reviewed By: JoshuaGross
Differential Revision: D21606971
fbshipit-source-id: ed1f6937ffd0f1e6c54e3ebc34595d75b6c5f6e1
Summary:
EZ diff to expose a new ReactFlag that will be used to configure the initialization of Fabric
changelog: [Internal] Internal change in fabric
Reviewed By: JoshuaGross
Differential Revision: D21606972
fbshipit-source-id: 53d6bac673b95f0fae93262ff52b815d76bb59ab
Summary:
In the previous diff I made a few more things "Retryable" exceptions, where previously only strictly ViewCommand-related code would throw Retryable exceptions. This change is to prevent FabricUIManager from swallowing these exceptions if they happen outside of the context of ViewCommands.
Changelog: [Internal] Fabric
Reviewed By: mdvacca
Differential Revision: D21607324
fbshipit-source-id: b3bad4694d2399db447a9117cc31169104b36de5
Summary:
## Motivation
This rename will fix the following CircleCI build failures:
- [test_ios_unit_frameworks](https://circleci.com/gh/facebook/react-native/150473?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link)
- [test_ios_detox_frameworks](https://circleci.com/gh/facebook/react-native/150474?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link)
## Investigation
We have 4 podspec targets that map to the same header namespace (i.e: `header_dir`) `ReactCommon`:
- **New:** `React-perflogger`: Directory is `ReactCommon/preflogger`, and contains `NativeModulePerfLogger.{h,cpp}`.
- `React-runtimeexecutor`: Directory is `ReactCommon/runtimeexecutor`, and contains only `RuntimeExecutor.h`
- `React-callinvoker`: Directory is `ReactCommon/callinvoker`, and contains only `CallInvoker.h`
- `ReactCommon/turbomodule/core`: Directory is `ReactCommon/turbomodule`, and contains C++ files, as well has header files.
**The problem:**
We couldn't import headers from `React-perflogger` in `ReactCommon/turbomodule/core` files.
**The cause:**
I'm not entirely sure why, but I was able to discern the following two rules by playing around with the podspecs:
1. If your podspec target has a cpp file, it'll generate a framework when `USE_FRAMEWORKS=1`.
2. Two different frameworks cannot map to the same `module_name` or `header_dir`. (Why? No clue. But something breaks silently when this is the case).
So, this is what happened when I landed `React-perflogger` (D21443610):
1. The TurboModules code generates the `ReactCommon` framework that uses the `ReactCommon` header namespace.
2. `React-runtimeexecutor` and `React-callinvoker` also used the `ReactCommon` header namespace. However, neither generate a framework because of Rule 1.
3. When I comitted `React-perflogger`, I introduced a second framework that competed with the `ReactCommon` framework (i.e: TurboModules code) for the `ReactCommon` header namespace. Rule 2 violation.
## Thoughts on renaming
- `<perflogger/NativeModulePerfLogger.h>` is too generic, and the `perflogger` namepsace is used internally within FB.
- `<react/perflogger/NativeModulePerfLogger.h>` matches our fabric header format, but I'm pretty sure that slashes aren't allowed in `header_dir`: I tested this and it didn't work. IIRC, only alphanumeric and underscore are valid characters for `header_dir` or `module_name`. So, I opted to just use `reactperflogger`.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D21598852
fbshipit-source-id: 60da5d0f7758eaf13907a080b7d8756688f40723
Summary: Internal loggers were not deallocated when images were canceled on RCTImageView
Reviewed By: fkgozali
Differential Revision: D21380284
fbshipit-source-id: 00440cf49708ec03ecd7d9268001aa458ccbf923
Summary:
This call is used to continue execution when the app has just been
started in a "wait for debugger" mode. This is the only case
in which it has an effect.
Notably, it should do nothing in the following cases, which a layperson
may be tempted to classify as "WaitingForDebugger":
* The app was running detached and hit a 'debugger;' statement
* The app is paused because of a breakpoint or hitting the Pause button
* The app stopped on an instrumentation breakpoint, and expects
the debugger to collect data and potentially auto-resume.
Changelog: [Internal] Add Hermes support for Debugger.runIfWaitingForDebugger
Reviewed By: mhorowitz
Differential Revision: D21557446
fbshipit-source-id: 790cec7444ddc61908d2ef9d92e4649b535d678f
Summary:
This diff fixes the position of TextInlineViews when nesting multiple Text.
The root is that we were not taking into consideration LayoutOffset of nested TextViews during the calculation of the nested views.
changelog: [Internal] Internal fix in Fabric
Reviewed By: JoshuaGross
Differential Revision: D21586893
fbshipit-source-id: 55e6ad0cf95222588ffe9185f5e22baea1059448
Summary:
This diff integrates the logging of Binding class using a MC
changelog: [Internal] Internal change to control logging of Fabric
Reviewed By: JoshuaGross
Differential Revision: D21574813
fbshipit-source-id: e7b2acbaa4cb8a8e748db91af5c6960cd47b520e
Summary:
This diff implements the eager initialization of fabric based on the param created in previous diffs
changelog: [Internal] Internal change in Fabric
Reviewed By: JoshuaGross
Differential Revision: D21574815
fbshipit-source-id: 1dfd2611ce8c8529ce5f6a7a8c48f8bee19be256
Summary:
This diff exposes a new react feature flag to eager initialize fabric
changelog: [Internal] Internal change in Fabric
Reviewed By: JoshuaGross
Differential Revision: D21574814
fbshipit-source-id: c74fb316963fe92e43ce0ca6262cb73a6a4acb7f
Summary:
## Motivation
This rename will fix the following CircleCI build failures:
- [test_ios_unit_frameworks](https://circleci.com/gh/facebook/react-native/150473?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link)
- [test_ios_detox_frameworks](https://circleci.com/gh/facebook/react-native/150474?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link)
## Investigation
We have 4 podspec targets that map to the same header namespace (i.e: `header_dir`) `ReactCommon`:
- **New:** `React-perflogger`: Directory is `ReactCommon/preflogger`, and contains `NativeModulePerfLogger.{h,cpp}`.
- `React-runtimeexecutor`: Directory is `ReactCommon/runtimeexecutor`, and contains only `RuntimeExecutor.h`
- `React-callinvoker`: Directory is `ReactCommon/callinvoker`, and contains only `CallInvoker.h`
- `ReactCommon/turbomodule/core`: Directory is `ReactCommon/turbomodule`, and contains C++ files, as well has header files.
**The problem:**
We couldn't import headers from `React-perflogger` in `ReactCommon/turbomodule/core` files.
**The cause:**
I'm not entirely sure why, but I was able to discern the following two rules by playing around with the podspecs:
1. If your podspec target has a cpp file, it'll generate a framework when `USE_FRAMEWORKS=1`.
2. Two different frameworks cannot map to the same `module_name` or `header_dir`. (Why? No clue. But something breaks silently when this is the case).
So, this is what happened when I landed `React-perflogger` (D21443610):
1. The TurboModules code generates the `ReactCommon` framework that uses the `ReactCommon` header namespace.
2. `React-runtimeexecutor` and `React-callinvoker` also used the `ReactCommon` header namespace. However, neither generate a framework because of Rule 1.
3. When I comitted `React-perflogger`, I introduced a second framework that competed with the `ReactCommon` framework (i.e: TurboModules code) for the `ReactCommon` header namespace. Rule 2 violation.
## Thoughts on renaming
- `<perflogger/NativeModulePerfLogger.h>` is too generic, and the `perflogger` namepsace is used internally within FB.
- `<react/perflogger/NativeModulePerfLogger.h>` matches our fabric header format, but I'm pretty sure that slashes aren't allowed in `header_dir`: I tested this and it didn't work. IIRC, only alphanumeric and underscore are valid characters for `header_dir` or `module_name`. So, I opted to just use `reactperflogger`.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D21585006
fbshipit-source-id: e3339273af5dfd65a1454d87213d1221de6a4651
Summary:
For Fabric LayoutAnimations, we need to support interpolating the Transform property (which really ends up just being interpolation of ScaleX, ScaleY, or ScaleXY transforms - not arbitrary matrices).
To support that, we need to be able to convert Transform back to folly::dynamic, and on the Java side we need to support accepting arbitrary matrices instead of transform maps of properties.
Changelog: [Internal] Fabric-only changes
Reviewed By: sammy-SC
Differential Revision: D21564590
fbshipit-source-id: b137f659b27e4b8fae83921a28ccf46035e18651
Summary:
Changelog: [Internal]
Using `empty()` vs `size() == 0` or `size() > 0`.
It is a more semantic way to check whether container is empty or not.
Reviewed By: JoshuaGross
Differential Revision: D21573183
fbshipit-source-id: b83283f687432a037941852114717a0f014e28db
Summary:
Changelog: [Internal]
For consistency, switching west const to east const.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D21574239
fbshipit-source-id: eb3459c63f731f51b24f40f9f80b574661ffd935
Summary: Changelog: [Internal][Yoga] throw std::logic_error instead of aborting the process and convert to java exception for jni layer
Reviewed By: pasqualeanatriello
Differential Revision: D21301235
fbshipit-source-id: 148b27920e62990a271e1d0df8c85a2cc42f4fd4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/28893
`JSIExecutor::callSerializableNativeHook` converts the arguments from `JSI::Value` to `folly::dynamic`. Then, `RCTNativeModule` converts the arguments from `folly::dynamic` to ObjC data structures in its `static invokeInner` function.
Therefore, I decided to start the sync markers inside `JSIExecutor::callSerializableNativeHook`, which required me to expose these two methode `ModuleRegistry::getModuleName` and `ModuleRegistry::getModuleSyncMethodName`. This shouldn't modify performance because we eagerly generate a NativeModule's methods when it's first required. So, at worst, this is doing a cache lookup.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D21443610
fbshipit-source-id: 67cf563b0b06153e56e63ba7e186eea31eafc853
Summary:
NativeModule async method calls are queued up on the JS side, and flushed to C++ on every Native -> JS call. Before we execute the batch of async NativeModule method calls, we convert it (a JS object) from a `jsi::Value` to a `folly::dynamic` object in `JSIExecutor::callNativeModules`. Then, in `JsToNativeBridge::callNativeModules`, we convert this `folly::dynamic` object into an `std::vector<MethodCall>`, before finally looping over these `MethodCall`s and invoking each NativeModule async method call.
The markers I'm adding in this diff measure this `jsi::Value -> folly::dynamic -> std::vector<MethodCall>` pre-processing.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D21435455
fbshipit-source-id: 4c5a9e2b73c1a2a49d7a8f224a0d30afe3a0c79c
Summary:
This diff instruments two markers:
- JSRequireBeginning: From the start of the JS require to when we start creating the platform NativeModule
- JSRequireEnding: From the end of platform NativeModule create to the end of the JS require
In order to accomplish this, I had modify `ModuleRegistry::ModuleRegistry()` to accept a `std::shared_ptr<NativeModulePerfLogger>`. I also had to implement the public method `ModuleRegistry::getNativeModulePerfLogger()` so that `JSINativeModules` could start logging the JS require beginning and ending.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D21418803
fbshipit-source-id: 53828817ae41f23f3f04a95b1d3ac0012735da48
Summary:
`RCTModuleData instance` is the entry-point for creating and initializing NativeModules on iOS. This diff instruments module-create for the legacy NativeModule system.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D21415435
fbshipit-source-id: 8554e41cba9105ef528a9a63c49042b99ebf8751
Summary:
## Description
This diff introduces `NativeModulePerfLogger`, its BUCK, Cocoapod, android-ndk targets. This diff also wires up those targets into the React Native bridge and TurboModules targets, so that we get signal on if the code compiles.
This diff also introduces `TurboModulePerfLogger`, which is a namespace that holds the `NativeModulePerfLogger` that'll do perf-logging for TurboModules.
## How will perflogging work on iOS?
1. Each application will, during React Native initialization, create a NativeModule perf logger.
2. If TurboModules are enabled, we'll call `TurboModulePerfLogger::setInstance(perfLogger)`. If TurboModules are disabled, we'll call `NativeModulePerfLogger::setInstance(perfLogger)`.
3. TurboModules, when they're created and used, will log events via `TurboModulePerfLogger::getInstance()`. NativeModules (i.e: bridge modules), when they're created and used, will log events via the `NativeModulePerfLogger::getInstance()`.
> **Note:** The NativeModule system will log events for non-TurboModules as well. Maybe we should log events for only NativeModules that conform to the `TurboModule` interface, when TurboModules are disabled. This'll ensure a fair comparison between the two systems.
## How will perflogging work on Android?
Please see the subsequent diff.
allow-large-files
Changelog:
[Both][Added] - Introduce `NativeModulePerfLogger`
Reviewed By: PeteTheHeat
Differential Revision: D21318053
fbshipit-source-id: 6ddf5b5a80bdc4076d2dd6588067e2b0ec8c2c6b
Summary:
This diff fixed hotkeys for dev tools like cmd+d, cmd+r, and cmd+i when Turbo Modules are enabled until we have a proper way to eagerly initialize turbo modules.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D21517482
fbshipit-source-id: 8c68bc126361aa961a4f05c93dc19ada32fe44c7
Summary:
Ez diff that revisits deprecated methods in UIManagerModule and update javadoc
Motivation: I'm cleaning up my fabric backlog before lockdown
changelog: [Android] Update documentation of UIManagerModule methods
Reviewed By: JoshuaGross
Differential Revision: D21487609
fbshipit-source-id: 896ae21e02d5b1aa57b7158d714986fd1f8c9c5c
Summary:
This diff deletes the deprecated PlayTouchSound method from UIManagerModules.
I verified there are no callsites of this method in Facebook sourcecode
changelog: [BREAKING][Android] Deletes the method PlayTouchSound method from UIManagerModule, this method was moved to the SoundManagerModule class.
Motivation: I'm cleaning up my fabric backlog before lockdown
Reviewed By: JoshuaGross, TheSavior
Differential Revision: D21487612
fbshipit-source-id: f630e2b7f927e0b607a30b9f4904feb63a561ab9
Summary:
The interface of css/TextLayoutManager now matches acual platform-specific implementations, so now CXX tests compiles and usable.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D21518656
fbshipit-source-id: cece3bea14c70410eea22abafb424f7a2cb201c0
Summary:
This diff extends the ReactShadowNode API to expose flex props, this is going to be used by some components that require access to it
changeLog: [Android][Added] Exposed getFlex method as part of ReactShadowNode API
Reviewed By: JoshuaGross
Differential Revision: D21554663
fbshipit-source-id: 26c9a3fe5f72a84120b16b553ab08231817c0efa
Summary:
Each ComponentDescriptor becomes capable of doing its own interpolation over props for animation purposes.
This new custom interpolator is called by default by the ConcreteComponentDescriptor, but `ComponentDescriptor::interpolateProps` is a virtual function and each ComponentDescriptor can provide custom interpolation if necessary.
For now, only View does any actual interpolation, to support LayoutAnimations.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D20965310
fbshipit-source-id: e1c1588107848e94c155efecb0da1cc1619ae544
Summary:
Reverted for now because it causes a crash.
Original commit changeset: 46e32de0f108 (D21484773)
Changelog: [Internal]
Reviewed By: sammy-SC, kacieb
Differential Revision: D21555488
fbshipit-source-id: 555a143fe8cf4c8806d910803f104271454f5797
Summary:
Text and the other Touchables have this prop called pressRetentionOffset. Pressable should be consistent with that.
Changelog:
[Breaking][General]: Pressable: Rename pressRectOffset to pressRetentionOffset to be consistent with other touchables
Reviewed By: yungsters
Differential Revision: D21552255
fbshipit-source-id: 31e64bad9e48ac98e4934dd2f4c0a7f526de5cb6
Summary:
Changelog: [Internal]
ScrollView didn't support centerContent prop. The implementation is copied over from Paper.
I added an example of this prop in RNTester.
Reviewed By: JoshuaGross
Differential Revision: D21548270
fbshipit-source-id: 28f6c8d769c5a6bc1d111b33970a06b95c259132
Summary:
I noticed an issue when the hermes debugger was attached. Console messages would no longer appear in the terminal. This is because the hermes inspector overrides the console object with its own to intercept messages and send them to the debug client.
With this change I made it so that messages are sent to the original console as well instead of completely replacing it.
Changelog:
[General][Fixed] - When Hermes debugger is enabled continue to send log messages to the console
Reviewed By: mhorowitz
Differential Revision: D21509895
fbshipit-source-id: 6d91c4b82682e404679533be14b3e5f12e687e79
Summary:
TextInlineViews in Android was incorrectly converting values to from float to int, this produced to loose precision and to render incomplete texts in some components.
This diff changed the types from int to float, avoiding loose precision.
The impact of this bug is not that high because in the conversion to int we were using Math.ceil(), which was already rounding the result to the next pixel.
changeLog: [Android][Fixed] Fix precision of TextInlineViews in Fabric Android
Reviewed By: JoshuaGross, shergin
Differential Revision: D21541159
fbshipit-source-id: 4741ab96964c35af1c1b7d3e821e505ecef2efce
Summary:
Was looking at removing logbox from CoreModules, realized it had a bunch of extra deps.
Changelog: [Internal]
Reviewed By: rickhanlonii
Differential Revision: D21535374
fbshipit-source-id: 2427cc66fa34635b49ac4b4fafaf0b6481f5687d
Summary:
This diff updates the loading banner to respect the RCTAppearance dev mode setting.
Changelog: [General] [iOS] Add dark mode support to loading banner
Reviewed By: fkgozali
Differential Revision: D21429148
fbshipit-source-id: d7d9e778245112a19accf813dcff693f0d187a38
Summary: This enables redbox in bridgeless mode, by removing a dep on the bridge. It also disables full screen logbox, since I couldn't figure out how to get it working without the bridge.
Reviewed By: rickhanlonii, ejanzer
Differential Revision: D21440233
fbshipit-source-id: cb1730fefe1639135fdf06039031975d53f95229
Summary: We don't yet have native driver support for animations in bridgeless mode on Android, which leads to some weird bugs (like an overlay that never disappears). Let's just disable animations on Android again.
Reviewed By: mdvacca
Differential Revision: D21537982
fbshipit-source-id: b4e8882a414fecbd52dd25e02325b5c588ee68c0
Summary:
## Problem
When self is nil, this may crash in RCTUIImageViewAnimated.m.
```
_displayLink = [CADisplayLink displayLinkWithTarget:[RCTWeakProxy weakProxyWithTarget:self] selector:selector(displayDidRefresh:)];
```
## Fix
Replace `RCTWeakProxy` with a concrete class `RCTDisplayWeakRefreshable` that has the displayDidRefresh method, that calls the displayDidRefresh method in its weak target.
### Original Github Issue
https://github.com/facebook/react-native/pull/28070#issuecomment-619295254
Changelog: [iOS] [Fixed] - Fix Animated image crash when CADisplayLink target in RCTWeakProxy is nil
Reviewed By: shergin
Differential Revision: D21419385
fbshipit-source-id: da7c3c38f81ea54f633da7f59359e07680ea2faf
Summary:
The previous implementation was incorrect causing a memory leak. In the new approach, we use a shared pointer to optional to be able to construct that ahead of time and then fill with actual value.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D21516794
fbshipit-source-id: ddcbf8a1ad2b1f629ae4ff2842edeb7bb2a275a6
Summary:
Changelog: [internal]
Fabric asks server for images of their real size and scale, not images of size that they would take up on the screen once rendered. Also scale of the screen is incorrect. This causes images to be twice as large as they have to be.
Look at the size of the first image size here in Paper, it is `{310.5, 207}`.
{F235394066}
If you compare it with Fabric, there it is `{800, 381}`
{F235394115}
It isn't just the size, but scale of request image as well. Fabric always asks for image of scale 1, unlike Paper which takes screen scale into account.
Reviewed By: shergin
Differential Revision: D21255794
fbshipit-source-id: 9db3ccafec1c09cedc5db5ac0a435a28a4c30c85
Summary:
In the latest `react-native-cli` we've added more flexibility for setting application title. New config key was introduced - `titlePlaceholder` - which will be changed during init process.
PR: https://github.com/react-native-community/cli/pull/650
## Changelog
[General] [Added] - Introduce `titlePlaceholder` for template configuration.
Pull Request resolved: https://github.com/facebook/react-native/pull/26218
Test Plan: Initialization works with the default template
Differential Revision: D17091492
Pulled By: shergin
fbshipit-source-id: 239110f2ad6f817d750575fa366ab49d146b36c1
Summary:
Forwards any extra parameters set on the main bundle URL (in development) to the derived bundle URLs used in hot reloading and bundle splitting.
Changelog: [General] - Forward URL parameters from main bundle to hot reloaded bundles
Reviewed By: cpojer
Differential Revision: D21455592
fbshipit-source-id: e1c375e3b6a0f3387372f1d96498dbf7d5237a09
Summary:
Adds the package name (Android) / bundle ID (iOS) as a new URL parameter named `app` in the bundle URL. This currently has no effect on Metro, which will ignore it for bundling / caching purposes.
Changelog: [General] - Add package name / bundle ID to bundle URL in development
Reviewed By: cpojer
Differential Revision: D21429764
fbshipit-source-id: 394fe50dba72219f7594ebeac9486a8264a836a6
Summary:
This makes sure the proper version of cocoapods gets used, this will avoid noise in diffs if someone ends up updating pods with a different version.
## Changelog
[Internal] [Changed] - Mention using bundler to install cocoapods in RNTester README
Pull Request resolved: https://github.com/facebook/react-native/pull/28873
Test Plan: N/A
Differential Revision: D21519862
Pulled By: shergin
fbshipit-source-id: 3dc555bc3aee6bee10127ba5b5862302a63346c4
Summary:
ReactViewManager uses the bridge (CatalystInstance) to access the UIManagerModule in its onClick method. This doesn't work in bridgeless mode, so I'm replacing this callsite with the new API, which uses UIManagerHelper + the reactTag to look up the appropriate UIManager (Paper or Fabric), and get the EventDispatcher from that.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D21510243
fbshipit-source-id: c2c6111e73c49ca6bf873819db8ece71c66417e4
Summary:
This early return is a very minor perf optimization, and it complicates things on Fabric: if scroll perf logging is disabled, the scroll position in C++ (State) doesn't get updated for the scrollview.
Just remove it. Always run the Runnable, no matter what.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D21503695
fbshipit-source-id: 13dfe232d692ff544bff725a2344a66b572f5444
Summary: Changelog: [Internal] Separate SegmentControl examples into separate file and make them functional based
Reviewed By: mdvacca
Differential Revision: D21475596
fbshipit-source-id: 19165232f2a8edefa66f122944621f93265ff704
Summary:
The approach is quite simple: we check the thread id, and if it matches the caller thread id, we unlock mutexes which lead to the normal uninterrupted execution flow.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: RSNara
Differential Revision: D21328313
fbshipit-source-id: 4290b8a0357dbad3563d7da9464c03ecce5ded7c
Summary:
This issue fixes https://github.com/facebook/react-native/issues/27649.
By using 2d decomposition that transforms a skewX into a rotate/scale/rotate, the skewX issue on Android was still there which made me suspect that the issue came from the decomposition algorithm. Then I noticed that the bug existed in the JavaScript decomposition as well which led me to a fix on the JS and therefore on the Android side most likely.
## Changelog
[Android] [Fixed] skewX transforms
Pull Request resolved: https://github.com/facebook/react-native/pull/28862
Test Plan:
Check that skewX works on Android.
On JS, making sure that processTransform() doesn't skip, you can try the following sequence:
```tsx
const matrix = processTransform([{ skewX: `${Math.PI / 3}rad` }]);
const result = MatrixMath.decomposeMatrix(matrix);
console.log({ result });
```
Differential Revision: D21493021
Pulled By: shergin
fbshipit-source-id: 89f7aca5fbfd0f0f8c6f90a26bd76bf8550acaa5
Summary:
This diff implements iOS-specific `PlatformRunLoopObserver` (and `MainRunLoopObserver`) that then being glued together with `SynchronousEventBeat` replaces `MainRunLoopEventBeat`, and then same thing glued with `AsynchronousEventBeat` replaces `RuntimeEventBeat`.
So, instead of two platform-specific classes we had on iOS (for that needs), now we have only one (that can be reused for a more broad variety of applications).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D21341998
fbshipit-source-id: fafde4e678770f7fcf9c1ff87acc02812a37e708
Summary:
We use `EventBeat::OwnerBox` in the `EventBeat` infra to represent weak ownership of classes that contain that, so those classes can ensure own life-time at some critical points.
Before this diff, we stored a pointer to EventDispatcher right after we create it. However, some components that we build require to have a valid pointer from the beginning (even before the EventDispatcher is created). To satisfy this requirement, we create a dummy pointer first and use it as an owner, then we merge (share control block) the pointer to an EventDispatcher into that. It works because the owner pointer never gets dereferenced (it's `void *`), so it does not matter which object it represents while it represents correct ownership.
In the future, this approach will allow us to remove the concept of `OwnerBox` completely and use just `std::weak_ptr<void>` instead.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D21441109
fbshipit-source-id: 7457c77bd31cd577f38a26e28e27eb7e33b6ad24
Summary:
The name of the value was incorrect.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D21496651
fbshipit-source-id: 464c98436bb8d5f2b6275b7eab1c32d187e2b23c
Summary:
We should check for corner cases.
Another interesting detail is behavior. Now (and previously) we return nullptr if case we could not find the most recent node. But maybe we should return the given node instead?
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D21480874
fbshipit-source-id: bb943c4508ec025316a3665d652e4b5e06dd795c
Summary:
We cannot use a raw pointer here because the tree might progress right after we call to `shadowTree.tryCommit` and we will get a dangling pointer as a result.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D21464832
fbshipit-source-id: 3998b39d29db672da54d4adcb6be55cd3d44d862
Summary:
In this method we have to maintain a retaining pointer to the node in order to access it as a raw pointer.
See also a comment in the codee.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D21464834
fbshipit-source-id: 69f6894009509e5feca291fab12c019208933816
Summary:
There is no need to use a raw pointer to a shared pointer as a return value of `UIManager::getNewestCloneOfShadowNode`. If it would be a very hot path, we could you a raw pointer to the node instead but it's not a hot path.
Prooving that using a raw pointer here is safe is quite complex (and I don't know if it's safe or not). So, I changed it to just a shared pointer.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D21464833
fbshipit-source-id: 813a3c9fca0147afb322db6855a0ce8fd2d47909
Summary:
Problem: ScrollView offset was not being reported to the C++ ScrollView side of Fabric.
This results in taps not working correctly, for example if you tap a button inside scroll view after you scrolled, the tap might not trigger anything.
The root cause of this is our implementation of detecting whether scroll view has stopped scrolling.
To make this more robust, I now require that multiple "frames" have not scrolled because it's easy to trigger race conditions by scrolling very fast.
We also explicitly call `updateStateOnScroll` in a couple more places.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21496396
fbshipit-source-id: 2e565dd2fc4fc1ce582daa8a449c520e7cb19be0
Summary:
Consolidates the logic for the default value of `blurOnSubmit` on `TextInput` in the JavaScript component.
This only materially impacts Fabric.
Changelog:
[Internal]
Reviewed By: mdvacca
Differential Revision: D21491482
fbshipit-source-id: 16d8aba32e7d0321a4583e87e03405ea587e35d4
Summary:
This change is especially important for Fabric when a lot of objects (mostly `ShadowNode`s) have shared ownership. Without this change, JSVM could not know that bunch of natively allocated objects should be deallocated.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: dulinriley
Differential Revision: D21484773
fbshipit-source-id: 46e32de0f108082e60df346884c9287023156149
Summary:
This diff refactors the FrescoModule in order to receive an ImagePipeline as a parameter. This is necessary to ensure the same ImagePipeline is used by every RN module
changelog: [Internal][Android]
Reviewed By: JoshuaGross
Differential Revision: D21428346
fbshipit-source-id: 70a6cc57c8585fe74b6d0b0d1fd86c539974ec23
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/28851
This diff creates a RuntimeExecutor that uses the bridge and exposes it on CatalystInstanceImpl.
Changelog: [Internal]
Reviewed By: mdvacca, RSNara
Differential Revision: D21051949
fbshipit-source-id: b3977fc14fa19089f33e297d29cedba0d067526d
Summary:
*This is a follow-up to https://github.com/facebook/react-native/issues/28645, redone using a build script based off of Metro's build script instead of using `flow-remove-types` and `flow-copy-source`.*
This pull request adds a build step to `react-native-codegen` that builds the Flow-annotated JS files so that users of the NPM module `react-native-codegen` do not need to use require hooks to be able to import it.
A new build script, `scripts/build.js` is added that builds every JS file in `src/` into a `lib/` folder, and also copies over the original Flow annotated files to `lib/` with a `.js.flow` extension, so users of `react-native-codegen` can still typecheck against it using Flow. The shell scripts in `src` are also copied over. It is based off of the [build script from Metro](https://github.com/facebook/metro/blob/00867816eb9b2f69c8af9cebb523e9e4d280671a/scripts/build.js)
## Changelog
[General] [Added] - Codegen: Add prepublish script to build Flow files
Pull Request resolved: https://github.com/facebook/react-native/pull/28827
Test Plan:
I am able to make use of the Codegen scripts without needing to use the `flow-node` CLI or the `flow-remove-types/register`
require hook.
Reviewed By: cpojer
Differential Revision: D21412173
Pulled By: hramos
fbshipit-source-id: 26ae67cdd04652ca4700a069a234a25558773cb1
Summary:
When you profile your heap and memory allocations with Memory Profiler, files with *.hprof extension are created in /android folder that has big sizes (up to 600 MB for each). These files may be needed to add to gitignore.
## 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
-->
[Android] [Added] - Add *.hprof files to gitignore
Pull Request resolved: https://github.com/facebook/react-native/pull/28789
Differential Revision: D21432927
Pulled By: hramos
fbshipit-source-id: a20f12645de5ca0874c9130094e2f97fe16b2203
Summary:
Adds a script that uses `react-native-codegen` to generate FBReactNativeSpec.
The generated output should not be considered ready for production use at this time.
The goal of adding this script at this time is to demonstrate the current status of native modules specs code generation in open source.
For example, the generated output may be used in RNTester, with some modifications due to some naming differences in react-native-codegen's output when compared to the FBReactNativeSpec files generated by the old codegen.
Usage:
```
./scripts/generate-native-modules-specs.sh ./codegen-out
```
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D21471004
fbshipit-source-id: 5ff3c57807d9ba2c91dc7fe32d227d218732b059
Summary:
This diff adds support for the "beforeScriptWithSourceMapExecution" instrumentation
breakpoint via "Debugger.setInstrumentationBreakpoint".
CDP describes it as a breakpoint, but we just set a flag in the inspector. A
fake breakpoint ID is synthesized for optional removal later.
Changelog: [Internal] Add Debugger.setInstrumentationBreakpoint to Hermes Inspector
Reviewed By: mhorowitz
Differential Revision: D21418218
fbshipit-source-id: 90fa49c0954980993815322d3a7effee416ed5db
Summary:
This removes the Hermes.setPauseOnLoad. It will be replaced by the more standard
Debugger.setInstrumentationBreakpoint's "beforeScriptExecution" event.
ChangeLog: [Internal] Remove Hermes.setPauseOnLoad message (to be replaced)
Reviewed By: mhorowitz
Differential Revision: D21418219
fbshipit-source-id: 93c53801c23487f9336b322c2bd737663ec21b97
Summary:
This diff eager initializes Fabric Android classes. This should help load all the Fabric classes at Bridge load time.
changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D21460507
fbshipit-source-id: 4b8d5c4e2d19e3a7eb3077027071e64ff16f1cbd
Summary:
Handle properties named 'id' as a special case.
An example of a native module that ran afoul of this is `ExceptionsManager`.
Observe how the ExceptionsManager spec at `Libraries/Core/NativeExceptionsManager.js` defines the ExceptionData type as containing an `id` property:
```
export type ExceptionData = {
message: string,
originalMessage: ?string,
name: ?string,
componentStack: ?string,
stack: Array<StackFrame>,
id: number,
isFatal: boolean,
// flowlint-next-line unclear-type:off
extraData?: Object,
...
};
```
Prior to this change, the generated code would redefine id in the SpecReportExceptionData struct...
```
namespace JS {
namespace NativeExceptionsManager {
struct SpecReportExceptionData {
// ...redacted...
double id() const; <---
// ...redacted...
SpecReportExceptionData(NSDictionary *const v) : _v(v) {}
private:
NSDictionary *_v;
};
}
}
```
...which would result in a build time error:
```
inline double JS::NativeExceptionsManager::SpecReportExceptionData::id() const
{
id const p = _v[@"id"];
^--- build time error here
return RCTBridgingToDouble(p);
}
```
Comparing the above example with the currently checked in `FBReactNativeSpec.h`, I see the expected output should be:
```
namespace JS {
namespace NativeExceptionsManager {
struct SpecReportExceptionData {
// ...redacted...
double id_() const;
// ...redacted...
SpecReportExceptionData(NSDictionary *const v) : _v(v) {}
private:
NSDictionary *_v;
};
}
}
```
...and...
```
inline double JS::NativeExceptionsManager::SpecReportExceptionData::id_() const
{
id const p = _v[@"id"];
return RCTBridgingToDouble(p);
}
```
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D21395463
fbshipit-source-id: e412648013ff9f70ebd294b6f5f81f1faccb4604
Summary:
This diff exposes the Text.includeFontPadding prop to java, then it uses the prop to calculate the height of Text components correctly.
changelog: [Internal][Fabric] Internal change in Fabric to support Text.includeFontPadding prop in fabric
Reviewed By: shergin
Differential Revision: D21446737
fbshipit-source-id: efe73fb6b0d402c3275ac8c012fa8fa06b743bdd
Summary:
This diff extends the ParagraphAttribute class to store the value of the includeFontPadding prop.
Note that this is an Android only prop, I'm not creating android blocks to improve "cleanliness" of the code.
changelog: [Internal][Fabric] Internal change in Fabric to support Text.includeFontPadding prop in fabric
Reviewed By: shergin
Differential Revision: D21446738
fbshipit-source-id: 0543e86aa18ce10f7a56bbaafe111cce0179ea86
Summary:
Currently the schema only allows to exclude a single platform (iOS OR Android). There are cases where we need to exclude multiple. This change converts the previous `excludePlatform` string property into an `excludePlatforms` array.
Changelog:
[Internal][Changed] - Added support to exclude multiple platforms in Codegen.
Reviewed By: sammy-SC
Differential Revision: D21426950
fbshipit-source-id: eff36ffa207109274794b4b300bf6313f8286161
Summary:
~~⚠️ Depends on https://github.com/facebook/flipper/pull/1086 and a new Flipper release.~~
Fixes https://github.com/facebook/react-native/commit/17f025bc26da13da795845a3f7daee65563420c0#commitcomment-38831234
Currently user’s are being told to add a definition of the `FB_SONARKIT_ENABLED` macro and examples, including those in stock React Native templates, set this for the user by making use of a `post_install` hook in the user’s `Podfile`. This leads to confusion, fragile code [when a user’s project dir structure deviates from vanilla], and is ultimately not necessary as CocoaPods already has dedicated mechanisms to:
* specify build settings (through the `xcconfig` property);
* and selectively include certain pods only in certain build configurations (e.g. debug).
## 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] [Changed] - Entirely control Flipper being enabled through inclusion in Podfile and optionally limiting to certain build configurations using the `:configuration` directive.
Pull Request resolved: https://github.com/facebook/react-native/pull/28796
Test Plan: Tested using the changes of https://github.com/facebook/flipper/pull/1086 in a new app that uses RN `master`.
Reviewed By: priteshrnandgaonkar
Differential Revision: D21449754
Pulled By: passy
fbshipit-source-id: 9ff7c7f4ffc32b364b1edd82b94e0b80c3997625
Summary:
Pass a default empty object to `AppContainer` if no `initialProps` were passed to `renderApplication`.
This prevents issues on Android, where we do not pass a default empty `initialProps` from native, as we do on iOS.
Changelog: [General] [Fixed] - Handle nullish `initialProps` correctly in `renderApplication`
Reviewed By: motiz88
Differential Revision: D21448692
fbshipit-source-id: 9630bdc2414532999abf3bf9da25047f0482fcab
Summary:
We consume Hermes through multiple .so's, which means we have multiple (weak) typeinfo definitions of facebook::jsi::JSError. Previously we were using gnustl, which would strcmp typeinfo to decide whether a certain exception handler applies, which meant this didn't cause any major issues. However since this is deprecated, we recently switched to libc++, which does not have this by behaviour (or it does, but behind a flag I'm not sure how to enable). This causes any JS exceptions to fall through from our exception handlers and fatal the app.
This problem is actually documented in the common Android NDK problems page: https://android.googlesource.com/platform/ndk/+/master/docs/user/common_problems.md#rtti_exceptions-not-working-across-library-boundaries
The suggested solution is to ensure that any exception types have a key function defined (a non-pure, out-of-line virtual function). The simplest one to add is a virtual destructor. This makes the object file that holds the implementation of the destructor export a non-weak typeinfo definition which will at load time override the other weak versions.
I'm not sure why we're the first to hit this. RN's JSIExecutor doesn't explicitly reference JSError which probably helps (https://github.com/facebook/react-native/blob/master/ReactCommon/jsiexecutor/jsireact/JSIExecutor.cpp#L256-L258) and they also don't use unguarded callbacks like we do.
Changelog: [Internal]
Reviewed By: mhorowitz
Differential Revision: D21426524
fbshipit-source-id: 474284ada1ca2810045dc4402c420879447f9308
Summary:
Move and create an empty rule that redirects as well, to handle //arvr rules
Need to do this way, since ovrsource sync rules are in different repo.
allow_many_files
allow-large-files
Steps:
- [X] Move glog from xplat/third-party to /third-party
- [ ] Update references in ovrsource to translate to //third-party instead of //xplat/third-party
- [ ] Get rid of temporary rule
- [ ] Update fbsource/third-party/glog to 0.3.5 (what we have in ovrsource)
Changelog: [Internal] Update reference for glog from xplat/third-party to /third-party.
Reviewed By: yfeldblum
Differential Revision: D21363584
fbshipit-source-id: c1ffe2dd615077170b03d98dcfb77121537793c9
Summary:
`SynchronousEventBeat` and `AsynchronousEventBeat` are a cross-platform re-implementation of run loop related parts of `MainRunLoopEventBeat` and `RuntimeEventBeat` (iOS specific classes for now). In the future, they will replace iOS- and Android-specifc event beat classes.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D21341996
fbshipit-source-id: 8eda9a5df537cd666b7728e32212a8bb5ddb3ab7
Summary:
`RunLoopObserver` is one of the core interfaces that bridge intrinsically platform-specific functionality to cross-platform React Native core. `RunLoopObserver` allows subscribing for notifications about changes in a run loop life cycle. Primarily it supposed to be used for observing UI (aka main) and JavaScript execution thread/run-loop.
Having a `RunLoopObserver` implemented in a platform-specific manner allows building these components in a cross-platform manner:
* Sync and async UI event delivery pipeline;
* Timing for some animation engine;
* Timers (probably additional features are required).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D21341997
fbshipit-source-id: 7ef61fb51f550dd0f2e89c64af657e0f0de029aa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/28833
The checked-in RNTester podfile was generated using Cocoapods version 1.9.1. This doesn't match the version currently used in CircleCI, which is 1.8.4. In order to update the offline mirrors and land them without breaking CircleCI, it seems we need to switch back to 1.8.4. This diff updates the podfile back to 1.8.4 and updates the offline mirrors.
Reviewed By: fkgozali
Differential Revision: D21392989
fbshipit-source-id: b14aa6e2798175534e9416410ba9d6877fb718c0
Summary:
This diff fixes a NullPointerException thrown when calling measureLayout function on a virtual node.
changelog: [Android] Fix measureLayout function for VirtualTexts
Reviewed By: JoshuaGross
Differential Revision: D21435030
fbshipit-source-id: aba6d81f333464e49d2d769b111842e7ae8ce769
Summary:
Quick diff to log of content of UpdateState mount item. This is useful for debugging. Note this will ONLY be logged when the constant FabricUIManager.IS_DEVELOPMENT_ENVIRONMENT is set to true
changelog: [Internal][Android] internal log for fabric android
Reviewed By: JoshuaGross
Differential Revision: D21428345
fbshipit-source-id: d000eb6dbdd39d15935fa2102072790e17372682
Summary:
Only breaking changes appear to be dropped Node 6 support: https://github.com/yargs/yargs/blob/master/CHANGELOG.md. Deduplicates quite a few copies of Yargs, yay!
Changelog: [Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: motiz88
Differential Revision: D21426137
fbshipit-source-id: b091e29ac2d9464d6ce9a716a99f7ae156a91a01
Summary:
Before this change, in case of incorrect measurements, Fabric's implementation of `measure` and `measureInWindow` incorrectly returned negative height and width. Now it returns zeros (as classic React Native does).
Fabric:
This does not fix `measureLayout` called for virtual nodes. This is not so trivially to fix and it will be done separately.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross, yungsters, mdvacca
Differential Revision: D21433239
fbshipit-source-id: fbaf5ee35c690506822c634daac4426542c2cdcf
Summary:
Workaround for a bug with Fabric when pressing on virtual text.
Changelog:
[Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: JoshuaGross
Differential Revision: D21432793
fbshipit-source-id: fe20eeadd5365707fb71edae7a76d374e26b4c86
Summary:
For some reason the specs were internal, but the native impl is still in github. So let's move these to github for consistency.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D21419934
fbshipit-source-id: f2c4486edca43c4348f3a3c6ce98f76a322bab0b
Summary:
Based on feedback we're updating these titles to be more clear for their source.
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D21413486
fbshipit-source-id: c144e7f759a4ff263b7ec80fa643eeb8ffac741b
Summary:
This diff fixes an off-by-one error probably caused by my font ligatures where when exactly two exceptions are thrown at the same time we would show the second exception instead of the first. If three or more were thrown, we would show the second.
I also fixed some tests that had the wrong descriptions and wrong behavior enforced.
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D21413186
fbshipit-source-id: 8e2940c89251dc042b10c6a2a2186089b6e7b53d
Summary:
In iOS 11, [CADisplayLink](https://developer.apple.com/documentation/quartzcore/cadisplaylink)'s frameInterval was deprecated in favor of preferredFramesPerSecond, but these two properties have different underlying assumptions.
- set frameInterval to 2 for 30fps
- set preferredFramesPerSecond to 30 for 30fps. When you use preferredFramesPerSecond, assume frameInterval is 1.
This fix ensures gifs in <Image> component will animate at same speed regardless of framerate.
Reviewed By: shergin
Differential Revision: D21414014
fbshipit-source-id: 40ab23bab1990cf65d2802830b6835f350999537
Summary:
Android ScrollView/HorizontalScrollView `smoothScrollTo` contains some logic that, if called multiple times in a short amount of
time, will treat all calls as part of the same animation and will not lengthen the duration
of the animation. This means that, for example, if the user is scrolling rapidly, multiple
pages could be considered part of one animation, causing some page animations to be animated
very rapidly - looking like they're not animated at all.
We use a custom animation to perform `smoothScrollTo` to improve the UX.
This resolves a longstanding issue in non-Fabric RN, as well as Fabric, since this code is shared between the platforms.
Changelog: [Update] Android ScrollView/HorizontalScrollView scrolls using custom animations instead of default Android `smoothScrollTo` implementation, leading to smoother scrolls for paginated ScrollViews
Reviewed By: mdvacca
Differential Revision: D21416520
fbshipit-source-id: 6ebe63cb054a98336b6e81253d35623fe5522f89
Summary:
Import folly to handle optionals (`folly::Optional<__type__>`)
Sort modules and indent generated code to match output from the old codegen. While not strictly necessary as these are generated files that should not be edited by hand, I found that matching the old codegen in this regard made it less of a chore when it came to comparing the output of both codebases.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D21395231
fbshipit-source-id: 289d617d7a2d93724456c80afea57a49c108cb9b
Summary:
Fixes https://github.com/facebook/react-native/issues/28726
When importing TouchableOpacity, it is treated as any by Flow. Replacing ComponentType with AbstractComponent works.
The [Flow documentation](https://flow.org/en/docs/react/types/#toc-react-componenttype) says the following about ComponentType:
> Note: In 0.89.0+, React.ComponentType is an alias for React.AbstractComponent<Config, any>, which represents a component with config type Config and any instance type.
So I'm thinking that since the instance type is treated as any with ComponentType, Flow treats TouchableOpacity as any as well.
## 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] - Fix Touchable{Opacity,Bounce,Highlight} being exported as `any` (Flow)
Pull Request resolved: https://github.com/facebook/react-native/pull/28737
Test Plan: I have done the same changes to react-native in my project's node_modules and seen that the components TouchableOpacity went from any to AbstractComponent with some props. Now I have a bunch of errors because I'm sending in wrong props to some touchables, which is good!
Reviewed By: cpojer
Differential Revision: D21362601
Pulled By: TheSavior
fbshipit-source-id: 5b98cc79eaef034eccdb7f47242f9f44be2ef2b8
Summary:
We are currently very strict about breakpoint location matching. This
diff allows some fuzz in the column, but not in the line.
Changelog: [Internal] Setting Hermes breakpoints no longer requires exact column match
Reviewed By: avp
Differential Revision: D21343198
fbshipit-source-id: a59786a9d63f9fe1ed576835ed660ba3343affe1
Summary:
`renderApplication` receives the root component that we need to render and an optional wrapper component. There are cases where we want to use the initial props passed to the root component in the wrapper component as well (e.g.: to provide a specific context to the root component), so this adds modifies `AppContainer` to accept the initial props and inject them into the wrapper component.
Changelog: [General] [Added] - Modified `renderApplication` to forward `initialProps` to `WrapperComponent`
Reviewed By: fkgozali
Differential Revision: D21347486
fbshipit-source-id: 1c4f702a3875077630de1a44d3ac9ef2c80bc10c
Summary:
Since support for contentOffset was added to horizontal ScrollView on android (30cc158a87) I'm seeing a crash in my app because of a library. What happens is that it passes a partial object for contentOffset so something like `{x: 1}` which causes a crash on Android.
According to the flow types the object should always contain both x and y but I think we should preserve the runtime behaviour and just use 0 like iOS does.
## Changelog
[Android] [Fixed] - Allow passing partial contentOffset to ScrollView on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/28817
Test Plan: Tested that passing partial object for contentOffset does not crash.
Reviewed By: JoshuaGross
Differential Revision: D21396319
Pulled By: shergin
fbshipit-source-id: 4b52c868e3bfe183ff7f68a76ac34d1abd5e1069
Summary:
The core issue solved in D21389371 was that erased elements of a TinyMap were being iterated over, because TinyMap has somewhat-complicated logic around cleaning out the underlying vector. In some very marginal cases, vectors were not being cleaned and an iterator pointing at erased elements was being returned.
The diff prevents some possible crashes in `begin()` and `find()` while making it much less likely to iterate over erased elements.
We also add a unit test to catch the case fixed in D21389371, in particular.
We also are keeping the code added in D21389371 (for now) since it's a cheap check, and will be a safeguard until we have rigorous testing around TinyMap. To be clear that logic should noop currently, but will prevent crashes in case guarantees around TinyMap change in the future.
Currently there is only one line of code that actually uses the TinyMap iterator, so this should be safe.
Reviewed By: shergin
Differential Revision: D21392762
fbshipit-source-id: 36dc998958c230fad01af93338974f8889cbcf55
Summary:
Before, compilation fails with P130281113. After fixing BUCK target, fails with P130281201.
After all changes, the tests succeed.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21390996
fbshipit-source-id: c85aa43b3ef7fc9642d226ae706c937b2a5a408d
Summary:
While #import is common in Objective C, it's a vendor specific extension in C++, only supported by GCC/Clang, and only when -pedantic is off. Its use causes build breaks with MSVC. Replace it with the standard #include.
## Changelog
[Internal] [Fixed] - Don't use #import in C++ Code
Pull Request resolved: https://github.com/facebook/react-native/pull/28825
Test Plan: We've ben running this change within react-native-windows for some time.
Differential Revision: D21391233
Pulled By: shergin
fbshipit-source-id: c0f94f314c46d6ac24067bbdcd5aaaeec9da283f
Summary:
Add a `console.warn()` call when calling `_scrollRef.scrollTo`, because `scrollTo` is not guaranteed to exist on `_scrollRef`.
Context:
`VirtualizedList` holds `_scrollRef`, which is usually a reference to a `ScrollView` component. However, there are several cases where it holds a `View` or other type of component instead.
A custom component can be passed in to `renderScrollComponent`, and then `_scrollRef` will point to that custom component. Additionally, if two VirtualizedLists are nested with the same orientation, `_defaultRenderScrollComponent` will return a View instead of a ScrollView.
Due to these possibilities, `_scrollRef` is not guaranteed to have a `scrollTo` method.
Changelog: [General] [Added] - Add warning when scrollRef does not have a scrollTo method
Reviewed By: JoshuaGross, TheSavior
Differential Revision: D21386842
fbshipit-source-id: 01e167e0ae0edea8f29853e8b242ce88a5103b49
Summary:
When we call `.erase` on the TinyMap, it sets the key of the element to 0. When we call `.begin()` later, TinyMap will sometimes, but not always, clean up the underlying Vector. This means that *most* of the time, underlying erased elements will be removed from the Vector; but sometimes erased elements will still be there when iterating over it.
This was causing us to generate extra "Create" mutations.
To fix this, for now we just check for zeroed-out elements when iterating over the vector.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21389371
fbshipit-source-id: 1e641050987d40a3f3e31499dcb373cfb28ae6f8
Summary:
The default application requires Kotlin version that is not supported by the Gradle plugin (should be at least `1.3.10`). However, instead of upgrading, we should remove it entirely. Here's why.
This commit https://github.com/facebook/react-native/commit/29d3dfbd196176af98c9727c82ff2668e697d78e introduced Detox for RNTester Android application.
Since the commit doesn't mention Detox for the default application and there are no Detox tests present by default in the default application, I believe that this addition was performed by a mistake.
The best way is to remove Kotlin from the default template. This step is described in the Detox documentation and all users that are integrating Detox will be asked to perform it anyway. No need to do it for them.
## Changelog
[ANDROID] [INTERNAL] - remove Kotlin from the default template
Pull Request resolved: https://github.com/facebook/react-native/pull/28626
Test Plan: Building a brand new project with `master` should work
Differential Revision: D21388961
Pulled By: shergin
fbshipit-source-id: 92666aa67f92b29f4e7f9c036b332bd058cdd49e
Summary:
Changelog: [internal]
As part of recycle, we should delete state. This is a common pattern used in other components as well.
Reviewed By: shergin
Differential Revision: D21348782
fbshipit-source-id: a5dee2f4ccee9b19498db31dab1983d8879dca71
Summary:
`babel/preset-env` pulls in a number of unused deps, like `caniuse-lite` (3 MiB) that knows about which browsers support certain features. We do not ship to browsers and always know which version of node we are using, so we don't need to pull this in.
I changed `jscodeshift` to optionally depend on `babel/preset-env` instead of always pulling it in.
This reduces node_modules by 7 MiB.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D21374475
fbshipit-source-id: 6f55e96e990ec0ca12f17bb3657bfa5429796b93
Summary:
Removes `PropTypes` as a dependency of `VirtualizedList` by no longer validating the return value of `getItemLayout`.
Changelog: [Internal]
Reviewed By: TheSavior, cpojer
Differential Revision: D21370890
fbshipit-source-id: 966db3557b714987aa91179c7654a5ebf27818ad
Summary:
Our parsers accept these but they are invalid. This fixes them.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D21373812
fbshipit-source-id: 6084757b9f842644fe629ae5e6d85baec611588d
Summary:
There's a corner case where:
* The bridge gets invalidated, and native modules are cleaning up themselves (but not done yet)
* Something asks for a NativeModule instance - ideally it should just get nil at this point
* If TM Manager is invalidating, we get nil correctly, but we continue thru the old NativeModule lookup logic
* The latter will fail anyway, and would throw a redbox (RCTLogError).
So, if the bridge is invalidated, if TM Manager returns nil, we should just return nil for old NativeModule lookup.
The module of interest is RCTImageLoader, which was requested by RCTImageView on deallocation. The problem is RCTImageView got dealloc'ed **after** the bridge has been invalidated, so the lookup would always fail...
Bonus: RCTImageView should just keep a weak ref to the RCTImageLoader, so that:
* if the imageLoader is still alive on image dealloc, it can still access them (last minute "meaningless" cleanup)
* if the imageLoader is gone, then the image deallocation doesn't do anything
Changelog: [iOS] [Fixed] - Fix module lookup race condition on bridge invalidation.
Reviewed By: p-sun, sammy-SC
Differential Revision: D21371845
fbshipit-source-id: 862dc07de18ddbfb90e87e24b8dbd001147ddce4
Summary:
This diff refactors the ImageLoaderModule class in order to prevent early execution of Fresco.getImagePipeline method when prefetching MC is disabled (see stack D21362266)
changelog: [Internal][Android]
Reviewed By: shergin
Differential Revision: D21368516
fbshipit-source-id: 53f99cd3c3f4848364182cb954a8d34821cb6d9e
Summary:
This diff extends the logging of image prefetching to include react_native ID in the ContextChain of the Fresco logger.
This is necesary to properly assign pre-fetching of RN Android images to the react_native ID
changelog: [Internal][Android]
Reviewed By: fkgozali
Differential Revision: D21362266
fbshipit-source-id: ff64f0ebd12f61b713996558eb2d962f96ad8d94
Summary:
This diff injects Fresco.ImagePipeline into ImageLoaderModule in order to ensure prefetching uses the same ImagePipeline than ReactImageView
changelog: [internal][Android]
Reviewed By: fkgozali
Differential Revision: D21362267
fbshipit-source-id: d6f55cffb6be6a012c2afb4ad5db2072bc7100ec
Summary:
This diff refactors the ReactCallerContextFactory class to recive surfaceID as a parameter instead of ThemedReactContext
This is necessary for the next diff of the stack
changelog: [Internal][Android]
Reviewed By: fkgozali
Differential Revision: D21362265
fbshipit-source-id: d0079788049fe86d2873eb6aa4bf1115b33457af
Summary:
In D20551411 we (I) replaced `std::mutex` with `std::recursive_mutex` in `executeSynchronouslyOnSameThread_CAN_DEADLOCK` in order to support synchronous `RuntimeExecutor`. It turned out that the idea was cool but totally incorrect. Quite obviously, double locking recursive mutex on the same thread does nothing, so the whole setup does not work at all.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D21328072
fbshipit-source-id: 7f1f81de61c36adb167fe624ada3bd71913bdf7c
Summary: Changelog: [Changed][General] Update react-native-community/eslint-config to 1.1.0, adding the new color rule
Reviewed By: rickhanlonii
Differential Revision: D21342153
fbshipit-source-id: ac1367353d4d3e69b6df29dc16f9fcb60cde3519
Summary:
Updating pods and fixing an issue in the RN podfile.
Changelog: [iOS][Fixed] Update podfile for RNTester
Reviewed By: PeteTheHeat
Differential Revision: D21336180
fbshipit-source-id: 4d51f53466ec2d432cf7a5775cb4d69d47423077
Summary:
This diff refactors the initial render of Fabric in order to set the layout metrics as we start the surface.
This prevents to create an additional fabric commit during initial render. Also this migth help fixing T63495589 (I wasn't able to repro T63495589 again when using this diff)
changelog: [Internal][Android] Internal change to reduce the amount of commits during initial render of Fabric
Reviewed By: JoshuaGross
Differential Revision: D21330072
fbshipit-source-id: 758c49b52ea4c12d5623b7c7d68c7318f4a6cd83
Summary:
This diff removes the variable 'useSurface' which wasn't beeing used in ReactRootView anymore
changelog: [Internal][Android] Internal cleanup of ReactRootView
Reviewed By: JoshuaGross
Differential Revision: D21318109
fbshipit-source-id: f850b27811608d16b22b6a3964455b172705c4c7
Summary:
This diff reduces exposure of UIManagerModule in the NativeAnimatedNodesManager class, this is necessary to enable NativeDriverAnimations in Venice
changelog: [Internal][Android] Internal change to enable native driver animations in RN bridgless mode
Reviewed By: ejanzer
Differential Revision: D21317629
fbshipit-source-id: 81cd4ade296de4757acefe566e1466154d6b4e4b
Summary:
This diff removes the hostname from the loading bar and shrinks it down so it's inside the margins of the safe area view, never blocking app content inside the safe area.
Changelog: [General] [iOS] Shrink loading bar down to not cover safe area.
Reviewed By: shergin
Differential Revision: D21339480
fbshipit-source-id: e8416af63b7e06bcc21c7b6277d5d01d61eb3f73
Summary:
In D20836890 we no longer set `_contentView.frame` inside `layoutSubviews`.
This doesn't work well with component views that set their `contentView` after `updateLayoutMetrics` is called. For Example legacy interop which sets its contentView in the `finalizeUpdates` method. Other component views that set their contentView during initialisation are fine.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D21302108
fbshipit-source-id: 5adcf489e4e650ac04b84c836a8f8d6f55a77267
Summary:
The AndroidInfoModule class defines a `getServerHost()` method that duplicates the logic in `AndroidInfoHelpers.getServerHost(context)`. This commit makes AndroidInfoModule call into AndroidInfoHelpers so that potential future changes to `AndroidInfoHelpers.getServerHost` don't need to be duplicated in `AndroidInfoModule.getServerHost`.
## Changelog
[Android] [Changed] - Internal change to make `PlatformConstants` use the same method to determine `ServerHost` as other code paths
Pull Request resolved: https://github.com/facebook/react-native/pull/28756
Test Plan: Tested by running the RNTester app and editing the root component to print out `NativeModules.PlatformConstants.getConstants()` and verified one of the properties was: `"ServerHost": "10.0.2.2:8081"`.
Differential Revision: D21252158
Pulled By: shergin
fbshipit-source-id: b460197e5f1d972a5b91991c32a929294e358d9f
Summary:
The change is gated by two QEs (iOS and Android).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D21317797
fbshipit-source-id: 34bfd9546600d9cb3467bddfc61363a16683f81f
Summary:
I spent the last several days thinking about state reconciliation issues, some crashes (T65586949) that suspiciously happen somewhere inside, and a bunch of issues that might be connected to that (possibly, some of T65516263 sub-task).
I cannot see some obvious problems in the current state reconciliation algorithm that might cause the crash (because of some use-after-free or other pure C++ issues), but I suspect some of the problems we experience might be caused by some details of how we reconcile states.
In the current approach, we rank all states based on the "hierarchical" history of their creation (state version is being calculated based on the version of the base tree). That's usually fine but in some cases when trees are being constructed concurrently, a logical version of a based tree does not correspond to the local version of a committed tree. In other words, the linear history of commits does not always correspond to the "hierarchical" history of trees generation that was done by different parties (e.g. React vs native state update pipeline).
In this diff, I tried to change the approach to change the algorithm to follow this logic: If some state is `obsolete` (already been committed and then replaced with newer one), we replace that with the most recent one. This change does not introduce the `obsolete` flag; is already used by State infra to avoid cloning nodes with an outdated state.
Interestingly, it fixes the issue with an empty BottomSheet on Android (T66177144). See the attached video. The hope is that it's also will
This change theoretically might affect all things that use State, so it hard to predict what can break and how. So, if we don't see obvious problems here, I would set up a GK/QE and run the experiment in prod.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D21295137
fbshipit-source-id: e5613218d3e11a56623cab9bbf2540495b2b24e8
Summary:
This diff extends venice app to render an Animation example test
changelog: [Internal][Android] Internal change to enable Animated in RN Bridgless mode
Reviewed By: PeteTheHeat
Differential Revision: D21317630
fbshipit-source-id: 9726fea9baba86191e63df909639d1d47ef5f359
Summary:
`JSCallInvoker` doesn't exist anymore, because it was renamed to `CallInvoker`. So, this `.clang-tidy` dotfile isn't necessary.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D21318061
fbshipit-source-id: 8098eef670cae35bf3c027c91f18f45eb7bcd33a
Summary:
As described in DevSettingsActivity, it should be added to the apps
debug/ instead of main/ manifest.
## Changelog
Android Changed - Move DevSettingsActivity from `main` to `debug` manifest
Pull Request resolved: https://github.com/facebook/react-native/pull/28770
Test Plan: Tested locally by building example app
Differential Revision: D21281922
Pulled By: shergin
fbshipit-source-id: ec4dc7c0ac54367aa38cca5b4146ef71cf18b73b
Summary:
Task is closed, I'm removing the TODO. I verified that the soft error is not being triggered
changelog:[Internal][Android] Internal cleanup of fabric android
Reviewed By: sammy-SC
Differential Revision: D21303999
fbshipit-source-id: 11d4a14c71d27ffc70a6d3b955a21085dd11859b
Summary:
This diff updates the loading banner to protect against showing percentages over 100%
Changelog: [Fixed] [iOS] Cap loading bar percentage at 100%
Reviewed By: shergin
Differential Revision: D21295809
fbshipit-source-id: 343f53acafa126800367444562730eff4ae67af4
Summary:
This diff reduces the minimum loading banner time and animation time to make the locating banner faster.
Changelog: [General] [iOS] Speed up loading banner animations
Reviewed By: PeteTheHeat
Differential Revision: D21290517
fbshipit-source-id: 111dff41df53b0246548e1da1db80c2188498a9c
Summary:
This diff fixes an issue where the initial "Loading from Metro..." message is flashed for a few milliseconds before the download progress kicks in. It's just jarring enough to be noticed and is ~600ms too fast to be read.
This diff adds a delay so that if the loading progress starts within 200ms we go straight to the progress.
Changelog: [Fixed] [iOS] Delay loading banner message to prevent flashing messages
Reviewed By: PeteTheHeat
Differential Revision: D21281870
fbshipit-source-id: d28c1eae01c2ac9d79f356f1870f17dbb22a9d84
Summary:
This diff fixes an issue where the loading banner message could update while the banner hide animation is going, catching your eye for no reason.
Changelog: [Fixed] [iOS] Do not update loading banner message while hiding
Reviewed By: PeteTheHeat
Differential Revision: D21280786
fbshipit-source-id: a10b33cd72f263d08eea6d8e94963514affbe24d
Summary:
This diff adds a hostname to the loading banner on iOS so it's clear which server you're loading from.
Changelog: [Added] [iOS] Added hostname to loading banner.
Reviewed By: PeteTheHeat
Differential Revision: D21280252
fbshipit-source-id: d7733c056f5fb63e32b247a4fa1476ab42c7da17
Summary:
This diff rejects the promise when if an error occurs while processing prefetching result, it applies the same concept as other methods in this class (e.g. see getSizeWithHeaders)
changelog: [internal][Android] Internal change in RN Image prefetching
Reviewed By: JoshuaGross
Differential Revision: D21295612
fbshipit-source-id: c3675e5f2d9c8e38094a538b388ff63a6ea18360
Summary:
I refined the error message of scrollToIndex.
When I used scrollToIndex with `index:0` and data that length is 0, I met the odd error message `Invariant Violation scrollToIndex out of range: requested index 0 but maximum is -1`.
Next, I thought that scrollToIndex with `index:-1` meant scrollToTop without checking data length. I met `Invariant Violation: scrollToIndex out of range: requested index -1 but maximum is -1`
Finally, I wondered what will happen to use scrollToIndex with `index:-1` and data that length is `5`. The result is `Invariant Violation: scrollToIndex out of range: requested index -1 but maximum is 5`
The above error messages will confuse us. I clarified the boudaries and separated the error messages
## Changelog
[General] [Fixed] - Clarified the boundaries in error message of scrollToIndex
Pull Request resolved: https://github.com/facebook/react-native/pull/28464
Test Plan:
I added 3 test cases to cover the new error messages for VirtualizedList.
Run `yarn test` and confirm it passes.
Reviewed By: cpojer
Differential Revision: D21140133
Pulled By: TheSavior
fbshipit-source-id: 9a7a704f7ec599d833d2ed3ca2be059d950539b5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/28779
Creating a JNI wrapper class for RuntimeExecutor so we can pass it to Fabric and TurboModules in Java.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D21049385
fbshipit-source-id: f833004225d9837acf6ffafd3988f89748cf12aa
Summary:
When I initially made TurboModuleManager.getModule thread-safe, I unintentionally broken TurboModule cleanup. This diff fixes that mistake.
## Mistake
```
Override
public void onCatalystInstanceDestroy() {
synchronized (mTurboModuleCleanupLock) {
mTurboModuleCleanupStarted = true;
}
final Set<String> turboModuleNames = new HashSet<>(mTurboModuleHolders.keySet());
for (final String moduleName : turboModuleNames) {
// Retrieve the TurboModule, possibly waiting for it to finish instantiating.
final TurboModule turboModule = getModule(moduleName); // ERROR!
if (turboModule != null) {
// TODO(T48014458): Rename this to invalidate()
((NativeModule) turboModule).onCatalystInstanceDestroy();
}
}
```
Before calling `getModule(moduleName)`, I set `mTurboModuleCleanupStarted = true`. This assignment makes all calls to `getModule` return `null`, which means that none of the TurboModules were having their `onCatalystInstanceDestroy()` method invoked.
Changelog:
[Android][Fixed] - TurboModule cleanup
Reviewed By: fkgozali
Differential Revision: D21290582
fbshipit-source-id: 3645b9a4f8c6f41498ebd9d51f9b5775edf2dbd7
Summary:
Running `./gradlew assembleRelease` fails as the path to the CLI contains a new line at the end. We don't run this command in `debug` mode, hence it passed the testing. My bad.
Fixed, checked in both `debug` with `bundleInDebug: true` and `release`.
Fixes https://github.com/facebook/react-native/issues/28700
## Changelog
[INTERNAL] [ANDROID] - Fix `React.gradle` to build Android apps in production
Pull Request resolved: https://github.com/facebook/react-native/pull/28776
Test Plan: Running `./gradlew assembleRelease` works
Reviewed By: hramos
Differential Revision: D21287789
Pulled By: TheSavior
fbshipit-source-id: dc3ec8eef7a919b072b562d2bd455e2f704bc083
Summary:
Resolve RNTester Xcode warnings.
## 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] [iOS] - Resolve RNTester Xcode warnings
Pull Request resolved: https://github.com/facebook/react-native/pull/28676
Test Plan: Building RNTester no longer shows project setting warnings
Differential Revision: D21109702
Pulled By: hramos
fbshipit-source-id: f7552d3a9857ee7415cd96622a0a79797a168698
Summary:
This is the codemod portion of the parent diff.
I modified all call-sites to `ReactContext.getNativeModule` to do a null check on the returned NativeModule.
Changelog:
[Android][Fixed] - Check if NativeModules returned from CatalystInstanceImpl.getNativeModule are null before using them.
Reviewed By: JoshuaGross
Differential Revision: D21272028
fbshipit-source-id: 6bd16c6bf30605f2dfdf4c481352063712965342
Summary:
## Description
When the TurboModule and the NativeModule systems are alive at the same time, after RN cleanup, if a TurboModule is required, we return `null` from TurboModuleManager. This causes `CatalystInstanceImpl.getNativeModule` to do a lookup on NativeModule registry, which throws an `AssertionError`, because the TurboModule isn't found. Instead of throwing an `AssertionError` from `CatalystInstanceImpl.getNativeModule`, this diff instead has that method return `null` in this particular case.
## Rationale
This should eliminate the crashes we're seeing in T46487253.
## Future action
In the future, we should guard `CatalystInstanceImpl.getNativeModule` with an `if (mDestroyed) return null;` statement. This'll ensure that if NativeModules are required after React Native has started cleanup, they'll be returned as `null`. Right now, we either return the destroyed NativeModule object, or create/initialize the NativeMoulde and return it, which is wrong.
Changelog:
[Android][Changed] - Make CatalystInstance.getNativeModule nullable
Reviewed By: JoshuaGross
Differential Revision: D21272029
fbshipit-source-id: 099ad9ab9fa2146299df4cf7f86ae7a8e526bb15
Summary:
When generating ip.txt in an iOS debug build, search en0 through en8 for an IP address rather than only checking en0 and en1. For example, on my Mac, the IP address I needed to use was on en5 and the IP address actually detected was a private network of one of my Parallels virtual machines (interface vnic0).
## 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] - Search en0 through en8 for the Metro Bundler's IP address when generating iOS debug builds
Pull Request resolved: https://github.com/facebook/react-native/pull/28764
Test Plan: Should make no difference to users for whom react-native-xcode.sh already worked. On a Mac with multiple virtual machines installed, should prevent ip.txt getting the private IP address of a virtual machine.
Differential Revision: D21280671
Pulled By: shergin
fbshipit-source-id: e6fe9c8344146626df96129968981462463201f7
Summary: Changelog: [Internal] [Yoga] Use double instead of float during rounding process to prevent loss of precision.
Reviewed By: mdvacca
Differential Revision: D21227565
fbshipit-source-id: 380b57535a356624cda8dc2017871a4ef3c882d1
Summary:
We neede that to make the test less flaky.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D21261487
fbshipit-source-id: afec45e03be10ba071a5ab808ce13f95b5f475e3
Summary:
Changelog: [Internal]
When there is a change coming from javascript, avoid triggering `onChange ` and `onSelectionChange` events since JavaScript already has these changes. This is only necessary for multiline text.
For changes coming through view commands, do not increment `_mostRecentEventCount`.
Reviewed By: shergin
Differential Revision: D21255228
fbshipit-source-id: e972dab0eb3dd21f611ee5c71d755bab593ae9cc
Summary:
Changelog: [Internal]
In `onKeyPress` event, we were not returning `key` property. This diff adds `key` property to `onKeyPress` event and removes other, redundant properties from `onKeyPress` event.
The implementation has been translated from Paper.
Reviewed By: shergin
Differential Revision: D21250411
fbshipit-source-id: f1e31381667acb9dec02d0b33883df8f8f5b2a4b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/28730
Moving RuntimeExecutor out of react/utils and into its own subdir of ReactCommon. I'm doing this because I'm going to be pulling this into CatalystInstance on Android, and I don't want to pull in all the files we don't need there; also, this should hopefully make the OSS NDK stuff easier (this uses the react/utils prefix to export, and I'm not sure if you can include a '/' in a gradle module name?)
Changelog: [Internal]
Reviewed By: shergin, mdvacca
Differential Revision: D21098528
fbshipit-source-id: 9fbd72901ece522b1caec3ec34fafb8f9b327275
Summary:
TextInput must have `LeafYogaNode` trait to be able contain non-yoga nodes.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D21252322
fbshipit-source-id: 820f3ae4811cb475550419af501739c57c7164e1
Summary:
Changelog: [Internal]
Previously `setTextAndSelection` was not dirtying layout. This would cause an issue where `setTextAndSelection` causes layout change. For example calling setTextAndSelection with empty string on a multiline auto expanding text input.
I changed one example in TextInputSharedExamples.js, "Live Re-Write (no spaces allowed) and clear" example is now multiline. This allows to test whether `setTextAndSelection` dirties layout. Enter multiline string to to the example text input and press clear. Observe that the text input shrinks to single line height.
Reviewed By: shergin
Differential Revision: D21182990
fbshipit-source-id: de8501ea0b97012cf4cdf8d5f658649139f92da6
Summary:
On Android, when using split-screen mode, the Window-relative position of a native View is not calculated properly when the app is running on the right (or bottom) half of the screen. The coordinates are currently calculated only based on View.getLocationOnScreen() with subtracting status bar height. Scenarios, where the window does not fill the entire screen (such as split-screen mode) are not supported.
We need to use a more general solution to subtract the actual position of the window from position of the view within the screen. This PR fixes the issue by subtracting coordinates of the Window retrieved from View.getWindowVisibleDisplayFrame(), which covers all scenarios when Window can be in a different position than the screen (incl. status bar offset).
## Changelog
[Android] [Fixed] - Calculating view position within the window in split-screen mode
Pull Request resolved: https://github.com/facebook/react-native/pull/28449
Test Plan:
1. Run an app in split-screen mode on the right half of the screen
2. Call UIManagerModule.measureInWindow() from JS to fetch a position of a View within a Window
3. Observe the wrong coordinates returned
4. Try the same with the fix
Reviewed By: mdvacca
Differential Revision: D21246297
Pulled By: shergin
fbshipit-source-id: 1f54b1a5d6610be17bf05521200304db2ba263ab
Summary:
Refs https://github.com/facebook/react-native/issues/28706
This small PR removes `tvOS` platform and `HelloWorld-tvOS` references from the e2e CI tests script. Also a small typo in comment has been fixed.
CC: dlowder-salesforce
## Changelog
[Internal] [Removed] - remove tvOS from the e2e CI tests
Pull Request resolved: https://github.com/facebook/react-native/pull/28743
Test Plan: Exec during `node ./scripts/run-ci-e2e-tests.js --ios` was successful.
Differential Revision: D21252185
Pulled By: shergin
fbshipit-source-id: 56981f2c5c3038412e9f37a81084de87e296d7d2
Summary:
Because of StateReconciliation (?) it is possible, even likely, that eventually the ShadowNode that ReactJS holds onto will not be the latest ShadowNode, and will not contain the latest LayoutMetrics.
This fixes the problem by always resolving the latest committed version of the ShadowNode before measuring it.
Changelog: [Internal] Fabric measure bugfix
Reviewed By: sammy-SC, mdvacca
Differential Revision: D21248472
fbshipit-source-id: a4f034c36d89a91a804f3b4cdf35e7ae748a1b91
Summary:
According to the Flow types, `contentOffset` is nullable. Support that.
Changelog: [Internal] Fix to (1) support null contentOffset in ScrollView and HorizontalScrollView, added on Android after the last release. (2) Correctly add support for contentOffset in ScrollView (I missed that when adding it to HorizontalScrollView in the previous diff).
Reviewed By: alsun2001
Differential Revision: D21243028
fbshipit-source-id: ebef9a9054a3e4dd88556739e836b7ece48fda12
Summary:
It's not immediately obvious from the UI/UX when/if this mechanism breaks, so it's good to have a test.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D21184718
fbshipit-source-id: 25432a1398cff3ce61f62cf433e3cb73d7a7a93f
Summary:
It's not allowed to return nullptr from the callback. The assert ensures it which is helpful during development.
Probably, we should consider using `gsl::not_null<>` here.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D21149891
fbshipit-source-id: a5f77b35029f22b499491721036405682f812a38
Summary:
Previously, a derived class, WithTuple, was used. This ran
into bugs in MSVC (see https://github.com/microsoft/STL/issues/121).
Instead, use specialization to get the same result using std::tuple
directly. This avoids the bug, and is a cleaner API.
Changelog: [Internal]
Reviewed By: dulinriley
Differential Revision: D21233677
fbshipit-source-id: 1d75991847164e525b4ba70f65a90627e5f8cd56
Summary:
This PR adds support for the dark mode and dynamic theme changing to the default App template and to the related `NewAppScreen` components. Using `useColorScheme` hook forced me to refactor a bit main `App.js` file, but I think those changes are step in the right direction according to way in which React Native is used in larger apps, so new `Section` component has been extracted to reduce code redundancy/repetition inside `App`.
Additional color `darker` has been added to the `Colors` statics from `NewAppScreen` because `dark` was too bright for the Dark Mode backgrounds.
Also main `StoryBoard` on iOS has been updated to use theme based colors instead of static or hardcoded ones. There was also an unused, empty `Label` which I have removed.
~~I'm not so much experienced with Android. If someone could also update Android splash screen (if Android requires such change) it will be nice. I want to look at this later using simulator.~~
> I have updated the Android splash screen and tested this change on the Android emulator.
If you have any comment or corrections feel free to post them out, I would like to put more work into this PR if it's needed. Dark Mode this days is a part of near every OS, so it could be considered as a standard feature. I hope those changes helps people which struggle with the basic theming implementation (+ there is now an example of hook and `children` prop usage in the template).
## Changelog
[Internal] [Added] - Add dark mode support to the default app template
Pull Request resolved: https://github.com/facebook/react-native/pull/28711
Test Plan:
I have tested the App from the template on the iOS device and in Android emulator with RN `0.63.0-rc`.
Screen recording on iOS (demonstarates both modes, both splash screens and transition):
Screenshot of iOS app in Dark Mode:
Screenshot of iOS app splash screen in Dark Mode:
Screenshot of Android app in the emulator:
Differential Revision: D21236148
Pulled By: shergin
fbshipit-source-id: 0c8a9534d3a3f8f8099af939243a889ac4df6cda
Summary:
This change upstreams a small change we did in react-native-windows to allow the RTLExample RNTester page to function correctly on Windows. The change is part of this Pr:
https://github.com/microsoft/react-native-windows/pull/4683
Currently the direction property is gated behind a check for Platform == 'iOS', which means it only works on iOS. Windows supports direction = 'rtl' so I've chanced this check to Platform != 'android'.
## 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] - Changed RTLExample RNTester page to use direction = 'rtl' when Platform is not Android.
Pull Request resolved: https://github.com/facebook/react-native/pull/28742
Test Plan: Confirmed this change works correctly in RNTester on Windows. Have not confirmed iOS as I don't have Mac hardware.
Differential Revision: D21235579
Pulled By: shergin
fbshipit-source-id: 47ab93c2bcd0dbc8347c6746081ae3c64f88faa5
Summary:
This diff removes unnecessary (int) casts in the calculation of layout for TextInlineViews
changeLog: [Internal][Android] Internal optimization on the calculation of layout for TextInlineViews
Reviewed By: JoshuaGross
Differential Revision: D21211532
fbshipit-source-id: 920c1f88d042f3e1f6bfd0f560371f7482a62064
Summary:
Fixes text layout so that the parent bounds are correctly respected. This fixes two bugs:
- **Parent width is not respected.** This was caused by the recent change to shrink-wrap text layout.
- **Parent height is not respected.** This has always been a bug.
After this change, Android will behave like iOS.
Changelog:
[Android] [Fixed] - Text layout no longer ignores parent bounds
Reviewed By: mdvacca
Differential Revision: D21199030
fbshipit-source-id: cc072bdcff64167db1f79b7bf965e57a7396cdf4
Summary:
For a very long time, iOS has supported the `contentOffset` property but Android has not:
https://github.com/facebook/react-native/issues/6849
This property can be used, primarily, to autoscroll the ScrollView to a starting position when it is first rendered, to avoid "jumps" that occur by asynchronously scrolling to a start position.
Changelog: [Android][Changed] ScrollView now supports `contentOffset`
Reviewed By: mdvacca
Differential Revision: D21198236
fbshipit-source-id: 2b0773569ba42120cb1fcf0f3847ca98af2285e7
Summary:
I noticed that in ModalHostShadowNode.java (not used in Fabric), there's an assumption that the Modal will have exactly one child on the native side; this child is explicitly specified in Modal.js.
However, in Fabric, these views are flattened and so the Modal will actually have N children - whatever children the product code passes into the Modal.
In *theory* this should be fine, but might be causing issues. Not sure.
This is an experiment and shouldn't be landed until we verify that (1) this actually matters, (2) that it fixes an issue with Modal on iOS or Android.
Changelog: [Internal] Change to make Fabric consistent with non-Fabric Modal
Reviewed By: mdvacca
Differential Revision: D21191822
fbshipit-source-id: 9d65f346387fd056649d4063d70220f637ba8828
Summary:
Updating state with a null wrapper is neither desirable, nor possible. The underlying task was closed, just cleaning up comments.
Changelog: [Internal] comments only
Reviewed By: mdvacca
Differential Revision: D21186545
fbshipit-source-id: d14ddd59d42e8fd91c6e7fd50037311d4e8d0b60
Summary:
The integration with Yoga was pretty complex from day one. The first attempt to make it simpler was in D19963353 when we removed a bunch of layers of indirection. This is the second iteration that aimed to simplify the structure of methods and their responsibilities.
The only conceptual change (that I am aware of) in this diff is that now we don't support (imaginary) case where a non-leaf YogaLayoutableShadowNode can have a non-YogaLayoutableShadowNode child. In the previous version, it was a no-op, now it's not supported and an assert will fire.
Alongside with refactoring, this diff implements several helper functions that verify the invariants important for the Concurrent Layout in debug mode.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D21198222
fbshipit-source-id: cc085904948056f861562af5bd2571de45a743b9
Summary:
Adds support for `RootTag` in the new codegen for Native Component Commands.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D21169371
fbshipit-source-id: 3b25433f3328e9c04cfe45bb176fc06d63559f14
Summary:
Adds support for `RootTag` in the new codegen for NativeModules/TurboModules.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D21160788
fbshipit-source-id: 952189f6e8bc8fde8b403d4c0e77b5d66b3f03e4
Summary:
Adds a `RootTag` parser test for the new codegen for NativeModules/TurboModules.
I'm doing this in a prerequisite commit in order to make the diff of the diff clearer when I implement proper support for `RootTag`.
This also fixes some of the minor typos and mistakes that I noticed. I also wanted to land these benign snapshot changes independent of the upcoming behavior changes.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D21160792
fbshipit-source-id: 5f29f34035da30d7afa2369dbc19e95954553e88
Summary:
Straightforward rename to clarify the purpose of this type.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D21160791
fbshipit-source-id: 422d09243edda0660815eb2f0ce51f7e56134983
Summary:
Straightforward rename to clarify the purpose of this type.
The current naming made more sense before the codegen also produced code for NativeModules.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D21160793
fbshipit-source-id: 6787ef298e32ff1b4d506afd831af96764f5af6f
Summary:
Straightforward rename to clarify the purpose of this type.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D21160790
fbshipit-source-id: eaf5e8c9f51e16134e153a6321857234be1aa338
Summary:
This is a follow-up pull request to https://github.com/facebook/react-native/issues/28280 (reviewed by shergin).
This pull request tried to solve the problem of the default color in a TextInput in dark mode on iOS being white instead of black. I got suggested to solve the problem not on the level of RCTTextAttributes, but on the level of RCTUITextField.
Setting `self.textColor = [UIColor black];` in the constructor did not work, because it gets overwritten by nil in `RCTBaseTextInputView.m`. There I implemented the logic that if NSForegroundColorAttributeName color is nil then the color is being set to black. I think the `defaultTextAttributes` property confuses here, because it ends up being the effective text attributes, e.g. if I unconditionally set the default text color to black, it cannot be changed in React Native anymore. So I put the nil check in.
## Changelog
[iOS] [Fixed] - TextInput color has the same default (#000) on iOS whether in light or dark mode
Pull Request resolved: https://github.com/facebook/react-native/pull/28708
Test Plan:
I have manually tested the following:
- The default text color in light mode is black
- The default text color in dark mode is black
- The color can be changed using the `style.color` attribute
- Setting the opacity to 0.5 results in the desired behavior, the whole TextInput becoming half the opacity.
– Setting the `style.color` to rgba(0, 0, 0, 0.5) works as intended, creating a half-opaque text color.
Differential Revision: D21186579
Pulled By: shergin
fbshipit-source-id: ea6405ac6a0243c96677335169b214a2bb9ccc29
Summary:
folly_futures was compiled with and exported -DFOLLY_MOBILE=1, while
folly_json did not. This flag disables fancy F14 data structures for
folly::dynamic in favor of a simple std::unordered_map.
This caused inlined/templated code from modules depending on
folly_futures to disagree with the implementations in folly_json,
leading to a crash.
The only such libraries were libhermes-inspector and (transitively)
libhermes-executor-debug, and these only use folly::dynamic for CDP
serialization, which is why the problem was not more apparent.
Changelog: [Internal] Fix crash when attaching a Hermes debugger
Reviewed By: mhorowitz
Differential Revision: D21193307
fbshipit-source-id: 2b795bb6f4f7f991e2adaacec62d62616117322b
Summary:
## Problems:
In my investigation of T65656635, I realized that the TurboModule system has a number of problems:
- In TurboModules, we use 1 lock to create n TurboModules. We should change this setup to n locks for n TurboModules. This way, two threads creating two different NativeModules don't compete for the same lock. Also, this is how it's done in Android (TurboModules & NativeModules), and iOS (NativeModules).
- In TurboModules, we don't calculate "requires main queue setup" faithfully. In the legacy system, if a NativeModule has a custom `init` method or a custom `constantsToExport` method, it "requires main queue setup" with a warning.
- In TurboModules, we don't create the NativeModule on the main queue, if "requires main queue setup" is true. Instead, the NativeModule is always created on the thread that requires it.
- In TurboModules, we don't perform any concurrency control around `id<RCTTurboModule>` setup. We should.
## What this diff does
In this diff, I fixed all the aforementioned issues by re-implementing `provideRCTTurboModule:`.
**Algorithm Notes:**
- **Gist:** When `n` threads race to create NativeModule `x`, only the first thread creates and sets up `x`. All others are told to wait. Once the creator thread finishes its job, it notifies all other waiting threads, which then wake up and return the newly created NativeModule. This algorithm was initially implemented in NativeModules for Android inside (ModuleHolder.java). I modified and implemented it for TurboModules for Android, and now this diff implements it for TurboModules for iOS.
- The TurboModule cache is replace with a TurboModuleHolder map. A TurboModuleHolder manages the creation lifecycle of a TurboModule, and holds a condition variable and mutex for doing concurrency control around it. When the bridge invalidates, in TurboModuleManager, we set the `invalidating` flag to true, which prevents the insertion of new entries into the TurboModuleHolder map.
- I added a `std::mutex` to serialize calls into the TurboModuleManagerDelegate, so we don't get races if the delegate isn't thread-safe.
Changelog:
[iOS][Fixed] - Re-implement RCTTurboModuleManager provideRCTTurboModule:
Reviewed By: shergin
Differential Revision: D21170099
fbshipit-source-id: 8792812c2237d3bfc80c9834c818e011de85b0ea
Summary:
`ShadowNodeFamilyFragment::Value` is a value couter-part type for `ShadowNodeFamilyFragment`.
We need that to be able safely copy data stored inside a `ShadowNodeFamilyFragment` object.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: kacieb
Differential Revision: D21169580
fbshipit-source-id: 1a485e1b2ae47bc7da9476a60466934ac9d61366
Summary:
We need it to be able pass an `EventEmitter` object to constructed concrete State objects.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D21169581
fbshipit-source-id: 3eef0310de7e2f061108aa85c1a39678a43fe85e
Summary:
According to the [0.62 blog post](https://reactnative.dev/blog/2020/03/26/version-0.62), Apple TV support has moved to react-native-tvos.
The template still contains info.plist for tvOS, so I've removed them for future releases.
## 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] [Removed] - Removed tvOS related files from the template
Pull Request resolved: https://github.com/facebook/react-native/pull/28706
Test Plan: run `react-native init TestTemplate` and remove tvOS related files and verified that iOS and Android runs on emulator.
Differential Revision: D21182211
Pulled By: hramos
fbshipit-source-id: 41d2e19e5158d7ec103a37c01a93cf511fc1e4c9
Summary:
RN itself does not depend on Metro any longer, which is abstracted away into the CLI. I don't think we need those type definitions any longer as we have proper Metro definitions internally. I'm removing them because they keep showing up in biggrep when I look for things.
Changelog: [Internal]
Reviewed By: GijsWeterings
Differential Revision: D21089924
fbshipit-source-id: 2845277af12dae0f0baefaf85adefffb6ef9f2a5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/28719
The Buck dependencies for the schema rule is missing the source files for the new codegen (and specifically, the parser).
Changelog:
[Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: cpojer
Differential Revision: D21162993
fbshipit-source-id: 4addb6f257134e245a5d86dd427ee2536ed6d658
Summary:
Adds `RootTag` as a valid type for arguments and return types in TurboModules (on both Android and iOS).
This will enable us to change `RootTag` into an opaque type. There are two compelling reasons to do this:
- JavaScript will no longer be able to safely depend on `RootTag` being a number (which means we can change this in the future).
- Call sites using `unstable_RootTagContext` will can get a `RootTag`, but call sites using the legacy `context.rootTag` will not. This means the opaque type will give us a strategy for migrating away from legacy context and eventually making `unstable_RootTagContext` the only way to access `RootTag`.
Changelog:
[Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: RSNara
Differential Revision: D21127170
fbshipit-source-id: baec9d7ad17b2f8c4527f1a84f604fc0d28b97eb
Summary:
Creates a `RootTag` type and refactors the `RootTagContext` module a bit.
This creates space for eventually changing `RootTag` into an opaque type that is only created once by `AppContainer`, and only consumed by native abstractions.
Changelog:
[Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: cpojer
Differential Revision: D21127173
fbshipit-source-id: 60177a6e5e02d6308e87f76d12a271114f8f8fe0
Summary:
`babel-eslint` is the parser you can supply to ESLint based off of Babel.
`babel-eslint` 10.1.0 is the newest production version of `babel-eslint`.
There are very few changes between 10.0.1 (the lowest previous version) and 10.1.0. There are only 3 non-version-bump commits: 2 bug fixes and enabling parsing of Flow enums.
The only project that was on a lower version than 10.0.1 was `/xplat/js/RKJSModules/Libraries/Relay/oss/__github__` - test below
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D21055850
fbshipit-source-id: bae0d8af5c6d833a4dbb0ad775c8e5e78ead1051
Summary:
Changelog: [Internal]
Flip text alignment in case layout direction is RTL.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D21130371
fbshipit-source-id: cf56ca052c17a48e321803b0f99f8a4baaa0e67b
Summary:
Easy diff to document in code how to enable logging of Shadow Tree instrospection
changeLog: [Internal] Internal change used on Fabric
Reviewed By: JoshuaGross
Differential Revision: D21150196
fbshipit-source-id: 8eb23ec3ea1d574b79b09333428ab52c851065dd
Summary:
Update differ test so it passes again. Previously to D21111423 (I think) nodes were being incorrectly detected as updated even if they weren't different, so now there are fewer unnecessary Update mutations generated.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21148647
fbshipit-source-id: cab6e3ecd0a457e1ac3155b3468bcc56663dab0b
Summary:
Per discussion in https://github.com/react-native-community/releases/issues/186 the iOS `PlatformColor()` function is documented to use the semantic color names provided by the system. The referenced HIG documentation itself links to the `UIColor` documentation for semantic colors names. However, these names differ depending on if you are viewing the new Swift API docs or the Objective C docs. The current Objective C implementation in react-native assumes Objective C UIColor selector names that are suffixed 'Color'. But in Swift, Apple provides a Swift Extension on UIColor that makes aliases without the the 'Color' suffix and then makes the original selectors invalid presumably via `NS_UNAVAILABLE_SWIFT`.
Since both selector names are valid depending on if you are using Objective C or Swift, let's make both forms be legal for `PlatformColor()`. In `RCTConvert.m` there is a dictionary of legal selector names. The code already supports the ability to have names be aliases of other selectors via a RCTSelector metadata key. The change adds code to the initialization of the map: it iterates over the keys in the map, which are all ObjC style UIColor selectors, and creates aliases by duplicating the entries, creating key names by stripping off the ObjC "Color" suffix, adds the RCTSelector key referring to the original and then appends these new Swift aliases to the map.
## Changelog
[iOS] [Changed] - Allow iOS PlatformColor strings to be ObjC or Swift UIColor selectors
Pull Request resolved: https://github.com/facebook/react-native/pull/28703
Test Plan:
The PlatformColorExample.js is updated to use the new, shorter Swift selector names. There are still other examples in the same file and in unit tests that exercise the ObjC selector names.
<img width="492" alt="PlatformColor" src="https://user-images.githubusercontent.com/30053638/79809089-89ab7d00-8324-11ea-8a9d-120b92edeedf.png">
Reviewed By: shergin
Differential Revision: D21147404
Pulled By: TheSavior
fbshipit-source-id: 0273ec855e426b3a7ba97a87645859e05bcd4126
Summary:
Yoga uses a dirty flag to re-layout nodes. In normal, single-threaded approach the policy for dirtying is simple: if a node was changed, we need to dirty it. In the Concurrent Yoga approach, those rules are not so simple, and it seems we haven't formalized those rules yet.
Investigating some layout issues that we have in Fabric, I tend to believe that we don't dirty as much we should. Hense this change adds mode dirtying.
Reviewed By: JoshuaGross
Differential Revision: D21092815
fbshipit-source-id: 4603c97ccb79efcdf5e6a4cc450ebe61b63effb3
Summary:
This is quite a fateful mistake. `getDirtied()` returns the pointer to a function which is obviously a mistake here; we should use `isDirty()` instead.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D21028569
fbshipit-source-id: 95212b31f4e32d51c594d5209f295397af3f1252
Summary:
This diff exports `isPackagerRunning` as a class method to be used without and instance.
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D21094414
fbshipit-source-id: 44becb59e3c08d66e4992c4c1b32d6efcd4fe257
Summary:
This Hermes-specific mode is similar to Debugger.setPauseOnExceptions
and lets the VM know that it should enter a Pause state whenever a new
script is loaded/executed.
The debugger can then take its time to parse the source map and update
any breakpoints, before automatically continuing.
Changelog: [Internal] Implement a Hermes.setPauseOnLoad CDP call
Reviewed By: bestander
Differential Revision: D20754604
fbshipit-source-id: 7f9d0638706c99e9dcb534699b633f658e364909
Summary:
Until now we've generated scaffolding entirely based on the official devtools
protocol spec. This diff adds support for defining custom domains in `custom.json`
which will be merged with the upstream protocol JSON definition.
ChangeLog: [Internal] Add support for Hermes-specific CDP messages
Reviewed By: bestander
Differential Revision: D20754605
fbshipit-source-id: a8075f81816a40114d1a3332192c7aa076b17848
Summary:
Easy diff to add a TODO to refactor `sendAccessibilityEvent` to use ViewCommands
This was orginally added D17142507
changelog: [Internal] Internal change
Reviewed By: JoshuaGross
Differential Revision: D21137348
fbshipit-source-id: aff38ccad8dfbb222f83161e2bd5da82f543e5db
Summary:
Assigning self as an owner makes a cycle which is obviously a bug.
Changelog: [Internal] Small change in Yoga (should not affect RN).
Reviewed By: SidharthGuglani
Differential Revision: D21111423
fbshipit-source-id: 1835561c055ac827f5ce98a044f25aed0d1845a5
Summary:
Changelog: [Internal]
We were assigned `undefined` value to incorrect edge, instead of `YGEdgeLeft` it should have been `YGEdgeRight`.
If node has `YGEdgeRight` value, it needs to be reassigned to `YGEdgeEnd` and its original value set to undefined.
Reviewed By: mdvacca
Differential Revision: D21095234
fbshipit-source-id: fbecd9b7e6670742ad4a4bb097760aa10eec8685
Summary:
This diff upgrades Jest to the latest version which fixes a bunch of issues with snapshots (therefore allowing me to enable the Pressable-test again). Note that this also affects Metro and various other tooling as they all depend on packages like `jest-worker`, `jest-haste-map` etc.
Breaking changes: https://github.com/facebook/jest/blob/master/CHANGELOG.md
This diff increases node_modules by 3 MiB, primarily because it causes more duplicates of `source-map` (0.8 MiB for each copy) and packages like `chalk` 3.x (vs 2.x). The base install was 15 MiB bigger and I reduced it to this size by playing around with various manual yarn.lock optimizations. However, D21085929 reduces node_modules by 11 MiB and the Babel upgrade reduced node_modules by 13 MiB. I will subsequently work on reducing the size through other packages as well and I'm working with the Jest folks to get rid of superfluous TypeScript stuff for Jest 26.
Other changes in this diff:
* Fixed Pressable-test
* Blackhole node-notifier: It's large and we don't need it, and also the license may be problematic, see: https://github.com/facebook/jest/pull/8918
* Updated jest-junit (not a Jest package) but blackholed it internally because it is only used for open source CI.
* Updated some API calls we use from Jest to account for breaking changes
* Made two absolutely egrigious changes to existing product code tests to make them still pass as our match of async/await, fake timers and then/promise using `setImmediate` is tripping up `regenerator` with `Generator is already run` errors in Jest 25. These tests should probably be rewritten.
* Locked everything to the same `resolve` version that we were already using, otherwise it was somehow pulling in 1.16 even though nothing internally uses it.
Changelog: [General] Update Jest
Reviewed By: rickhanlonii
Differential Revision: D21064825
fbshipit-source-id: d0011a51355089456718edd84ea0af21fd923a58
Summary:
The diff changes how the `empty raw props` optimization works in `ComponentDescriptor::cloneProps()`. Now it only fires only when the base `props` object is null, which is practically all production cases we have (and care about). (I tried, in a normal run there were no cases where the empty raw props were passed with non-null props.) From the other side, the old behavior that may return the same props objects previously several times created bugs and practically unexpected results and practically disallowed to clone props objects easily.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D21110608
fbshipit-source-id: 884807cd8e9c5c3e6cc1c9e4c1f0227259cc21fb
Summary:
This PR fixes the drawing of the border rounded edges when the border-radius is small than the border-width. The current implementation capped the possible border-radius making it impossible to set smaller border-radii when using thicker borders. After inspection it was found that the rounded-rect calculation is incorrect.
## Changelog
`[Android] [Fixed] - Fix rounded border-drawing when border-radius is smaller than border-width`
Pull Request resolved: https://github.com/facebook/react-native/pull/28358
Test Plan:
**Faulty situation:**
As you can see, when the border-radius becomes very low, the border is stuck at a minimum value. Only after setting the border-radius fully to 0 is it again rendered correctly.
**After the fix:**
Differential Revision: D21124739
Pulled By: shergin
fbshipit-source-id: cefd1776b77b5b9fb335e95fd7fdd7f345579dc4
Summary:
Apparently, `std::this_thread::sleep_for` uses a different clock to measure time which causes ofter misalignment with the clock which Telemery uses which makes the test flaky. Using the same clock should fix it.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D21116058
fbshipit-source-id: 52dde2e325776d365431a2a957dcc12dfe53f890
Summary:
This PR fixes incorrect drawing of the View borders on Android, after changing the border-radius back to 0 *(and when no background-color is defined)*.
This happens because the `drawRoundedBackgroundWithBorders` function in ReactViewBackgroundDrawable changes the style on the Paint object to `STROKE`. This style is however never reverted back to `FILL`. This change ensures that the Paint style is set to `FILL` for the full execution of the `drawRectangularBackgroundWithBorders` function.
## Changelog
`[Android] [Fixed] - Fix border-drawing when changing border-radius back to 0`
Pull Request resolved: https://github.com/facebook/react-native/pull/28356
Test Plan:
**Faulty situation:**
**After the fix:**
Differential Revision: D21124741
Pulled By: shergin
fbshipit-source-id: 2044f8e8ad59a58df42b64d7ee8c4ad1d3b562f1
Summary:
Before the change, an incorrect (NaN or Inf) values in LayoutMetrics might force an early return in the `updateLayoutMetrics:oldMetrics:` method implementation. This was not correct because the rest of the method also didn't run in this case, so it might force some value to stale.
E.g., imagine we have an instruction that contains NaN size and `display: none`. Previously, the function might just return right before applying sizes and progress the stored "already applied" value of LayoutMetrics which will cause the view being visible even if it should not.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D21110644
fbshipit-source-id: 501319d7b1dcd5c18f27e0ceca3c8d207485c49b
Summary:
This pull request adds a Unicode `u8` prefix to the string literal returned in `AttributedString.cpp`'s `Fragment::AttachmentCharacter()`.
This fixes the following error when building on MSVC:
```
react\attributedstring\AttributedString.cpp(21): error C4566: character represented by universal-character-name '\uFFFC' cannot be represented in the current code page (1252)
```
## Changelog
[Internal] [Fixed] - Fabric: Add Unicode prefix to AttachmentCharacter
Pull Request resolved: https://github.com/facebook/react-native/pull/28617
Test Plan: The Fabric test suite has been ran on a Clang-based build of Fabric on macOS, and no regressions in it have been noted.
Differential Revision: D21118078
Pulled By: shergin
fbshipit-source-id: c105de5e4edb67fed97ce44153a75d9d380bf588
Summary:
This pull request changes the include of Glog from `<Glog/logging.h>` to `<glog/logging.h>` in `MountingTest.cpp`. This fixes building on a case-sensitive filesystem.
## Changelog
[Internal] [Fixed] - Fabric: Fix case of Glog include in MountingTest.cpp
Pull Request resolved: https://github.com/facebook/react-native/pull/28616
Test Plan: The `include` of Glog no longer causes issues with building `MountingTest.cpp` on a case-sensitive filesystem.
Differential Revision: D21118085
Pulled By: shergin
fbshipit-source-id: c958c54bf88333fd5001127779c855ce8c2666c3
Summary:
We need to break up the `uimanager` module in order to solve circular dependencies problem (which future diff would have otherwise).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D20885646
fbshipit-source-id: b8e3199c0eacc57a5be1481595cf97c84f972293
Summary:
We need to break up the `uimanager` module in order to solve circular dependencies problem (which future diff would have otherwise).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D20885645
fbshipit-source-id: 8148bd934879802b076261ed86fa78acf0a07ed3
Summary:
We need to break up the `uimanager` module in order to solve circular dependencies problem (which future diff would have otherwise).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D20885163
fbshipit-source-id: 08eb1ba1d408fc0948e8d0da62380786a40973af
Summary:
Yoga uses `std::array` a lot (and `std::array` is not a `std::vector`), so it's useful for printing Yoga values.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D21028570
fbshipit-source-id: c6bf114d5362f085ea201ecdc5b7d59646b33ebd
Summary:
This is a debug-only feature that simply should be an assert. When it triggers in debugger and bubbles to some random exception catch block which makes it impossible to understand was exactly it happens. Making it an assert will stop debugger exactly where it happens.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D21028571
fbshipit-source-id: 3df4ec0da922026bb9df61081cb71113577e06e9
Summary:
* <Image> must be a leaf node; having a proper trait will fail earlier in case of misuse (mounting something inside).
* <View> must have a `View` trait because it's for what that trait is.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D21028573
fbshipit-source-id: 457716d4661333eb2357f34316f3e495ab4fda24
Summary:
We don't use it as vitrual anymore (setLayoutMetrics is a non-virtual method already), so it does not need to be marker virtual.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D21028572
fbshipit-source-id: 99f86fdd4cf2f5972034d9058d7b82bdc8680187
Summary:
This diff makes the ColorValue export "official" by exporting it from StyleSheet in order to encourage its use in product code.
Changelog: Moved ColorValue export from StyleSheetTypes to StyleSheet
Reviewed By: TheSavior
Differential Revision: D21076969
fbshipit-source-id: 972ef5a1b13bd9f6b7691a279a73168e7ce9d9ab
Summary:
We have a large amount of small packages that are completely unused, or only have one call site. This diff cleans up a lot of them and reduces node_modules by 12 MiB (down to 187).
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D21088213
fbshipit-source-id: 5fa7d3da5cbe744b0d9d3e3450d6135c1488ee79
Summary:
fix typo in `YogaJNIBase.java` as there is no such file called `YGJNI.cpp`
Pull Request resolved: https://github.com/facebook/yoga/pull/990
Reviewed By: pasqualeanatriello
Differential Revision: D20735102
Pulled By: SidharthGuglani
fbshipit-source-id: 3f9f4d78ba390feae3451330f997a221ab4ec70e
Summary:
Changelog:
[Internal][Yoga] YGDirection variable was initialized incorrectly by casting -1 to YGDirection. Changing it to default value of direction
Same for YGMeasureMode.
Reviewed By: pasqualeanatriello
Differential Revision: D20869042
fbshipit-source-id: 7bfe490193321baae875ef6fb49a938851950c9f
Summary:
Recent changes broke the script - wrong path to open `RNTesterPods.xcworkspace` and other scripts - we change dir with `cd`.
Another change is incorrect use of `RNTesterProject.xcodeproj` instead of a `xcworkspace`.
This PR is a simple and short fix to make it run.
## Changelog
[INTERNAL] - chore: update `./scripts/test-manual-e2e.sh`
Pull Request resolved: https://github.com/facebook/react-native/pull/28653
Test Plan: Run `./scripts/test-manual-e2e.sh`. Things work.
Differential Revision: D21079792
Pulled By: hramos
fbshipit-source-id: 6bdb8be016f044852ed216ec53f80db40c84b5fd
Summary:
## Summary
Please check out D21035208.
## Changes
- Update `RCTTurboModuleManagerDelegate getTurboModule:instance:jsInvoker:nativeInvoker:perfLogger` to use `RCTTurboModuleManagerDelegate getTurboModule:(const ObjCTurboModule::InitParams)`
- Update all implementations of `RCTTurboModuleManagerDelegate` in accordance with this API change
Changelog:
[iOS][Changed] - Make RCTTurboModuleManagerDelegate create TurboModules via ObjCTurboModuleManager::InitParams
Reviewed By: PeteTheHeat
Differential Revision: D21036272
fbshipit-source-id: c16002c47db26e2ba143fc1080afe9e2fe1e7816
Summary:
## Summary
Please check out D21035208.
## Changes
- `ObjCTurboModule::ObjCTurboModule` changed to accept a bag of arguments `const ObjCTurboModule::InitParams` instead of an argument list.
- TurboModule iOS codegen scripts updated to generated `ObjCTurboModule` subclasses that accept a `const ObjCTurboModule::InitParams` object in their constructor, and forward it to `ObjCTurboModule::ObjCTurboModule`.
- All manually checked in code-generated ObjC++ classes (i.e: RCTNativeSampleTurboModule, RCTTestModule, FBReactNativeSpec) are updated.
## Rationale
This way, the code-gen can remain constant while we add, remove, or modify the arguments passed to ObjCTurboModule.
## Commands run
```
function update-codegen() {
pushd ~/fbsource && js1 build oss-native-modules-specs -p ios && js1 build oss-native-modules-specs -p android && popd;
}
> update-codegen
```
Changelog:
[iOS][Changed] Update ObjCTurboModule to use ObjCTurboModule::InitParams
Reviewed By: PeteTheHeat
Differential Revision: D21036266
fbshipit-source-id: 6584b0838dca082a69e8c14c7ca50c3568b95086
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/28658
This moves the Java files to FB internal and updates all the buck files.
## Changelog:
[Android] [Removed] This diff removes the CheckBox export from React Native. Internally, we are requiring CheckBox directly now and externally people will have to use the community maintained module.
Reviewed By: cpojer
Differential Revision: D21066998
fbshipit-source-id: 76821fcae899ff7342697ea7dd4737ef3b008213
Summary:
I'm trying to use JSI for a React Native custom module. I saw these existing examples where the JSI API is used in the context of a CMakeLists.txt:
https://github.com/terrysahaidak/host-object-test/blob/master/libs/android-jsi/test-jsi/src/main/cpp/CMakeLists.txthttps://github.com/ericlewis/react-native-hostobject-demo/pull/4/files#diff-834320be1b4e4016bac27c05dcd17fb9
In both cases, they manually grab the include directories and jsi.cpp from node_modules/react-native, but I also saw that node_modules/react-native/ReactCommon/jsi/jsi already has a CMakeLists.txt that appears to be intended to provide a jsi static lib, so I tried to pull this into my own CMakeLists.txt like this:
```
add_subdirectory(${RN_DIR}/ReactCommon/jsi/jsi ${CMAKE_CURRENT_BINARY_DIR}/jsi)
...
target_link_libraries(MyLib jsi)
```
Unfortunately when doing this, the consuming project still doesn't see the correct include directories. The change I'm proposing here is to use `target_include_directories` and declare that `..` is a public (to consumers) include directory for the library named `jsi`. With this change, you can do what I showed above to consume the jsi lib by just pulling in the CMakeLists.txt file into your own CMakeLists.txt file.
Changelog: [General][Fixed] Fix jsi cmake include dirs
Pull Request resolved: https://github.com/facebook/hermes/pull/207
Reviewed By: willholen
Differential Revision: D21074270
Pulled By: tmikov
fbshipit-source-id: 7d9ec3255f57a16c0b2be489dffa4540727738a1
Summary:
Simple test to see what it looks like when view flattening/unflattening is animated with LayoutAnimations.
Changelog: [Internal] adding another example to LayoutAnimations example
Reviewed By: mdvacca
Differential Revision: D21074805
fbshipit-source-id: 551ed740f0ab5c5adcb19f5c35e932b8983cd108
Summary:
Add more options to the LayoutAnimation example so it's easier to test more features of LayoutAnimations.
1) Add an option to animate reordering of views
2) Make animations slower, so it's easier to see what's going on and easier to trigger race conditions
3) Add options to mutate without animation, to test interrupting existing animations
Changelog: [Internal] Updated Catalyst RNTester LayoutAnimation example with additional options
Reviewed By: mdvacca
Differential Revision: D21050309
fbshipit-source-id: 1daba4fd487693c34a2d40eb39a68c7d03c24f93
Summary:
Removes the post install step for Flipper, as the latest version of YogaKit is compatible with swift 5.
cc alloy
## 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
-->
[Flipper] [Template] - Remove the post install step for Flipper
Pull Request resolved: https://github.com/facebook/react-native/pull/28651
Test Plan: Tested a newly created RN app without post install step and it built successfully.
Reviewed By: passy
Differential Revision: D21064653
Pulled By: priteshrnandgaonkar
fbshipit-source-id: da56d0754d918e30a0ebe480c77590f0139d48ac
Summary:
This diff introduces a new "Open Debugger" menu item for VMs that support on device debugging and for opening the React DevTools in Flipper.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D20784279
fbshipit-source-id: caecdace00007224692d994a75c106842c8b2acb
Summary:
Updating the community eslint-plugin used in the eslint-config to the latest version.
expecting new eslint-config version to be released with this change so that it can be included in new project template for 0.63 https://github.com/react-native-community/releases/issues/186
## 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] [Changed] - Update community eslint plugin in the eslint config
Pull Request resolved: https://github.com/facebook/react-native/pull/28642
Test Plan: yarn lint passes
Differential Revision: D21048976
Pulled By: cpojer
fbshipit-source-id: 2c3ec0ef450cf357d8c88db7873f4ca1154b2034
Summary:
When text is in a constrained parent view using `maxWidth`, long text may wrap. When the text wraps, the final width is dependent on the word breaking strategy and text content. This means that the text width is not necessarily `maxWidth`.
However, the current way that we compute text layout does not shrinkwrap the text width as much as possible. This leads to visual gaps to the end-side of wrapped text.
This changes the text layout slightly so that we use the length of the longest line.
This bug only exists on Android. After this change, Android behaves like iOS.
Changelog:
[Android] [Fixed] - Fixed excessive space in Text view with word-wrapping
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D21056031
fbshipit-source-id: e9b7793f2632caafcce69bc15bac61330b0ed958
Summary:
## Problem
Every time we want to add, remove, or change the data passed to JavaTurboModule's constructor, we have to modify the C++ TurboModule codegen. (The same is true of `ObjCTurboModule`).
**Why was this necessary?**
- `JavaTurboModule` is effectively an abstract class whose constructor is always invoked by code-generated C++ classes. These C++ code-generated class constructors accept an argument list, and manually foward each and every item in that list to `JavaTurboModule::JavaTurboModule`.
## The fix
In this diff, I introduce a struct `JavaTurboModule::InitParams`, to represent a bag of arguments:
```
class JSI_EXPORT JavaTurboModule : public TurboModule {
public:
struct InitParams {
std::string moduleName;
jni::alias_ref<JTurboModule> instance;
std::shared_ptr<CallInvoker> jsInvoker;
std::shared_ptr<CallInvoker> nativeInvoker;
};
```
All `JavaTurboModules` will be created with an instance of this `InitParams` struct, instead of a list of arguments. Our code-generated C++ `jsi::HostObject` sublcasses will simply accept `InitParams` in their constructor, and forward it to `JavaTurboModule`'s constructor. This way, the codegen remains oblivious to what arguments JavaTurboModule requires.
## Okay, but why do we need this change now?
In the future, I plan to modify the constructor for `JavaTurboModule` to accept a performance logger, and a `RuntimeExecutor`. Similar modifications are planned for ObjC. For this reason, to avoid these four codemods, and any potential other codemods that occur because we're making modifications to `JavaTurboModule` or `ObjCTurboModule`, I'm launching this codemod, and the codemods in this stack.
## Misc Fix
- Previously, we were generating the TurboModule name from the Spec filename. This is incorrect because that name represents the spec name. Now, the name will be forwarded from TurboModuleManager in the `JavaTurboModule::InitParams` struct.
## Alternative implementations
I initially considered using `ContextContainer`, but decided against it because:
1. There are no type-safety guarantees.
2. I think it's a bit overkill for this scenario. We just need an opaque bag of data, and for our purposes a simple struct does the job fine.
## Commands run
Reviewed By: fkgozali
Differential Revision: D21035208
fbshipit-source-id: 9542cafea192081bc34d337ab3a7a783083eb06c
Summary:
> Starting April 30, 2020, all apps submitted to the App Store must use an Xcode storyboard to provide the app’s launch screen and all iPhone apps must support all iPhone screens.
Updated iOS Launch screen as per [App Store policy change](https://developer.apple.com/news/?id=03042020b).
Community discussion: https://github.com/react-native-community/discussions-and-proposals/issues/209
## Changelog
Changed iOS Launch Screen from a `xib` to `storyboard`. The `LaunchScreen.xib` file has been replaced with `LaunchScreen.storyboard`. Xcode automatically picks up the new Launch Screen no additional change is required.
[iOS] [Deleted] - Deleted LaunchScreen.xib
[iOS] [Added] - Added LaunchScreen.storyboard
Pull Request resolved: https://github.com/facebook/react-native/pull/28239
Test Plan: Build the Xcode project under `template/iOS` and verify that the new launch screen is identical to the previous one.
Reviewed By: cpojer
Differential Revision: D20408892
Pulled By: hramos
fbshipit-source-id: 9c38df58d1304088a23f3d73e0fbd87675804f1a
Summary:
This diff introduces a new "Open Debugger" menu item for VMs that support on device debugging and for opening the React DevTools in Flipper. Provided so that we don't drift too far from the Android code.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D20784270
fbshipit-source-id: 6bb16431d25a6c093a583e2e041b8cffa6765ddd
Summary:
This fixes build failures where `CIRCLE_PR_NUMBER` is not set. This can happen if the PR did not come from a fork.
## Changelog
[Internal] [Fixed] - Fix CIRCLE_PR_NUMBER may not always be set
Pull Request resolved: https://github.com/facebook/react-native/pull/28640
Test Plan: Report bundle size step should pass on both this PR and https://github.com/facebook/react-native/issues/28641.
Reviewed By: cpojer
Differential Revision: D21045553
Pulled By: TheSavior
fbshipit-source-id: fdfcb1bb88a96345b78ca69c49623df71d4cd608
Summary:
The `cliPath` has always been optional value and in fact, even had its default value hardcoded in the React gradle file.
In this PR, I am just taking use of it and remove throwing an error, which is going to be a really annoying breaking change.
## Changelog
[ANDROID] [INTERNAL] - Don't require `cliPath`
Pull Request resolved: https://github.com/facebook/react-native/pull/28625
Test Plan:
Run Android project, everything works.
Provide custom `cliPath`, it gets respected
Reviewed By: cpojer
Differential Revision: D21044222
Pulled By: TheSavior
fbshipit-source-id: 8029f988d92abb9f64f30e05932c0d407d0c997e
Summary:
This release will include the new platform-colors rule.
Changelog: [Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: cpojer
Differential Revision: D21022163
fbshipit-source-id: 65c831b3c820e44f75631b935118b043180ab3c7
Summary:
In D20659799, I improved `TurboModuleManager.getModule(moduleName)` thread-safety by ensuring that if two threads race to require the same NativeModule, only one thread creates the NativeModule, while the other one waits until it's created.
## The problem:
What I failed to realize was that when two threads race to require two different NativeModules, we can get concurrent calls into `TurboModuleManagerDelegate.getModule(moduleName)`, and `TurboModuleManagerDelegate.getLegacyCxxModule(moduleName)`, which don't have any thread-safe guarantees.
## The fix
`TurboModuleManagerDelegate` is supposed to be an input to the TurboModule system. So, rather than expecting that all TurboModuleManagerDelegates are thread-safe, which might be a reasonable ask (see T65532092), this diff has `TurboModuleManager` acquire the delegate's lock before calling into it. This ensures that we don't get concurrent access into the delegate, which could be reading from, or writing to, some data structure in these method calls. (This was the case with `ReactPackageTurboModuleManagerDelegate`, which is what Fb4a and Workplace use under the hood).
Changelog:
[Android][Fixed] - Control concurrent calls into TMMDelegate from TurboModuleManager
Reviewed By: mdvacca
Differential Revision: D21025965
fbshipit-source-id: d22c4abfe87f9e534717a06f186dde87d3cd24df
Summary:
This cache is unnecessary, because:
1. TurboModuleManager caches all created TurboModules
2. TurboModuleManager calls into the TurboModuleManagerDelegate at most once per NativeModule `moduleName`.
This diff also makes ReactPackageTurboModuleManager thread-safe, which should help get rid of the crashes in T46487253.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21027998
fbshipit-source-id: c9b5ccc3da7b81787b749e70aa5e55883317eed7
Summary:
We're still seeing NativeModule eager-init crashes in T46487253. So, just to be extra careful, in case this diff doesn't fix the problem, I'm adding logging into `TurboModuleManager.getModule(moduleName)` to see why TurboModules are showing up as `null`.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21027984
fbshipit-source-id: 74ee62aeac09a4fdb29547e90ef4fa7c07de17a6
Summary:
This pull request adds `YGNode.h` and `YGStyle.h` to the headers exported by Yoga's podspec. They are required by the new Fabric architecture of React Native.
The modulemap and its umbrella header automatically generated by Cocoapods adds all exported headers to the `modulemap`. Having YGNode and YGStyle exported through here has problems, because they are only available in environments that have C++ available, and will produce errors otherwise.
This pull request fences off the contents of those headers in an `#ifdef __cplusplus` block, so they will not cause errors when imported into environments where C++ isn't available.
I had considered adding a custom modulemap to the podspec as part of this pull request, but this way seems the least "invasive", and this way you are able to add and remove exported headers in the podspec without needing to worry about updating the umbrella header at the same time.
Changelog:
[Internal] - Yoga Podspec: Export YGNore and YGStyle headers
Pull Request resolved: https://github.com/facebook/yoga/pull/997
Reviewed By: hramos
Differential Revision: D20966075
Pulled By: mdvacca
fbshipit-source-id: 5f5caa6b639d11e660b968d681da9a4de6c0eb8e
Summary:
Enhance the label-actions config and support a "Type: Upgrade Issue" label.
- Point to the Upgrade Support repository whenever the Type: Upgrade Issue label is applied.
- Close the issue.
Changelog:
[Internal] label-actions: Add canned response for upgrade issues
Reviewed By: cpojer
Differential Revision: D20974607
fbshipit-source-id: 3cd7890aaeb1e57baf2acc5ca85a9b3ae5117c56
Summary:
Changelog: [Internal]
We don't use view command `setMostRecentEventCount`, let's get rid of it.
Reviewed By: JoshuaGross
Differential Revision: D21016600
fbshipit-source-id: 6491c063e9d6a89252300cb47c010b248e473f4b
Summary:
Early ViewCommand Dispatch will solve this category of crashes by going through an entirely different codepath. For users not in that experiment, it might be good to have a mitigation that prevents non-critical issues from crashing (like "blur" failing).
Currently, "blur" failures cause lots of screens to crash. There's no useful signal and those crashes aren't super actionable, so seems better to swallow.
If/when early viewcommand dispatch ships as the default/only mode, we can remove this try/catch entirely.
The only concern I have with landing this is the perf implications of putting a try/catch inside this loop.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D21023213
fbshipit-source-id: 310fe2d55a44bc424692a2365ccd5882f35f9d82
Summary:
This pull request updates RNTester's AppDelegate's Fabric mode to reflect changes made to the SurfacePresenter APIs. It now makes use of `RCTSurfacePresenterBridgeAdapter` to create its `SurfacePresenter`.
## Changelog
[Internal] [Fixed] - Fixed outdated API usage in RNTester's AppDelegate
Pull Request resolved: https://github.com/facebook/react-native/pull/28580
Test Plan: `RNTester/RNTester/AppDelegate.mm` now compiles without error when `RN_FABRIC_ENABLED` is enabled.
Reviewed By: hramos
Differential Revision: D20966067
Pulled By: mdvacca
fbshipit-source-id: 8d0168d468240cff61554f2f2df799aaf5d876c1
Summary:
`const ReactNative` is assigned to but never used. Let's get rid of it.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D21016502
fbshipit-source-id: afcb0cfc501adf07e0c4d4452a831160e1cda088
Summary:
Make sure width/height is always passed as Undefined when measure mode is changed to Undefined.
Changelog: [Internal][Yoga] Set width and height as Undefined when we change measure mode to Undefined
Reviewed By: alickbass
Differential Revision: D20029838
fbshipit-source-id: b9931f6ddb13ffd1565889535ade5bbffbe0c304
Summary:
Use the latest published release of hermes-engine. Update RN to invoke `hermesc` instead of `hermes`.
Changelog: [Android] [Changed] - Upgraded to Hermes 0.5.0
allow-large-files
Reviewed By: mhorowitz
Differential Revision: D20998564
fbshipit-source-id: 4824e273bcb044029a5a7e9379f168d3da47da50
Summary:
Now we can control the differentiator mode via MC.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: fkgozali
Differential Revision: D20978857
fbshipit-source-id: 13264948762f02f874d8d051c873d378062d6db4
Summary:
We currently see a lot of errors happens because of division by zero in `AnimatedDivision` module. We already have a check for that in the module but it happens during the animation tick where the context of execution is already lost and it's hard to find why exactly it happens.
Adding an additional check to the constructor should trigger an error right inside render function which should make the error actionable.
Changelog: [Internal] Early crash in AnimatedDivision in case of division by zero.
Reviewed By: mdvacca
Differential Revision: D20969087
fbshipit-source-id: 0d98774b79be2cc56d468a4f56d2d7c8abf58344
Summary:
Calling `-[RCTRedBox showErrorMessage]` twice causes a crash
We used `-[UIViewController isBeingPresented]` to tell whether view controller is already presented.
But from the documentation:
> A Boolean value indicating whether the view controller is being presented.
Source: https://developer.apple.com/documentation/uikit/uiviewcontroller/2097564-beingpresented?language=objc#
---
So this means that if you present it, wait until presentation animation is finished and then call `-[RCTRedBox showErrorMessage]` again, following exception will be thrown.
```
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'Application tried to present modally an active controller <UIViewController: 0x7fc33e422f50>.'
```
Changelog: Fix crash caused by presenting view controller twice from RCTRedBox
Reviewed By: PeteTheHeat
Differential Revision: D20946645
fbshipit-source-id: 763066e37db4e56efb0118b2e7867ad0724bae81
Summary:
```
Welcome to Gradle 6.3!
Here are the highlights of this release:
- Java 14 support
- Improved error messages for unexpected failures
For more details see https://docs.gradle.org/6.3/release-notes.html
```
## Changelog
[Android] [Changed] - Update Gradle Wrapper to 6.3
Pull Request resolved: https://github.com/facebook/react-native/pull/28173
Test Plan: Build project
Differential Revision: D20958894
Pulled By: mdvacca
fbshipit-source-id: a02ab0eb6aff97148c12b844fdd1f9f2617ae53f
Summary:
This change removes the `ColorAndroid` API. It was added more as a validation tool than as something useful to a developer. When making the original [PlatformColor PR](https://github.com/facebook/react-native/pull/27908) we felt it was valuable and useful to have working platform specific methods for the two platforms in core to test that the pattern worked in app code (PlatformColorExample.js in RNTester) and that the Flow validation worked, etc. Practically `PlatformColor()` is more useful to a developer on Android than `ColorAndroid()`. Now that the construct has served its purpose, this PR removes the `ColorAndroid` function and its related tests and other collateral.
## 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
-->
[Android] [Removed] - Remove ColorAndroid function as it adds no value over PlatfromColor
Pull Request resolved: https://github.com/facebook/react-native/pull/28577
Test Plan: RNTester in both iOS and Android was tested. Jest tests, Flow checks, Lint checks all pass.
Reviewed By: cpojer
Differential Revision: D20952613
Pulled By: TheSavior
fbshipit-source-id: 7d2cbaa2a347fffe59a1f3a26a210676008fdac0
Summary:
Move CheckBox JS files to FB internal
## Changelog:
[General] [Removed] This diff removes the CheckBox export from React Native. Internally, we are requiring CheckBox directly now and externally people will have to use the community maintained module.
Reviewed By: cpojer
Differential Revision: D20910775
fbshipit-source-id: 809e135dc3f68911ac0a004e6eafa8488f0d5327
Summary:
This adds a ProGuard for `hermes` rule so it does not have to be added by users manually.
https://github.com/facebook/react-native/issues/28270
## 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
-->
[Android] [Added] - ProGuard rule for hermes
Pull Request resolved: https://github.com/facebook/react-native/pull/28571
Test Plan:
1. Create a project with/without hermes.
2. Enable proguard.
Reviewed By: cpojer
Differential Revision: D20947095
Pulled By: hramos
fbshipit-source-id: 79b166ad2dd060f20041d9f5cfe2f794c754843d
Summary:
Recently, a default Podfile has been modified to not contain all the React Native pods, but use a helper method `use_react_native!`.
While this is great, it assumes a hardcoded path of `../node_modules/react-native` to be always the correct location of the React Native.
https://github.com/facebook/react-native/blob/d4d8887b5018782eeb3f26efa85125e6bbff73e4/scripts/autolink-ios.rb#L7-L9
Unfortunately, due to the way Ruby works, this completely hides the path away from the users.
Before, they could have seen the wrong path explicitly in a Podfile and knew to update it to resolve path-related issues.
With the current version in `master`, I can see a lot of issues where developers wonder how to resolve the path issues and how to pass the path itself.
https://github.com/facebook/react-native/blob/4118d798265341061105f3a53550db83c66a71cb/template/ios/Podfile#L5-L10
This PR uses React Native CLI configuration (that is already used to link 3rd party dependencies) to explicitly define the correct path to the React Native.
As a result, we don't have to change the paths here whether we're running monorepo or not.
## Changelog
[IOS] [INTERNAL] - Always provide an explicit path to React Native
Pull Request resolved: https://github.com/facebook/react-native/pull/28572
Differential Revision: D20945194
Pulled By: TheSavior
fbshipit-source-id: 010f9754f2ed78ef62fd52f4d201f296f5af6d27
Summary:
Changelog: [Internal]
Calling `_backedTextInputView.attributedText = attributedString` causes cursor to be moved to the end of text input.
This applies to both, `UITextField` and `UITextView`.
This is not desired as when JS sets a new text, we don't want the cursor to be moved to the end of text input.
JS has the option to use view commands if it wishes to move cursor somewhere.
Reviewed By: JoshuaGross
Differential Revision: D20836201
fbshipit-source-id: 9234e54cfbc5fc206f723626988e505275788aae
Summary:
Changelog: [Internal]
UIKit uses either `UITextField` or `UITextView` as its UIKit element for `<TextInput>`. `UITextField` is for single line entry, `UITextView` is for multiline entry.
There is a problem with order of events when user types a character.
In `UITextField` (single line text entry), typing a character first triggers `onChange` event and then `onSelectionChange`. JavaScript depends on this order of events because it uses `mostRecentEventCount` from this even to communicate to native that it is in sync with changes in native.
In `UITextView` (multi line text entry), typing a character first triggers `onSelectionChange` and then `onChange`. As JS depends on the correct order of events, this can cause issues. An example would be a TextInput which changes contents based as a result of `onSelectionChange`. Those changes would be ignored as native will throw them away because JavaScript doesn't have the newest version.
Reviewed By: JoshuaGross
Differential Revision: D20836195
fbshipit-source-id: fbae3b6c0d388fc059ca2541ae980073b8e5f6c7
Summary:
D20831545 integrated TurboModules with the bridge's `onBatchComplete` event. This fixed the RCTNativeAnimatedModule jank, so I'm re-converting RCTNativeAnimatedModule into a TurboModule.
Changelog:
[iOS][Fixed] - Make RCTNativeAnimatedModule TM-compatible
Reviewed By: PeteTheHeat
Differential Revision: D20850744
fbshipit-source-id: bb85a1bb27963e7d39bf149d0a3d7b71c88175da
Summary:
This adds a `minimumSize` property to RCTRootView, and forwards any changes to it's shadow view. This **does not** change any default behaviour, as the default minimum size is `CGSizeZero` before & after this diff.
Changelog: [iOS][Internal] Add minimumSize to RCTRootView & RCTRootShadowView
Reviewed By: RSNara
Differential Revision: D20905456
fbshipit-source-id: a03f880e782891f60ef86b9c898965e05a5e796e
Summary:
## Problem
For some reason, D20831545 broke the `use_frameworks!` build of RNTester.
## Building RNTester
```
pushd ~/fbsource/xplat/js/react-native-github/RNTester && USE_FRAMEWORKS=1 pod install && open RNTesterPods.xcworkspace && popd;
```
## Error
I built RNTester locally, and the error was this:
```
Undefined symbols for architecture x86_64:
"facebook::jsi::HostObject::set(facebook::jsi::Runtime&, facebook::jsi::PropNameID const&, facebook::jsi::Value const&)", referenced from:
vtable for facebook::react::ObjCTurboModule in RCTImageEditingManager.o
vtable for facebook::react::ObjCTurboModule in RCTImageLoader.o
vtable for facebook::react::ObjCTurboModule in RCTImageStoreManager.o
"facebook::jsi::HostObject::getPropertyNames(facebook::jsi::Runtime&)", referenced from:
vtable for facebook::react::ObjCTurboModule in RCTImageEditingManager.o
vtable for facebook::react::ObjCTurboModule in RCTImageLoader.o
vtable for facebook::react::ObjCTurboModule in RCTImageStoreManager.o
ld: symbol(s) not found for architecture x86_64
```
## Fix
It looked like libraries that depend on "ReactCommon/turbomodule/core" weren't linking to JSI correctly. So, I modified all such Podspecs to also depend on "React-jsi":
```
arc rfr ' s.dependency "ReactCommon/turbomodule/core", version' ' s.dependency "ReactCommon/turbomodule/core", version\n s.dependency "React-jsi", version'
```
This seemed to do the trick. In buck, we'd fix this problem using exported_dependencies. I skimmed through cocoapods, and couldn't find such a configuration option there. So, I guess this will have to do?
Changelog:
[iOS][Fixed] - Fix Cocoapods builds of RNTester
Reviewed By: fkgozali, hramos
Differential Revision: D20905465
fbshipit-source-id: 60218c8274ec165752a428f2a7a9a546607c8fec
Summary:
This diff renames the analyticsTag prop for the intenral_analyticsTag in ImageView component
changelog: [internal] Creation of internal_analyticTag prop in ImageView, for now this prop is meant to be used internally.
Reviewed By: TheSavior
Differential Revision: D20904497
fbshipit-source-id: 2a28f746772ee0f9d657ec71549020c1f3e9d674
Summary:
This diff avoids passing the analyticsTag prop to native if this is set to null
changelog: [internal] internal optimization
Reviewed By: TheSavior
Differential Revision: D20904498
fbshipit-source-id: f1ea1e5aa3199ef073668df86ca7cf6e20f70c5b
Summary:
Changelog: [Internal]
The cause of crash was `NullPointerException`, which happened because of `mReactContextForRootTag.get(rootTag)` returning `null`. This is solved by checking whether it returns `null` before passing it to `I18nUtil`.
Reviewed By: mdvacca
Differential Revision: D20890623
fbshipit-source-id: c884c6838b83b944a5438375a4c060c1f5b1dc6e
Summary:
Ez cleanup in ImageProps, this import is not being used anymore
changelog: [internal] internal change
Reviewed By: JoshuaGross
Differential Revision: D20880600
fbshipit-source-id: 7d903b5a6e16c37e61dec661b6bd1f9a6b442cc3
Summary:
As part of this diff I create the new ImageContext object that will be used to allow the update of the analyticsTag prop for components that contain multiple images in their view hierarchy
changelog: [JS][Added] Add ImageContext object, this object can be used to update the Imageview's analyticsTag prop on RN components that contain multiple images in their view hierarchy
Reviewed By: JoshuaGross
Differential Revision: D20880603
fbshipit-source-id: f2094bfd3ab1c867cf7c107e678a098aab7e94a8
Summary:
This diff extends the Android Image View manager to support the new analyticsTag prop. this prop is going to be used to track performance for images in android
changelog: [Android][Added] Add analyticsTag prop into ImageView component
Reviewed By: JoshuaGross
Differential Revision: D20880602
fbshipit-source-id: e302e8fa83706e6517b228d44a3094a1686830f7
Summary:
The appearance module uses sync native module methods which doesn't work with the chrome debugger. This broke in 0.62: https://github.com/facebook/react-native/issues/26705
This fix makes the appearance module return 'light' when using the chrome debugger.
Changelog: [Fixed] Appearance `getColorScheme` no longer breaks the debugger
Reviewed By: yungsters
Differential Revision: D20879779
fbshipit-source-id: ad49c66226096433bc9f270e004ad4a6f54fa8c2
Summary:
This is an internal only module that we use to detect whether we are in async debugging mode.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D20879780
fbshipit-source-id: 5915f4e1c54a3fda0cf607c77f463120264fdbc4
Summary: According to our logs, 80% of these warnings are coming from AppStateModule. It's not particularly interesting or surprising that the CatalystInstance would be torn down when there's some app event, so let's stop taking up DB space with a useless message.
Reviewed By: ejanzer, mdvacca
Differential Revision: D20879426
fbshipit-source-id: b1182461aed4a66d82cb34bbd4b12782af6ed7b3
Summary:
Original commit changeset: fbd72739fb71
Changelog: Back out "[react-native][PR] Fixed scrollview inset when RN view is embedded in another view"
Reviewed By: TheSavior
Differential Revision: D20878607
fbshipit-source-id: 0d77b9fb08c637f7894c399a219a242e472b0700
Summary:
Recently we removed `npx` usage from `react-native-cli` flow. After checking usages in this repo I found unused reference.
## 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] [Removed] - Remove unused `npx` reference
Pull Request resolved: https://github.com/facebook/react-native/pull/28544
Test Plan: Tests pass
Reviewed By: cpojer
Differential Revision: D20873090
Pulled By: hramos
fbshipit-source-id: 12e05e9635a83f19439024766817e4599320af98
Summary:
In bridgeless mode, the CatalystInstance doesn't exist, but we still need to be able to access the sourceURL in SourceCodeModule (which is needed to render the images in LogBox warnings and errors). This diff adds a new API for getting the sourceURL directly from ReactContext, instead of having to call context.getCatalystInstance().getSourceURL(), and updates SourceCodeModule to use it.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D20848700
fbshipit-source-id: 3ecda81a17121178b76bbb3e9b0f27f103c1961a
Summary:
Changelog: [Internal]
Setting `_borderLayer.frame` inside `-[RCTViewComponentView layoutSubviews]` causes unwanted animation because it is not wrapped in `CATransaction`.
Moving it to `-[RCTViewComponentView updateLayoutMetrics]` which is called inside `CATransaction`.
Reviewed By: shergin
Differential Revision: D20836890
fbshipit-source-id: 2048a25fd2edb8109f6275c1186c0adae4b9f504
Summary:
NativeModules can be created from any number of threads. In the legacy system, `ModuleHolder`, the class responsible for creating NativeModules, has built-in concurrency control to ensure that NativeModule creation is thread-safe. This diff introduces that thread-safety to the TurboModule infra. Basically, after this diff, if `n` threads race to create a TurboModule x, only the first thread will create x. All other threads will wait until x is created.
Changelog:
[Android][Fixed] - Make TurboModule creation thread-safe
Reviewed By: mdvacca
Differential Revision: D20659799
fbshipit-source-id: 2b720fe1ea49e40ae0d6dae50d422f23a6f45520
Summary:
This diff:
1. Has ObjC NativeModules use the native `CallInvoker` to invoke JS -> native sync/async calls.
2. Integrates the native `CallInvoker` for each ObjC NativeModule with the bridge. This way, the bridge is informed of all JS -> native TurboModule method calls, and dispatches `onBatchComplete` appropriately.
Changelog:
[iOS][Fixed] Integrate ObjC TurboModules async method calls with the bridge
Reviewed By: fkgozali
Differential Revision: D20831545
fbshipit-source-id: da1cbb4ecef4cae85841ca7ef625ab8e380760cd
Summary:
Remove these warnings until the methods in ScrollResponder have been moved into ScrollView, so that unactionable warnings aren't firing.
Changelog:
[General][Removed] Remove console warnings for innerViewNode/Ref in ScrollView
Reviewed By: TheSavior
Differential Revision: D20850624
fbshipit-source-id: ce90988e204c3cc3b93536842ec3caa12cf6994e
Summary:
I'm using RNN, which embeds RN view inside native view controllers.
On iOS 13, a modal view controller is "floating" and is offset from the top of the screen.
This causes the calculation of inset in `KeyboardAvoidingView` incorrect as it mixes local view controller coordinate space, with keyboard's screen coordinate space.
## Changelog
[iOS] [Fixed] - Fixed `KeyboardAvoidingView` inset in embedded views (i.e modal view controllers on iOS 13)
Pull Request resolved: https://github.com/facebook/react-native/pull/27607
Test Plan:
1. Tested before and after in a simple view controller (should stay the same)
2. Tested before and after in a modal view controller (should be offset before, and fixed after)
3. Repeated no. 2 with each device rotation (upsideDown, landscapeLeft, landscapeRight)
Reviewed By: cpojer
Differential Revision: D20812231
Pulled By: TheSavior
fbshipit-source-id: fbd72739fb7152655028730e284ad26ff4a5da73
Summary:
## Problem:
Let `A` be the set of all ObjC NativeModules that neither provide nor reqeust a method queue.
The TurboModule system dispatches all method calls to NativeModules in `A` synchronously to the JS thread. Here is the relevant logic:
**RCTTurboModule.mm:**
Link: https://fburl.com/diffusion/nz9gqje8
```
jsi::Value performMethodInvocation(
// ...
)
{
// ...
dispatch_queue_t methodQueue = NULL;
if ([instance_ conformsToProtocol:protocol(RCTBridgeModule)] &&
[instance_ respondsToSelector:selector(methodQueue)]) {
methodQueue = [instance_ performSelector:selector(methodQueue)];
}
if (methodQueue == NULL || methodQueue == RCTJSThread) {
// This is the default mode of execution: on JS thread.
block();
} else if (methodQueue == dispatch_get_main_queue()) {
```
**Why does this end up happening?**
1. NativeModules that request a method queue have `synthesize methodQueue = _methodQueue` in their `implementation` section. This generates a `methodQueue` getter for the NativeModule, and also creates an ivar to back that getter. The TurboModule system generates a `dispatch_queue_t` and uses ObjC's KVC API to write to the ivar. So in the above logic, for NativeModules that provide a method queue, methodQueue will neither be `NULL` nor `RCTJSThread`, so we don't dispatch synchronously to the JS thread.
2. NativeModules that provide a method queue will return something that is not `NULL` or something that is `RCTJSThread`. If they return `NULL`, the infra will throw an error early. If they return `RCTJSThread`, we'll dispatch synchronously to the JS thread, as we should (...wait. For async NativeModule methods that dispatch to `RCTJSThread`, should we dispatch asynchronously to the JS thread, via jsInvoker? **Edit:** Nope: https://fburl.com/diffusion/ivt9b40s.). In all other cases, we dispatch to appropriately to the respective method queue.
3. For NativeModules that neither provide nor request a method queue (i.e: NativeModules in `A`), they don't implement the `methodQueue` selector. Therefore, we dispatch synchronously to the JS thread.
## The fix (Part 1):
The first step towards fixing this problem is to generate `dispatch_queue_t`s for NativeModules in `A`.
That's what this diff accomplishes.
Changelog:
[iOS][Fixed] - Create method queue for NativeModules that don't provide nor request one.
Reviewed By: fkgozali
Differential Revision: D20821054
fbshipit-source-id: 17a73550ad96766c5c7e719e28e1cc879e36465c
Summary:
This allows the iOS device to be reloaded through the metro command line, besides the fact that whenever packagerServerHost is called, it will only get the IP address once when debugging.
## Changelog
[iOS] [Fixed] - Fixed connection of metro reload command to iOS device
Pull Request resolved: https://github.com/facebook/react-native/pull/28477
Test Plan:
- Build any react-native project in debug mode to an iOS device connected through USB
- Press the “r” key on the terminal that is running metro
- The device should now reload the project
Reviewed By: cpojer
Differential Revision: D20818462
Pulled By: TheSavior
fbshipit-source-id: 6d9792447d205223dad8fbd955518885427cbba8
Summary:
Making a PR from GitHub, I need to copy-paste the link, and it would be easier to just triple-click a line with the URL rather than carefully selecting the URL from the text.
<img width="723" alt="Screen Shot 2020-04-03 at 17 33 47" src="https://user-images.githubusercontent.com/100233/78378550-6c12af80-75d1-11ea-93a4-2eae568ce602.png">
## Changelog
[General] [Changed] - Make PR template easier to use with changelog URL.
Pull Request resolved: https://github.com/facebook/react-native/pull/28516
Reviewed By: fkgozali
Differential Revision: D20842238
Pulled By: hramos
fbshipit-source-id: 3fef7a994f36a996bbbc52556600d468a56210a9
Summary:
Adding a README for `react-native-codegen` since the package was published.
Also added a `files` prop in package.json so unused file won't be included in the package.
## Changelog
[Internal] [Changed] - Add README for react-native-codegen.
Pull Request resolved: https://github.com/facebook/react-native/pull/28507
Test Plan: verify js files to function correctly without including files other than `src`
Reviewed By: rickhanlonii
Differential Revision: D20836113
Pulled By: cpojer
fbshipit-source-id: e860f14760e9c1dbe121f5fb95ccf72d4ddb2af1
Summary:
Improve issue triage by automatically adding the "Needs: Author Feedback" label.
NOTE: The old label-actions app should be disabled when this PR is merged: https://github.com/apps/label-actions/installations/7445225
## Changelog
[Internal] - Issue Triage
Pull Request resolved: https://github.com/facebook/react-native/pull/28484
Test Plan: Verified the same `label-actions.yml` and workflow config on a private repo.
Reviewed By: cpojer
Differential Revision: D20817443
Pulled By: hramos
fbshipit-source-id: 39732dd67509c9fb9cf6ff7306913f5ec088266d
Summary:
`RCTTurboModuleManager` will create a native `CallInvoker` for each ObjC NativeModule. This `CallInvoker` will be used to dispatch calls from JS to native. Before passing the native `CallInvoker` to the `ObjCTurboModule`, it'll first use `RCTCxxBridge decorateNativeCallInvoker` to get a bridge-aware decorated native `CallInvoker`. That way, the bridge remains informed about async TurboModule method calls that took place since the last time it was flushed. This ensures that we don't end up dispatching `onBatchComplete` any less with TurboModules on than we do with TurboModules off.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D20831546
fbshipit-source-id: b2eb4e0097e0dabf8c4bd8fdc4c850a0858af699
Summary:
We'll be using a native CallInvoker to dispatch sync and async method calls to ObjC NativeModules. This native CallInvoker will hold a reference to the ObjC NativeModule's method queue.
**Why is the native CallInvoker required for ObjC NativeModules?**
In the case where the ObjC NativeModule neither provides nor requests a method queue, we must create a method queue for it. When we go to invoke a method from JS, for these NativeModules specifically, there is no way to access this method queue. A native CallInvoker is a convenient abstraction that holds on to that method queue. For async calls, we'll just call `CallInvoker::invokeAsync`, and for sync calls, we'll just call `CallInvoker::invokeSync`.
**Why do we need sync call support for native `CallInvoker`?**
In ObjC, sync NativeModule method calls block the JS thread, then execute synchronously on the NativeModule's method queue, and then unblock the JS thread. This is what'll be implemented by `CallInvoker::invokeSync`.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D20829955
fbshipit-source-id: efb9d5408a1ade81069a943c865f232d4d10acfe
Summary:
Now, instead of accepting a `std::function` that schedules work, and returning a `CallInvoker`, `Instance::getDecoratedNativeCallInvoker` will accept a `CallInvoker` that schedules work, and return a decorated `CallInvoker`.
I think this change will help with readability. It also clarifies that the bridge is adding additional behaviour to the native `CallInvoker`.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D20826885
fbshipit-source-id: a2c5681d10a4544ee3d2a0d1f1cbd386ef06d0e6
Summary:
Add version badge to README of eslint-config, and add specific url for the homepage so people looking at the npm package can find out where the package is from.
## Changelog
[Internal] [Changed] - Add version badge to README of eslint-config
Pull Request resolved: https://github.com/facebook/react-native/pull/28506
Test Plan: Not required as the only changes are made in README and homepage prop of package.json
Differential Revision: D20837085
Pulled By: cpojer
fbshipit-source-id: 820d3b44b069780ec8764c6152d2e7fd5220933c
Summary:
Might be worthwhile to just kill this method instead, since we're having all NativeModules provide their TurboModule jsi::HostObjects. But I'll leave that decision to a later time.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D20809201
fbshipit-source-id: ee73d4b5454a76460832a54f9b864841e5b2b9c0
Summary:
This is necessary to integrate TurboModule async method dispatch with the bridge's `onBatchComplete` event. See D20717931 for more details.
This diff is similar to D20480971.
**Note:** This stack doesn't really make any functional changes, since the native CallInvoker is `nullptr` right now.
Changelog:
[Internal]
Reviewed By: fkgozali
Differential Revision: D20809199
fbshipit-source-id: bf465a3a51bdddb8b56d1e696ca510fdf071f9ec
Summary:
This diff adds a temporary Feature Flag to control a fix in TextInlineView (see previous diffs of the stack)
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D20812920
fbshipit-source-id: 90fece9b29ba173546d96e4d9baf1ccabb3031b2
Summary:
This diff cleans the variable NativeViewHierarchyOptimizer.mTagsWithLayoutVisited right after all the view updates for a rootShadowNode have been processed by the UIImplementation class.
This intends to fix the bug reported in the task: T61185028, which root cause seems related to the fact that the variable NativeViewHierarchyOptimizer.mTagsWithLayoutVisited is not cleaned up when updating multiple rootShadowNodes as part of the same batch
changelog: [Android][internal] internal bug fix
Reviewed By: JoshuaGross
Differential Revision: D20812921
fbshipit-source-id: 28067ee29a931d7a9e9c33c90aceb4e3512dac1a
Summary:
Do not nag on PRs that contain internal changelogs (meaning, the change doesn't need to be called out in release notes).
## Changelog
[Internal] - This should be acceptable.
Pull Request resolved: https://github.com/facebook/react-native/pull/28486
Test Plan: See PR.
Reviewed By: cpojer
Differential Revision: D20817454
Pulled By: hramos
fbshipit-source-id: a7082c4db05ec53ad27349db7e5bce2cfffd6930
Summary:
This is the first of three PRs related to enabling multi-bundle support in React Native. More details, motivation and reasoning behind it can be found in RFC [here](https://github.com/react-native-community/discussions-and-proposals/issues/152).
Logic responsible for installing globals was pulled out from `loadApplicationScript` to `initializeRuntime` since it should be ran only once, what was left was renamed to `loadBundle`.
It's based on dratwas work from [here](https://github.com/callstack/react-native/tree/feat/multibundle/split-load-application), but applied to current `master` to avoid rebasing 3-months old branch and issues that come with that.
## Changelog
[Internal] [Changed] - split `loadApplicationScript` into `initializeRuntime` and `loadBundle` to enable multi-bundle support in the future
Pull Request resolved: https://github.com/facebook/react-native/pull/27844
Test Plan: Initialized new RN app with CLI, set RN to build from source and verified the still app builds and runs OK using code from this branch.
Reviewed By: rickhanlonii
Differential Revision: D19888605
Pulled By: ejanzer
fbshipit-source-id: 24ace48ffe8978796591fe7c6cf53a61b127cce6
Summary:
Hard-coded to false everywhere, and write-only. We never read from this.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D20788252
fbshipit-source-id: ae117ebc51db7045947b9713602527ff4220833e
Summary:
Remove unused feature flag. This is not used within Facebook and I'm not aware of usage outside of FB.
Changelog: [Removed] Removing Android feature flag: lazilyLoadViewManagers
Reviewed By: mdvacca
Differential Revision: D20788210
fbshipit-source-id: 435316e3de7830d7cb7f14537351883e4fc6eeaa
Summary:
## Overview
This diff is an RFC to port a logging feature from iOS to Android.
Changelog: [Internal]
## Motivation
On iOS we have the following log functions and behaviors available for logging native warnings and errors:
- **Warnings** (`RCTLogWarn`)
- Log level 'warn' to console
- Display warning in LogBox
- **Errors** (`RCTLogError`)
- Log level 'error' to console
- Display a native RedBox (needs converted to show a LogBox if available)
- **Logs**
- We also have `RCTLog`, `RCTTrace`, `RCTAdvice`, `RCTInfo`, which just log to the console.
In Java, we have:
- **Warnings**
- **None**, added in this diff
- **Errors** (`DevSupportManager.showNewJavaError`)
- Log level 'error' to console with `FLog.e`
- Display a native RedBox (needs converted to show a LogBox if available
- **Logs**
- `ReactSoftException` (crashes the app??)
- `ReactNoCrashSoftException` (only logs??)
- Others?
## Details
This diff adds a method to pair with `RCTLogWarn`, `DevSupportManager.showNewJavaWarning`, which will log to the console and show a LogBox warning if LogBox is available.
## Concerns
I have a few concerns/questions about the state of logging on Android:
- Should/can we move all of the logging to it's own class, like how RCTLog works?
- Why does some logging happen on DevSupportManager and some in other classes?
- If we moved it all to it's own class, how could we access the reactContext to call the RCTLog JS module
Reviewed By: JoshuaGross
Differential Revision: D20056394
fbshipit-source-id: 32d57e300685e46da8039fc77cb22b4084acf81a
Summary:
Get jest tests to be runnable on windows, and match current snapshots
## Changelog
[Internal] [Fixed] - More consistent snapshots on windows
Pull Request resolved: https://github.com/facebook/react-native/pull/28482
Test Plan: run `yarn test` on a windows machine, and hit the test_windows circleci tests
Reviewed By: hramos
Differential Revision: D20799002
Pulled By: cpojer
fbshipit-source-id: da3db0171c34a43199c7d3dc17b622b37bc91701
Summary:
While resolving the flexible items we calculate totalFlexShrinkScaledFactors which uses the flexBasis or initial width of node (Not min-width).
At a later stage during distribution of space we are subtracting value from this which also takes care of min-width.
For example
If node has flexShrink 1 and width 100 and min-width 301 then totalFlexShrinkScaledFactors will become -1*100 = -100
but later we are subtracting -1 * 301 (min-width) = -301 which is ambiguous and causing layout inconsistencies with how web behaves.
Fixed this by only using the flexBasis or width for these calculations.
Changelog:
[Internal][Yoga] Fix layout issue when flexShrink and min-width are used together
Reviewed By: pasqualeanatriello
Differential Revision: D20219419
fbshipit-source-id: 948fbc06ca541d4ad307c88c8a2df65d157778b1
Summary:
If name is passed in as part of RuntimeConfig, that is included
in the description, too.
Changelog: [Internal]
Reviewed By: dulinriley
Differential Revision: D20716320
fbshipit-source-id: f2fba6df32f496090dee787d8b7f55a6a4dd8ed8
Summary:
## Context
For now, assume TurboModules doesn't exist.
**What happens when we call an async NativeModule method?**
Everytime JS calls an async NativeModule method, we don't immediately execute it. The legacy infra pushes the call into some queue managed by `MessageQueue.js`. This queue is "flushed" or "emptied" by the following events:
- **Flushed:** A C++ -> JS call. NativeModule async methods can called with an `onSuccess` and/or `onFail` callback(s). Calling `NativeToJsBridge::invokeCallback` to invoke one of these callbacks is one way for ObjC++/C++/Java to call into JS. Another way is via JSModule method calls, which are initiated by `NativeToJsBridge::callFunction`.
- **Flushed:** When `JSIExecutor::flush` is called. Since TurboModules don't exist, this only happens when we call `JSIExecutor::loadApplicationScript`.
- **Emptied:** When more than 5 ms have passed, and the queue hasn't been flushed/emptied, on the next async NativeModule method call, we add to the queue. Afterwards, we empty it, and invoke all the NativeModule method calls.
**So, what's the difference between flushed and emptied?**
> Note: These are two terms I just made up, but the distinction is important.
If the queue was "flushed", and it contained at least one NativeModule method call, `JsToNativeBridge` dispatches the `onBatchComplete` event. On Android, the UIManager module is the only module that listens to this event. This `onBatchComplete` event doesn't fire if the queue was "emptied".
**Why does any of this matter?**
1. TurboModules exist.
2. We need the TurboModules infra to have `JsToNativeBridge` dispatch `onBatchComplete`, which depends on:
- **Problem 1:** The queue being flushed on calls into JS from Java/C++/ObjC++.
- **Problem 2:** There being queued up NativeModule async method calls when the queue is flushed.
In D14656466, fkgozali fixed Problem 1 by making every C++/Java/Obj -> JS call from TurboModules also execute `JSIExecutor::flush()`. This means that, with TurboModules, we flush the NativeModule async method call queue as often as we do without TurboModules. So far, so good. However, we still have one big problem: As we convert more NativeModules to TurboModules, the average size of the queue of NativeModule method calls will become smaller and smaller, because more NativeModule method calls will be TurboModule method calls. This queue will more often be empty than not. Therefore, we'll end up dispatching the `onBatchComplete` event less often with TurboModules enabled. So, somehow, when we're about to flush the NativeModule method call queue, we need `JsToNativeBridge` to understand that we've executed TurboModule method calls in the batch. These calls would have normally been queued, which would have led the queue size to be non-zero. So if, during a batch, some TurboModule async method calls were executed, `JsToNativeBridge` should dispatch `onBatchComplete`.
**So, what does this diff do?**
1. Make `Instance` responsible for creating the JS `CallInvoker`.
2. Make `NativeToJsBridge` responsible for creating the native `CallInvoker`. `Instance` calls into `NativeToJsBridge` to get the native `CallInvoker`.
3. Hook up `CatalystInstanceImpl`, the Android bridge, with the new JS `CallInvoker`, and the new native `CallInvoker`. This fixes `onBatchComplete` on Android. iOS work is pending.
Changelog:
[Android][Fixed] - Ensure `onBatchComplete` is dispatched correctly with TurboModules
Reviewed By: mdvacca
Differential Revision: D20717931
fbshipit-source-id: bc3ccbd6c135b7f084edbc6ddb4d1e3c0c7e0875
Summary:
Changelog: [Internal]
View with `ShadowColor` was getting flattened and therefore views didn't have shadow property set.
This is fixed by promoting ShadowColor so in case it is set, it forms stacking context.
Reviewed By: shergin
Differential Revision: D20792201
fbshipit-source-id: 1033ac00e32047ffbb14e61b7c26348c578d132d
Summary:
The next version of Babel changes how it prints file names in errors. This diff fixes the test by using `/` as the `cwd` and switches the plagin to use `path.buildCodeFrameError` so errors will be more helpful for users.
I renamed the `nodePath` variable to `path` because that's what babel plugins usually do.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D20781805
fbshipit-source-id: cc149dce6389aa9402ce70ea30035c74a6150ea3
Summary:
The differ was still producing correct, but not minimal, instruction sets in some cases due to an optimization that was buggy.
This affected cases where 2+ nodes were inserted at the beginning of a list. It would trigger the old behavior where all nodes after the first would be removed, deleted, then reinserted.
See the test case (which was failing and now passed) and P128190998 (the 3->4 transition) for samples.
Changelog: [Internal] Fabric differ
Reviewed By: mdvacca
Differential Revision: D20785729
fbshipit-source-id: 2fea6a816753066abb358ed7bb51003140cd5fc4
Summary:
Updating the eslint config and metro-preset used in project template.
## Changelog
[General] [Changed] - Upgrade eslint-config and metro-preset in project template
Pull Request resolved: https://github.com/facebook/react-native/pull/28443
Test Plan:
- Start new project with `npx react-native init TestLint`
- upgrade lint and metro-config
- run lint and start up emulator on iOS and android
Reviewed By: cpojer
Differential Revision: D20771048
Pulled By: hramos
fbshipit-source-id: a6d387b8687cee348681bcb10d22c7e3de291ed7
Summary:
This diff implements the instruction pointer save/restore trick Tzvetan came up with; allowing us to observe and modify the IP from outside the interpreter loop with negligible overhead.
From Tzvetan's internal post on the subject:
> [Today] the interpreter IP is just a local variable in the interpreter function, so there is no way to get to its value from outside the function. It lives in a register and we don't want to make it a Runtime field since the overhead [of accessing it via memory in the interpeter loop] would kill us.
> However, if you really think about it, it only lives in a register while the interpreter function is running. For the rest of the time, it is spilled by the C++ compiler onto the stack.
So, precisely when we need it, it is actually stored in memory. The only problem is, we don't know where! Admittedly, that is an annoying problem, but it feels like it should be solvable.
> What if, instead of relying on the compiler to spill the IP register, we manually spill it ourselves, to a known location? It works. Example: https://godbolt.org/z/ftSDnp
This diff implements this approach across the whole interpreter loop: whenever we call out of the loop we capture/publish the IP and restore it again immediately after the external call returns. This means we can now see the IP outside the interpret loop and even change it. This is effectively "for free" as the compiler now skips spilling/restoring the IP behind the scenes.
The immediate benefit of this is knowing the current IP allows us to have more accurate stack-traces during execution. In future this may enabled tricks like changing the IP before returning to the interpreter loop, allowing things outside the interpreter to affect program flow without adding logic to the interpreter loop.
Reviewed By: tmikov
Differential Revision: D20151091
fbshipit-source-id: 3814382639800208d8985a32ede31ba8f7ff7c80
Summary:
Changelog: [Internal]
`orderIndex_` was only being assigned for `ViewShadowNode`, not for other `ShadowNodes` that are later represented on the screen.
Reviewed By: shergin
Differential Revision: D20746477
fbshipit-source-id: c04c2cfea14b9141d22bc3d9e9bb4c0c59925754
Summary:
Fixes `test_android` and `test_docker` build failures. Thanks to dulmandakh for identifying the fix.
Changelog:
[Internal] [Android] [Changed] - Use Android SDK 29 to build during CI tests
Pull Request resolved: https://github.com/facebook/react-native/pull/28455
Test Plan: Circle CI shows `test_android` and `test_docker` passing: https://app.circleci.com/jobs/github/facebook/react-native/142273
Reviewed By: sturmen
Differential Revision: D20766589
Pulled By: hramos
fbshipit-source-id: 8ef8a8ce3a6e7353ae47425accb3bd26cf1608c4
Summary:
motivation is following - the RNTester app is imho the best place to try out any changes that a contributor would make, yet it is not directly mentioned in the contributor guide. This fixes it.
## Changelog
[Internal] - Docs
Pull Request resolved: https://github.com/facebook/react-native/pull/28042
Test Plan: not necessary
Reviewed By: TheSavior
Differential Revision: D20401260
Pulled By: hramos
fbshipit-source-id: 01c1b7dff56b59909c94b2feb609650f0baba1a9
Summary:
Changelog: [internal]
`ModalHostViewShadowNode` didn't have `RootNodeKit` trait, therefore `getRelativeLayoutMetrics` was including nodes in ancestors that it shouldn't have.
Reviewed By: shergin
Differential Revision: D20735801
fbshipit-source-id: 6b81e3b174c2f82e530abc2bca2da8bebc2270b0
Summary:
We are replacing inline-ed implementation with practically the same one implemented as the helper method.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D20551409
fbshipit-source-id: fcc6f497cd240af65fba534051c217fe5746ce82
Summary:
Here we implement a bunch of helper methods that allow customizing the behavior of a RuntimeExecutor "on-demand" on the caller side. We will use it in the next diff(s).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: PeteTheHeat
Differential Revision: D20551411
fbshipit-source-id: 51d3cd02b69753110c0e1155347c6e52eb882c7d
Summary:
Refs facebook/react-native-website#1776.
Despite in-code description `PixelRatio.getFontScale()` is working properly on the iOS (it also reflects the user settings).
This PR updates the in-code description to match current behaviour.
I have decided to skip in the code information about additional setting in `Accessibility` menu and in `Control Centre`, but if you think it is important just let me know, I can update this PR.
## Changelog
[Internal] [Fixed] - Fix PixelRatio getFontScale method description
Pull Request resolved: https://github.com/facebook/react-native/pull/28407
Test Plan: N/A
Differential Revision: D20750260
Pulled By: shergin
fbshipit-source-id: c40ec2fd49cd60e2975351c3a1c453aab0045da4
Summary:
Some of the repository name of Lean Core(https://github.com/facebook/react-native/issues/23313) libraries has been renamed.
This PR updates the warning message to display the updated url.
## Changelog
[General] [Changed] - Update warning message of deprecated imports
Pull Request resolved: https://github.com/facebook/react-native/pull/28452
Test Plan: updated URL can be accessed.
Reviewed By: cpojer
Differential Revision: D20745184
Pulled By: TheSavior
fbshipit-source-id: 2c3ed6a000b45022ca6c4862305aa567c4d18b2e
Summary:
## Overview
This diff refactors the Inspector, moving logic to look up view data for a touched view inside the renderer as `getInspectorDataForViewAtPoint`. We then implement that same function for Fabric in order to support the inspector in that renderer.
Requires https://github.com/facebook/react/pull/18388
## Motivation
Reason one for this refactor is that, previously, the inspector held all of the logic to look up view data for a given x,y touch coordinate. To do this, it would take the React tag and coordinates, look up the native view tag, measure it, and then ask React internals for the Fiber information of that tag. All of this is deeply coupled to React internals, yet the logic is outside of React core in the Inspector.
Reason two is that, for Fabric, the logic for getting the view data is different than Paper. In Fabric, we pass the x,y coordinates to native directly, which returns an instance handle. That handle can be used to measure the ShadowNode, or retrieve the Fiber information.
By moving the logic into the renderer in React core, we decouple the implementation details of looking up view data for a tapped point and allow ourselves the ability to add and change renderer-specific code for the actual lookup without impacting outsiders like the Inspector.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D20291710
fbshipit-source-id: a125223f2e44a6483120c41dc6146ad75a0e3e68
Summary:
There's (potentially) a lot of expensive reflection calls here that, as best I can tell, end up being ignored if the supplied color is null. Better to early return.
Changelog: [General] [Internal] Preclude reflection when setting cursor color if color is null
Reviewed By: JoshuaGross
Differential Revision: D20670594
fbshipit-source-id: 480a988355bbd79008002c4326d4b35035ec2a95
Summary:
Accessing this field via reflection is explicitly blacklisted by Google in Android 10 and higher. They have provided a new API to change the color, which I have implemented here. [The old setColorFilter is deprecated](https://developer.android.com/reference/android/graphics/drawable/Drawable#setColorFilter(int,%20android.graphics.PorterDuff.Mode)) so I also updated that method call as well.
Changelog: [General] [Fixed] Use new setTextCursorDrawable API for Android 10
Reviewed By: JoshuaGross
Differential Revision: D20656068
fbshipit-source-id: 58a92b57c0a892c7c87fc5d735e4ceaa4e987ec7
Summary:
This issue closes https://github.com/facebook/react-native/issues/28241
Migrated Windows test from AppVeyor to CircleCI
## Changelog
[Internal] [Changed] - Migrated Windows test from AppVeyor to CircleCI
Pull Request resolved: https://github.com/facebook/react-native/pull/28245
Test Plan: For CircleCI to Pass
Reviewed By: cpojer
Differential Revision: D20689163
Pulled By: hramos
fbshipit-source-id: 285c762457ef00f7884ee9157b3f336044c0452f
Summary:
Changelog: [Internal]
Current implementation of `measure` doesn't take transform into account..
So if you had a view which has width and height 100 and had `Scale(0.5, 0.5, 1)` (this will shrink view by half). Calling `getRelativeLayoutMetrics` would report its size being `{100, 100}`.
This applies if view's parent has transformation as well, because transformation is applied to all subviews of the view as well.
Reviewed By: mdvacca
Differential Revision: D20621590
fbshipit-source-id: 2cf902a0494291c821ecada56f810c5e6620db5a
Summary:
Changelog: [Internal]
Until now `Rect operator*(Rect const &rect, Transform const &transform)` supported only scaling. Now it supports translation and rotation as well.
Reviewed By: shergin
Differential Revision: D20622876
fbshipit-source-id: 1b65393bd3fd6fd9a8941903e0f2681a10097e4a
Summary:
`LayoutInspectingPolicy` has two flags, `includeTransform` and `includeScrollViewContentOffset`.
`includeScrollViewContentOffset` seems to be redundant for two reasons.
# 1st
From looking at callers, they have always the same value.
I looked at all call sites, and they are either always both set to true or both set to false.
# 2nd
The way we include scroll view content offset, is through transformation, so setting `includeTransform` to true and `includeScrollViewContentOffset` to false will include content offset anyway. In order to make both flags work, we would need to introduce further changes to `getRelativeLayoutMetrics`. But since the flag isn't used anyway, I think it is better to get rid of it for now. If we need it in the future, we could re-introduce it.
Reviewed By: shergin
Differential Revision: D20622256
fbshipit-source-id: fb6156c66b752319ea928239fa723ff90688b0a0
Summary:
Two things:
1) I reimplement Valentin's idea in D19965405, so that TinyMaps can be iterated over, with a couple of bugfixes (calling front() or back() on an empty vector will crash).
2) I now use TinyMap instead of better::map in the "optimized" diffing algorithm.
3) `erase` now actually removes elements from the vector, but only when more than half of elements have been erased.
4) If you repeatedly erase elements at the beginning of the vector, they will no longer be iterated over. This is a specific optimization for our heaviest TinyMap use-cases.
These amount to some small but hopefully somewhat meaningful perf improvements.
Changelog: [Internal] Fabric perf
Reviewed By: shergin
Differential Revision: D20718719
fbshipit-source-id: 91f4b2e2e0f6387ae484e43d5b0095103087baa6
Summary:
This fix aims to address the issue when bundling an Android app for release and getting the error exhibited in https://github.com/facebook/react-native/issues/28002 which I also encountered myself.
The config was changed sometime in November 2019 (as part of https://github.com/facebook/react-native/issues/26940, commit https://github.com/facebook/react-native/commit/a3b08048674e324dbe1f0ca816f35607e9e06a2f) to be very opinionated when it comes to the use of `npx` which Gradle itself cannot find anyway (I have `npx` installed globally and it didn't pick it up).
Another issue that the use of `npx` creates is that Gradle should only ever use the currently installed react-native cli rather than a (possibly) higher version which may not always have backward compatibility.
The proposed change simply throws a more descriptive error rather than defaulting to a tool which may or may not exist on the machine, be it CI or a development environment. I've also modified the RNTester app to reflect the correct config implementation relative to the RNTester app itself.
In real projects, the config inside `android/app/build.gradle` should look similar to the following snippet:
```
project.ext.react = [
cliPath: "$rootDir/../node_modules/react-native/cli.js",
entryFile: "index.js"
];
```
## Changelog
[Android] [Fixed] - Gradle release config
Pull Request resolved: https://github.com/facebook/react-native/pull/28415
Test Plan:
- [x] Successfully bundled an Android release build with correct config
- [x] Works with RNTester app
Reviewed By: mdvacca
Differential Revision: D20714372
Pulled By: hramos
fbshipit-source-id: 4d66139249c6f840582a71a48c64e6a6595f7af0
Summary:
The [PlatformColor PR](https://github.com/facebook/react-native/pull/27908) added support for iOS and Android to express platform specific color values. The primary method for an app to specify such colors is via the `PlatformColor()` method that takes string arguments. The `PlatformColor` method returns an opaque Flow type enforcing that apps use the PlatformColor method instead of creating Objects from scratch -- doing so would make it harder to write static analysis tools around Color values in the future. But in addition to `PlatformColor()`, iOS has a `DynamicColorIOS()` method that takes an Object. The Flow type for this Object cannot be opaque, but we still want to enforce that app code doesn't pass variables instead of Object literals or that values in the Objects are variables. To ensure `DynamicColorIOS()` can be statically analyzed this change adds an ESLint rule to enforce that `DynamicColorIOS()` takes an Object literal of a specific shape. A `ColorAndroid()` was also introduced not for practical use but just to test having platform specific methods for more than one platform in the same app. A second ESLint rule is created for `ColorAndroid` as well.
## Changelog
[General] [Changed] - Add ES Lint rules for `DynamicColorIOS()`and `ColorAndroid()`
Pull Request resolved: https://github.com/facebook/react-native/pull/28398
Test Plan: `yarn lint` passes.
Reviewed By: cpojer
Differential Revision: D20685383
Pulled By: TheSavior
fbshipit-source-id: 9bb37ccc059e74282b119577df0ced63cb9b1f53
Summary:
This unit test is to verify that the new diffing algorithm generates a "minimal" instruction set, with regards to removes and inserts ("moves").
These unit tests are here to verify the expected behavior in this new algorithm, but these tests may be modified or deleted in the future if we decide we want to change this behavior.
Changelog: [Internal] fabric unit test
Reviewed By: mdvacca
Differential Revision: D20706592
fbshipit-source-id: 5f9991498e0d788ecbf88d938bfe6d3f0f27af40
Summary:
An evolution of D20633188 but more performant.
There are three optimized paths before the slow path.
The first optimized path tries to pair identical nodes from old/new tree, and generate Update mutations, until we hit nodes that are different (indicating either a remove or an insert). This already existed.
The next two optimizations, introduced by Tim in his JS pseudocode, were inspired by ReactJS's diffing algorithm. They work in cases where the rest of the nodes are (1) all removals/deletes or (2) all creates+inserts.
Finally, if those final two optimized paths can't run, it's because there is a mix of delete+remove, create+insert, and "move" operations, mixed at the beginning, middle, and/or end of the list.
This has slightly better average/best-case complexity as the previous implementation.
In particularly pathological cases where all nodes are arbitrarily reordered, or reversed, for instance (ABCDE->EDCBA) the algorithm has the same complexity as the previous algorithm (quadratic).
For now iOS is pinned to the older differ
Changelog: [Internal] Experiment to optimize diffing algorithm in Fabric
Reviewed By: shergin
Differential Revision: D20684094
fbshipit-source-id: d29fba95a0328156c023e1c87804f23770ee1d91
Summary:
`std::this_thread::sleep_for` is not really precise and will attempt to sleep for "at least" that much time, but may sleep much longer depending on what CPUs are doing and scheduling policies.
To get this to pass on my machine, I had to substantially increase the thresholds.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D20689571
fbshipit-source-id: f159420d24a95da2b5d95d49ed7882e783291e98
Summary:
State Reconciliation has been running 50/50 for a while and all metrics look stable. This is necessary for providing a good experience so we should ship to everyone unconditionally.
Changelog: [Internal] Fabric diffing reconciliation process improvement
Reviewed By: mdvacca
Differential Revision: D20715694
fbshipit-source-id: 25b2635ecc29b67e2911679c9db66bc84d37dec1
Summary:
In preparation for upgrading babel, I'm updating some of our source transform tools to the latest versions.
Changelog: [Internal]
Reviewed By: GijsWeterings
Differential Revision: D20675201
fbshipit-source-id: fa4fee2652529c6677087e42cdd1325a8080e46f
Summary:
The newly added console warnings in D19304480 are adding a lot of warning noise due to missed infra callsites. Those callsites need to be updated before these warnings can be added.
Changelog:
[Removed] Remove console warnings from ScrollView methods
Reviewed By: rickhanlonii
Differential Revision: D20700917
fbshipit-source-id: cb618ee3a291d26e1942e4f91bbc02dee41fb78b
Summary:
onEndReached can be triggered twice when more items are added to the end of the list. This change makes it so that a second call to onEndReached won't happen until the user scrolls down to the new end of the list.
Changelog:
[General] [Fixed] - Fix double call to onEndReached in VirtualizedList
Reviewed By: sahrens
Differential Revision: D20066740
fbshipit-source-id: 129d7ae6bfd241eeea18fe0bb12b82be67735874
Summary:
Have ScrollView use forwardRef so that the host component methods like `measure` and `measureLayout` are available without having to call `getNativeScrollRef`. Instead, you can use `<ScrollView ref={myRef} />` and directly call all methods of ScrollView and host components on `myRef`.
Previous usage:
```
const myRef = React.createRef<React.ElementRef<typeof ScrollView>>();
<ScrollView ref={myRef} />
const innerViewRef = myRef.current.getNativeScrollRef();
innerViewRef.measure();
```
New usage:
```
const myRef = React.createRef<React.ElementRef<typeof View>>();
<ScrollView ref={myRef} />
// now, myRef.current can be used directly as the ref
myRef.current.measure();
myRef.current.measureLayout();
// Additionally, myRef still has access to ScrollView methods
myRef.current.scrollTo(...);
```
Changes:
* Added deprecation warnings to ScrollView methods `getNativeScrollRef`, `getScrollableNode`, and `getScrollResponder`
* Added the forwardRef call to create `ForwardedScrollView` - this takes in `ref` and passes it into the class ScrollView as `scrollViewRef`.
* Forwarded the ref to the native scroll view using `setAndForwardRef`.
* Added statics onto `ForwardedScrollView` so that `ScrollView.Context` can still be accessed.
* Added type `ScrollViewImperativeMethods`, which lists the public methods of ScrollView.
* Converted all public methods of ScrollView to arrow functions. This is because they need to be bound to the forwarded ref.
* Bound all public methods of ScrollView to the forwarded ref in the `setAndForwardRef` call.
* Flow typed the final output (ForwardedScrollView) as an abstract component that takes in the props of the `ScrollView` class, and has all methods of both the inner host component (`measure`, `measureLayout`, etc) and the public methods (`scrollTo`, etc).
Changes to mockScrollView:
* Changed mockScrollView to be able to mock the function component instead of a class component
* Updated necessary tests
Changelog:
[General] [Changed] - Make ScrollView use forwardRef
Reviewed By: TheSavior
Differential Revision: D19304480
fbshipit-source-id: 6c359897526d9d5ac6bc6ab6d5f9d82bfc0d8af4
Summary:
Upgrading the embedded version of React DevTools, primarily to pull in [this PR](https://github.com/facebook/react/pull/18397) which will reduce the impact of this package on `node_modules` size.
# Update process
Following a similar process as D15973709, I began by searching for [all of the references](https://our.intern.facebook.com/intern/biggrep/?corpus=xplat&filename=.json&case=false&view=default&extre=&s=%22react-devtools&engine=apr_strmatch&context=false&filter[uninteresting]=false&filter[intern]=false&filter[test]=false&grep_regex=) to the `react-devtools-core` package and updated all v4 usage to to point to the new 4.6.0 release:
1: Manually update "react-devtools-core" versions:
```
js/package.json
js/react-native-github/package.json
nuclide/package.json
sonar/desktop/app/package.json
sonar/desktop/plugins/reactdevtools/package.json
vscode/modules/vscode-webview/package.json
```
2: Setup Yarn proxy:
```
yarn config set proxy http://fwdproxy:8080/
yarn config set https-proxy http://fwdproxy:8080
```
3: Run "yarn" in each of the above directories.
4: Run the lockfile shell script:
```
~/xplat/js/scripts/update-oss-yarn-lockfile.sh
```
5: Update the generated `MOBILE_JS_NODE_MODULE_DEPS.bzl` by running
```
js1 build buckfiles
```
## Changelog:
[General] [Changed] - Upgrade embedded React DevTools backend from v4.0.6 to v4.6.0.
Reviewed By: cpojer, gaearon
Differential Revision: D20676091
fbshipit-source-id: 99865bdba9bce45e2a7d582d5fb550cfdbeeca3a
Summary:
Updates `eslint-plugin-react-hooks` to 3.0.0. This introduces a new lint error when you use a Hook inside a class.
Changelog:
[General][Changed] - Updated the React Hooks ESLint Plugin
Reviewed By: cpojer
Differential Revision: D20675528
fbshipit-source-id: d0cbe9748fd15df7a4c6de00bd1462610e0a43d6
Summary:
This is another attempt to fix an issue very similar to T59424871. The previous attempt was in D19249490. I don't know why we don't see production crashes (stalls) but it happened to me (and not to me) in the debugger. The previous attempt didn't work because we still could have a deadlock because we tried to acquired shared mutex already owned exclusively by the `suspend` method.
Here is another approach: Instead of using one shared mutex, now we use two. One is similar to what we had and another that protects `suspend` and `resume`. Besides that, now we pass a Scheduler to functions that use that explicitly. This way we can be more explicit about acquiring mutexes and the overall flow of execution. The idea is: Now an arbitrary code that can be reentrant does not cover with mutexes, so the deadlock is not possible.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D20639228
fbshipit-source-id: 98515742f00f2ae94b50b585c9f1f0611e169ebe
Summary:
Jobs now have a `run_disabled_tests` argument that allows for the selective execution of disabled tests. When working on re-enabling a failing test, the contributor just needs to set `run_disabled_tests` to `true` in the appropriate workflow in `.circleci/config.yml`.
Tests can be kept green by moving failing tests into the disabled section until a contributor can provide a fix, thus ensuring signal is maintained on master. For example, a failing end-to-end test might be disabled in order to allow the signal from unit tests to be provided, as opposed to flat out failing the entire job.
What was done in this PR:
* The failing `test_js_e2e` job has been fixed, and merged into the `test_js` job. An empty disabled tests section is added for future use.
* The failing `test_ios_e2e` job has been merged into `test_ios`, with all of its steps gated behind the `run_disabled_steps` argument.
* The failing Android end-to-end tests have been added to `test_android`, gated behind the `run_disabled_steps` argument
* The failing Podspecs test has been added back into `test_ios`, gated behind the `run_disabled_steps` argument
## Changelog
[Internal] [CI] - ✅ Green CI, disabled test infrastructure work
Pull Request resolved: https://github.com/facebook/react-native/pull/28392
Test Plan: Verified on Circle CI
Reviewed By: cpojer
Differential Revision: D20665512
Pulled By: hramos
fbshipit-source-id: 831738027f90f4b23313893d8342d7e654f34726
Summary:
`fbsource//xplat` and `//xplat` are equivalent for FB BUCK targets. Removing extra prefix for consistency.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D20656211
fbshipit-source-id: deb91b917d349bc500acbb03d734ff621f6e1fc7
Summary:
`fbsource//xplat` and `//xplat` are equivalent for FB BUCK targets. Removing extra prefix for consistency.
Changelog: [Internal]
Reviewed By: scottrice
Differential Revision: D20495655
fbshipit-source-id: a57b72f694c533e2e16dffe74eccb8fdec1f55f5
Summary:
Logbox has a retain cycle (see linked task for my deeper investigation).
This diff doesn't fix the retain cycle, but it's just good practice to not retain self strongly in blocks.
Changelog: [iOS][Internal] Fix retaining self in block in LogBox implementation
Reviewed By: shergin
Differential Revision: D20630693
fbshipit-source-id: cf399495e9bcd1917932fcc0e9c9d2d2a32bf6f0
Summary:
## Problems
Repro steps:
1. Disable Fabric (because CMD + R doesn't work with Fabric right now).
2. Open up Marketplace and hit `CMD + OPT + R`
3. **Observe:** The progress bar doesn't show up right away. It also doesn't actually show progress.
https://pxl.cl/140g1
RN Support post: https://fb.workplace.com/groups/rn.support/permalink/3437652016283389/
## Fixes
The first problem is that progress bar doesn't actually show progress.
**Fix:** Bundle load progress is updated in `RCTCxxBridge`, where we first require `RCTDevLoadingView`, and then call its `updateProgress` method. Previously, we wouldn't lazily load `RCTDevLoadingView`, it already didn't exist. Lazily loading `RCTDevLoadingView` causes the progress view to show up. Here: https://pxl.cl/140gt
If you look at the above video, you'll notice there are two stages to the progress bar: stage 1 displays the actual progress. Stage 2 prompts that we're downloading the JS bundle. As you can see, stage 1 and stage 2 have different background colors, even though both of them are green.
**Fix:** I adjusted the JS to match the Native color. Here: https://pxl.cl/140gT
We're almost there, but the progress bar is dismissed twice?
**Fix:** I dug into the code, and the reason why was because when we hit `CMD + R`, we invalidate the bridge, and immediately re-initialize it. This means that we asynchronously invalidate the old TurboModuleManager, and immediately create a brand new one. Therefore, two `RCTDevLoadingView` modules can (and do) exist at once. So, I moved `RCTDevLoadingView` to be an instance member of `FBReactModule`, to ensure that it doesn't get cleaned up and re-created when TurboModuleManager is deleted and re-created. This finally fixed the progress bar jank:
https://pxl.cl/140hn
Changelog:
[iOS][Fixed] - Remove RCTDevLoadingView jank
Reviewed By: rickhanlonii
Differential Revision: D20607815
fbshipit-source-id: 05825c67adaf3cfda70be0fa2dc92d413dc8921b
Summary:
The bridge complains if modules aren't exported, which isn't really helpful with lazily loaded modules and turbo modules.
I considered only turning this off when TurboModules is enabled, but figured we'd be killing this soon anyways... If anyone feels strongly I can go that approach.
Changelog: [iOS][Internal] Remove RCTExportModule log spam
Reviewed By: shergin
Differential Revision: D20629575
fbshipit-source-id: d32d9fe244c4d06acfee982fca7c7f63da294dc5
Summary:
This just updates the `react` package to the latest stable version. We updated it to experimental internally earlier so this brings the open source version to the latest before the branch cut. This doesn't include any breaking changes.
Changelog:
[General][Changed] - Update to React 16.13.1
Reviewed By: cpojer
Differential Revision: D20642909
fbshipit-source-id: 68a4c74bfe72f1abdb33b0b9071a4f4e8e568318
Summary:
While ViewConfig infra isn't perfect we need to check some value for correctness during prop-parsing.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D20639055
fbshipit-source-id: 193dcd0769bc7777bc8d60c964ede72ebdaa83e4
Summary:
This gets us on the latest Prettier 2.x:
https://prettier.io/blog/2020/03/21/2.0.0.html
Notably, this adds support for TypeScript 3.8,
which introduces new syntax, such as `import type`.
Reviewed By: zertosh
Differential Revision: D20636268
fbshipit-source-id: fca5833d003804333a05ba16325bbbe0e06d6c8a
Summary:
Changelog: [Internal]
Hermes inspector includes pthreads, arpa and sys headers on all OSes that would break vanilla Windows builds. This diff adds a check for posix-compliance before inclusion
(Note: this ignores all push blocking failures!)
Reviewed By: dulinriley
Differential Revision: D20564449
fbshipit-source-id: 8e264bc3104065dc4315bb291e8560609fe65184
Summary:
Changelog: [Android] [Updated]
mOverrideColorScheme should be assigned before the first colorSchemeForCurrentConfiguration call, so the initial setting of mColorScheme will reflect the override
Reviewed By: zackargyle
Differential Revision: D20630173
fbshipit-source-id: a2a2d174d3fc40c14f27dce6a7fa8e67203480c9
Summary:
- Timestamp of entries in our Firebase instance sometimes get stored as number. This means that we may not always be diffing against the latest master commit.
- Size report of Android and iOS gets overwritten depending on which build finishes first.
## Changelog
[Internal] [Fixed] - App bundle size diff not always being compared against latest commit
[Internal] [Fixed] - Android and iOS app bundle size diff overwrite each other
Pull Request resolved: https://github.com/facebook/react-native/pull/28368
Test Plan:
- We are now using Firebase's own [firebase.firestore.Timestamp.now](https://firebase.google.com/docs/reference/js/firebase.firestore.Timestamp#now) to ensure that we always get a timestamp in the preferred format. This has been tested locally but can only be verified when merged to master and we start getting new data. In the meantime, I'll manually fix up all the entries in the store.
- There should be one app bundle size comment for Android and one for iOS in this PR.
Reviewed By: cpojer
Differential Revision: D20601620
Pulled By: hramos
fbshipit-source-id: 0c3e4b78a74cbd659f1957a6aa74322b016e0646
Summary:
The [previous attempt](https://github.com/facebook/react-native/pull/28304) to fix the publish step failed, so now reverting to manually configuring things. This PR adds an entry to SSH’s `known_hosts` file using github.com’s public key that I have verified as per [these instructions](https://serverfault.com/a/807363):
```
~/C/R/react-native [master] » nmap github.com --script ssh-hostkey
Nmap scan report for github.com (140.82.118.4)
rDNS record for 140.82.118.4: lb-140-82-118-4-ams.github.com
PORT STATE SERVICE
22/tcp open ssh
| ssh-hostkey:
| 1024 ad:1c:08:a4:40:e3:6f:9c:f5:66:26:5d:4b:33:5d:8c (DSA)
|_ 2048 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48 (RSA)
```
These fingerprints line up with [the ones posted by GitHub](https://help.github.com/en/github/authenticating-to-github/githubs-ssh-key-fingerprints), so my setup should be good and can be trusted to grab the public key from the right host:
```
~/C/R/react-native [master] » ssh-keyscan -t rsa -H github.com
# github.com:22 SSH-2.0-babeld-d48c3acd
|1|If6MU203eXTaaWL678YEfWkVMrw=|kqLeIAyTy8pzpj8x8Ae4Fr8Mtlc= ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ==
```
## Changelog
[Internal] [Fixed] - Make automated publishing of packages from CI work again
Pull Request resolved: https://github.com/facebook/react-native/pull/28370
Test Plan: I used the command being added in this PR in [a failed CI job](https://app.circleci.com/pipelines/github/facebook/react-native/4104/workflows/916127cb-177f-4583-9f90-cae5318041d8/jobs/140810). When I invoked the publish script manually I was not greeted by the blocking prompt and the package was successfully published: https://www.npmjs.com/package/react-native/v/0.0.0-56cf99a96
Reviewed By: cpojer
Differential Revision: D20601527
Pulled By: hramos
fbshipit-source-id: b1a4405228408cfc4a1b3b44ab88c79522af3a66
Summary:
When passing an object to contentOffset that doesn't have `y` prop set it causes the following error:
```
Error: AnimatedValue: Attempting to set value to undefined
This error is located at:
in ScrollView (at src/index.js:638)
...
```
This happens since a runtime check was added to the `AnimatedValue` constructor. (a3aaa471ec)
According to flow types the object passed to contentOffset should always contain both x and y props but since it worked before when y is undefined I think its fine to patch the runtime behaviour defensively, especially since the code change is simple.
## Changelog
[General] [Fixed] - Fix Animated Value initialized with undefined in ScrollView
Pull Request resolved: https://github.com/facebook/react-native/pull/28349
Test Plan: Tested that the crash no longer reproduces when passing an empty object to contentOffset.
Reviewed By: cpojer
Differential Revision: D20601664
Pulled By: hramos
fbshipit-source-id: b098a2dd1e702f995a9a92fa6e4e9a204187dac4
Summary:
Enhance our issue management workflow by having the bot respond automatically whenever a label is applied to the issue.
## Changelog
[Internal] - CI
Pull Request resolved: https://github.com/facebook/react-native/pull/28374
Test Plan: Not tested. If needed, could be applied to a different, test repository.
Reviewed By: cpojer
Differential Revision: D20606887
Pulled By: hramos
fbshipit-source-id: 874d1464527ea76bf51394a7d3e98e4fd8f69345
Summary:
Changelog: [Internal]
Removing historic layout animations index adjustment (D20323928) broke the Dating Secret Crush screen.
Since flushing animations (D20319824) had to be reverted due to issues with Saved + Privacy Shortcuts (https://fburl.com/tasks/eijtmifu) we need to track pending deletions across `manageChildren` operations.
Reviewed By: JoshuaGross
Differential Revision: D20601079
fbshipit-source-id: c6f116683750e97abe7f988cf361d2a6449e90e6
Summary:
Handles the case when a value in an object parameter of a turbo module spec is null (even if the type is nullable).
For example, given:
```
export interface Spec extends TurboModule {
+myFunc: ({|
foo: ?string,
|}) => void;
}
```
and calling `NativeModule.myFunc({foo: null})`, we see an error like:
```
JSON value '<null>' of type NSNull cannot be converted to NSString
```
Guarding against this by converting NSNull's to nils
## Changelog:
[iOS] [Fixed] - Fix crash when passing null value in object parameter of bridged method
Reviewed By: fkgozali
Differential Revision: D20591590
fbshipit-source-id: fdb90f34131427a235f2e3c99147bf1e6a9c6732
Summary:
This is pure syntactic change. Often we don't have a shared pointer to ShadowNodeFamily and only have just a reference. At the same time, `ComponentDescriptor::createState` does not have to accept a shared pointer. So, it's better to accept just a reference.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D20578787
fbshipit-source-id: 905277001e096d41e75007575b59ea2ea15fbf4b
Summary:
add support to the android implementation of the Picker component for setting the background color.
Changelog: [Android] [Added] - Support item background color in Dialog Picker
Differential Revision: D20566131
fbshipit-source-id: d693b40803fa1051ec955c5728994c820fecd9e9
Summary:
Changelog: [Internal]
# There are three changes in this diff
## _stateRevision is replaced with a BOOL
`_stateRevision` was protecting against setting attributed string that is already visible to the user. Previously this was ok because the change was only coming from native, any changes from JS were ignored.
Imagine following scenario:
1. User taps key.
2. Update state is called on component initiated by native.
3. New state is created with incremented revision by one.
4. `_stateRevision` gets set to new state's revision + 1.
5. Now JS wants to change something because it just learnt that user tapped the key.
6. New state is created again with incremented revision by one.
7. Update state is called on the component, but the change isn't applied to the text view because `_state->getRevision()` will equal `_stateRevision`.
By having a BOOL instead of number, we very explicitly mark the region in which we don't want state changes to be applied to text view.
## Calling [_backedTextInputView setAttributedText] move cursor to the end of text input
This is prevented by storing what the current selection is and applying it after `[_backedTextInputView setAttributedText]` is called.
This was previously invisible because JS wasn't changing contents of `_backedTextInputView`.
## Storing of previously applied JS attributed string in state
This is the mechanism used to detect when value of text input changes come from JavaScript. JavaScript sends text input value changes through props and as children of TextInput.
We compare what previously was set from JavaScript to what is currently being send from JavaScript and if they differ, this change is communicated to the component.
Previously only first attributed string send from JavaScript was send to the component.
# Problem
If children are used to set text input's value, then there is a case in which we can't tell what source of truth should be.
Let's take following example
We have a text field that allows only 4 characters, again this is only a problem if those 4 characters come as children, not as value.
This is a controller text input.
1. User types 1234.
2. User types 5th character.
3. JavaScript updates TextInput, saying that the content should stay 1234.
4. In `TextInputShadowNode` `hasJSUpdatedAttributedString` will be set to false, because previous JS value is the same as current JS value.
Reviewed By: shergin
Differential Revision: D20587681
fbshipit-source-id: 1b8a2efabbfa0fc87cba210570142d162efe61e6
Summary:
See https://github.com/facebook/react/pull/18366
This contains a fork of the upstream Flow types. We shouldn't be syncing this since these leads to conflicting types.
As a result, these uses have already been codemodded away. Only the imports remained.
Changelog:
[React Core] - Remove ReactTypes from sync.
Reviewed By: gaearon
Differential Revision: D20583740
fbshipit-source-id: fc86a934cbdca8ff90fe90282b86ecc945a85e5f
Summary:
Changelog: [Internal]
# Fabric
1. If `start` and `end` parameters in `setTextAndSelection` are -1, we don't move the cursor. Previously the cursor would be moved to beginning of text input.
2. In view commands, do not validate `eventCount`. It is passed in as undefined from JS because Fabric's text input doesn't use `eventCount`.
# Paper
1. If `start` and `end` parameters in `setTextAndSelection` are -1, we don't move the cursor. Previously the cursor would be moved to beginning of text input.
Reviewed By: shergin
Differential Revision: D20538290
fbshipit-source-id: c7aeddc25f58697254474058ce901df958321f7c
Summary:
This fixes two things:
1) Currently it only respects Start and End padding, and if there's a Theme default, it will override Left/Right padding. Whoops.
2) Currently it doesn't respect when a TextInput starts with padding, but then is removed.
This resolves both.
It still does not account for RTL support.
Changelog: [Internal] Fix AndroidTextInput padding
Reviewed By: mdvacca
Differential Revision: D20573151
fbshipit-source-id: e89791641b6699e728cde9dbd661a8c21485fbc8
Summary:
Fixes https://github.com/facebook/react-native/issues/28361.
## Changelog
[Internal] [CI] - Fix test_android
Pull Request resolved: https://github.com/facebook/react-native/pull/28363
Test Plan:
Prior to fix:
```
react-native $ ./scripts/circleci/buck_fetch.sh
Guessing 168a69309928ba16065cdb33b1775a4af9f924a6 as the last one used version.
Using additional configuration options from /Users/hramos/.buckconfig.d/experiments, /etc/buckconfig.d/fb_chef.ini, /etc/buckconfig.d/fb_chef_override.ini
Invalidating internal cached state: Watchman failed to start. This may cause slower builds.
Parsing buck files: finished in 1.5 sec
Buck wasn't able to parse /Users/hramos/git/react-native/ReactAndroid/src/main/java/com/facebook/fbreact/specs/BUCK:
IOError: [Errno 2] No such file or directory: '/Users/hramos/git/react-native/tools/build_defs/platform_defs.bzl'
Call stack:
File "/Users/hramos/git/react-native/.buckd/resources/168a69309928ba16065cdb33b1775a4af9f924a6/buck_server/buck_parser/profiler.py", line 507, in wrapped
return func(*args, **kwargs)
File "/Users/hramos/git/react-native/ReactAndroid/src/main/java/com/facebook/fbreact/specs/BUCK", line 1
load("//tools/build_defs:platform_defs.bzl", "ANDROID")
File "/Users/hramos/git/react-native/.buckd/resources/168a69309928ba16065cdb33b1775a4af9f924a6/buck_server/buck_parser/profiler.py", line 507, in wrapped
return func(*args, **kwargs)
This error happened while trying to get dependency '//ReactAndroid/src/main/java/com/facebook/fbreact/specs:FBReactNativeSpec' of target '//ReactAndroid/src/main/java/com/facebook/react/devsupport:devsupport'
```
After fix:
```
react-native $ ./scripts/circleci/buck_fetch.sh
+ buck fetch ReactAndroid/src/test/java/com/facebook/react/modules
Guessing 168a69309928ba16065cdb33b1775a4af9f924a6 as the last one used version.
Using additional configuration options from /Users/hramos/.buckconfig.d/experiments, /etc/buckconfig.d/fb_chef.ini, /etc/buckconfig.d/fb_chef_override.ini
Invalidating internal cached state: Watchman failed to start. This may cause slower builds.
Parsing buck files: finished in 1.1 sec
Configuration 'ANDROID_SDK' points to an invalid directory '/opt/android_sdk'.
When creating rule //ReactAndroid/src/main/java/com/facebook/hermes/instrumentation:instrumentation.
```
> Note: I don't have the Android SDK configured in this machine.
Verified on Circle CI. `test_android` is now green: https://circleci.com/gh/facebook/react-native/140682?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link
Reviewed By: cpojer
Differential Revision: D20564934
Pulled By: hramos
fbshipit-source-id: 5d843b8f113c4db5391ee39addc3ff259d962290
Summary:
Historically, React Native didn't support a lot of custom project structures apart from the standard flat directory with `ios` and `android` folders. The CLI had to be explicitly started from the project root, otherwise Metro didn't work right.
In order to resolve the project root in the most accurate way, React Native assumed that project root is always `../../` from its location in `node_modules` - this is not true when the installation gets hoisted (e.g. in a monorepo).
To address that, janicduplessis brought support for custom [`PROJECT_ROOT`](https://github.com/facebook/react-native/commit/9ccde378b6e6379df61f9d968be6346ca6be7ead) that allowed overriding the `../../` in case it wasn't true.
Today, CLI is able to automatically resolve the project root, no matter where it's started. It will traverse the tree of the directories upwards and stop as soon as it meets `package.json`.
As a result, it doesn't really matter from where we start the CLI anymore as a part of `react-native-xcode.sh`.
By replacing the default value of `$REACT_NATIVE_DIR/../../` with `$PWD, that is default for all Xcode scripts, we can make the setup for monorepo easier - nobody will need to set `$PROJECT_ROOT` in order to override the incorrect defaults.
By default, all scripts defined in Xcode run from `$PWD` directory, which is the location of the iOS project. In the future, we will be able to remove `cd` entirely.
To better understand this PR, let's look a few hypothetical structures as an example:
#### Monorepo:
> tl;dr works out of the box, no need to mess around with paths
```
- package.json
- packages/
- my-app/
- index.js
- package.json
- ios/
- MyApp.xcodeproj
```
**Before this PR**, the `react-native-xcode.sh` will start the CLI like this:
```bash
cd $REACT_NATIVE_DIR/../../
node <absolute_path_to_cli.js> bundle --entry-point index.js
```
- Because we change the directory to the root of monorepo, CLI throws an error. All in all, there's no `react-native` dependency at the workspace root.
- Some users turn `no hoist` in an act of troubleshooting the errors, which resolves the problem - `react-native` is moved under `my-app/node_modules` which makes this mechanism resolve properly.
- Some users find out about `PROJECT_ROOT` and set it to overwrite the default value. For example, setting `export PROJECT_ROOT = "$PWD/../` will set the directory to `my-app`, which has a dependency on `react-native` in a `package.json` and makes the CLI happy.
**After this PR**, the `react-native-xcode.sh` will start the CLI like this:
```bash
cd $PWD
node <absolute_path_to_cli.js> bundle --entry-point index.js
```
- The `$PWD` is `packages/my-app/ios/` because that's where the Xcode project is located. CLI will automatically set the root to `../` because that's where it finds `package.json` with `react-native` dependency. It will pass that root to Metro, unless users have set a different one themselves. Thanks to that, all paths to JavaScript files remain working and unaffected.
- No need to set `PROJECT_ROOT` anymore.
- We don't rely on the location of `node_modules`, which is cleaner and future proof.
#### Standard:
> tl;dr no changes
```
- ios/
- MyApp.xcodeproj
- index.js
- package.json
```
**Before this PR**, the `react-native-xcode.sh` will start the CLI like this:
```bash
cd $REACT_NATIVE_DIR/../../
node <absolute_path_to_cli.js> bundle --entry-point index.js
```
- Everything works fine. Path from `react-native` inside `node_modules` is correct - the project root is set right to `/`
**After this PR**, the `react-native-xcode.sh` will start the CLI like this:
```bash
cd $PWD
node <absolute_path_to_cli.js> bundle --entry-point index.js
```
- The root will be set to where Xcode project is located, which is `/ios`. This is the PWD for all Xcode scripts.
CLI will look for the `package.json` going upwards from `ios` folder. Will stop at `/`, find out it has `react-native` dependency, load it and its commands and proceed further.
## Changelog
[iOS] [Feature] - Better monorepo support when building release apk
Pull Request resolved: https://github.com/facebook/react-native/pull/28354
Test Plan:
- All projects (standard/monorepo) run without issues.
- PROJECT_ROOT is not needed.
CC: Titozzz (who wrote monorepo guide), alloy, bartolkaruza
Reviewed By: cpojer
Differential Revision: D20558005
Pulled By: hramos
fbshipit-source-id: 2551120beadcfd4c2f1393ce8a2c2fa6b93c9290
Summary:
Add diffing to app bundle size reports.
## Changelog
[Internal] [Changed] - Add diffing to app bundle size reports
Pull Request resolved: https://github.com/facebook/react-native/pull/28284
Test Plan:
- App bundle size reports should now display a diff where available
- Right now, the database contains only one entry for the last known good iOS build
- Triggering a new build should not create additional comments
Reviewed By: cpojer
Differential Revision: D20450158
Pulled By: hramos
fbshipit-source-id: 720772275f24d3ff0a49705f4dada2efe2e99bd3
Summary:
We initially added the nightly build test to run every hour, in order to more quickly validate it. Now that it has been validated we can run it every night as it is intended to do.
cc hramos
## Changelog
[General] [Changed] - Change nightly build from hourly to nightly
Pull Request resolved: https://github.com/facebook/react-native/pull/28346
Reviewed By: cpojer
Differential Revision: D20550143
Pulled By: hramos
fbshipit-source-id: 9487c6785684ad6ea7e877290d50a33118090a7f
Summary:
Earlier this week I introduced a change in the old, non-Fabric renderer (D20378633 D20427803) that (gated behind a feature-flag) executes ViewCommands before all other types of commands, as a perf optimization and (I think) a potential fix for a category of race conditions.
I've added more details in comments here.
The Fabric renderer uses the same feature-flag that I introduced for the non-Fabric renderer.
Changelog: [Internal] Fabric
Reviewed By: mdvacca
Differential Revision: D20449186
fbshipit-source-id: bb3649f565f32c417a6247369902333989a043aa
Summary:
Instead of just blindly retrying all ViewCommands if they fail - which could be dangerous, since it's arbitrary imperative commands we'd be executing twice, potentially with bad app state - we only retry if the ViewCommand throws a "RetryableMountingLayerException".
Changelog: [Internal] Optimization to ViewCommands
Reviewed By: mdvacca
Differential Revision: D20529985
fbshipit-source-id: 0217b43f4bf92442bcc7ca48c8ae2b9a9e543dc9
Summary:
Simplifying the dispatchMountItems reentrance and retry logic.
Motivation: cleanup so I can work on dispatching ViewCommands before anything else.
Importantly, this gives us the properties that:
1) Only one function is responsible for calling dispatchMountItems
2) Only one function is responsible for deciding if we shouldn't call dispatchMountItems due to reentrance
3) Only one function is responsible for all cleanup
4) Only one function maintains all of the relevant flags (except dispatchPreMountItems... two total now, instead of 4 before)
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D20437035
fbshipit-source-id: 5370366790eb25f653bee6c1950e747458374a61
Summary:
Original commit changeset: b594d0e6e9b6
D20319824 introduced a problem in LayoutAnimations, which makes surfaced as the problem in T63911344. This diff reverts D20319824.
Changelog: [Internal]
Reviewed By: lunaleaps
Differential Revision: D20541918
fbshipit-source-id: ff72b839f57d39051122920a38b2632cbb5ec362
Summary:
This diff fixes an issue where errors in LogBox during tests would cause the tests to crash.
The crash is due to the NativeExceptionsManager module not being mocked (as all native module need to be in tests). The fix is to properly mock the NativeExceptionManger.
This fix exposed an infinite loop issue where failures in LogBox will be logged to the ExceptionManager, which logs to the console, which logs to LogBox, creating a loop. This diff also fixes that look by moving the LogBox internal error check to the top of the monkey patched console methods.
Changelog: [Internal]
Differential Revision: D20428590
fbshipit-source-id: 7289a480c99ba8dee67772178b7629afb40b330a
Summary:
This PR adds the `isFocused` method to the mock of the TextInput component. My understanding some of the latest changes on the TextInput to make it use a forwardRef change the way this method is mock giving an error when trying to use in on a mock.
The change suggested here fixes the issue.
## Changelog
[JavaScript] [Fixed] - Fix the mock for TextInput to support the `isFocused` method
Pull Request resolved: https://github.com/facebook/react-native/pull/28332
Reviewed By: cpojer
Differential Revision: D20538044
Pulled By: TheSavior
fbshipit-source-id: be734af105ab62ffdf9ed4017bd70845e207f8cd
Summary:
The new prop on RCTParagraphComponentView is meant to be used only by external introspection tools, not the RN core.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: nscoding
Differential Revision: D20523078
fbshipit-source-id: 4c457d070fd2c172d681c5aa7f731d2d52bba291
Summary:
Just includes the manual changes to get the perf logger moved to the ObjCTurboModule constructor.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D20498443
fbshipit-source-id: e607588f47ccc8ae199cd97043b09dfaff7a72dd
Summary:
Previously, I had logic inside `RCTTurboModuleManager` to attach the `id<RCTTurboModulePerformanceLogger>` to the `ObjCTurboModule` object
```
/**
* By default, all TurboModules are long-lived.
* Additionally, if a TurboModule with the name `name` isn't found, then we
* trigger an assertion failure.
*/
auto turboModule = [strongSelf provideTurboModule:moduleName];
/**
* TODO(T63718299): Move this setter into the ObjCTurboModule constructor
*/
if (performanceLogger) {
if (auto objCTurboModule = std::dynamic_pointer_cast<facebook::react::ObjCTurboModule>(turboModule)) {
objCTurboModule->setRCTTurboModulePerformanceLogger(performanceLogger);
};
}
```
This diff removes that logic in `RCTTurboModuleManager`, and it also removes `ObjCTurboModule::setRCTTurboModulePerformanceLogger`. Henceforth, we'll instead pass the `id<RCTTurboModulePerformanceLogger>` into `ObjCTurboModule`'s constructor. I've made all the necessary changes to the codegen scripts in this diff as well.
This should also resolve T63903079 by simply eliminating the code that's crashing production FB apps.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D20480971
fbshipit-source-id: c3899981f880aa5d1354b5c3f4018c8fd57c3bae
Summary:
The ['Needs Attention'](https://github.com/hramos/needs-attention) action will remove the "Needs: Author Feedback" label and replace it with "Needs: Attention" whenever the original author of an issue adds a comment.
Removes the `no-response` GitHub integration. The 'close after 21 days' functionality from `no-response` is not present in the 'Needs Attention' action. We'll need to add this back some other way. Considering we were not closing issues that were in the Needs Response state until recently, I think it's OK to proceed here.
## Changelog
[Internal] [CI] - Enable 'Needs Attention' action
Pull Request resolved: https://github.com/facebook/react-native/pull/28338
Test Plan: https://github.com/hramos/needs-attention/issues/1
Reviewed By: cpojer
Differential Revision: D20506380
Pulled By: hramos
fbshipit-source-id: a5a0a7fc330821b7c51aabc0905f520d5caa829a
Summary:
## Description
In T63516227, we're seeing a crash that occurs because `networking.methodQueue` is `nil`, and we try to `dispatch_async` to it.
## Hypothesis
This looks like a problem with NativeModule cleanup:
1. Some JS executes a call to `RCTBlobManager.addNetworkingHander`. This schedules an async method call on the `RCTBlobManager` method queue.
2. In `RCTCxxBridge invalidate`, on the JS thread, we loop through all the `RCTModuleData`s, and invalidate them. This invalidates our NativeModules (perhaps not all but only `RCTNetworking`).
3. The `RCTBlobManager.addNetworkingHander` method call finally executes, with `RCTNetworking`'s methodQueue set to nil, which throws this error.
Changelog:
[iOS][Fixed] - Fix RCTBlobManager cleanup crash
Reviewed By: PeteTheHeat
Differential Revision: D20498096
fbshipit-source-id: d2d60984637ddf883278289258aa9b2ae81bb172
Summary:
Changelog: [internal]
layoutDirectionPass down layoutDirection from `RCTSurfacePresenter` down to `YogaLayutableShadowNode`.
In `ParagraphShadowNode`, we propagate layoutDirection from yoga node to `TextAttributes.layoutDirection`.
Reviewed By: shergin
Differential Revision: D20420041
fbshipit-source-id: 86e01d31ea9415acb8579c44c470cac870ec1b8f
Summary:
Changelog: [Internal]
# Why was it crashing?
Crash was caused by `data.getTrackImageRequest()` returning NULL. The crash happened inside `getCoordinator` method. If you look at the implementation of the method below
```
if (request) {
return &request->getObserverCoordinator();
} else {
return nullptr;
}
```
you might notice that we check for NULL, why is it crashing then? And why is it only crashing in production?
The reason is compiler's optimiser, which looks at `data.getTrackImageRequest()`, this method returns `ImageRequest const &` and sees that this method will always return a value, never NULL. Compiler then looks at our `getCoordinator` function, sees that we check there for nullity but since it can never be null, removes that branch.
# Solution
Create new SliderState with non null image observer.
Reviewed By: shergin
Differential Revision: D20491367
fbshipit-source-id: 17b7cf31feabbe6f8ece324a3d329902b2ef6a2d
Summary:
A few recent imports have explicitly added ".js" to the end of their path. This prevents Metro from resolving platform-specific JS files, e.g. "Foo.android.js" or "Foo.windows.js" instead of "Foo.js".
React Native Windows provides its own implementation of files in a few cases where stock React Native will share them between Android and iOS. We hope to reduce/eliminate these long term, but requiring explicit ".js" files currently breaks us in a couple of places where we have custom implementations.
This change is a quick regex replace of ES6 and CommonJS imports in 'Libraries/" to eliminate ".js".
## Changelog
[General] [Fixed] - Do not explicitly include ".js" in Library imports
Pull Request resolved: https://github.com/facebook/react-native/pull/28311
Test Plan: I haven't done any manual validation of this, but `flow-check` should catch any issues with this during CI.
Reviewed By: cpojer
Differential Revision: D20486466
Pulled By: TheSavior
fbshipit-source-id: 31e1ccc307967417d7d09c34c859f0b2b69eac84
Summary:
Patch for T63997094.
Will still crash in debug mode, and log soft errors, so as not to entirely hide errors.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D20473855
fbshipit-source-id: 8b052b1ae3c886f83d6a7922feb158172cdcd33d
Summary:
We don't need it anymore because the same logic is already implemented in `YogaLayoutableShadowNode::layoutTree()`.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D20464175
fbshipit-source-id: 3dd2293ee102a9b67a856104720d3a7dc4103d7f
Summary:
Changelog: [Internal]
# Problem
SafeAreaView is getting reused, its previous `safeAreaInsets` is top: 44, bottom: 34 so `safeAreaInsetsDidChange` doesn't get called because it doesn't change. Therefore state gets never updates because `safeAreaInsetsDidChange` is never called.
# Solution
Update state whenever a new state is assigned.
Reviewed By: shergin
Differential Revision: D20444198
fbshipit-source-id: 75d1458450c70d74647df4962ddad88d5f6a38d2
Summary:
Changelog: [internal]
# Problem
Assigning `CALayer.contents` implicitly animates the difference. As we keep `UIView` in recycle pool between usages, they keep their previous state. This was causing animation of border when the views were being reused.
# Solution
Wrapping application of mutations in `CATTransaction`.
Reviewed By: shergin
Differential Revision: D20442045
fbshipit-source-id: 214d6c422f23f399dec46b5bf1a38a7b64758160
Summary:
Fixed some url in the code that was outdated.
## Changelog
[Internal] [Fixed] - Fix outdated url in Image Example of RNTester and comment in StyleSheet Type
Pull Request resolved: https://github.com/facebook/react-native/pull/28285
Test Plan: Url can be accessed, and content displayed makes sense.
Differential Revision: D20464293
Pulled By: shergin
fbshipit-source-id: f0c97f7a95ed2a3d6c396cff6cda0bdaab7f5c35
Summary:
Fixes https://github.com/facebook/react-native/issues/28271
As explained by mmallet-youilabs , if the parameters passed to the `move` function are too expensive, this can have an impact on performance. Thus making these parameters captured by value mutable, the parameters are not movable.
## Changelog
[iOS] [Fixed] - Message
Pull Request resolved: https://github.com/facebook/react-native/pull/28297
Test Plan: Steps to reproduce (and expected results) are not applicable (unless running with a profiler).
Differential Revision: D20464278
Pulled By: shergin
fbshipit-source-id: 846a8bc6c61cb4aa21fbd96b419c3775190a2c84
Summary:
This PR is to address https://github.com/facebook/react-native/issues/28200
Even though GeoLocation was extracted from the Core, there are still libraries i.e. the CoreLocation.h library included which cause Apple to reject Apps, as mentioned here.
This removed all references to the CoreLocation library that where remaining.
## Changelog
[iOS] [Removed] - Message
Pull Request resolved: https://github.com/facebook/react-native/pull/28300
Test Plan:
- Flow check passes.
- RNTest built successfully.
Differential Revision: D20441145
Pulled By: shergin
fbshipit-source-id: 03faa4d20dc15cea931b42f34f13814df9c94a01
Summary:
Now we have `zIndex` feature implemented in the Core, we don't need to take `view.layer.zIndex` into account when we do hit-testing, so now we don't need to sort *all subviews* on *all levels of hierarchy* every time we process touch down event.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D20425987
fbshipit-source-id: 025bd968ae948b9b0a4188845efc0de950fb5cdf
Summary:
Now we have `zIndex` feature implemented in the Core, we don't need to have it implemented on the mounting layer.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D20432156
fbshipit-source-id: f77b96919bab21b6628472b9fe58c5f4e3233318
Summary:
Now, having `orderIndex` feature in the core, we can use it for implementing `zIndex` feature. All we need to do is just to assign this `zIndex` value to `orderIndex`.
Then we will use this to remove some platform-specific code that implements `zIndex` on the mounting layer.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D20432155
fbshipit-source-id: b4d62b63006f45899de38e1f40b1dfbe69550ada
Summary:
This behavior matches the behavior of `dynamic_cast` (on which some callsites rely on).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D20456792
fbshipit-source-id: 9604da0f9f78cc7357e60ed11012756e753e4b45
Summary:
This was causing an exception cascade leading to production
errors. Added a test which repros the problem and passes with the
fix.
Changelog: [Internal]
Reviewed By: tmikov
Differential Revision: D20408858
fbshipit-source-id: 3fa9b8669bf3bf7617bfc05ef8f23d52bc969b4e
Summary:
This fixes a bug in Android TextInlineViews that was reproducible in ActivityLog screen, see T63438920
Since Text are virtual nodes it is not necessary for these kind of views to stack views during diffing.
changelog: [internal]
Reviewed By: shergin
Differential Revision: D20448085
fbshipit-source-id: 2d852975493bf6bcc7840c80c5de5cb5f7890303
Summary:
Changelog: [Android] [Added]
Adding:
- OverrideColorScheme interface to AppearanceModule
- setOverrideColorScheme method to AppearanceModule
This allows RN surfaces's color scheme to be overriden by custom theme from the app.
When set, AppearanceModule will use the value from OverrideColorScheme instead of system theme (light/dark)
Reviewed By: JoshuaGross
Differential Revision: D20405810
fbshipit-source-id: 8e562148a75231781649b615fdaf3368beeb477d
Summary:
This method does not have implementation and we don't use it.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D20423392
fbshipit-source-id: cfb5e4a60dbeca26a968c29d20e74dd6af0bf660
Summary:
The current implementation of `Pressability` has a bug related to `onLongPress`.
When a user starts a press gesture, we keep track of the activation position (occurs after waiting `delayPressIn` milliseconds). If the touch moves away from that position by more than 10dp, we rule out the long press gesture. This means no matter how long you hold down the press, even if you move it back to within 10dp, we will not fire `onLongPress`.
However, there is currently a bug where we never reset the cached activation position. This means that after the first press gesture, all subsequent long press gestures must start within 10dp of that first press gesture. This leads to seemingly intermittent missing long press gestures.
This fixes the bug by ensuring that whenever a press gestures is terminated (either via a cancel or release), we reset the activation position.
Changelog:
[General][Fixed] - Fixed Pressability to properly fire `onLongPress`.
Reviewed By: TheSavior
Differential Revision: D20410075
fbshipit-source-id: e4727b7a9585ce3ea39481fc13e56b6b91740c8c
Summary:
We need that to move all `TextShadowNode`s to the end of the list of nodes to make view indexes work for nodes that actually have views.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D20396717
fbshipit-source-id: efbef47ef89ab37e83e020c029c39e1a62727fda
Summary:
The diff introduces a new field in `ShadowNode` which defines in which order ShadowViews created from the node and its siblings will appear ShadowView tree. The feature will be used to overcome some platform limitations (e.g. on Android) on the mounting layer (it will be able to move some nodes of some time to the end (or beginning) of the list) and build features like zIndex ordering in C++ core.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D20396718
fbshipit-source-id: 16aef7c2b5511c874341ab7554e5585b2cdc356f
Summary:
This diff changes how we pass lists of nodes to `calculateShadowViewMutations`: previously we passed that as `const &` and now we pass them as rvalue references because we will need to mute them in the future diffs.
This diff also adds a `static_assert` to ensure that the lists are movable.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D20353754
fbshipit-source-id: 0c3383bff6ded8a49d1ac003fce8919d3906b5bb
Summary:
Apps implementing `UISceneDelegate` no longer clear out images when backgrounded because `UIApplicationDidEnterBackgroundNotification` no longer gets fired.
## Changelog
[iOS] [Added] - UIScene support for RCTImageView
Pull Request resolved: https://github.com/facebook/react-native/pull/28141
Test Plan:
1. Create a new iOS app implementing `UISceneDelegate` or modify an existing one
2. Open a React view with some images
3. Switch to another app, or background the current app
4. Observe that `-[RCTImageView clearImageIfDetached]` gets called
Reviewed By: shergin
Differential Revision: D20009200
Pulled By: hramos
fbshipit-source-id: bdbf79d6cf56a295344c036b9225efec672fa780
Summary:
Switching queues in `RCTLocalAssetImageLoader` is unnecessary. We dispatch to main queue before assigning the image to `UIImageView`.
Changelog: Remove redundant queue switch from RCTLocalAssetImageLoader
Reviewed By: PeteTheHeat
Differential Revision: D20347223
fbshipit-source-id: ff6215838f0462356d4a516e6ec31c82a742881a
Summary:
Allow JS to keep track of mostRecentEventCount and pass it into each event or prop update. We really don't want to separately keep track of that data.
In non-Fabric, the ShadowNode will keep track of the mostRecentEventCount associated to prop updates. In Fabric, that happens on the C++ ShadowNode.
Changelog: [Internal] Simplification to TextInput native state
Reviewed By: mdvacca
Differential Revision: D20374573
fbshipit-source-id: 385fba6ec69a071c78832a686b397699a6c55d67
Summary:
This PR only fixes a little typo that I noticed working on the documentation of React Native website taking reference from this source code, and then saw it 😅
## Changelog
[General] [Fixed] - Fixed typo from `inly` to `only` inside `Modal.js` library code.
Pull Request resolved: https://github.com/facebook/react-native/pull/28057
Test Plan: Not needed.
Reviewed By: cpojer
Differential Revision: D20197178
Pulled By: TheSavior
fbshipit-source-id: 372f263a16a2de665ced7c0d3f10e3897777d19f
Summary:
ViewCommands are sort of like setNativeProps updates, in that they're direct manipulations of Views on-screen that don't go through the normal
commit/diff process that other UI updates do. This is an MVP that shows how we can do this in non-Fabric RN.
Changelog: [Internal] experiment, allow ViewCommands to be executed before other types of UIOperations
Reviewed By: axe-fb, mdvacca
Differential Revision: D20378633
fbshipit-source-id: 5f3c54d3c84b4e4f7cb060a9505b20b0e5b7afed
Summary:
In production, we'd like to be able to track the performance metrics of TurboModules. So, I'm introducing a new protocol called `RCTTurboModulePerformanceLogger`. It allows the application to be notified at points during stages of TurboModule creation, and TurboModule method invocation.
**Why can't we use `RCTPerformanceLogger`?**
`RCTPerformanceLogger` is meant to be used to profile RN initialization. It supports a fixed list of markers. Each marker has a type, and there can only be one instance of it. This isn't suitable for logging events in the TurboModule system.
Reviewed By: mdvacca
Differential Revision: D20310976
fbshipit-source-id: a49251b325c94f912cd35ab1cd8fc010f2cfc08f
Summary:
This can cause a deadlock if the main thread synchronously calls into some JS that creates a TurboModule. However, this is also the behaviour of legacy NativeModules. Furthermore, this also greatly simplifies how we'll fix async method invocation in TurboModules: T55255146.
Changelog:
[Internal]
Reviewed By: fkgozali
Differential Revision: D20364251
fbshipit-source-id: d0db85665506f08c51c2f33a123e69960923e7f3
Summary:
In one of our test apps (actually on Mac not iOS, but same code) we very consistently crash in RCTCxxBridge.executeApplicationScript when js debugging, due to a timing issue where another thread has reset _reactInstance in between the null check on self->_reactInstance and usage of it on these lines:
```
} else if (self->_reactInstance) {
self->_reactInstance->loadScriptFromString(std::make_unique<NSDataBigString>(script),
```
The thread doing the reset is doing so switching the executorClass to WebSocketExecutor.
In the scenario we crash, the packager has a bundle ready and quickly returns it, though its a 34MB string being passed to NSDataBigString which must be taking long enough for the other thread to get a chance to reset.
## Changelog
[iOS] [Fixed] - Fix crash in RCTCxxBridge.executeApplicationScript
Pull Request resolved: https://github.com/facebook/react-native/pull/25991
Test Plan: Ran apple code path in normal from bundle file and js debugging scenarios.
Reviewed By: shergin
Differential Revision: D19186065
Pulled By: hramos
fbshipit-source-id: ae1d4b5b50b7fb33b74aba21addc2978e917479f
Summary:
Changelog: [Internal]
Add one more error around AnimatedValue.js returning an undefined value for "value" property.
Since this error happens in construction of the animated node, it makes sense that the constructor could be passed an undefined value?
Reviewed By: zackargyle
Differential Revision: D20354532
fbshipit-source-id: ba35172cd91977c48c849a2b1e27596c4dd8b4d4
Summary:
Before this change, fields of EmptyLayoutMetrics have some "invalid" values to allow us to compare equal them individually and get `false`. Turned out that having invalid values there might break some serialization layers, which is no good.
This change fixes that and adds explicit check for EmptyLayoutMetrics before running a comparison of individual fields.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D20324881
fbshipit-source-id: ab8e2a402f6bdfb393fc9b6789decb526fa94dfa
Summary:
During some rc releases we have seen the file `gradlew.bat` get diffs from release to release, and sometimes the diff is nothing, except some script messing with the line endings of that file.
According to [this](https://help.github.com/en/github/using-git/configuring-git-to-handle-line-endings#example) and my own experiments using `unix2dos` and `dos2unix` to swap the line endings of that file, this change fixes this problem.
We specify all the `.bat` files should have the Windows line endings.
## Changelog
[General] [Fixed] - Specify line endings of `.bat` files for Windows in `.gitattributes`
Pull Request resolved: https://github.com/facebook/react-native/pull/28274
Test Plan:
To assist with the test, you can use `brew install unix2dos`.
- Init a new project or use an existing one.
- Make sure in your `.gitattributes` of the project and of the user (home dir or `.config/git/attributes` don't have anything about `.bat` files, or `* text=auto`.
- Run `unix2dos ./android/gradlew.bat`.
- Check git status.
- Run `dos2unix ./android/gradlew.bat`.
- Check git status.
- You will notice that the changes when swapping around are the whole file changed.
- Using the changes in this PR, and doing the above, the git status will be no changes, as it should be. The line changes stay Windows-style.
Reviewed By: cpojer
Differential Revision: D20369235
Pulled By: TheSavior
fbshipit-source-id: 4bb6e9f46caecd36211834c7dc3f0e2e64272862
Summary:
Upgrades Flipper to 0.33.1 for both the Android template and RNTester.
## Changelog
[Android] [Changed] - Upgrade Flipper dependency to 0.33.1
Pull Request resolved: https://github.com/facebook/react-native/pull/28275
Test Plan: Still trying to figure out how to get my Gradle setup working again. Until then, CI.
Reviewed By: cpojer, mweststrate
Differential Revision: D20369480
Pulled By: TheSavior
fbshipit-source-id: 048c944819168a352214349f6a83407a587479c9
Summary:
Changelog: [Internal]
# Problem
`scrollView.state.contentOffset` was not in sync with actual `contentOffset` in case `contentOffset` is changed programatically.
# Solution
Add a flag `_isUserTriggeredScrolling` that indicates whether the current scroll is triggered by user or not. In case it isn't, update state.
Reviewed By: shergin
Differential Revision: D20098161
fbshipit-source-id: 021d916e7a45a24095a47bb8f84d1102226b672a
Summary: Added markerDrop API that will replace markerCancel in future.
Reviewed By: furdei
Differential Revision: D20003457
fbshipit-source-id: 38cf68455d9274761a49014d9cbb50d82f4e9437
Summary:
I was unsure how, or if, DecoratedHostObjects worked. Marc had created the linked task to make sure that things worked right with multiple levels of decorated host objects. I decided to do that, thinking it would show a bug; instead it showed me that the pattern did work, and let me figure out how.
Changelog: [Internal]
Reviewed By: mhorowitz
Differential Revision: D20263797
fbshipit-source-id: 8bbe71cba1b6ef5b2673566759112320dd1894b8
Summary:
See D19204032. In some cases the View might not have a ThemedReactContext, it may be wrapped, so we use a previously-created helper to get the correct context from the View or we throw a soft exception.
Changelog: [Internal] Fabric change
Reviewed By: mdvacca
Differential Revision: D20355126
fbshipit-source-id: 469a3b7f8f2d3b98236f3170dd62c4a6e7e1e46f
Summary:
Work around crash in Android TextInput when default colors are null.
This likely indicates that the Context is corrupted in some way, so this is not a permanent solution.
Changelog: [Internal] Raise soft exception is default platform text color isn't defined
Reviewed By: mdvacca
Differential Revision: D20351080
fbshipit-source-id: d912c9348272c2f3a3b8d571d465d482060efe5a
Summary:
Changelog: [Internal]
This solves the problem of viewToAdd indices being invalid if the deletes are asynchronous within the scope of one `manageChildren` call.
Since deletions are performed first, we keep a set of tags being deleted.
During view insertion, we iterate through and filter those tags out of our count.
Reviewed By: JoshuaGross
Differential Revision: D20324643
fbshipit-source-id: 150230428fcd65b8c43cc1f2331e9ce02d31fff9
Summary:
The new name is get_preprocessor_flags_for_build_mode.
Changelog: [Internal]
Reviewed By: d16r
Differential Revision: D20351718
fbshipit-source-id: 67628ce81e7244f0f72af2d00d92842a649ff619
Summary:
This diff changes how we apply layout constraints to a root node before layout. We previously used two arguments of `YGNodeCalculateLayout` but that's not expressive enough in cases we have min & max sizes.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross, sammy-SC
Differential Revision: D20268051
fbshipit-source-id: 85aaae65326432993296c3cbc9f7fb8919b07386
Summary:
This diff introduces a new method of `LayoutableShadowNode` called `measure`. The purpose of the method is to measure the node from an "outside" perspective (including paddings and so on). The existing method with the same name (but with slightly different signature) will be renamed to `measureContent` in future diffs.
Hense we will have two `measure*` methods:
* `measureContent` measures nested content of the node;
* `measure` measures the node (outside).
This diff also introduces a default implementation of a new measure that uses `layoutTree` under the hood.
Measures the node with given layoutConstraints and layoutContext.
The size of nested content and the padding should be included, the margin should *not* be included.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross, sammy-SC
Differential Revision: D20268047
fbshipit-source-id: 29c28cf16c5afe24f1bfb6e76c42816d4583a8fa
Summary:
This diff changes API we use to measure text. Previously, a platform-specific measure infra returned just the size of the text, now it returns the size and an array of frames that describe where attachments are placed.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D20268041
fbshipit-source-id: 7c065607b6af18a36318db0aab24dad0f171d33a
Summary:
`ParagraphShadowNode::Content` describes all nested content of a `Paragraph` component as a single entity allowing to reason about that as a thing that holds an invariant. Now we can store that as a single thing, copy, pass to functions, build on top of that and etc.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC, mdvacca
Differential Revision: D20268043
fbshipit-source-id: e976588ad76615259c72bc21f9ad8d923f2f3b9f
Summary:
These `assert`s must be satisfied. Having them allows us to fail early in case of bugs.
I spent a log of time debugging an issue and finally found that after adding those `assert`s.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D20268046
fbshipit-source-id: 1d8ddd6de00069bd2a79e74af5e4278aa6c9131b
Summary:
Removing `virtual` qualifier for `LayoutableShadowNode::setLayoutMetrics()`. Original design implied that some subclass might override that method to provide additional functionality but we never used that and seems not it does not much the overall design: we store `layoutMetrics` *inside* `LayoutableShadowNode`.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D20268042
fbshipit-source-id: 2aa9b3da316b97f26493fb04d19ca8290bd5d2a6
Summary:
A bunch of convenience functions for rounding float values to be aligned to the device pixel grid. We had something like this on iOS, now we need to have that in xplat C++ code.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D20268044
fbshipit-source-id: 980b61c793eaeafb160e2b3c1d9742402800cd47
Summary:
This diff adds a non-const method to AttributedString that allows accessing a list of fragments by reference.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D20268040
fbshipit-source-id: cd0c8be126607b99686f7f596106b38fbe3da230
Summary:
`BaseTextShadowNode::getAttributedString()` was replaced with simular method `BaseTextShadowNode::buildAttributedString()` which does same work with following differences:
* Besides returning `AttributedString`, it retures an array of `Attachment`s elements of which points to `ShadowNode`s that form attachments;
* Now we use single `AttributedString` to construct result instead of concatenation objects recurvily walking the tree.
We will use the array of attachments later.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D20268048
fbshipit-source-id: 371c548826bdfd5c4f4b18915d68977724885ce6
Summary:
Changelog: [Internal]
Track delete animations and when `manageChildren` is called on a certain view tag, finish all pending deletion animations before manipulating children
Reviewed By: JoshuaGross
Differential Revision: D20319824
fbshipit-source-id: b594d0e6e9b6fecc5eca2938f284be631494e55c
Summary:
Changelog: [Internal]
# Context Timeline
* ~March 2019 landed D14529038 (I'll be referring to this as "index adjustment fix")
which attempted to fix a reproducible issue with layout animations: P127130177, see Spencer's diff for more context: D14245985
* May 2019 I realized that "index adjustment fix" has a bug in it and attempted to fix with D15485132, but was eventually reverted because of other crashes
* Just recently have been getting tasks related to crashes that are attempting to either remove or add a view that is out of bounds which is caused by invalid index because of the "index adjustment fix".
# What is this diff doing?
I'm removing the "index adjustment fix" because I found that the original layout animation repro, P127130177, no longer repros on latest master with the "index adjustment fix" reverted.
Additionally, I've found a consistent crash in (RN bookmark > Sample Integration App > Relay Sample Friends) of a bad view deletion because of the "index adjustment fix"
Removing the index adjustment fix may have effects elsewhere but it seems better to remove this and go back to what layout animations was doing a year ago than to continue on in this half-baked state.
Reviewed By: JoshuaGross
Differential Revision: D20323928
fbshipit-source-id: ba4a222915add00e98a9936ba2a8efc4006fb8e3
Summary:
Fixed some typos in the comment.
## Changelog
[Internal] [Fixed] - Fixed typo in the comments
Pull Request resolved: https://github.com/facebook/react-native/pull/28269
Test Plan: Changes are only made in the comments, so test is not necessary.
Reviewed By: cpojer
Differential Revision: D20342637
Pulled By: shergin
fbshipit-source-id: f6e7dd538ee54c43e1570c35e1f8c4502054e328
Summary:
Upgrade detox version to avoid a crash, per https://github.com/wix/Detox/issues/1947#issuecomment-596547229.
Changelog: [Internal] Upgrade Detox to 15.4.4.
Reviewed By: TheSavior
Differential Revision: D20344541
fbshipit-source-id: a7a3d97b858dbbb13a796dbc3c5c0c47f3ffe556
Summary:
This diff updates the errors thrown by Metro for invalid requires, and fixed a bug in Fast Refresh that was failing to handle errors returned by metro. The net result is that invalid requires are displayed as syntax errors with code frames.
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D20107057
fbshipit-source-id: 59f77aa1da620d2c619a7cc45d90f40ef8b54448
Summary:
Adds `TextKind` trait to Paragraph and TextInput shadow nodes.
Later on it could cause confusion why they do not have this trait.
Changelog: [Internal]
Reviewed By: shergin, mdvacca
Differential Revision: D20254008
fbshipit-source-id: 56fb264fa4fe38a5f00f080558cdc7992fd51fea
Summary:
Investigating a crash, I spend half of an hour staring at `__bridge`, `__bridge_retained`, `CFRelease` and etc trying to understand is there a bug or not. Even if I think there was no bug there, it should not be this way. We have a nice abstraction around that madness we should use to make the code obvious.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D20260917
fbshipit-source-id: 2b511ebf46a78950c4720e749099134aed1dd890
Summary:
Updating react-native-windows to build with Visual Studio 2019 and the v142 toolset.
## Changelog
[Internal] [Fixed] - Fix MSVC build break in VS 2019
Pull Request resolved: https://github.com/facebook/react-native/pull/28253
Test Plan: No real change, only adding a missing include for `stdexcept`.
Reviewed By: cpojer
Differential Revision: D20321273
Pulled By: shergin
fbshipit-source-id: ffe8b4d3a96ce4ed1db303020d77a806637e88bc
Summary:
This diff fixes the rendering of the TextInput RNTester examples in catalyst app.
The root cause of the bug is that we were parsing the props of the text using the TextAttributeProps class, this is incorrect because TextAttributeProps is a holder of the C++ TextAttributes and not TextProps, but the name is confusing.
As a consecuence there was some mistmaches of types during parsing and that was throwing an exception in some examples.
I created the task T63643819 to refactor these classes to make this cleaner.
I'll be working on T63643819 next week, now I want to unblock this bug.
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D20320969
fbshipit-source-id: 7b47546ba4f34df2a7fa151ab200823ea2eeb696
Summary:
We don't know why exactly it happens but (seemingly) sometime Paragraph component receives an empty State object. This causes a crash because of unchecked access to an instance variable.
This diff introduces an assert in DEBUG mode and the check for prod.
Why is this happens? Hard to say, probably `layout()` method (which updates `State`) is not being called on ShadowNode. Why? One explanation can be that Yoga skips some subtree during layout because it starts from "visibility: hidden" component. We need to investigate it more and figure out what exactly going on and what should we need to improve besides the check. That's why we have an assertion.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D20260512
fbshipit-source-id: 4772855f41c6694be2ed6c0a19da40332d2bb8db
Summary:
Instead of comparing the entire AttributedString, compare just the strings and the TextAttributes of Fragments.
Concretely what I'm seeing is that the Frame of the associated parent ShadowViews are changing very frequently, making it impossible to actually modify the TextInput in some cases. However, we shouldn't forcibly reset the content of the TextInput if the frame of the parent is changing and not the actual child contents.
Changelog: [Internal] Fabric TextInput bug fix
Reviewed By: shergin
Differential Revision: D20319359
fbshipit-source-id: 2f51f521ad76fff9da6f6c8b5e795f03c33e496f
Summary:
When any list cell that may contain nested VirtualizedLists is laid out, it's possible that the offset of any child lists relative to the outermost list has changed. We need to tell these children to re-measure themselves relative to that outermost list, so that their viewability calculations are correct.
We already do this for regular list cells -- we just need to extend that logic to any child lists that may live in the ListFooterComponent.
Changelog: [General] [Fixed] - Fix viewability calculations for nested VirtualizedLists inside of a parent list's FooterComponent
Differential Revision: D20310961
fbshipit-source-id: 4bfcfb95c87329f2ee337d5499e5c7162ba692e8
Summary:
In this diff I'm doing the following:
- Deprecating the method UIManagerModule.resolveRootTagFromReactTag
- Removing the callsites to the method UIManagerModule.resolveRootTagFromReactTag
- Refactoring the callsites in order to keep the same behavior for rootTags
- Throwing an exception if this method was being called with a non rootTag
- Controlling this change of behavior with a MC
This is possible because long time ago we refactored all the callsites to this method to ensure we only use rootTag. I'm making extra steps to make sure this deprecation is safe and we don't break production if this method was being called with a non Root Tag.
changelog: [Android][Deprecated] We are deprecating the method UIManagerModule.resolveRootTagFromReactTag, this will not be supported in the next version of RN
Reviewed By: fkgozali
Differential Revision: D20309166
fbshipit-source-id: 8b89ba889313ae03ed543f402b68f1bb4064ca68
Summary:
All `NSNumber *` arguments of NativeModules need to be marked with `__nonnull`. Otherwise, when TurboModules are disabled, we run into a RedBox.
Changelog:
[iOS][Fixed] - Fix RCTDevLoadingView RedBox on Reload
Reviewed By: PeteTheHeat
Differential Revision: D20292188
fbshipit-source-id: a8a5d0b2070575d7728b6308b129196242671fe6
Summary:
As documented in T61647031, Text colors were sometimes not being updated because the ParagraphState was not always updating with a new AttributedString.
Turns out, it's because the equality comparator for Color had not been implemented, and so State was not being set in some cases.
The confusing part is that now color comparisons return true **more often** than before (if you're comparing two smart pointers of opaque data without a custom comparator, in theory I assume they're comparing pointer values and returning false way more often... but maybe my understanding is off). This distracted us for a while in finding an other ~fairly simple solution.
We should keep this in mind if we experience other, similar issues with text attributes not updating.
Changelog: [Internal] Fabric
Reviewed By: mdvacca
Differential Revision: D20300307
fbshipit-source-id: 13d86495f4c4ef8a0219fec66d39a49b4f7e6c2a
Summary:
Similar to the previous diff in this stack, I'm adjusting the React files we use to make sure require and import statements don't get extracted by Jest. Right now Jest extracts them, and when it looks up dependencies in reverse it just ignores the ones that don't exist.
Corresponding React PR (to make sure this change doesn't get reverted during the next sync): https://github.com/facebook/react/pull/18222
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D20282829
fbshipit-source-id: 5ff6a64d31672dd29243d020e8174797a44d9267
Summary:
Someone pointed out in this Github issue: https://github.com/facebook/react-native/issues/27532
that the memory pressure warning from Android was being ignored, when it can easily
be used to start a garbage collection on the JS runtime.
Changelog: [Internal] Add a memory pressure handler for jsi::Runtime
Reviewed By: mhorowitz
Differential Revision: D20072943
fbshipit-source-id: 869a14068aa02bd378e8b26d8c18b76a5d0f7bc0
Summary:
It's not clear why exactly but seems in some cases, for some views the hierarchical relationship between views is required (when it should not be conceptually). Turning this feature off for Android for now.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D20292833
fbshipit-source-id: 1aab8468cedeb5c1440a95944be7eca3216e0db0
Summary:
I noticed that there was a `height` and `width` props in `Image` component, but those props are not being used in `RCTImageView`(ios) or `ReactImageView`(android).
## Changelog
[GENERAL] [Removed] - Remove Unused ImageProp
Pull Request resolved: https://github.com/facebook/react-native/pull/28151
Test Plan: Start a new React Native Project, and use `Image` component with `width` and `height` props and verify that it does not display the image on both iOS and Android
Reviewed By: shergin
Differential Revision: D20197126
Pulled By: TheSavior
fbshipit-source-id: 186119448826659d7c01c7c8a271157228169c30
Summary:
Of course if props aren't changing, rawProps won't have paddings anymore and so padding gets reset.
Also, make sure we pay attention to paddingVertical and paddingHorizontal styles.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D20269583
fbshipit-source-id: 2903fd0f7e6178f506109467d9a8f67b6d013a25
Summary:
Do we need this? Is it possible for any of these codepaths to execute in production? If so, it would be nice to avoid NPEs or even scheduling work on the UI thread.
Maybe we want to add soft exception logging for if these paths are called?
Changelog: [Internal] make sure LogBox does even less work when it's not hooked up
Reviewed By: rickhanlonii
Differential Revision: D20156812
fbshipit-source-id: ba9faedcb3b0951e6913724ca99549dc2d16237e
Summary:
On Android, when changing the props on TextInput component, there are cases where behavior is incorrect.
ex: there were two other PR requests to fix the following issues:
1) TextInput doesnt respect the autoCapitalize prop when keyboardType is set to "default"
2) Password visibility is broken
But those PRs ended up breaking a transition from phone-pad to default
Root cause
- The issue is that the bits that Android defines to store the InputType flags are reused.
- For example, the previous issue: TYPE_TEXT_FLAG_CAP_WORDS and TYPE_NUMBER_FLAG_DECIMAL are both using 0x00002000 bit. So when switching input types from phone-pad to default (text), it is not known if this bit should be cleared. It could have been set for capitalize or for indicating the num pad should be generic.
the solution is to always unset the TYPE_CLASS flags before setting the keyboardType so the user has the correct keyboard.
Changelog: [Fixed] TextInput transition from phone-pad to default
Reviewed By: JoshuaGross
Differential Revision: D20263334
fbshipit-source-id: 0b283fbd6314bf10b90f760917447d2439aaa147
Summary:
This adds support for 'returnByValue' in Runtime.evaluate invocations.
If the result of the evaluation can't be serialized to JSON, the results
are undefined.
ChangeLog: [Internal] - Hermes Inspector now supports 'returnByValue' in CDP Runtime.evaluate calls
[Facebook]
This is change was made to support debug completion in VSCode for ReactVR.
Reviewed By: ArchDev
Differential Revision: D19961115
fbshipit-source-id: d20af82b35d6bde88ab74b5c5a4c07415122c142
Summary:
Marketplace eagerly initializes a few NativeModules. These NativeModules are TurboModule compatible, and the device/user is in the TurboModule test. So these NativeModuels should be returned from the TurboModule system. However, for some reason, we end up doing a lookup on the `NativeModuleRegistry` for these NativeModules.
This means that either:
1. The TurboModuleManager isn't attached to the CatalystInstance
2. The TurboModuleManager returned null from getModule.
These logs will help us get to the bottom of what's going on.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D20260150
fbshipit-source-id: bb554ead412ad3b0fa7502b77f575365608ebc98
Summary:
Add configuration for [no-response bot](https://probot.github.io/apps/no-response/). This will make it so that issues tagged with the "Needs: Author Feedback" are closed after 21 days of inactivity. More importantly, it will make it so that the label is removed whenever the original author of the issue adds a comment.
## Changelog
[Internal] - N/A
Pull Request resolved: https://github.com/facebook/react-native/pull/28202
Test Plan: Verified no-response is enabled for this repository.
Reviewed By: cpojer
Differential Revision: D20256358
Pulled By: hramos
fbshipit-source-id: 51a11e868081afced9ee26640393f08501a8f103
Summary:
{emoji:26a0} This is a follow up to https://github.com/facebook/react-native/issues/25425 -- which isn't merged yet… See https://github.com/facebook/react-native/pull/25919/files/2a286257a6553a80a34e2b1f1ad94fc7bae36ea3..125aedbedc234c65c8d1b2133b79e926ad6cf145 for actual diff
Currently, StatusBar native module manages the status bar on iOS globally, using `UIApplication.` APIs. This is bad because:
- those APIs have been deprecated for 4 years
- Apple really, really wants you to have an explicitly defined view controller, and control the status bar there
- it [breaks external native components](https://github.com/facebook/react-native/issues/25181#issuecomment-506792819)
- it's [not compatible with iPadOS 13 multi window support](https://github.com/facebook/react-native/issues/25181#issuecomment-506690818)
for those reasons I we should transition towards view controller-based status bar management.
With that, there is a need to introduce a default React Native root view controller, so I added `RCTRootViewController`. Using it is completely opt-in and there is no breaking change here. However I believe this should be a part of the template for new RN iOS apps.
Additionally, I added `RCTRootViewControllerProtocol` with hooks needed for RCTStatusBarManager to control the status bar. This means apps that want to have total control over their view controller can still opt in to react native VC-based status bar by conforming their root view controller to this protocol.
## Changelog
[iOS] [Added] - Added `RCTRootViewController` and `RCTRootViewControllerProtocol`
[iOS] [Fixed] - `UIViewControllerBasedStatusBarAppearance=YES` no longer triggers an error as long as you use `RCTRootViewController`
[iOS] [Fixed] - Status bar style is now correctly changed in multi-window iPadOS 13 apps if you use `RCTRootViewController` and set `UIViewControllerBasedStatusBarAppearance=YES`
Pull Request resolved: https://github.com/facebook/react-native/pull/25919
Test Plan: - Open RNTester → StatusBar → and check that no features broke
Reviewed By: fkgozali
Differential Revision: D16957766
Pulled By: hramos
fbshipit-source-id: 9ae1384ee20a06933053c4404b8237810f1e7c2c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/28058
I'm taking the first step towards supporting iOS 13 UIScene APIs and modernizing React Native not to assume an app only has a single window. See discussion here: https://github.com/facebook/react-native/issues/25181#issuecomment-505612941
The approach I'm taking is to take advantage of `RootTagContext` and passing it to NativeModules so that they can identify correctly which window they refer to. Here I'm just laying groundwork.
- [x] `Alert` and `ActionSheetIOS` take an optional `rootTag` argument that will cause them to appear on the correct window
- [x] `StatusBar` methods also have `rootTag` argument added, but it's not fully hooked up on the native side — this turns out to require some more work, see: https://github.com/facebook/react-native/issues/25181#issuecomment-506690818
- [x] `setNetworkActivityIndicatorVisible` is deprecated in iOS 13
- [x] `RCTPerfMonitor`, `RCTProfile` no longer assume `UIApplicationDelegate` has a `window` property (no longer the best practice) — they now just render on the key window
Next steps: Add VC-based status bar management (if I get the OK on https://github.com/facebook/react-native/issues/25181#issuecomment-506690818 ), add multiple window demo to RNTester, deprecate Dimensions in favor of a layout context, consider adding hook-based APIs for native modules such as Alert that automatically know which rootTag to pass
## Changelog
[Internal] [Changed] - Modernize Modal to use RootTagContext
[iOS] [Changed] - `Alert`, `ActionSheetIOS`, `StatusBar` methods now take an optional `surface` argument (for future iPadOS 13 support)
[iOS] [Changed] - RCTPresentedViewController now takes a nullable `window` arg
[Internal] [Changed] - Do not assume `UIApplicationDelegate` has a `window` property
Pull Request resolved: https://github.com/facebook/react-native/pull/25425
Test Plan:
- Open RNTester and:
- go to Modal and check if it still works
- Alert → see if works
- ACtionSheetIOS → see if it works
- StatusBar → see if it works
- Share → see if it works
Reviewed By: PeteTheHeat
Differential Revision: D16957751
Pulled By: hramos
fbshipit-source-id: ae2a4478e2e7f8d2be3022c9c4861561ec244a26
Summary:
Changelog: [Internal]
# Problem
Fabric didn't know about content offset, even though `reactSmoothScrollTo` calls `updateStateOnScroll`, the value of content offset is {0, 0}.
# Fix
Call `updateStateOnScroll` from `reactSmoothScrollTo` with where the scroll view is going to be rather than where it is.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D20248959
fbshipit-source-id: b1da645576dd5e8dce29e7e1d90ab232e0df9fd5
Summary:
# Problem
HorizontalScrollView was not reporting its `contentOffset` to Fabric, therefore `measure` was returning wrong value.
# Solution
Copy over implementation of `updateState` from scrollView. I noticed that there is a lot of duplication between the two classes, that's why I decided to duplicate `updateState` as well.
Changelog: [Internal]
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D20247552
fbshipit-source-id: 48b1eb0c11198a32531effe55301f8d554e92130
Summary:
Currently the error messages lead users to assume that all problems are because we're trying to use the ReactContext too early; it could be because we're using it too late, after it's been destroyed. Because of D17944723, it could be because we're accessing too late, after teardown.
Changelog: [Internal] making some error messages more specific and helpful
Reviewed By: mdvacca
Differential Revision: D20251909
fbshipit-source-id: e236d57e4d7d9c778d41de95160c242bcd69b3c9
Summary: Now, following the previous diff, we remove `LayoutableShadowNode::isLayoutOnly()` and change the view flattening algorithm to rely on two new traits. See the previous diff to learn more about how it works.
Reviewed By: sammy-SC
Differential Revision: D20212252
fbshipit-source-id: 87a07e8bb17b2e66e5703f107dc35ca7a8e49634
Summary:
This diff introduces two new `ShadowNodeTrait`s that we will use in the future in the new (slightly tweaked) view-flattening algorithm. (Note: this diff does not enable the new flattening, it's just preparation.)
The idea is that we split the notion of `isLayoutOnlyView` into two traits:
* `FormsView`: `ShadowNode`s with this trait must be represented as `ShadowView`s. Normal "visible" ShadowNodes will have this trait, but "layout only views" in old nomenclature will not.
* `FormsStackingContext`: `ShadowNode`s with this thread not only must be represented as `ShadowView`s but also have to form a "stacking context" which means that their children must be mounted as `ShadowView`'s children.
Our implementation does not exactly follow W3C spec in terms of sets of props that create the stacking context (because of historical reasons and mobile specifics) but ideologically it's the same. We start from the very conservative implementation where only views with background-color and borders do not form stacking context and then we probably extend that to more props.
Most importantly for us now, we will enforce the absence of ``FormsStackingContext` for `ParagraphShadowNode` and the presence of `FormsView` for `TextShadowNode` on Android where it's essential for mounting layer.
Read more about stacking context here: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Positioning/Understanding_z_index/The_stacking_context
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D20212253
fbshipit-source-id: 0fbaee214ce2c5886cb0232843a2a3c7bb20655d
Summary:
During the development of `Pressability`, I removed the default "press in delay" in order to minimize differences between `Touchable` (as used by `TouchableWithoutFeedback`) and `Pressability`. However, it was a bug that `TouchableWithoutFeedback` zero'd out the default press delay.
This restores the original "press in delay". This will make it so that when users swipe over a pressable element in a scroll view, the scroll view will have time to cancel the touch and prevent a press in behavior (visual jank).
Changelog:
[General] [Changed] - Increase default `delayPressIn` value for `Pressability` to 130ms.
Reviewed By: TheSavior
Differential Revision: D20176152
fbshipit-source-id: 5d6481395ee501bcab20ab98cb46a6be2c423ddf
Summary:
Passing `layoutContext` to yoga crashes fb4a-64. Until I have a solution let's back this out.
Original commit changeset: 9df7da4bef8c
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D20246917
fbshipit-source-id: 220744fde9f74e8157fc0714c63639b01152e4ab
Summary:
Now we tweak more props in order to prepare for new flattening algorithm.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D20212254
fbshipit-source-id: 7391155072f93046e78fbecf4bb4b42cb1caacdc
Summary:
This is a part of migration staterted in D19390813.
There is no need to have those as const. The whole *Props object is usually const (and when it's not, props should not be too).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D20212255
fbshipit-source-id: 87f3d8e7a94c6626bd9b0fc304f75e915dd73d4c
Summary:
I propose this change because we (and a lot of other people, I'd guess) pass an `async` function as a parameter to `onRefresh`. Because the `async` function returns a `promise`, flow is reporting an error. I think the type checking here can be relaxed either all the way to `any` (because RN does not care here what we return) or to `void | Promise<void>` to account for async functions.
looking at https://github.com/facebook/react-native/commit/fb7b2d353356f67a3149c19ad733d46ec6842767#diff-a9c5687ae65236ba3e7f34bfdcdec81d seems like the second is preferred
## Changelog
[General] [changed] - relax RefreshControl's onRefresh flow typing
Pull Request resolved: https://github.com/facebook/react-native/pull/28167
Test Plan: * flow passes
Reviewed By: hramos
Differential Revision: D20196529
Pulled By: TheSavior
fbshipit-source-id: bb5a314bcfb5fb9c8ab71eccb449f1322aeebacb
Summary:
Changelog: [Internal]
Use LayoutContext to pass `fontSizeMultiplier` down to ParagrapShadowNode.
Reviewed By: shergin
Differential Revision: D20184596
fbshipit-source-id: 3965a127069a21328ed19cb3f9732f0a2d1c4d58
Summary:
In order to build dynamic text sizing, `LayoutableShadowNode::measure` needs to accept `LayoutContext`
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D20184598
fbshipit-source-id: 8928b59d51948caf3654f40049212a89a91dceb6
Summary:
In order to build dynamic text sizing, we need to pass layoutContext to `yogaNodeMeasureCallbackConnector`
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D20184597
fbshipit-source-id: 9df7da4bef8cbad3bc87d63ed0c5aa5f420dbc11
Summary:
This diff fixes the RN Android codegen to support null values for Color typed props.
This was already supported but it recently changed as part of D20169335, when we added the new prop type "color".
changelog: [internal]
Reviewed By: TheSavior
Differential Revision: D20213689
fbshipit-source-id: 42d624de3d1296582f4dcc9c7decd0c02aacca98
Summary:
What's changed:
* `end()` now returns the pointer to the imaginary element after the very last one (which is aligned with STL);
* `erase()` now swaps the removing and the last elements and shrinks the size of an array.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D19965405
fbshipit-source-id: 92eedf38d55be35a0d9ab6120634b51c8d6e4674
Summary:
Turns out that dispatchMountItems was reentrant, meaning that something (in particular, updateState) could cause mount items to be queued up which would then be executed synchronously, out-of-order, in the middle of the previous dispatchMountItems call.
We will continue to monitor this and see how often we're reentering: T63181639 and via any soft exceptions that are logged.
For context, there are currently three ways dispatchMountItems gets called: 1) On every UI Tick in the UI thread, in a loop; 2) via animations, via synchronouslyUpdateViewOnUIThread, which happens to fail a *lot* currently; 3) when there is a commit on the UI thread, like with a Java->C++ state update. We must account for reentrance and failure in all three cases and make sure the `mInDispatch` flag is reset after success or failure in all of those situations.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D20170160
fbshipit-source-id: 834f1d9b65000caa7f2eea4849e5e7951d2b6be6
Summary:
In heap snapshots, it was found that really large (20 MB) strings representing network data
were being logged as part of `Systrace.beginEvent` strings from `MessageQueue` in DEV mode.
To combat this, use `JSON.stringify` with limits to keep the depth, strings, arrays, and objects
in check.
Changelog: [Internal] Change `stringifySafe` to have max limits on string size
Reviewed By: yungsters
Differential Revision: D20016501
fbshipit-source-id: e123016557bc154e4210e0b4df44360570da8016
Summary:
D19837753 updated the native platforms to support complex color objects however the diff failed to build when going through this code path (as we do at Facebook).
This updates the automatic PropSetter classes to go through the new Color handler.
Changelog:
[Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: mdvacca
Differential Revision: D20169335
fbshipit-source-id: 8eb9c8b48b1840832b3aec9ffcb83c3cf614ce0e
Summary:
$title
Now that the codegen handles the new PlatformColors, regenerating the checked in native component files.
Changelog:
[Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: mdvacca
Differential Revision: D20175914
fbshipit-source-id: fa7b8e5139dcfe06f49582d7810fae12e1e1fb4b
Summary:
This Pull Request implements the PlatformColor proposal discussed at https://github.com/react-native-community/discussions-and-proposals/issues/126. The changes include implementations for iOS and Android as well as a PlatformColorExample page in RNTester.
Every native platform has the concept of system defined colors. Instead of specifying a concrete color value the app developer can choose a system color that varies in appearance depending on a system theme settings such Light or Dark mode, accessibility settings such as a High Contrast mode, and even its context within the app such as the traits of a containing view or window.
The proposal is to add true platform color support to react-native by extending the Flow type `ColorValue` with platform specific color type information for each platform and to provide a convenience function, `PlatformColor()`, for instantiating platform specific ColorValue objects.
`PlatformColor(name [, name ...])` where `name` is a system color name on a given platform. If `name` does not resolve to a color for any reason, the next `name` in the argument list will be resolved and so on. If none of the names resolve, a RedBox error occurs. This allows a latest platform color to be used, but if running on an older platform it will fallback to a previous version.
The function returns a `ColorValue`.
On iOS the values of `name` is one of the iOS [UI Element](https://developer.apple.com/documentation/uikit/uicolor/ui_element_colors) or [Standard Color](https://developer.apple.com/documentation/uikit/uicolor/standard_colors) names such as `labelColor` or `systemFillColor`.
On Android the `name` values are the same [app resource](https://developer.android.com/guide/topics/resources/providing-resources) path strings that can be expressed in XML:
XML Resource:
`@ [<package_name>:]<resource_type>/<resource_name>`
Style reference from current theme:
`?[<package_name>:][<resource_type>/]<resource_name>`
For example:
- `?android:colorError`
- `?android:attr/colorError`
- `?attr/colorPrimary`
- `?colorPrimaryDark`
- `android:color/holo_purple`
- `color/catalyst_redbox_background`
On iOS another type of system dynamic color can be created using the `IOSDynamicColor({dark: <color>, light:<color>})` method. The arguments are a tuple containing custom colors for light and dark themes. Such dynamic colors are useful for branding colors or other app specific colors that still respond automatically to system setting changes.
Example: `<View style={{ backgroundColor: IOSDynamicColor({light: 'black', dark: 'white'}) }}/>`
Other platforms could create platform specific functions similar to `IOSDynamicColor` per the needs of those platforms. For example, macOS has a similar dynamic color type that could be implemented via a `MacDynamicColor`. On Windows custom brushes that tint or otherwise modify a system brush could be created using a platform specific method.
## Changelog
[General] [Added] - Added PlatformColor implementations for iOS and Android
Pull Request resolved: https://github.com/facebook/react-native/pull/27908
Test Plan:
The changes have been tested using the RNTester test app for iOS and Android. On iOS a set of XCTestCase's were added to the Unit Tests.
<img width="924" alt="PlatformColor-ios-android" src="https://user-images.githubusercontent.com/30053638/73472497-ff183a80-433f-11ea-90d8-2b04338bbe79.png">
In addition `PlatformColor` support has been added to other out-of-tree platforms such as macOS and Windows has been implemented using these changes:
react-native for macOS branch: https://github.com/microsoft/react-native/compare/master...tom-un:tomun/platformcolors
react-native for Windows branch: https://github.com/microsoft/react-native-windows/compare/master...tom-un:tomun/platformcolors
iOS
|Light|Dark|
|{F229354502}|{F229354515}|
Android
|Light|Dark|
|{F230114392}|{F230114490}|
{F230122700}
Reviewed By: hramos
Differential Revision: D19837753
Pulled By: TheSavior
fbshipit-source-id: 82ca70d40802f3b24591bfd4b94b61f3c38ba829
Summary:
Tracing isn't supported in OSS builds, so use `hermes/hermes.h` instead
of `hermes_tracing.h` to avoid pulling in any unnecessary dependencies.
Changelog: [Internal]
Reviewed By: dulinriley
Differential Revision: D20201826
fbshipit-source-id: 4c2977db191bb9a1a82310888a435b761629169b
Summary:
This line was and apparently has always been triggered from the
HermesExecutorFactory. We just didn't notice because we didn't build with
assertions.
Changelog: [Internal] Don't crash on load when assertions and Hermes are enabled
Reviewed By: dulinriley
Differential Revision: D20163138
fbshipit-source-id: af672bb51eeb1833f3e27ad9a00921731c345fc5
Summary:
Changelog: [Internal] Throw error when setting Animated value to undefined.
Background:
ReadableNativeMap removes keys that have undefined values. Somewhere some animation is setting the value to be undefined.
Follow up: Find a way to warn generally that undefined values are being set for maps that become ReadableNativeMaps
Reviewed By: JoshuaGross
Differential Revision: D20169325
fbshipit-source-id: 404b727dc238703ebe5f71a0939340d5f1b3b211
Summary:
Bumps `promise` from 7.1.1 to 8.0.3. The package [hasn't changed significantly between these two versions](https://github.com/then/promise/compare/7.1.1...8.0.3). This is part housekeeping, part making it easier to make PRs to `promise` and then upgrade after they're merged.
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D20094814
fbshipit-source-id: d8933bd39aa3e9f9b19e4d5a09b0828ecc032085
Summary:
Clearing `props` and `state` (which we don't use) allows avoiding retain cycles.
The memory leak was caused by a retain cycle:
AttributedString -> Fragment -> ShadowView -> PharagraphState -> TextLayoutManager -> Cache -> AttributedString.
We don't use `props` and `state` parts of `ShadowView` inside `AttributedString`.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D20182791
fbshipit-source-id: 2ddc5d53a1cb594e3d1cc39933e8958eb6425389
Summary:
We recently bumped our engine requirement in https://github.com/facebook/react-native/issues/28174 but are still installing an older Node version.
## Changelog
[Internal] [Fixed] - Install Node 10 as is required for `test_ios_e2e`
Pull Request resolved: https://github.com/facebook/react-native/pull/28199
Test Plan: `test_ios_e2e` should start building again.
Reviewed By: cpojer
Differential Revision: D20170498
Pulled By: hramos
fbshipit-source-id: 59822c50d38307f69824721db36a2c45185dd248
Summary:
Adding `xcscheme` files for iOS template back in. They were removed in https://github.com/facebook/react-native/issues/26471 after https://github.com/facebook/react-native/issues/25451. We have reverted the change on `.gitignore`, as this directory is supposed to be in git, but we didn't revert the removed files. Now they are back as well.
You can also see here that the two files are still missing, they got removed on rc.0 and are still missing on rc.3.
https://react-native-community.github.io/upgrade-helper/?from=0.61.5&to=0.62.0-rc.3
## Changelog
[iOS] [Changed] - Add `xcscheme` files for iOS template back in.
Pull Request resolved: https://github.com/facebook/react-native/pull/28198
Test Plan: `init` a nre project, and check if the files are there or not. The paths are `ios/MyApp.xcodeproj/xcshareddata/xcschemes/MyApp.xcscheme` and `ios/MyApp.xcodeproj/xcshareddata/xcschemes/MyApp-tvOS.xcscheme`
Reviewed By: cpojer
Differential Revision: D20179447
Pulled By: TheSavior
fbshipit-source-id: b0f08c0f32d6bb7630179bc2fe46d9ac10f6c1d7
Summary:
This diff implements serialization and deserialization of text attachments as part of the calculation of layout of text components
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D20087251
fbshipit-source-id: dbcbd22f856aadace14343205548154ea80c8464
Summary:
ez diff to remove TODO to support inlinew Views in Fabric + venice
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D20088698
fbshipit-source-id: bd7cbbd76a8c13edf94d4eecac0dd670ccd0d209
Summary:
We are currently unintentionally including both libhermes-executor-release.so
and libhermes-executor-debug.so in all OSS RN builds.
RN tries both in turn, but since they both exist and the release executor is compatible
with the debug build, we always get the release executor without debug functionality.
While we sort this out, switch the load order. Since the debug executor is not compatible
with the release build, so it'll fail to load and try the next one.
ChangeLog: [Android] Fix Hermes debugger being disabled by default
Reviewed By: mhorowitz
Differential Revision: D20163828
fbshipit-source-id: ee4d87f40e42a7c8eedfdb7e1fc17eb3e5966ba5
Summary:
Changelog: [internal]
# Problem
We have node A with N children.
Calling cloning constructor on `YogaLayoutableShadowNode` causes new `yogaNode_` to be created.
However if `fragment.children` is nil in cloning constructor, which basically says children were not changed, then the existing children's `owner` becomes invalid.
# Solution
In the clone constructor, always call `updateYogaChildren`. This updates yoga children with the new `owner`.
Reviewed By: JoshuaGross
Differential Revision: D20139582
fbshipit-source-id: 3932694d4381b601df07dd8a57887ce7c09f1582
Summary:
The sizes of attachments are legit parts of `AttributedString`s identity, so we need to incorporate it into the equality test.
We need that to make measurement cache work correctly with inline views.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D20151505
fbshipit-source-id: ae47c24a753eab1e497fcfaa93de557ffb30d874
Summary:
This is a redo of D16969764, with a few extensions.
## Changes
1. Move `RCTDevLoadingView.{h,m}` to `CoreModuels/RCTDevLoadingView.{h,mm}`
2. Extract ObjC API of `RCTDevLodingView` into `RCTDevLoadingViewProtocol` in `ReactInternal`.
3. Create API `RCTDevLoadingViewSetEnabled.h` in `ReactInternal` to enable/disable `RCTDevLoadingView`
Changelog:
[iOS][Added] - Make RCTDevLoadingView TurboModule-compatible
Reviewed By: PeteTheHeat
Differential Revision: D18642554
fbshipit-source-id: 6b62e27e128d98254b7a6d018399ec1c06e274fc
Summary:
Make the Android app bundle size report more legible, and update existing reports if possible.
## Changelog
[Internal] [Changed] - Update existing app bundle size report if possible
[Internal] [Changed] - Generate table for APK sizes report
Pull Request resolved: https://github.com/facebook/react-native/pull/28169
Test Plan:
- App bundle size reports should be updated when possible
- Android apk sizes should be reported using a table
Reviewed By: cpojer
Differential Revision: D20141490
Pulled By: hramos
fbshipit-source-id: 3fc1b808b27e893c0a3e4e34eafc39094448799c
Summary:
`nativeId` type is `NSString`, not `NSNumber`. The `.h` file already has the proper type but `.mm` had a wrong one.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D20135465
fbshipit-source-id: e5f9fbf4940d3883334c910f96f0aa850a069d8c
Summary:
This is step 3 in creating a new DevSupportManager with a better async API for loading the JS bundle from Metro.
Right now DevSupportManagerImpl calls a method on its ReactInstanceManagerDevHelper delegate when the JS bundle is done being downloaded from the server. However, I want to move to a callback-based method for bridgeless mode (similar to packager status). In this diff, I'm adding a protected method that uses a callback, and then calling that from `reloadJSFromServer` with a callback that calls the delegate, to preserve existing behavior.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19871102
fbshipit-source-id: 2dbb6b91c5b927df86c3db42aa11e080d57ea78e
Summary:
This is the second step in creating a new DevSupportManager impl with more async-friendly APIs for bundle loading, which I'll use in bridgeless mode. This diff creates a new interface, AsyncDevSupportManager, and two implementations, mirroring what we currently have.
This new interface doesn't define any methods yet.
Changelog: [Android][Changed] Specify DevSupportManager.setPackagerLocationCustomizer in DevSupportManager impls
Reviewed By: mdvacca
Differential Revision: D19870812
fbshipit-source-id: 042a43e1a3055aba6d7325f948060300b5bf17f3
Summary:
This is the first step for adding my own async APIs for DevSupportManager to use in bridgeless mode.
To avoid having to add these APIs to the DevSupportManager interface + both of its implementations, I'm instead splitting DevSupportManager into a base class + final impl so I can more easily share logic with the new impl I'll create.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D19846619
fbshipit-source-id: c67b0231f4e6581fb484f9a4899ed0b7f08fb684
Summary:
We will soon be enforcing that flow suppressions will only apply when on an error's primary location ([post](https://fb.workplace.com/groups/179614562644215/permalink/559286354677032/)). This diff uses the codemod created in D20008770 to move all suppression comments to their primary locations in the `xplat/js` flow root, and deletes suppression comments that are not on any primary locations.
This diff was generated with:
```
~/fbsource/fbcode/flow/packages/flow-dev-tools/bin/tool suppression-primary-locations --json-file ~/www/errors.json ~/fbsource/xplat/js
hg st -n | xargs grep -l -P '@(partially-)?generated' | xargs hg revert
hg st -n | xargs grep -l 'format' | xargs prettier --write
```
Changelog: [Internal]
bypass-lint
Reviewed By: dsainati1
Differential Revision: D20122544
fbshipit-source-id: d94e409aadb18bb399a1ddbf9f3f2494fe4fb54c
Summary:
Looks like there could be cases when the NativeHirearchyManager may be asking if it should animate on a view that has been removed. Adding a null check
Changelog:
[General] [Fixed] - Check null values in shouldAnimate
Reviewed By: makovkastar
Differential Revision: D20063054
fbshipit-source-id: 5b3b1c27b9aba57a592bd8d4e27a970cf0912b5d
Summary:
Run clang-format and add .clang-tidy with `clang-diagnostic-*` to several more directories in order to catch any problems.
Changelog:
[Internal]
Reviewed By: shergin
Differential Revision: D19860169
fbshipit-source-id: 7785aab010c8e6945cc6b5c9b68cb8ee0cdbb7fa
Summary:
The PlatformConstants native module exposes the ability to query the React
Native version used to build native code. This is managed on iOS and Android by
a version bumping script, which replaces module code based on a template.
It is currently difficult to accurately determine this version for out-of-tree C++
platforms (I.e. React Native Windows). The version of upstream react-native we resolve to is ultimately
dependent on the version of react-native chosen a peer dependency, which is not
neccesarily constant given a build of react-native-windows.
We could try to hack around this, and make our native build try to reason about
the resolved pacakge for react-native using a lockfile, but a much cleaner
solution is to embed version into C++ code, similar to what is done for Android
and iOS. This change does that, adding a header with React Native version and
updating the build stamping script to write to it.
Usage sample:
```c++
constants["reactNativeVersion"] = folly::dynamic::object();
constants["reactNativeVersion"]["major"] = ReactNativeVersion.Major;
constants["reactNativeVersion"]["minor"] = ReactNativeVersion.Minor;
constants["reactNativeVersion"]["patch"] = ReactNativeVersion.Patch;
```
## Changelog
[General] [Added] - Stamp React Native Version Into C++ Code
Pull Request resolved: https://github.com/facebook/react-native/pull/28036
Test Plan: Validated that the bumping script will accurately update the header, can compile under both MSVC and Clang.
Differential Revision: D19865992
Pulled By: hramos
fbshipit-source-id: 9e0b8e9519015bb62c60b9935a234cd367a1926a
Summary:
Changelog: [internal]
# Problem
Implementation of `matricesDiffer` was ignoring first element in the matrix, therefore two matrixes that were different were actually evaluated as same and React didn't pass value to native.
# Solution
Take first element in the matrix into account when comparing matrices.
Reviewed By: cpojer
Differential Revision: D20117210
fbshipit-source-id: 84c3b4e580da44bda4fc8bd8669318282ae9aa32
Summary:
We were already doing this for ViewCommands sent with integer IDs; we should do the same for now with String commands. Otherwise, screens with TextInputs are unusable during development because these exceptions are thrown very often around reload and navigation.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D20127446
fbshipit-source-id: a5d65ff6ae5b520fd0efffa5c325b5cca3bd53a0
Summary:
Cloning subtrees is not something specific to a RootNode, so it makes sense to have it in ShadowNode. Soon we will use that to clone subtrees inside Paragraph component to implement Inline Views.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D20090666
fbshipit-source-id: 0a64ef9bda438cd55d5fd21d3ad83b36221fa89e
Summary:
All logic that is performed on the root node only was moved from `layout` to a separate methods `layoutTree`. That makes the code simpler and allows reusing `layoutTree` in InlineViews feature.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D20052025
fbshipit-source-id: 3070a1cca4e322c6d077ede751ea80359c96a600
Summary:
Similar to a previous diff but for `setChildren`.
`YogaLayoutableShadowNode::setChildren()` was renamed to `YogaLayoutableShadowNode::updateYogaChildren()`. Now we don't need to pass an argument to this function because the object is already initialized. The new name also disambiguates this method with `getChildren()` from `ShadowNode` (which does something completely different). The rest of the changes is just type adjustments.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D20052031
fbshipit-source-id: 6157cad9b55d4cdd97ce04e1278ac1369bfb96bc
Summary:
`YogaLayoutableShadowNode::setProps()` was renamed to `YogaLayoutableShadowNode::updateYogaProps()`. Now we don't need to pass an argument to this function because the object is already initialized. The new name also disambiguates this method with `getProp()` from `ShadowNode` (which does something completely different).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D20052018
fbshipit-source-id: 4d9651bb4452408708fa1b36bb5c5c8639f7d1bb
Summary:
How we can finally make `ViewProps` inherit `YogaStylableProps` and remove `dynamic_cast`. This overall change is aligned with D19963353.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D20052026
fbshipit-source-id: 1066f9a259b50d4672111c9c03a71c2590d59aca
Summary:
Here we delete several constructors that were needed only because `YogaLayoutableShadowNode::yogaStyle` was private (which is not true anymore).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC, mdvacca
Differential Revision: D20052033
fbshipit-source-id: c2afcaf2fdebb65cdcde6c214c8b78aa35d45e91
Summary:
Here we refine the `ShadowNode::BaseTraits` static method. Before this change, ConcreteViewShadowNode<> enforces Layoutable and YogaLayoutable traits. This change moves that responsibility to LayoutableShadowNode and YogaLayoutableShadowNode which makes overall logic more coherent.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D20052027
fbshipit-source-id: fd25264204b0232b1dbbff6f9dfefd9fbcb146c4
Summary:
Now we can move custom to `YogaLayoutableShadowNode` code from `ConcreteViewShadowNode<>` template to `YogaLayoutableShadowNode` itself reducing the amount of templated code and reduce overall complexity.
Note, here we have to do `dynamic_cast` for now, we will address that in coming diffs.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D20052021
fbshipit-source-id: dac5969a97b75e54c7728a1ca8161922bd2245ca
Summary:
The fact that `LayoutableShadowNode` now inherits `ShadowNode` allows us to de-virtualize `getLayoutableChildNodes` and move that to `LayoutableShadowNode`. Less code, less virtual dispatch, less complexity.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D20052032
fbshipit-source-id: 580e86b5a746028e470788e00027f247bf77126c
Summary:
D19963353 mentioned the infrastructure that re-routes methods calls related to adding and cloning children between YogaLayoutableShadowNode and ShadowNode. `cloneAndReplaceChild` is exactly this. It was implemented as a virtual method that is called from `ConcreteViewShadowNode`. The whole process requires building a list of children of some class and passing that as a list of pointers. Now we don't need it all that because we can call directly and statically. That change will allow us to simplify that infra even more in the future diffs.
With all previous changes, now we can implement `getYogaLayoutableChildren` inside `YogaLayoutableShadowNode` and call that statically. Eventually, that will allow us to remove templated `getChildrenSlice`. Previously the call for that method must be in `ConcreteViewShadowNode`, now it's not true anymore which we will use later to even better goodness.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D20052020
fbshipit-source-id: e5c819a4d21b2dbcd08f3439e1783e3a9cba5ef4
Summary:
D19963353 mentioned the infrastructure that re-routes methods calls related to adding and cloning children between YogaLayoutableShadowNode and ShadowNode. `cloneAndReplaceChild` is exactly this. It was implemented as a virtual method that is called from `ConcreteViewShadowNode`. The whole process requires building a list of children of some class and passing that as a list of pointers. Now we don't need it all that because we can call directly and statically. That change will allow us to simplify that infra even more in the future diffs.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D20052022
fbshipit-source-id: ddf341c112edd8a2f79eaf74465a9a360a168541
Summary:
This is another perf-critical place where using traitCast should help with perf.
After this change we practically will not have any `dynamic_cast`s (except those which will be delited (with methods where they are used) in the future diffs).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D20052029
fbshipit-source-id: 63b589d3c3322f0afd72f18b4701fe31d0e05c2f
Summary:
We use this function in Diffing, and Diffing is one of the hottest pieces of Fabric. Removing `dynamic_cast` here should improve perf. See the previous diff for more details.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D20052023
fbshipit-source-id: d6427ebf076d7f8244f0aeaf16407efa2368957e
Summary:
The Diffing is one of the hottest pieces of Fabric. Removing dynamic_cast here should improve perf. See the previous diff for more details.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D20052030
fbshipit-source-id: 27fd9f34f2a1f9d22b9da6b1e3c1a2982045c07a
Summary:
`traitCast` is a special form of static_cast that checks additional requirements (similar to `dynamic_cast`) before performing the cast. We will use that in many places in the coming diffs.
Restructuring the class hierarchy in the previous diff finally allows us to do static casts among ShadowNode and LayoutableShadowNode and other classes (previously it wasn't allowed because of lack of common base class).
Why we don't want to use `dynamic_cast`:
* It's expensive (and we need to do the cast on the hottest fragments of the framework). (See: (1) http://www.stroustrup.com/fast_dynamic_casting.pdf and (2) https://www.youtube.com/watch?v=ARYP83yNAWk Herb Sutter & proposal of `down_cast`).
* It's code-size inefficient, whereas `static_cast` has zero runtime and code-size overhead.
* Removing `dynamic_cast` will allow us finally to opt-out `RTTI` (additional code size and perm wins).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D20052024
fbshipit-source-id: d293c1cf80deb7817d333d5306d6b32bf3abdb27
Summary:
This is a very crucial change, everything else in this stack depends on it.
Here is the set of constraints that we have for ShadowNode-based class hierarchy:
* `ShadowNode` is a base class that defines basic operations on the nodes. It does not have virtual methods by design (virtual dispatch hurts performance; we want to limit and centralize that in `ComponentDescriptor`s).
* `ConcreteShadowNode<>` template *statically* wires particular `ShadowNode` and particular `Props` establishing a type-safe relationship between them ensured on compile time.
* Not all `ShadowNode`s are "layoutable", not all "layoutable" `ShadowNode`s use Yoga to do layout.
* Layotability (and YogaLayotability) feature is implemented as two classes `LayoutableShadowNode` and `YogaLayoutableShadowNode`. These classes essentially need to know something about the ShadowNode nature of the object (get the list of children or replace some children).
Before the change, `LayoutableShadowNode` and `YogaLayoutableShadowNode`classes did not inherit `ShadowNode` because we don't want to use *virtual inheritance* for `ShadowNode`: `ConcreteShadowNode<>` already inherits `ShadowNode`, so if we make `LayoutableShadowNode` inherits `ShadowNode`, we will have to somehow flatten this inheritance hierarchy (and the virtual inheritance is an answer to that). (Yes, C++ supports multiple inheritance and virtual inheritance.)
Before this change, we solved this dilemma this way: We have a subclass-template `ConcreteViewShadowNode<>` that inherits `ConcreteShadowNode<>` and `YogaLayoutableShadowNode`. Then, we had a bunch of methods that implement the rerouting of some functionality from `YogaLayoutableShadowNode` to `ShadowNode` and vise-versa. (See the diagram "Before".)
That worked fine, except the caveats:
* That wiring is nasty, complex, hard to reason about and overall limiting.
* There is no way to statically cast `LayoutableShadowNode` to `ShadowNode` (because there is no common base class). That forces us to use dynamic_cast on some perf critical paths (including layout, diffing and so on).
* Adding features that rely on interop between `LayoutableShadowNode` and `ShadowNode` is a nightmare.
It should be a better way to deal with this dilemma, and this diff implements a different approach: We can have a base class of `ConcreteShadowNode<>` as a template parameter. With this approach, we can make `LayoutableShadowNode` inherit `ShadowNode` and when we need to instantiate a `ConcreteShadowNode<>` that needs to be layoutable, we can just specify `YogaLayoutableShadowNode` as a base class. (See the diagram "After".)
This simple change will allow us to simplify a lot of things. The rest of the stack is about getting rid of unnecessary moving parts. Which will finally allow us to build "Inline Views" feature.
```
╭──────────────────────╮
│ ◎ ○ ○ ░░░░░░░░░░░░░░░│
├──────────────────────┤
│ │
│ │
│ Before │
│ │ ┌────────────────────────────┐ ┌────────────────────────────┐
│ │ │ │ │ │
│ │ │ ShadowNode │ │ LayoutableShadowNode │
└──────────────────────┘ │ │ │ │
└────────────────────────────┘ └────────────────────────────┘
▲ ▲
│ │
╔════════════════════════════╗ ┌────────────────────────────┐
║ ║ │ │
┌────────�║ ConcreteShadowNode<> ║ │ YogaLayoutableShadowNode │
│ ║ ║ │ │
│ ╚════════════════════════════╝ └────────────────────────────┘
│ ▲ ▲
│ │ │
│ │ │
│ │ │
│ │ ╔════════════════════════════╗ │
│ │ ║ ║ │
│ └─────║ ConcreteViewShadowNode<> ║─┘
│ ║ ║
│ ╚════════════════════════════╝
│ ▲
│ │
│ ┌──────────────┴───────────────┐
│ │ │
│ │ │
│ │ │
┌────────────────────────────┐ ┌────────────────────────────┐ ┌────────────────────────────┐
│ │ │ │ │ │
│ TextShadowNode │ │ ViewShadowNode │ │ ParagraphShadowNode │
│ │ │ │ │ │
└────────────────────────────┘ └────────────────────────────┘ └────────────────────────────┘
╭──────────────────────╮
│ ◎ ○ ○ ░░░░░░░░░░░░░░░│
├──────────────────────┤
│ │ ┌────────────────────────────┐
│ │ │ │
│ After │ │ ShadowNode │
│ │ │ │
│ │ └────────────────────────────┘
│ │ ▲
└──────────────────────┘ ┌────────────────────────────────────┤
│ │
│ ╔════════════════════════════╗
┌────────────────────────────┐ ║ ConcreteShadowNode ║
│ │ ║ <Base: ShadowNode> ║
│ LayoutableShadowNode │ ║ ║
│ │ ╚════════════════════════════╝
└────────────────────────────┘ ▲
▲ │
│ ┌────────────────────────────┐
┌────────────────────────────┐ │ │
│ │ │ TextShadowNode │
│ YogaLayoutableShadowNode │ │ │
│ │ └────────────────────────────┘
└────────────────────────────┘
▲
│
╔════════════════════════════╗
║ ConcreteShadowNode ║
║ <Base: ║
║ YogaLayoutableShadowNode> ║
╚════════════════════════════╝
▲
│
╔════════════════════════════╗
║ ║
║ ConcreteViewShadowNode<> ║
║ ║
╚════════════════════════════╝
▲
├─────────────────────────────────────┐
│ │
┌────────────────────────────┐ ┌────────────────────────────┐
│ │ │ │
│ ParagraphShadowNode │ │ ViewShadowNode │
│ │ │ │
└────────────────────────────┘ └────────────────────────────┘
```
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D19963353
fbshipit-source-id: b65c8a5064bdb54ab64f08a8e546aa9e2b5a486b
Summary:
We are moving towards 100%-prettified files. That's another step when we apply Clang Format for `React/Fabric`.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D20112417
fbshipit-source-id: 020d818e5cb8e2f509c5276738c8f252f6817a56
Summary:
Note: I'm currently testing this, so do not review just yet.
Adding a nightly CI build in preparation for further work on [React Native: Benchmark Suite](https://github.com/react-native-community/discussions-and-proposals/issues/186.)
Currently it will only run the job `nightly_job` which will simply run `$ echo "Nightly build run"`. The plan is to do nightly checks and performance status on the React Native repo, and create a dashboard where we can see performance changes over time. More on this in the proposal: [React Native: Benchmark Suite](https://github.com/react-native-community/discussions-and-proposals/issues/186.)
## Changelog
[General] [Added] - Add nightly CI build
Pull Request resolved: https://github.com/facebook/react-native/pull/28066
Test Plan: Individual jobs will have their own test plan.
Reviewed By: sebmck
Differential Revision: D20008434
Pulled By: hramos
fbshipit-source-id: a5e8aad616c28bfad8f3455b5ebadf7a7d174a55
Summary:
For backwards-compatibility with Paper, we're implementing a feature in Fabric that will allow TextInputs to use the default padding from the theme in Android.
Note that this uses some pretty ugly hacks that probably shouldn't be used inside of components at all: looking directly at rawProps, overriding props/Yoga styles in the component descriptor, etc. I would (personally) really like to kill this feature entirely unless and until we can find a more elegant solution.
Changelog: [Internal]
TextInputs are still not pixel-perfect with Paper, but they're much closer, and the underline visual glitchiness is no longer an issue.
Reviewed By: mdvacca
Differential Revision: D20109605
fbshipit-source-id: 543282843e0a9f03a504d72d7a014431099bd64c
Summary:
Used the deploy_xplat.sh script.
There were a few errors after running the script, so I reverted the changes to those files and the errors went away. This is expected because the new version does not introduce errors, so these errors were caused by the deploy script.
Changelog: [Internal]
Reviewed By: samwgoldman
Differential Revision: D20070916
fbshipit-source-id: 56b8f56eab952010f44219ce1b5c4ec66a0b084a
Summary:
Upgrade detox version so the codec of the recording of the iOS simulator can be specified.
Changelog: [Internal] Upgrade Detox to 15.4.0
Reviewed By: hramos, TheSavior
Differential Revision: D20079348
fbshipit-source-id: 4effc040286b92b468550fdbec1a2373339134d1
Summary:
Changelog: [Internal]
As agreed in https://fb.quip.com/Oh2mAaTAbBj6, `findNodeAtPoint` now calls callback with `shadowNode` instead of `instanceHandle`.
Reviewed By: shergin
Differential Revision: D20097269
fbshipit-source-id: bd2a1bcd26ab2510f16c3e73f628be4b1f7dacfc
Summary:
Changelog: [Internal]
# Problem
Calling `UIManager::updateState` does not increment state revision because it calls `ConcreteComponentDescriptor::createState` which creates new state with state revision 1.
# How did this propagate?
This error propagated itself in TextInput when trying to input a value, you would be only allowed to type in 1 character.
Reviewed By: JoshuaGross
Differential Revision: D20072844
fbshipit-source-id: 37b8173307e1d91d6e9c41b5ff2e185dde31cc38
Summary:
Some dependencies don't need to be downloaded by consumers:
- `connect` is only used in RNTester, moved to dev dependencies
- `escape-string-regexp` is not used directly, removed
- `eslint-plugin-relay` was in both deps and dev deps, removed from deps
Overall, this results in node_modules being 3.3MB smaller on clean install.
cc cpojer as you may already be aware. Feel free to treat these as a reference when optimizing internal deps.
## Changelog
[Internal] [Changed] - Remove connect, escape-string-regexp, eslint-plugin-relay deps
Pull Request resolved: https://github.com/facebook/react-native/pull/28171
Test Plan: CI passes
Reviewed By: hramos
Differential Revision: D20097591
Pulled By: cpojer
fbshipit-source-id: 0800751996accf39fd777bc6458be19f66f436a3
Summary:
Upgrading CLI to latest. alloy should have done a local commit on the 0.62 branch and this pr is just meant to sync the status between master and 0.62 branch.
cc grabbou alloy
nit: it seems that the new 4.1.1 CLI version pulls in quite a bit of dependencies, I hope it's ok. It seems it's mostly because of `pretty-format`.
## Changelog
[Internal] [Changed] - Bump CLI to ^4.1.x
Pull Request resolved: https://github.com/facebook/react-native/pull/28172
Test Plan: None
Reviewed By: hramos
Differential Revision: D20097587
Pulled By: cpojer
fbshipit-source-id: ec95498ced374d1e4e6b696f2167fedf66395ac9
Summary:
We are moving towards 100%-prettified files. That's the first step when we apply Clang Format for `ReactCommon`.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D20110895
fbshipit-source-id: 0a0ce4997cf1c3721b0b07ef78c1a57ce87d20f9
Summary: The `Function::call` method says it leaves the JS `this` object undefined. According to my tests, that's not completely true: if the function is defined to use strict mode via `"use strict"` either inside itself or in the file it was defined in, it does leave it `undefined`, but if the function is defined in non-strict mode, it sets `this` to the global object instead. This diff updates the documentation to reflect this.
Reviewed By: mhorowitz
Differential Revision: D19613483
fbshipit-source-id: 4b9ecf81c6318592be05a216748dcb22e32989f8
Summary:
This diff:
1. Updates `update-specs.js` to also check in the JNI TurboModules codegen output.
2. Updates all the checked in OSS codegen.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19907536
fbshipit-source-id: 179e01aff05f4c970c20f1482f096dbca10caed3
Summary:
This diff disables the rendering of TextInlineViews in ClassicRN when the users is running with Fabric enabled.
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D20087254
fbshipit-source-id: b4664b17b4c845d212f72e75eee58860fe31abee
Summary:
This diff changes the Fabric measure API in order to support attachments parameters
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D20087252
fbshipit-source-id: 20e1526aaa3695d38d0805416df8a32adb8296ad
Summary:
Changelog: [Internal]
If `layer.mask` was set and the view got reused without having a different `layer.mask`, this value would persist between reuses.
I also added a call to `super finalizeUpdates` as it is best practice to call super, the parent class right now doesn't do anything but in the future we might add there some default logic.
Reviewed By: shergin
Differential Revision: D20030174
fbshipit-source-id: c90be3f4e9a8f3814000f177a3d50061f5aa120c
Summary:
Changelog: [Android] [Changed] - Internal storage now will be preferred for caching images from ImageEditor.
Now we try to write to internal cache directory first.
If that fails (due to no memory error or other IOException), we attempt to write to external storage (if that is allowed).
I introduced additional configuration flag, `allowExternalStorage` which is true by default.
And i updated documentation for new behaviour - see
`ImageEditor.cropImage(..)` comment.
Reviewed By: makovkastar
Differential Revision: D19878158
fbshipit-source-id: 7e338ce68f535f74c62b5eecd5a94af7e7396f8b
Summary:
Right now the code frame and stack trace for metro errors are useless. This diff improved these errors by showing the metro code frame for the source of the issue, and stripping the stack trace.
Ideally we could show the metro stack trace as well, but since stack traces are tightly coupled to symbolication (and metro source code does not need symbolicated, nor could it be), this is an acceptable incremental improvement.
Arguably, even showing the code frame is inappropriate and we should show a generic crash screen with reload and report buttons.
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D20057353
fbshipit-source-id: 5e999cea14c1cbd2f69737e3992a3e8d159fdf89
Summary:
Until now, there were two measure functions that differ in only one parameter (rootTag). The rootTag is used to use the context associated to the tag as part of the calculation of layout, otherwise it just uses the ReactApplicationContext.
This diff unifies both method into an unique method that
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D20081281
fbshipit-source-id: b1f6a6cedbf78f36f36fd0f93407c23c6996d76b
Summary:
Use codegen'd ViewCommands added in previous diff as a replacement for setNativeProps.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18619298
fbshipit-source-id: 08069e828e92ac3cca9813bbcdca99d99fb50883
Summary:
The migration from classy to functional component partially broke controlled TextInput selections. This fixes it.
The nuance is that even though we have "event counters" sent from native, "onChange" and "onChangeSelection" are separate events;
so even if you receive new text and a new native event counter, your selection may be out-of-date. Incrementing the event counter
when sending selection events breaks text updates; and adding another native event counter seems like overkill. Instead, in JS, we statefully
keep track of (1) the native event counter, (2) whether or not the selection has been updated for that event counter.
Changelog: [internal]
Reviewed By: mdvacca
Differential Revision: D18867152
fbshipit-source-id: c569ecd03ce0042d6feb5fa8af4c756588607a09
Summary:
I think this NativeModule was converted before we checked in the Java codegen output for TurboModules. I'm making `DeviceInfoModule` extend `NativeDeviceInfoSpec` to properly make it a TurboModule.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D19911145
fbshipit-source-id: fcec8c5b991bd9fd991e690dfa51f1bd36117e5f
Summary:
We recently updated React Native's docs site to have its own domain reactnative.dev and needed to update the URLs in the source code
CHANGELOG:
[INTERNAL]
Reviewed By: hramos
Differential Revision: D20072842
fbshipit-source-id: 1970d9214c872a6e7abf697d99f8f5360b3b308e
Summary:
Removed an array.slice() call in the callImmediatesPass, which seems unnecessary to me, as the variable is immediately re-assigned on the next line.
Also fixed some flow issues, clarified a systrace marker and opensourced the relevant tests.
Changelog: [Internal] [Fixed] Improved JSTimer efficiency
Reviewed By: yungsters
Differential Revision: D20039181
fbshipit-source-id: 9b146980e8fa9f94b2f6153cc67cc7ced58104e5
Summary:
This diff disables preallocation of virtual nodes, I'm doing this as an intermediate step to eradicate virtual nodes from the android mounting layer.
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D20048996
fbshipit-source-id: 8fe0b03bcfcfd83a3093d1503ac93a20a5e9a57e
Summary:
This diff extends the MountingManager to not fail when trying to update event emitter of a non created view. This is necessary as intermediate step to remove virtual nodes out of the RN Fabric Android
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D20048998
fbshipit-source-id: c2a3633400ac67c2f46ec52ed3ad80289ff6aeb9
Summary:
This diff cleans up mobile config and ReactFeatureFlags that are not used anymore
changeLog: [internal]
Reviewed By: JoshuaGross, makovkastar
Differential Revision: D20026794
fbshipit-source-id: 3d941db195075a9cf49b7ecc0bf1ee839fcca189
Summary:
This diff enables support for TextInlineViews with dynamic sizes by default, removing old code and calls to MCs.
changelog: [internal]
Reviewed By: JoshuaGross, makovkastar
Differential Revision: D20026795
fbshipit-source-id: 48adf356b418866d937be9b478d9186342a07de8
Summary:
This diff fixes whitespace trimming in codeframes by setting the whitespace size to 0 instead of infinity for lines that's don't have whitespace. This fixes a bug in frames where lines with 0 whitespace would not be considered.
So frames like this, where the common whitespace should be 0:
```
217 | function Hi(a?: String) {
> 218 | return Platform.OS === 'android' ? obj.die() : obj.die();
| ^
219 | }
220 |
221 | export default CrashReactApp;
```
Are instead trimmed at the second most common whitespace, which is 2. That's because line 217 has a whitespace length of 0, but we consider it as Infinity. When we get to line 218, we set the whitespace to 2. Then on line 19 we consider if 2 < Infinity and decide that the common whitespace is 2 resulting in:
```
217 | nction Hi(a?: String) {
> 218 | return Platform.OS === 'android' ? obj.die() : obj.die();
| ^
219 |
220 |
221 | port default CrashReactApp;
```
By setting the whitespace per line to 0 when there's no whitespace match, lines without whitespace can accurately report their size and move the pointer back to the 0 position.
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D20030301
fbshipit-source-id: f1dec8cc57479f37ffa8128f93f7c8b3c6baaf91
Summary:
This diff interpolates logs before passing them downstream so that we don't see a bunch of logs with "%s" everywhere.
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D20034903
fbshipit-source-id: 966917aa21ba07af3fb114e6a6931d4bbf860040
Summary: Switching SwipeRefreshLayout to use the bridgeless-friendly API for getting the EventDispatcher.
Reviewed By: mdvacca
Differential Revision: D20016310
fbshipit-source-id: 2f674f45768640fb6219df690fa34f74206fdf19
Summary: Right now, animations don't work on Android in bridgeless mode because NativeAnimatedModule directly uses the UIManagerModule for various things. Previously, I added a bridgeless check to the module's `initialize()` method to avoid adding a listener on the UIManager; in this diff, I'm moving that check so that we also skip adding the lifecycle listener on the context in bridgeless mode, too. I'll remove this check once we come up with a replacement for the UIManagerModule API.
Reviewed By: JoshuaGross
Differential Revision: D19964171
fbshipit-source-id: 7c461f535e370b0e607c28905c505239cce0e157
Summary:
*Pressable* is a component which is intended to replace the Touchable* components such as *TouchableWithoutFeedback* and *TouchableOpacity*. The motivation is to make it easier to create custom visual touch feedback so that React Native apps are not easily identified by the “signature opacity fade” touch feedback.
We see this component as eventually deprecating all of the existing Touchable components.
Changelog:
[Added][General] New <Pressable> Component to make it easier to create touchable elements
Reviewed By: yungsters
Differential Revision: D19674480
fbshipit-source-id: 765d657f023caea459f02da25376e4d5a2efff8b
Summary:
Fabric debugging.
I also have an agenda of removing all instances of `ReactConstants.TAG`, because it's overly broad and not helpful during debugging.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D20016401
fbshipit-source-id: 91e5cd7e8eb662b1a4a887c1e4e66a31ec741b46
Summary:
motivation: there are cases where one'd like to control the radius of the ripple effect that's present on TouchableNativeFeedback - in my case, I want to make sure that both icons and text have the same ripple appearance, but that's currently not possible as far as I can tell.
Currently (afaik) the only way to set (upper) ripple limits is by specifying width, height and border radius ( + `overflow: hidden`), and this works well for icons which can usually be bounded by a square, but not for text which can have rectangular shape.
This PR adds `rippleRadius` parameter to `SelectableBackground()`, `SelectableBackgroundBorderless()` and `Ripple()` static functions present on `TouchableNativeFeedback`. It can make the ripple smaller but also larger. The result looks like this:
added to RNTester:
difference from the other ripples:
I'm ofc open to changing the api if needed, but I'm not sure there's much space for manoeuvring. While I was at it, I did a slight refactor of the class into several smaller, more focused methods.
It's possible that in some cases, this might help to work around this issue https://github.com/facebook/react-native/issues/6480.
## Changelog
[Android] [Added] - allow setting custom ripple radius on TouchableNativeFeedback
Pull Request resolved: https://github.com/facebook/react-native/pull/28009
Test Plan: I tested this locally using RNTester
Reviewed By: TheSavior
Differential Revision: D20004509
Pulled By: mdvacca
fbshipit-source-id: 10de1754d54c17878f36a3859705c1188f15c2a2
Summary:
Addresses deprecation warnings from `octokit/rest`. This is a follow up to https://github.com/facebook/react-native/issues/28019.
## Changelog
[Internal] [Fixed] - Address deprecation warnings from `octokit/rest`
Pull Request resolved: https://github.com/facebook/react-native/pull/28050
Test Plan: PRs should still get app bundle sizes report, but the warnings in the build logs should be gone.
Reviewed By: cpojer
Differential Revision: D20008805
Pulled By: hramos
fbshipit-source-id: 891d14fd9d55f217194a095d2736494416dacda2
Summary:
As we don't link modules manually anymore it's better to point the user in another direction when they face this issue.
## Changelog
[Internal] [Changed] - tweak missing RCTAnimation warning message
Pull Request resolved: https://github.com/facebook/react-native/pull/28139
Reviewed By: cpojer
Differential Revision: D20009264
Pulled By: hramos
fbshipit-source-id: 114cae4fe908186eab3d8d9e79c2016015406821
Summary:
The accessibility roles and states description strings are not able to be localized on iOS platform. Those strings are exposed to the end users so it should be localized. This PR is to add localized strings as a resource bundle to the React Core Pod so that any React Native app integrating the React Native dependencies using CocoaPods can get the localized accessibility roles and states description.
## Changelog
[iOS] [Added] - Add localized accessibility strings to React Core pod
Pull Request resolved: https://github.com/facebook/react-native/pull/27995
Test Plan: Verified with RNTester app.
Differential Revision: D19975587
Pulled By: PeteTheHeat
fbshipit-source-id: f8eb4e25194f0cd603c98a6221ec87503a2826ed
Summary:
`AccessibilityInfo.isScreenReaderEnabled().then()` fails by default in tests because that function is mocked and it doesn't return a promise (the default return value is `undefined`). Returning `Promise.resolve(false)` is a good default in this case so it doesn't break any code relying on it.
Changelog: [General] [Fixed] - Fix `AccessibilityInfo.isScreenReaderEnabled` mock in Jest setup
Reviewed By: lunaleaps, motiz88
Differential Revision: D19972921
fbshipit-source-id: 3c8498d5aeeac54d1f5cf333ae39658e22c180a1
Summary:
The [PlatformColor PR](https://github.com/facebook/react-native/pull/27908) is currently open to implement the [PlatformColor proposal](react-native-community/discussions-and-proposals#126). When that PR was imported into Facebooks internal builds it was found that the change to the `processColor()` function to return an opaque type or `number` instead of just `number` breaks internal components.
This PR is a simplification of the PlatformColor PR only changing the return type of `processColor()` from `?number` to `?number | NativeColorType` where `NativeColorType` is just an empty but opaque type. This will allow changes to be made to these internal components but with less risk than the larger PR.
## Changelog
[General] [Changed] - Add NativeColorType opaque type to normalizeColor() ahead of PlatformColor PR
Pull Request resolved: https://github.com/facebook/react-native/pull/28040
Test Plan: Flow checks, Jest test, iOS unit tests, iOS integration tests, and manual testing performed on RNTester for iOS and Android.
Differential Revision: D19860205
Pulled By: TheSavior
fbshipit-source-id: 799662c6621d3974158b375ccccfa136982c43b4
Summary:
This method isn't necessary for the migration to LogBox because we have a YellowBoxDeprecated module instructing users to use LogBox.ignoreLogs (so no old code should be calling LogBox.ignoreWarnings).
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D19950302
fbshipit-source-id: 4850884e770f812273978b9a205f5b914e5a9d2f
Summary:
This diff replaces YellowBox with YellowBoxDeprecated, adding warnings for using the module directly instead of YellowBox. Also adds a no-op message for unstable_enableLogBox.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D19949700
fbshipit-source-id: 269c341a2cedcdb2f7a80947d3239db078238201
Summary:
This diff replaces YellowBox with LogBox so that it can be deprecated and removed.
After this diff, it will no longer be possible to go back to YellowBox and all paths referencing it will be gone.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D19949695
fbshipit-source-id: 28a55866e514020bdcc6854aae565cffbbe8af58
Summary:
Make iOS use Commands instead of UIManager.{focus,blur}. This makes these apis compatible with Fabric and paper at the same time.
Changelog:
[Internal] Switch iOS focus/blur calls to use new commands
Reviewed By: mdvacca
Differential Revision: D19458995
fbshipit-source-id: 8c4aacd41941f54a887aeec1a17d9ce0b6878ab1
Summary:
This makes Android dispatch focus/blur through the Fabric view manager when running in Fabric.
Changelog:
[Internal] Switch Android focus/blur calls to use new commands
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D19458362
fbshipit-source-id: 23e1d989ec55bc8abff4279e259f4b6c953ac0a3
Summary:
This diff is just here to make it easier for me to work on the stack. It needs to be ripped out of the stack before landing
Changelog:
[Breaking][General] The `target` field of events is now a native component, not a react tag
Reviewed By: mdvacca
Differential Revision: D19458361
fbshipit-source-id: 1d03a58553cf96dc72f6d1323dfb37b1a8cdca75
Summary:
Make the script ready for picking in 0.62.0-rc.3.
* Rename the script to remove ambiguity. “autolinking” is a CLI feature where 3rd-party pods are automatically discovered: https://github.com/react-native-community/cli/blob/master/docs/autolinking.md
* Make the Flipper version of the pods configurable, as requested [here](https://github.com/facebook/react-native/pull/28044#discussion_r378662636).
* Make RNTester’s Podfile use the same form as the template–including enabling Flipper by moving the CPP define into the right place in the Xcode project and out of the Podfile.
* Get rid of Podfile.lock thrashing by making the default CDN spec source explicit.
## Changelog
[iOS] [Changed] - Disambiguate autolinking-ios.rb script from CLI’s “autolinking” feature and bring RNTester & template in line.
Pull Request resolved: https://github.com/facebook/react-native/pull/28077
Test Plan: RNTester builds, as does a new application.
Reviewed By: PeteTheHeat
Differential Revision: D19956392
Pulled By: TheSavior
fbshipit-source-id: 6c800ddb646b49fc45c088978e2794cd7b60ea48
Summary:
Changelog: [internal]
Repro steps:
1. Go to fbsource/fbobjc.
2. Run following focus command P124860753.
3. Enable Address Sanitizer in Xcode.
3. Run the app from Xcode.
5. Make sure `react_fabric.enable_marketplace_home_ios` and `react_fabric.enabled_state_reconciliation_ios` Mobile Config flags are set to true.
6. Navigate to Marketplace Home and observe use of freed memory exception. You have to wait until second page of marketplace home feed is loaded.
{F228880980}
# Root cause
`ChangedShadowNodePairs` being a vector of pairs of references.
Those `shared_ptr` do not outlive the the run of `reconcileStateWithTree` (that's what I originally thought when I made them references).
This was introduced in D19814500.
Reviewed By: JoshuaGross
Differential Revision: D19977784
fbshipit-source-id: 8c4a381137baa08a6af9d3c1cb295fe6c2b2bf95
Summary:
1/4 of https://github.com/facebook/react-native/issues/28103
## Changelog
[JavaScript][Removed] - Remove leftover `Incremental` component.
Pull Request resolved: https://github.com/facebook/react-native/pull/28107
Test Plan: In RNTester `Incremental` component is no longer used so I modified one of existing examples to use it.
Reviewed By: rickhanlonii
Differential Revision: D19960536
Pulled By: TheSavior
fbshipit-source-id: 791bda7138ac23916957577ed5f5c465c5e96299
Summary:
Changelog: [Internal]
This allows to block queue until image is fetched.
In paper, the photo of dog will not appear unless the network request is "fast enough".
{F228670428}
Reviewed By: shergin
Differential Revision: D19907906
fbshipit-source-id: 98d68abf1255388f9b97fb9da367d8f583a4220d
Summary:
The current AppVeyor test is failing on node v8. Since v8 is no longer active (https://nodejs.org/en/about/releases/), updated to the current LTS versions.
## Changelog
[Internal] [Changed] - Changed AppVeyor Node test versions to 10 & 12
Pull Request resolved: https://github.com/facebook/react-native/pull/27980
Test Plan: Hopefully makes the tests green �
Differential Revision: D19873610
Pulled By: hramos
fbshipit-source-id: 6f42a6046a1c015d327b15dc9537d0c2bb27e978
Summary:
TextInput’s `InputAccessoryView` was using a [deprecated] prop-type as a Flow type, which TheSavior asked me to fix [here](https://github.com/alloy/rn2dts/commit/6ba4b28a22d8c0bd346996d78743016eaae707e1#r37343692).
## Changelog
[iOS] [Fixed] - Fixes the `InputAccessoryView.backgroundColor` prop’s typing to use `ColorValue`.
Pull Request resolved: https://github.com/facebook/react-native/pull/28105
Test Plan:
Passes:
```bash
yarn flow-check-ios
```
Differential Revision: D19956401
Pulled By: TheSavior
fbshipit-source-id: 0c16f292b0143e83235a23712a0a7a11b8317f4e
Summary:
I just stumbled upon [This PR](https://github.com/facebook/react/pull/18039) and thought it would be great for react-native repo to have the same.
This creates a link in issue template that will lead people who found error in the documentation to the appropriate repo, and people who has questions about react-native will be lead to the support page.
<img width="1034" alt="Screen Shot 2020-02-15 at 13 44 02" src="https://user-images.githubusercontent.com/6936373/74582027-ce9bf600-4ff9-11ea-9dc5-21601c4007c4.png">
## Changelog
[Internal] [Changed] - Add links to Issue template
Pull Request resolved: https://github.com/facebook/react-native/pull/28079
Test Plan: This pr does not contain any change in the functionality of react-native.
Differential Revision: D19954747
Pulled By: hramos
fbshipit-source-id: 7cce094e2519c0f508858a034f053d058d801f35
Summary:
Right now, `requestFocus()` is a no-op if the EditText view thinks it's already focused. In certain cases, though, we still want to focus the view even if it's already focused - for example, if TalkBack is enabled and you dismiss the keyboard, you want to be able to tap on the TextInput again to bring back the keyboard, even though the View never thinks it lost focus.
What I'm doing instead is basically disregarding the View's current focus state if we *would* focus the TextInput, which is in 3 circumstances:
- When the view is attached to a window, if autofocus is true
- When the focus is being requested by JS
- When the focus is being requested by an accessibility action from the OS
Changelog: [Android][Fixed] Change how TextInput responds to requestFocus to fix a11y focus issue
Reviewed By: mdvacca
Differential Revision: D19750312
fbshipit-source-id: 30b9fab40af4a083fa98f57aba7e586540238bea
Summary:
This diff replaces some YellowBox references with LogBox so we can remove it.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D19948126
fbshipit-source-id: b26ad1b78d86a8290f7e08396e4a8314fef7a9f3
Summary:
Migrates internal calls from ignoreWarnings to ignoreLogs so we can remove YellowBox.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D19813781
fbshipit-source-id: 16c7b3f2cd38cba1901eccb4d5b9a2396a37ba1b
Summary:
We need to export this so that users can call methods like:
```
LogBox.ignoreAllLogs();
LogBox.ignoreLogs([/whatever/]);
```
Changelog: [General] [Added] Export LogBox module
Reviewed By: TheSavior
Differential Revision: D19813773
fbshipit-source-id: 8c301c16247c5b9f4b23e8afaf6a9783b4b4c724
Summary: This diff reverts the iOS LogBox module back to the UIWindow strategy used by Redbox.
Reviewed By: sammy-SC
Differential Revision: D19941390
fbshipit-source-id: 4aea09137ea9e8bfc166a733272647a79102bf35
Summary:
Changelog: [Internal]
Switching queue here is not necessary if we are already on the main queue.
This is important for Fabric SSTs, otherwise images are missing.
Reviewed By: shergin
Differential Revision: D19907908
fbshipit-source-id: 52e82484afc8e2f591d0c5cc126952990d992e96
Summary:
Both the UIManagers use ReactConstants.TAG currently, so certain logs are ambiguous. Use FabricUIManager's tag instead for all logs to disambiguate.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19945587
fbshipit-source-id: 0a9d62b5c0276688b2ad3acf8d893b523c26560a
Summary:
Moves the LogBox images from base64 data to files since base64 is not supported everywhere.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D19879323
fbshipit-source-id: 2dc03eebfc712ed863ed76322e133fcad5b00bb4
Summary:
ChangeLog: [Both] Adds perf markers for `XMLHttpRequest`s
Makes it easier to see JS-based network operations in performance traces.
Reviewed By: zackargyle
Differential Revision: D19903143
fbshipit-source-id: c5ce60163569e003830d8079cb2b580469d5bd5d
Summary:
We've updated the version of plugin to 1.7.0 that includes similar fix to D19910353
## Changelog:
Changelog: [Internal]
Reviewed By: kassens
Differential Revision: D19912264
fbshipit-source-id: 973d4211bf56e33da427e01c9c561e15f7406ffb
Summary:
https://github.com/facebook/react-native/pull/22166 removed inline styles from TextInputTestModule but applied the incorrect style to some of the TextInputs - instead of setting the text color, it set the margin. This caused the test to fail because no color was applied.
Changelog: [Android] [Fixed] Fixed style in TextInputTestCase
Reviewed By: zackargyle
Differential Revision: D19912362
fbshipit-source-id: d5068114b726ee7583842e5f6f323862b0c28e44
Summary:
Same as rickhanlonii’s 2c89e51507, but for the application template.
## Changelog
Changelog: [Android] [Fixed] Template instacrash from missing androidx dependency
Pull Request resolved: https://github.com/facebook/react-native/pull/28071
Test Plan: Apps build with the template from v0.62.0-rc.2 don’t instacrash.
Differential Revision: D19908895
Pulled By: mdvacca
fbshipit-source-id: 63337f4c0c0ffeb3b024682744610c7915e2b742
Summary:
[A recent change to JSStringToSTLString](https://github.com/facebook/react-native/pull/26955) causes a crash when the function is invoked with invalid UTF-16 data. The old behaviour, restored here, was to truncate the string before the first invalid character.
Here's how [the original code](https://github.com/facebook/react-native/blob/aee88b6843cea63d6aa0b5879ad6ef9da4701846/ReactCommon/jsi/JSCRuntime.cpp#L287) handled this case:
```
std::string JSStringToSTLString(JSStringRef str) {
size_t maxBytes = JSStringGetMaximumUTF8CStringSize(str);
// ^ maxBytes >= 1 regardless of str's contents
std::vector<char> buffer(maxBytes);
// ^ vector is zero initialised
JSStringGetUTF8CString(str, buffer.data(), maxBytes);
// ^ writes '\0' at the first invalid character and returns early (see JSC source code)
return std::string(buffer.data());
// ^ copies the string up to the first '\0'
}
```
See the JSC implementations of [`JSStringGetUTF8CString`](https://opensource.apple.com/source/JavaScriptCore/JavaScriptCore-7600.8.7/API/JSStringRef.cpp.auto.html) and [`convertUTF16ToUTF8`](https://opensource.apple.com/source/WTF/WTF-7600.7.2/wtf/unicode/UTF8.cpp.auto.html).
Based on the fact that `JSStringGetUTF8CString` *always* null-terminates the buffer - even when it bails out of converting an invalid string - here we're able to both
1. keep the fast path (not zero-initialising, not scanning for the null terminator) for the common case when the data is valid and JSStringGetUTF8CString returns a nonzero length; and
2. return the truncated string when JSStringGetUTF8CString returns an error code of 0, by scanning for the null terminator.
Changelog: [General] [Fixed] - Fix crash when passing invalid UTF-16 data from JSC into native code
Differential Revision: D19902751
fbshipit-source-id: 06bace2719800e921ec115ad6a29251eafd473f6
Summary:
Previous config used Node10 and NodeLTS executors, but the naming wasn't accurate. As of today, Node 12 is LTS, Node 10 is also LTS but entering maintenance in April: https://nodejs.org/en/about/releases/
This PR switches all jobs to use Node 12 as nodelts, and renames test_js_lts to test_js_prevlts to reflect it's use of Node 10 (the previous Node LTS release). The executors are named NodeLTS and NodeLTSPrev. Later this year, we can switch these to use Node 14 and Node 12 as Node 10 goes into maintenance.
## Changelog
[Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/28048
Test Plan: Circle CI
Reviewed By: TheSavior
Differential Revision: D19887240
Pulled By: hramos
fbshipit-source-id: a8d553dca0f47a5ab6132a3880830a60a1b28736
Summary:
Having the overridden function that returns a different type is apparently not a good idea (and might cause bugs and unexpected behavior), so it was renamed. The function also got a new return type (`const &` instead of `std::shared_ptr`) for simplicity, better performance, and smaller code size.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D19837694
fbshipit-source-id: b7a96424bd040409371724907b3fb3931cd8a2e8
Summary:
In all other areas of JSI, std::string is treated as potentially
containing UTF-8 bytes (instead of ASCII). This fixes the inconsistency.
Changelog: [Internal]
Reviewed By: mhorowitz
Differential Revision: D19871520
fbshipit-source-id: c703f07e10bedbf2518d0bec903f85f43bbcbdf5
Summary:
Use the latest published release of hermes-engine.
Changelog: [Android] [Changed] - Upgraded to Hermes 0.4.0
Reviewed By: mhorowitz
Differential Revision: D19866355
fbshipit-source-id: be2bed957bc034d3e6107804229abc2d83e40d40
Summary:
This class is no longer used by the core and thus can be removed.
It isn't exposed as part of our public API so this is technically not a breaking change, although it may still cause people trouble if they are reaching into internals. It is expected that people will use forwardRef instead of this class.
I will follow up this diff with a removal from the ReactNativeRenderer as well.
Changelog:
[Internal] Remove ReactNative.NativeComponent from React Native
Reviewed By: JoshuaGross
Differential Revision: D19888400
fbshipit-source-id: 78da51e6c0edf9d8706395d376c3bfe75dabda03
Summary:
We must use FLog instead of android.util.log, this diff moves the current callsites of android.util.log to FLog
changeLog:[internal]
Reviewed By: JoshuaGross
Differential Revision: D19884741
fbshipit-source-id: 300f7d691961aa51f0b525c37da7ae3d64fe5131
Summary:
# Problem
`UIManager::getRelativeLayoutMetrics` returns incorrect `frame.origin.y` value.
Just quick reiteration how calculation of `frame.origin` works. We take frame of the target shadow node, travers hierarchy to the root and keep adding `frame.origin` of each ancestor to target shadow node's origin.
One more important piece of information, to calculate scroll view's `frame.origin`, we need to have its contentOffset which gets passed to Fabric core through state.
# So where does it go wrong?
Problem is that on Android, calling view command `scrollTo` doesn't set its internal state correctly. So when we calculate the layoutmetrics, scroll view's `frame.origin` is off by whatever value was used in `scrollTo`.
# The fix
In `ReactScrollView`, correctly set state after `scrollTo` is called on it.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D19835549
fbshipit-source-id: d56e7b0b05023c0497e52c8b46fdcf58ca78b4a5
Summary:
If we're using synth traces in production, we probably don't want to accumulate the trace in memory, and write it to a file in one big step when an error happens. Rather, we'd like to write the trace incrementally, to a file: file system space is less scarse than memory, and doing it incrementally means less to do in the error handler.
This diff is the first step towards writing the synth trace incrementally. The most difficult aspect of this is that in the existing code, on Android, the trace is written in the handler of an Intent. Java-level operations on the Intent yielded a temporary filename under the application (so if the application is uninstalled, these temporary files are deleted). We must do something similar, but choose the filename within native code, on construction of the SynthTrace object. We copy what profiling does for this: assume the tmp dir is /data/data/<app>, where <app> can be found from reading /proc/self/cmdLine.
The SynthTrace constructor now takes a new argument: a unique_pointer to a stream. If null, no trace file is written, and the SynthTrace just accumulates records in memory. (This functionality is used during trace replay.) . If non-null, the trace is written to that stream.
The "write{BridgeTraffic}Trace..." methods become "flushAndDisable{BridgeTrafficTrace}" methods.
This diff is the first step towards incremental traces: the trace is still written at the end, but we've arranged that the place to write it is available at construction of the SynthTrace object. Later diffs will move recording of static things (e.g., the RuntimeConfig) into the ctor, then actually make us write the trace to the file incrementally.
For ReactNative:
Changelog: [Internal]
Reviewed By: haozhun, dulinriley
Differential Revision: D19471297
fbshipit-source-id: c1de4d2d9f44a87c7ff6fea38a1ce67de593940c
Summary:
Resolve React-RCTText warning: `'UIKeyboardTypeASCIICapableNumberPad' is only available on iOS 10.0 or newer`
## Changelog
[iOS] [Fixed] - Resolve React-RCTText Xcode warning
Pull Request resolved: https://github.com/facebook/react-native/pull/28054
Test Plan: Build template, React-RCTText should no longer throw a warning.
Differential Revision: D19887063
Pulled By: hramos
fbshipit-source-id: 3437ee993babd7cdaec259af24526e197acb64bb
Summary:
This refactors some logic which sets up HMRClient in JS. The logic should live in RCTDevSettings, so it is shared in bridge/bridgeless mode.
This also means the logic will be compiled out when `RCT_DEV_MENU` is false.
Reviewed By: RSNara
Differential Revision: D19563629
fbshipit-source-id: 5c2553be9fd686a2a178f03bb5eed7a82cbadb1b
Summary:
With new logic we save one attributed string copy operation.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D19844371
fbshipit-source-id: 62f6b0f9c8514a1b55224ccaa52c8fa89c06c9e7
Summary:
Add debug logs for T62192299, which will hopefully tell us why RN is being destroyed in otherwise useless logs.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19866793
fbshipit-source-id: 6656c305c8ef567335ea7fe82e4e1c68092a49d2
Summary:
When building RNAndroid, Gradle files are generated. Added them to `.gitignore`. If it is ideal to have them in the repo I can commit them.
## Changelog
[Internal] [Fixed] - Added ReactAndroid generated Gradle files to .gitignore
Pull Request resolved: https://github.com/facebook/react-native/pull/28014
Test Plan: Build ReactAndroid, generated Gradle files no longer show up in git changes.
Differential Revision: D19873998
Pulled By: mdvacca
fbshipit-source-id: 29af7612df611bba1e83f4afac8692e1aa6df515
Summary:
Instead of returning a `bool` which gives no information about the cause of the error,
return `void` and throw when there's some error.
Another alternative is returning `std::error_code`, but that's less flexible than throwing, and
this API already supports throwing.
Changelog: [Internal]
Reviewed By: jbower-fb
Differential Revision: D19170033
fbshipit-source-id: 870cd996a1a53c94524455f31765c1da99f57a1d
Summary:
New release with some fixes for RN consumers. See
https://github.com/facebook/SoLoader/releases/tag/v0.8.2
## Changelog
[Android] [Chore] Update SoLoader to 0.8.2
Reviewed By: cpojer
Differential Revision: D19856837
fbshipit-source-id: 77a8fe1aa62db951413931e8a7d5e05325beb24e
Summary:
Just released a new version. No changes impacting us here.
Changelog: [Android] [Chore] Upgrade soloader targets
(Note: this ignores all push blocking failures!)
Reviewed By: cpojer
Differential Revision: D19856603
fbshipit-source-id: bab56be19fe231ac70040fca772ce3bc77269692
Summary:
This updates the lint to include an update to `getModuleName` that landed in the compiler a few days ago so that lint and compiler requirements match in all cases again.
js1 upgrade dependency -p eslint-plugin-relay@1.6.0
Changelog:
[General] [Changed] - upgrade eslint-plugin-relay to 1.6.0
Reviewed By: alunyov
Differential Revision: D19856543
fbshipit-source-id: 2fe3b49f6cd2d170132132557ec8834ca7e94181
Summary: changelog: [General] `console.error` calls, and uncaught exceptions are now displayed in the Metro logs as well
Reviewed By: passy
Differential Revision: D19743075
fbshipit-source-id: a665a06cfc7854ae785af177af8f2478bb1d76b0
Summary:
When `[RCTReconnectingWebSocket stop]` is called and `[RCTReconnectingWebSocket reconnect]` is scheduled afterwards (i.e. connection didn't happen before `[RCTReconnectingWebSocket stop]` being invoked), it will keep reconnecting forever.
Also fixes retain loop in block within `[RCTReconnectingWebSocket reconnect]`. When RCTReconnectingWebSocket is stopped and reference to it set to nil, block in reconnect will still keep self alive and reconnecting forever.
I found this edge case when I tried to stop RCTPackagerConnection after some time, so it doesn't spam with `[] nw_socket_handle_socket_event [C34585.1:1] Socket SO_ERROR [61: Connection refused]` when we don' have Metro running (we have brownfield app, so iOS devs don't need Metro running most of the time).
## Changelog
[iOS] [Fixed] - RCTReconnectingWebSocket is reconnecting infinitely when stopped before getting connected
Pull Request resolved: https://github.com/facebook/react-native/pull/26864
Test Plan:
- Put breakpoint into `[RCTReconnectingWebSocket reconnect]`
- Start sample RN app **without having Metro running**
- Into AppDelegate add something like
```objc
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(5 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
[RCTPackagerConnection.sharedPackagerConnection stop]
});
```
- After the previous block is dispatched reconnect should not be invoked anymore
Reviewed By: motiz88
Differential Revision: D19767742
Pulled By: rickhanlonii
fbshipit-source-id: dabb2369b06217b961e9d2611257c106d350f70c
Summary:
Right now, people are calling `getInnerViewNode` and `getInnerViewRef` to get the ref of the `View` within `ScrollView`. Instead, this change adds a prop to `ScrollView` to give people direct access to that `View` if they need it.
Previous usage:
```
const myRef = React.createRef<React.ElementRef<typeof ScrollView>>();
<ScrollView ref={myRef} />
const innerViewRef = myRef.current.getInnerViewRef();
innerViewRef.measure();
```
New usage:
```
const myRef = React.createRef<React.ElementRef<typeof View>>();
<ScrollView innerViewRef={myRef} />
// now, myRef.current can be used directly as the ref
myRef.current.measure();
```
Changelog:
[Changed][General] ScrollView: Deprecate getInnerViewNode and getInnerViewRef methods. Use innerViewRef={myRef} prop instead.
Reviewed By: TheSavior
Differential Revision: D19713191
fbshipit-source-id: 3304cb94a253dafb458ef49d6331e0e432693431
Summary:
This diff adds required Detox integrations to the RNTester app to be able to run Detox end-to-end tests on the Android version of the app.
* Instructions at https://github.com/wix/Detox/blob/master/docs/Introduction.Android.md were followed.
* The `minSdkVersion` version for the app was bumped to 18, as required by Detox.
* I also added build and test configurations in `package.json`
* The debug app is able to run some of the existing tests, but the release app instacrashes. I do not know the reason for the instacrash at this time.
* CI integrations to build and test the Android app will be added in future diffs
Changelog:
[Internal] add Detox integrations to the RNTester Android app
Reviewed By: TheSavior
Differential Revision: D19566834
fbshipit-source-id: 5dd506bbdbb426a5db18146e5dc7c450a27b1d0c
Summary:
With the release of 0.118 Flow now checks for unsafe additions between numbers and null/void. This enables this check in xplat.
```~/fbsource/fbcode/flow/tool add-comments --bin `which flow` --comment="//flowlint-next-line unsafe-addition=off" ~/fbsource/xplat/js```
`js1 test -u __tests__/flowconfig-sync-test.js`
Changelog: [Internal]
bypass-lint
Reviewed By: nmote
Differential Revision: D19823403
fbshipit-source-id: 1f059de6c9d973cda11930f1fadb485679d4ecec
Summary:
Changelog: [Internal]
There shouldn't be any logical changes to the code.
Reviewed By: JoshuaGross
Differential Revision: D19814500
fbshipit-source-id: 2be492eebb284c7e241662d9d78117badcb2eee4
Summary:
# Problem
We calculate `stateRevision_` in constructor from children, but children change after shadowNode is initialised and before it is sealed. So the `stateRevision_` we calculate in constructor can be incorrect.
# Solution
Recalculate `stateRevision_` whenever children change. This can happen in two methods `ShadowNode::replaceChild` and `ShadowNode::appendChild`. This diff implements this solution.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D19813840
fbshipit-source-id: 8fc3b6601e4618f4ee5b322eebc230e0bbb92e3a
Summary:
This adds support for `adjustsFontSizeToFit` and `minimumFontScale` on Android. The implementation tries to match closely the behaviour on iOS (hardcoded 4px min size for example). It uses a simpler linear algorithm for now, opened to improving it now if it is a deal breaker or in a follow up.
See https://twitter.com/janicduplessis/status/1171147709979516929 for a more detailed thread about the implementation
## Changelog
[Android] [Added] - Implement `adjustsFontSizeToFit` on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/26389
Test Plan: Tested by adding the existing `adjustsFontSizeToFit` example from the iOS text page to android. Also added a case for limiting size by using `maxHeight` instead of `numberOfLines`.
Reviewed By: mdvacca
Differential Revision: D17285473
Pulled By: JoshuaGross
fbshipit-source-id: 43dbdb05e2d6418e9a390d11f921518bfa58e697
Summary:
Added description for rejectResponderTermination prop for the TextInput, which seemed to have been deleted.
Descriptions are taken from https://github.com/facebook/react-native/pull/16755/files
## Changelog
[Internal] [Added] - Add description for rejectResponderTermination prop for TextInput
Pull Request resolved: https://github.com/facebook/react-native/pull/28001
Test Plan: This PR only changes comment, which has no effect on actual function.
Differential Revision: D19820886
Pulled By: TheSavior
fbshipit-source-id: 5cbaafcbae0bdbf6932ef9c7c0c1a75cd6d8794e
Summary:
This is no longer necessary with the new Flipper release.
Pull Request resolved: https://github.com/facebook/react-native/pull/27964
Test Plan:
This was a built-time problem so the CI jobs would catch this.
## Changelog
[Android] [Removed] - pickFirst options for RNTester and template
Differential Revision: D19815829
Pulled By: passy
fbshipit-source-id: d8f66e64e7e922b8ea18ad6eeec3a1c8e6bc77fa
Summary:
Before this change the Element<> API didn't allow to specify state objects and crashed during instantiation of non-null states.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D19816358
fbshipit-source-id: 95ba5e03ea98c0260593462146e8523c95245e2b
Summary:
RNTester ended up using JSC for both jscDebug and hermesDebug. Now it uses the
correct one. It still includes all executors, but it's a step in the right
direction.
ChangeLog: [General] [Fixed] RNTester now uses the VM specified in the build flavor
Reviewed By: passy
Differential Revision: D19752239
fbshipit-source-id: 0db4e5201fc80c2a0b91531e3f4333148c1d9c7c
Summary:
This pull request fixes a few `#include`s in the Fabric source:
* Changes `<Glog/logging.h>` to `<glog/logging.h>` in two files, which was an issue for case-sensitive file systems
* In `ParagraphProps.cpp`, changes the include of `attributedstring/primitives.h` from a relative style to a more absolute style.
## Changelog
[Internal] [Fixed] - Fabric: Fix various includes
Pull Request resolved: https://github.com/facebook/react-native/pull/27947
Test Plan: Fabric compiles perfectly, and the Fabric test suite passes.
Reviewed By: shergin
Differential Revision: D19788148
Pulled By: sammy-SC
fbshipit-source-id: 30a297e8aea50c7c7fd5f48745edf04811a6bdbd
Summary:
Changelog: [Internal]
When I was originally implementing this view command (D19471025), I misunderstood the desired behaviour.
The text parameter isn't meant to change text in the specified `select` but it is supposed to override text of entire text input.
Reviewed By: shergin
Differential Revision: D19793484
fbshipit-source-id: 64ba36ddfa27ac5a0adf48495cb4e985a429e005
Summary:
This pull request fixes the CXX stub for `TextLayoutManager`. The signature for `TextLayoutManager::measure` changed slightly, and this patch updates the stub to reflect that.
## Changelog
[Internal] [Fixed] - Fabric: Fix CXX Stub for TextLayoutManager
Pull Request resolved: https://github.com/facebook/react-native/pull/27948
Test Plan: Fabric compiles, and the Fabric test suite passes.
Reviewed By: shergin
Differential Revision: D19788207
Pulled By: sammy-SC
fbshipit-source-id: 8f42cca0be99022b038742728ad4fec6c04d5cf0
Summary:
This change removes the concept of `StateTarget`, replacing its role with `ShadowNodeFamily`.
When `StateTarget` was built, we didn't have a concept of `Family`, and when we added it we introduced a retain-cycle: ShadowNode -> Family -> StateTarget -> ShadowNode. This diff fixes that.
This change does not change conceptually how the state behaves, it just adjusts internal machinery.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D19799013
fbshipit-source-id: c1360bfbf6b8ac34e2a856a40047eafeb50ed070
Summary:
Before this change, the concrete component-specific data/payload object associated with a State was stored inside a templated subclass as a normal instance variable; after the change, it's stored as a shared pointer inside the base class. The original motivation was that storing that inside subclass saves us one shared pointer and one heap allocation.
This approach overcomplicated a lot of things and all possible savings are probably compensated with additional complexity (we have to have templated state-update lamdas in subclasses and so on). And to update the data in the previous approach we need to create a shared pointer to data anyway.
This change will allow future improvements in the coming diff.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D19799014
fbshipit-source-id: 287ed939353ba58d9e434d1502ecfbb208c6daa5
Summary:
Only use State Reconciliation during certain commits from ReactJS, not during State commits or others
The idea is that this will have better perf, since many types of commits don't need State Reconciliation at all.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19794999
fbshipit-source-id: 336325f225d993a6aae9f55cb95a7a2b38a6d853
Summary:
This implements proposal #2 in our State architecture doc: https://fb.quip.com/bm2EAVwL7jQ5
Problem description: see the text in the comment of TreeStateReconciliation.h
Solution: see also comments in TreeStateReconciliation.h.
Changelog: [internal]
Reviewed By: mdvacca
Differential Revision: D19617329
fbshipit-source-id: 845fb5fe27f2591be433b6d77799707b3516fb1a
Summary:
Update the default issue template (e.g. the one shown when no custom template is chosen at https://github.com/facebook/react-native/issues/new/choose, and instead a new issue is opened via https://github.com/facebook/react-native/issues/new) to clarify that moving forward without a template will result in the issue getting closed.
The bot will aggressively close issues that have no labels, and only using a custom template will guarantee your issue has a label.
## Changelog
[Internal] - GitHub-only change.
Pull Request resolved: https://github.com/facebook/react-native/pull/27996
Test Plan: N/A
Differential Revision: D19802342
Pulled By: hramos
fbshipit-source-id: a3e991bec4fc69e91cb5cedf5e2ee6b8ef1148f9
Summary:
Systraces were disabled a year ago in D14019272 because we suspected they can negatively affect perf. We don't think this is the case anymore.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19786284
fbshipit-source-id: 185ed45b134fdcadf131cfddfcf8faf37537a684
Summary:
**Resolve/Reject Promise**
* Add onFulfill and onReject to the `PushNotificationIOS.requestPermissions()` Promise
**Replace Apple-deprecated notification method**
* Old: In iOS 10, `UIApplication.registerUserNotificationSettings` was deprecated. Calling this would then call the AppDelegate's lifecycle function `didRegisterUserNotificationSettings`, and then in the AppDelegate, we'd call `RCTPushNotificationManager.didRegisterUserNotificationSettings` to return the user settings.
[registerusernotificationsettings Doc](https://developer.apple.com/documentation/uikit/uiapplication/1622932-registerusernotificationsettings?language=objc)
* New: Replace deprecated function with Apple's recommended `UNUserNotificationCenter.currentNotificationCenter getNotificationSettingsWithCompletionHandler`, which no longer needs the AppDelegate lifecycle method because it directly returns the user's settings in a completion hander.
[requestauthorizationwithoptions Doc](https://developer.apple.com/documentation/usernotifications/unusernotificationcenter/1649527-requestauthorizationwithoptions?language=objc)
**Add Tests**
* Add tests on `PushNotificationIOSExample.js` to test that the onFulfill and onReject are called
* On `PushNotificationIOSExample.js`, instead of asking permission upon page load, ask for permission when the user taps the button "Request Notifications (Should Display Alert)".
* Before, asking for permission multiple times before would result in the RN error "cannot call requestPermissions twice before the first has returned", now you can ask for permission as many times as you want because I've removed the now unused `RCTPromiseResolveBlock`.
**Future**
If this works on device (we have to land this to test push on device), we can delete `RTCPushNotificationManager.didRegisterUserNotificationSettings` which is being called from several apps.
Changelog:
[iOS] [Added] Resolve and reject promise for PushNotificationIOS.requestPermissions
Reviewed By: PeteTheHeat
Differential Revision: D19700061
fbshipit-source-id: 02ba815787efc9047f33ffcdfafe962b134afe6d
Summary:
We use this for RN tester but it is not currently included in npm releases. It cleans up the podfile a lot and will make adding / removing pods easier in the future since it won't require users to update their project.
## Changelog
[iOS] [Added] - Use autolink script in template on iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/27984
Test Plan: Not sure if there is a way to end to end test this but I've been using this autolink script in my fork for a while.
Differential Revision: D19787729
Pulled By: cpojer
fbshipit-source-id: b843ea723085830f13e8f0149833d1beb1efdfac
Summary:
Upgrading CLI to latest. This diff is intended to be cherry-picked to 0.62.
cc grabbou kelset
## Changelog
[Internal] [Changed] - Bump CLI to ^4.0.0
Pull Request resolved: https://github.com/facebook/react-native/pull/27976
Test Plan: None
Differential Revision: D19769017
Pulled By: cpojer
fbshipit-source-id: c3f5cd8afc0bc26372ee9f9e9dbaf4e68cdec216
Summary:
These props are applied to `View`, therefore they most not be a part of base text attributes, so we reset them.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D19764144
fbshipit-source-id: a0d2900e3161c47b83114360c843fa85a4389f8a
Summary:
This functionality was deprecated in [this commit](https://github.com/facebook/react-native/commit/e2bd7db732602b2c477fe040f2946bd8293df297) on Feb 12th, 2019, originall in 0.59.0
Changelog:
[Breaking][General] Alert: Remove deprecated support for Alert.prompt with type as Callback (deprecated in 0.59)
Reviewed By: cpojer
Differential Revision: D19762618
fbshipit-source-id: a8edb6045bbc57d56e75fd281e602f5370ba1810
Summary:
Starting on iOS 13, a View Controller presented modally will have a "bottom sheet" style unless it's explicitly presented full screen.
Before this, modals on iOS were only being dismissed programatically by setting `visible={false}`. However, now that the dismissal can happen on the OS side, we need a callback to be able to update the state.
This PR reuses the `onRequestClose` prop already available for tvOS and Android, and makes it work on iOS for this use case.
Should fix https://github.com/facebook/react-native/issues/26892
## Changelog
[iOS] [Added] - Add support for onRequestClose prop to Modal on iOS 13+
Pull Request resolved: https://github.com/facebook/react-native/pull/27618
Test Plan:
I tested this using the RNTester app with the Modal example:
1. Select any presentation style other than the full screen ones
2. Tap Present and the modal is presented
3. Swipe down on the presented modal until dismissed
4. Tap Present again and a second modal should be presented
Differential Revision: D19235758
Pulled By: shergin
fbshipit-source-id: c0f1d946c77ce8d1baab209eaef7eb64697851df
Summary:
Of course, compare_exchange_strong didn't actually do what I wanted.
Using a mutex is simpler and actually has the semantics we want: atomically get the current value, compare, and bail if the value is the same, or swap and continue.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D19754451
fbshipit-source-id: 6b0aef217b235959af683ec5e31b07a0dd7bb040
Summary:
List components aren't host components so checking if the direct component itself's internals isn't sufficient to know if we are in Fabric. For lists, we have to call through some helper functions to get to the host component.
Hopefully we will fix this in the future by making the lists use forwardRef, or by getting rid of the JS Driver altogether, but for now, this is fine (TM).
Changelog: Internal
Reviewed By: mdvacca
Differential Revision: D19731067
fbshipit-source-id: 0e73583c6bf7c10de30e668a390d29718d31b295
Summary:
This method is being stripped in release builds because it's used directly from C++ and not referenced in Java. Adding `DoNotStrip` to prevent this.
Changelog: [Internal]
Reviewed By: PeteTheHeat, mdvacca
Differential Revision: D19708826
fbshipit-source-id: a572f0295ab3b49e5884d0a6c723d65e4bbc9226
Summary:
It turns out that in release builds, proguard is doing something weird with inner classes, so that getSimpleName() is actually returning "OuterClass$InnerClass" in some cases. We have logic to handle this case already in JavaScriptModuleRegistry, so I'm moving that out to a static method that I can access in bridgeless mode.
Also adding tests for it.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19701703
fbshipit-source-id: 625737bfb50ca8ba2bd26034e2a74c682783ba8a
Summary:
- We use a fork of Microsoft's react-native-windows which uses a fork of Facebook's react-native
- YGValue.h does not compile with Clang on Windows
- This change should fix that
- I want to put the change here so that it bubbles back to our fork > https://our.intern.facebook.com/intern/diff/D19656093/
#Changelog:
[General][Fixed] Make YGValue.h compile with Clang on Windows
Reviewed By: SidharthGuglani
Differential Revision: D19717489
fbshipit-source-id: ad867ecaf910bb64a777a06c656a1867bb15484b
Summary:
In working to remove dead code from the code base, we identified that a number of classes that subclassed `RCTEventEmitter` were being reported as unused when they are in active use. That was due to a lack of a `[super initialize]`. This diff adds the call to super.
Changelog:
[General] [Added] - Call to `super` in `+initialize` of `RCTEventEmitter`
Reviewed By: javache
Differential Revision: D19727783
fbshipit-source-id: 19c6c7f08e7a8b2f764988fdfcd70f92dbf1b74b
Summary:
The documentation in two out of the three variants of `Function::callWithThis` incorrectly stated that the `this` value was to be `undefined` instead of set to `jsThis`, which contradicts the point of the `callWithThis` method existing in the first place. This diff fixes that issue.
Changelog: [General] [Fixed] - Fix documentation comments for HermesJS's `Function::callWithThis` method to accurately reflect how `this` is handled.
Reviewed By: jbower-fb
Differential Revision: D19714074
fbshipit-source-id: 123688c1f7e578d6356bec54604fb6e30f06b0b1
Summary:
Easy diff to add extra logging when Fabric tries to add a view inside a view that is not a ViewGroup
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D19737506
fbshipit-source-id: ecb858820de7befc385e725c45b537359e39c0e7
Summary:
Simple hack to prevent duplicate onLayout events from being emitted to JS.
Because of the addition of State Reconciliation to the Fabric lifecycle (see previous diff), in certain circumstances entire subtrees can be relayed-out many, many times even though they aren't changing. For JS product code that responds to every onLayout and forces a ReactJS tree commit (see: some usages of VirtualizedList) this can cause an async infinite loop of commits and layouts even though the tree and the LayoutMetrics aren't actually changing. Even though nothing is changing, it can still cause serious performance regressions and even some bugs since the internals of various state machines may assume onLayout won't be called many times.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D19715280
fbshipit-source-id: d879e24f1c7b1f710ad430b7473aa9293d093dea
Summary:
Flow is moving the react-dom libdef to flow-typed. To prepare for that, we should add `react-dom_v16.x.x` to the react-native library definitions
Changelog: [Internal]
Reviewed By: samwgoldman
Differential Revision: D19726257
fbshipit-source-id: b2dcbc938b482b73947cc2683b87229873b573dd
Summary:
Bridgeless mode requires all native modules to be turbomodules. The iOS animated module was converted to TM, but reverted due to perf issues. RSNara is looking into it, but it may be an involved fix. As a short term workaround, to unblock release mode testing of bridgeless mode, use `AnimatedMock`.
Changelog: [Internal] Disable animations in bridgeless mode
Reviewed By: RSNara
Differential Revision: D19729827
fbshipit-source-id: e6c4d89258ec23da252c047b4c67c171f7f21c25
Summary:
Removing the experimental types-first flag from RN templates, until these are properly documented in the docs. See https://github.com/facebook/flow/issues/8279 for context.
Changelog: [Internal]
Reviewed By: jbrown215
Differential Revision: D19728257
fbshipit-source-id: 8f7473b9c8383bd1eef76b5733ff3a26e2e554fc
Summary:
React is way better than it used to be...
Changelog: [Internal]
Reviewed By: zackargyle, lunaleaps
Differential Revision: D19421772
fbshipit-source-id: db82b68a0c2f31e9ef7e1875fd9e4bf27ef6295a
Summary:
Adding a `.clang-tidy` to a bunch of dirs under `react-native-github/ReactAndroid` and `react-native-github/ReactCommon`.
I don't want to add a single `.clang-tidy` at the root because we'll need more fine-grained control over what checks are enabled in different parts of the codebase; for example, fabric will and TM will probably have more checks enabled than older parts of the codebase that we're not actively modernizing, and the Hermes team probably wants its own config to be consistent with the rest of their codebase.
Starting off each `.clang-tidy` by only enabling clang-diagnostic; this is just to test that it's working. In the future, we'll work with the community to gradually enable more checks.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19705749
fbshipit-source-id: 979cea053b645ac4a9790340033bfcfb49ca0f97
Summary:
This test has been failing internally because it attempts to access external images during CI execution, which it is blocked from doing. Because Detox synchronizes with the app to make sure network requests and animations are complete before continuing, the test waits indefinitely for these images to be fetched.
This diff makes the following changes
* External images are replaced with fb-hosted images
* Timeout threshold is reduced
* Detox initialization is broken out into two steps to help debug any future instances of this occurring
* If Detox is blocked for over 20 seconds, diagnostic messages will be printed indicating why it's being blocked
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D19671592
fbshipit-source-id: 368c683101ed7fc68578fc7758061b31c96c241d
Summary:
This diff refactors Text and Text input components in Fabric to support customizable emojis
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D19679391
fbshipit-source-id: 358aa97064209d28d317ba4ca5fff84245c9b1bb
Summary:
This diff refactors support of emojis in RN classic in order to make it easy to extend support for text input and fabric (as part of this stack)
changelog:[internal]
Reviewed By: JoshuaGross
Differential Revision: D19679394
fbshipit-source-id: 45eff49800b3db281721088f107494005d390fff
Summary:
## This diff
- Add a hybird scene tracker that support both native navigation and js navigation
- It also has a filter that bypass loading routes and unrelated routes like log box
- The tracker can provide exactly what surface user is looking at
Changelog: [Internal]
Differential Revision: D19667699
fbshipit-source-id: 600efd05e68bf2702c6c2b1d794e720059f75f81
Summary:
All of our other JS view configs are gated by the `RN$Bridgeless` flag. This one has been behind a DEV flag instead. We've been using it in DEV for a long time now, so it's probably ok to be in prod, but I figured it's better to just be consistent with the rest of the native components, since we only need this for bridgeless.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D19669902
fbshipit-source-id: bd28cf84947bfe298efd95ae07e38c2bf4e45091
Summary:
Changelog: [internal]
`ShadowNodeFamily` can be used as target in state updates instead of `ShadowNode`.
Reviewed By: shergin
Differential Revision: D19517428
fbshipit-source-id: 6831357e749239d5afec1dfd2d44a26ca6553e51
Summary:
Changelog: [internal]
Merges all of responsibilities of `StateCoordinator` into `ShadowNodeFamily`.
Reviewed By: shergin
Differential Revision: D19500104
fbshipit-source-id: f31ffded5a840e722fd898eef6a9f52cd2186df7
Summary:
This diff regenerates all Jest inline snapshots (`expect().toMatchInlineSnapshot()`) now that we use Jest 24.9.0 which fixes a longstanding [formatting instability bug](https://github.com/facebook/jest/issues/8424).
This is strictly a formatting change.
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D19684238
fbshipit-source-id: 77c1e5fe9d2dfef85dffdcc00056fb439d7d7f84
Summary:
Upgrades Jest to the latest 24.x release, [24.9.0](https://github.com/facebook/jest/blob/master/CHANGELOG.md#2490). This is a minor update as we are already on 24.x across the board.
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D19683451
fbshipit-source-id: 12eaeb8b6341d81daf6bdc8f35728967729f291e
Summary:
When an asset is outside of the metro project root, it can lead to relative paths like `/assets/../../node_modules/coolpackage/image.png` as the `httpServerLocation`. This can happen for example when using yarn workspaces with hoisted node_modules.
This causes issues when bundling on iOS since we use this path in the filesystem. To avoid this we replace `../` with `_` to preserve the uniqueness of the path while avoiding these kind of problematic relative paths. The same logic is used when bundling assets in the rn-cli.
CLI part of this PR: https://github.com/react-native-community/cli/pull/939
## Changelog
[General] [Fixed] - Fix resolving assets outside of the project root
Pull Request resolved: https://github.com/facebook/react-native/pull/27932
Test Plan: Tested that an asset in a hoisted node_modules package doesn't show up before this patch and does after in a release build.
Differential Revision: D19690587
Pulled By: cpojer
fbshipit-source-id: 8a9c68af04594ce1503a810ecf2e97ef5bfb8004
Summary:
Add warning messages for Clipboard, SegmentedControlIOS, ProgressViewIOS, ProgressBarAndroid that has been published in community repo.
## Changelog
[General] [Deprecated] - Add deprecation warnings for Clipboard, SegmentedControlIOS, ProgressViewIOS, ProgressBarAndroid.
Pull Request resolved: https://github.com/facebook/react-native/pull/27929
Test Plan: yarn lint
Differential Revision: D19690577
Pulled By: cpojer
fbshipit-source-id: d53fbe9980c5eb2f7b62deb397064aa727d513bd
Summary:
Add warning message for development that is trying to use ToolbarAndroid that has been removed from ReactNative in 0.61
Ref: https://github.com/facebook/react-native/issues/26591
## Changelog
[General] [Deprecated] - Add warning message for trying to use ToolbarAndroid which has been removed from the core.
Pull Request resolved: https://github.com/facebook/react-native/pull/27930
Differential Revision: D19690581
Pulled By: cpojer
fbshipit-source-id: 8e404fe62651fba4940199c74c45270d6e853740
Summary:
This implement the autoFocus functionality natively instead of calling the focus method from JS on mount. This is needed to properly fix the issue described in https://github.com/facebook/react-native/issues/27217, where when using native navigation (UINavigationController) text input focus needs to happen in the same frame transition starts or it leads to an animation bug in UIKit.
My previous attempt fixed the problem only partially and the bug could still happen since there is no guaranty code executed in useEffect will end up in the same frame as the native view being created and attached.
To fix this I added an autoFocus prop to the native component on iOS and in didAttachToWindow we focus the input if it is set. This makes sure the focus is set in the same frame as the view hierarchy containing the input is created.
## Changelog
[iOS] [Fixed] - Add native support for TextInput autoFocus on iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/27803
Test Plan:
- Tested that the UI glitch when transitionning to a screen with an input with autofocus no longer happens in my app.
- Tested that autofocus still works in RNTester
- Made sure that onFocus does get called and TextInputState is updated properly
Differential Revision: D19673369
Pulled By: TheSavior
fbshipit-source-id: 14d8486ac635901622ca667c0e61c75fb446e493
Summary:
This is a quite fragile and important part of the render engine. We need to dirty Yoga node only in cases where a change affects layout. In the case of over-dirtying, we can kill performance. In the case of under-dirtying, we can produce an incorrect layout.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D19596279
fbshipit-source-id: 9f2ac67c44cb35c8ba44be1025b94b7921b74e17
Summary:
This is aligned with all simular changes that we do for `*Props` types (see D19583582 and D19390813).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D19596281
fbshipit-source-id: 283b89c65504e20a461b12c2d1218325c6621dd8
Summary:
Reasons:
* The name of the method now better represent what it's doing;
* It exposes information about "dirty" state of the node without opening actual `LayoutableShadowNode` protected APIs;
* It's a tiny bit faster now because it checks the flag before calling Yoga.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D19596282
fbshipit-source-id: 3d87d9d5ba20bb8e360683f149b5ebf90beecd65
Summary:
Follow up to https://github.com/facebook/react-native/issues/27803. To keep consistency between the implementations this also implements autoFocus natively on Android. This will allow removing the JS auto focus logic completely.
## Changelog
[Android] [Fixed] - Implement native TextInput autoFocus on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/27924
Test Plan: Test using the TextInput example in RN tester.
Differential Revision: D19674506
Pulled By: TheSavior
fbshipit-source-id: 9cbb517fc69bccd11f5292a1ccb4acea2e3713e9
Summary:
This diff changes the behavior of UIImplementation.resolveViewManager() to return null instead of throwing an exception when trying to find an unexistent viewManager during the computation of constants for view Managers.
The C++/JS code manages exceptions and null results when a view manager doesn't exists, this diff simplifies the way this method operates.
changeLog: [internal]
Reviewed By: rickhanlonii
Differential Revision: D19624423
fbshipit-source-id: df31dcfae9a588bf325b61d529cec6ead59fb19d
Summary:
I hit a crash when testing bridgeless mode in a release build:
Error: Exception in HostFunction: java.lang.NoSuchMethodError: no non-static method "Lcom/facebook/react/modules/core/JavaTimerManager;.createTimer(IJZ)V"
It turns out that `JavaTimerManager.createTimer()` is getting stripped from release builds because it's not referenced in Java at all. Adding `DoNotStrip` annotation to keep it around. The other methods in JavaTimerManager don't need this because they're referenced by TimingModule - this is the only method that's only used directly from C++ by bridgeless mode.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19655519
fbshipit-source-id: 8b9862475986bb84b12d81f73f677cc2e4860c67
Summary:
fbobjc_target_sdk_version is not available in Buck used for OSS, and broke Android CI.
## Changelog
[Android] [Fixed] - Android CI dependency fetch
Pull Request resolved: https://github.com/facebook/react-native/pull/27919
Test Plan: ./scripts/circleci/buck_fetch.sh will successfully run on CI,
Reviewed By: RSNara
Differential Revision: D19663699
Pulled By: fkgozali
fbshipit-source-id: c1f10cfad6c3415c876570139f1af2bcc9e56e4e
Summary:
Previously, users of the TurboModuleManager system would have to `TurboModuleManager.installBindings()` themselves, which synchronously attached the `__turboModuleProxy` function on the JS `global` object.
After these changes, the TurboModuleManager, when created will schedule work on the JS thread to install the global `__turboModuleProxy` function. As long as you create the TurboModuleManager before you run the bundle, we'll install the bindings before any TurboModules are accessed.
Changelog:
[Android][Fixed] - Install TM Bindings on JS thread
Reviewed By: ejanzer
Differential Revision: D19335956
fbshipit-source-id: 967ac2d3a0510392f6f0e42efe79b1a0ff6768c4
Summary:
After D19565499, the `LongLivedObjectCollection` will be cleared on the JS thread when the jsi::Runtime is deleted. This diff makes it so that we never hold strong references to `CallbackWrapper`s in our Android TurboModules infra. Therefore, we can leverage the changes in D19565499 to ensure that our `jsi::Function`s are deleted before the `jsi::Runtime`.
## Caveat
If you delete a TurboModule by itself, it's jsi::Functions that haven't been invoked won't be released. This is also the case for iOS. I plan to fix this for both iOS and Android at a later point in time.
Changelog:
[Android][Fixed] - Refactor jsi::Function cleanup in TurboModules
Reviewed By: mdvacca
Differential Revision: D19589151
fbshipit-source-id: efa3cc6c83634014159ac7500dcf6bef9c925762
Summary:
It makes perfect sense because `Builder` builds totally new shadow trees, so those are not sealed or used by anyone yet.
Assigning it to const shared pointer will do logical sealing (and it does not requires const-cast).
Fewer const-casts in the code, fewer bugs.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D19596284
fbshipit-source-id: 75d1c706034958ba7e4bc80a68af75a57c46eb6f
Summary:
Before this change `Element<X>` cannot have children of `Element<Y>` which was wrong because we don't have such limitation in Fabric.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D19596283
fbshipit-source-id: 9002f5dd42b3d05e7cf492499499399c97b58152
Summary: Migrate ReactTextinputManager to support bridgeless mode by accessing the EventDispatcher through the UIManagerHelper instead of from ReactContext.
Reviewed By: mdvacca
Differential Revision: D19614184
fbshipit-source-id: 5dd4945223d10785f8fe171e06d6f7ef42f9d834
Summary:
Changelog: [Internal]
# Analysis
Measure returns following values for `frame.y` when tapping item in bottom sheet.
Fabric 412.33331298828125.
Paper 49.
In Paper, the frame.y returned is the position of tapped item in bottom sheet relative to the bottom sheet itself, which is correct.
This can happen in both BottomSheet and Modal.
# Why it happens?
In [UIManager.getRelativeLayoutMetrics](https://our.intern.facebook.com/intern/diffusion/FBS/browse/master/xplat/js/react-native-github/ReactCommon/fabric/uimanager/UIManager.cpp?commit=a372cf516ba1245ad9462e68376ee759c118a884&lines=172-181) if `ancestorShadowNode` is nullptr we populate `ancestorShadowNode` with `rootShadowNode` for the surface.
Problem is that BottomSheet that is presented, is not a separate surface. This means that we climb up the shadow node hierarchy all the way to root shadow node and keep adding offsets. Even though we should stop when we hit shadow node representing BottomSheet.
# How could be this fixed?
I think we should add a new shadow node trait that would mark node as root node. As we are traversing the shadow node tree upwards and adding offset of that node, once we hit a node that is "anchor", we would immediately stop the traversal.
This solution is inspired by Paper where the node representing BottomSheet has a special flag which marks it as "root" node.
accepttoship
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D19640454
fbshipit-source-id: bde623b1f41a9745a41f0aada7221bf924fad453
Summary: `requireNativeComponent` redboxes in bridgeless mode because there is no UIManager. This adds a handwritten view config to avoid using UIManager.
Reviewed By: ejanzer
Differential Revision: D19624044
fbshipit-source-id: 5ae68f63068a131a305754003154ee0cf0f1be46
Summary:
## Description
You're not supposed to hold on to JSI objects (ex: `jsi::Function`) past the point where their `jsi::Runtime` is deleted. Otherwise, we get a dangling pointer crash, like this: T60262810! Historically, this cleanup problem has always been really tricky to get right. With this diff, I hope to fix that problem once and for all by deleting all `jsi::Function`s when we delete the global `__turboModuleProxy` function.
## Current Setup
- The TurboModules infra uses weak references to `CallbackWrapper`s to hold on to the `jsi::Function`s passed from JS to ObjC.
- The LongLivedObjectCollection holds on to strong references to `CallbackWrapper`s. This ensures that the `jsi::Function`s aren't deleted prematurely. This also means that we can use `LongLivedObjectCollection` to delete all `CallbackWrappers`.
- `TurboModuleBinding` is the abstraction we use to install the global `__turboModuleProxy` function. It is owned by `TurboModuleManager`, and `TurboModuleManager` uses it to clear all references to `jsi::Function`s, when we delete all NativeModules.
## Solution
1. Transfer ownership of `TurboModuleBinding` from `TurboModuleManager` to the `__turboModuleProxy` function.
2. Clear the `LongLivedObjectCollection` when `TurboModuleBinding` is deleted.
Changelog:
[iOS][Fixed] - Clear all held jsi::Functions when jsi::Runtime is deleted
Reviewed By: JoshuaGross
Differential Revision: D19565499
fbshipit-source-id: e3510ea04e72f6bda363a8fc3ee2be60303b70a6
Summary:
Changelog: [Internal]
Exposes `synchronouslyWaitForStage` to `RCTFabricSurface`.
This is a first step towards having screenshot tests rendered with Fabric.
Reviewed By: shergin
Differential Revision: D19603837
fbshipit-source-id: 26c14cf3bbd67fea96319ff08d3321557ddcdd9c
Summary:
Issue: https://github.com/facebook/react-native/issues/27565
initalizeFlipper should be set in template app by default.
## Changelog
[iOS] [Changed] - Added Flipper to template app
[Android] [Changed] - Added Flipper to template app
Pull Request resolved: https://github.com/facebook/react-native/pull/27569
Test Plan:
Connect Flipper to the iOS application
Connect Flipper to the Android application
Reviewed By: passy
Differential Revision: D19344704
Pulled By: rickhanlonii
fbshipit-source-id: ca126fd2caab13751ddc2ce6d195bd0c644c704e
Summary:
We are deprecating SharedShadowNode in favor of ShadowNode::Shared, the previous diff already removed most of the usages of SharedShadowNode
changelog: [internal]
Reviewed By: shergin
Differential Revision: D19217718
fbshipit-source-id: 1b7cd1af0ecdc6112befdc45c1dd0fca5012ab21
Summary:
ShadowNode::Shared and SharedShadowNode represent the exact same type. Nowadays we use ShadowNode::Shared instead of SharedShadowNode.
This diff replaces usages of SharedShadowNode for ShadowNode::Shared in the fabric folder.
Changelog: [internal]
Reviewed By: shergin
Differential Revision: D19217717
fbshipit-source-id: 112331b22251aa3a3d5e183395c54f2ca0f56e47
Summary:
A new triage group is being set up. As part of the triage process, all new issues will be tagged as "Needs: Triage 🔍". We can achieve this by baking the label into the default issue template.
The `react-native-bot` has been updated so it does not auto-close issues tagged with this label. Previously, it would look for the presence of the "Bug" label to determine if someone used the default issue template.
I've removed HTML comments from the template to minimize confusion. Folks that may not be familiar with HTML or Markdown and how they handle comments.
## Changelog
[Internal] - Modify GitHub issue template
Pull Request resolved: https://github.com/facebook/react-native/pull/27842
Test Plan: N/A
Differential Revision: D19629687
Pulled By: hramos
fbshipit-source-id: 25a989ebc04e42e7be234244a9ded48756cb9ba4
Summary:
We can now use `rn_apple_library` to the same effect.
Changelog: [Internal]
Reviewed By: adamjernst
Differential Revision: D19610730
fbshipit-source-id: 98353b062229c192447d1f49e6fe9bdcf12c6a96
Summary:
In case when Platform is different from Android or iOS, ScrollView initialised RCTScrollView two times, which caused a crash. It looks for me that default option is obsolete and can be united with iOS one to fix this issue.
## Changelog:
[Internal] [Fixed] - Fixed crash during ScrollView initialisation if Platform.OS is not iOS or Android
Reviewed By: ejanzer
Differential Revision: D19623046
fbshipit-source-id: 84f8a46ea24b463aa6aae761f4386ab7e4e95f9b
Summary:
This validate function uses the `UIManager.getViewManagerConfig` API to verify if props are supported. Bridgeless mode doesn't support UIManager APIs.
It seems like these `deprecatedPropType` will be removed eventually, so let's ignore it in bridgeless.
Changelog: [Internal] Ignore deprecatedPropType in bridgeless mode
Reviewed By: ejanzer
Differential Revision: D19603819
fbshipit-source-id: 2c744705be8821cc6a9d8daaac3e652987447e4d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/27841
Follow up from https://github.com/facebook/react-native/pull/27539 - adding back in the optimization that Detox has in TimersIdlingResource to avoid iterating over the entire timers queue if the next timer is already within the specified range.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19522346
fbshipit-source-id: 32609f434d1ca575a5a49ad630e288c43fa90864
Summary:
Depends on https://github.com/facebook/react-native/issues/27833.
Updates the Flipper version to the most recent release.
## Changelog
[Android] [Changed] - Upgrade Flipper version in default template
Pull Request resolved: https://github.com/facebook/react-native/pull/27837
Test Plan:
This is a bit annoying, but I can't test this against the 0.62-rc.0 version. I tried patching it by running `react-native init --version 0.62.0-rc.0 testproj`, which would fail because of a missing androidx dep. After adding `implementation 'androidx.swiperefreshlayout:swiperefreshlayout:1.0.0'` to the deps, that was fixed but now after updating, `libfbjni.so` is missing because my PR https://github.com/facebook/react-native/issues/27729 isn't part of the RN dependency yet.
Given that this mirrors the RNTester app, I'm pretty confident that the change here is otherwise correct and will work on top of master with the most recent template changes.
Differential Revision: D19619365
Pulled By: passy
fbshipit-source-id: 5723bd105ab3ab86b7f00e1a26e29e1e9dc58290
Summary:
Adds build version and an onPress for the build info.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D19334440
fbshipit-source-id: b201b630086179faca31a08c62019a2019cedf4f
Summary:
Now that react-native has got rid of all the uses of create-react-class, it doesn't need to be listed as a dependency.
## Changelog
[General] [Removed] - Removed create-react-class from dependencies
Pull Request resolved: https://github.com/facebook/react-native/pull/27861
Test Plan: Will hit build break when building bundle if its still needed. Other risks are if community packages are relying on create-react-class in their code, but not declaring it in their dependencies. -- But those packages should fix their dependencies.
Differential Revision: D19568065
Pulled By: cpojer
fbshipit-source-id: be26c3376aaebfa829def12983b04349ba9907ae
Summary:
Here is a mutation test for the Diffing algorithm that we use to diff ShadowNode trees and flatten them. As a side-effect, it also "tests" that Concurrent Yoga does not crash and produces decent cloning requests.
The test works this way:
1. We create a random ShadowNode tree;
2. We create a View tree from that that we continue to maintain;
3. We apply random mutation on this;
4. We layout the tree;
5. We generate the mutation instruction comparing a previous tree with a new one;
6. We apply mutations on the first tree;
7. We generate a new tree from scratch;
8. We compare the new tree with the tree updated with mutations and expect equivalence;
9. Repeat a million times.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D19357714
fbshipit-source-id: 04765ede87d91180952ae650ff0d505dfac2ed8e
Summary:
Can be handy for general animation components, like `FancySuspense`.
ChangeLog:
[General][Added] Export LayoutAnimationConfig flow type
Reviewed By: zackargyle, TheSavior
Differential Revision: D19345668
fbshipit-source-id: 26178d1eb0b6f710f652bf82c8095dec5bf5afbd
Summary:
As discussed in https://github.com/facebook/react-native/issues/27863, the following changes were made to modernize the internal default logging function:
- `RCTDefaultLogThreshold` is now set to `RCTLogLevelTrace` in both release and debug builds—the Apple logging system will discard uncollected log entires, while allowing for collection when needed
- `RCTLogLevel` is translated to the appropriate log type
- The log subsystem is "com.facebook.react.log"
- `RCTLogSource` translates to the appropriate category ("native"/"javascript")
- Log the provided message using `os_log_with_type`
Closes https://github.com/facebook/react-native/issues/27863
## Changelog
[iOS] [Changed] - Use Apple unified logging API (os_log)
Pull Request resolved: https://github.com/facebook/react-native/pull/27892
Test Plan:
## From Original PR
Ran a test app in the iOS simulator, and verified that logs are correctly displayed in Console.app as well as using the following command:
```sh
/usr/bin/xcrun simctl spawn booted log stream --level debug --style compact --predicate 'process=="ReactNativeTesterApp" && subsystem=="com.facebook.react.log"'
```
## Peter's Test Plan
1. Apply P125583473
2. Verify log output in Xcode P125583504
3. Apply this diff
4. Verify log output in Xcode P125583597
These appear unchanged, after digging into why, I realized that FB doesn't even use the default log function, we inject a custom one [here](https://fburl.com/diffusion/887a1axs). So this PR shouldn't affect us at all. :)
Differential Revision: D19605414
Pulled By: PeteTheHeat
fbshipit-source-id: 1d70fb702c337a759905d4a65a951a31353ce775
Summary:
Introduces `Rect`, an (eventual) replacement for `EdgeInsetsProp`.
This new type is then used in `Pressability` to expand support such that `hitSlop` and `pressRectOffset` can be either a `Rect` or a numeric size.
Changelog:
[Internal]
Reviewed By: yungsters
Differential Revision: D18742616
fbshipit-source-id: 13dd360f68ab804839938fc950fa2f4b25d3ed8c
Summary:
This was all yungsters idea. I blame him. :)
Switching Pressable to be a functional component presents a new challenge. ReactNativeTestTools can no longer find its instance because there is no instance Pressable uses forwardRef.
We need a way to both find a pressable, and then call the onPress callback if the pressable isn't also disabled.
So in DEV (and thus test) we add the pressable config to a secret key on a function passed onto View. The TestTools look for this key on this function, and then can call onPress.
Super hacky, but so is all of ReactNativeTestTools. We aren't proud of this.
Changelog:
[General][Changed]: Added support for Pressable to ReactNativeTestTools.tap
Reviewed By: yungsters
Differential Revision: D18849358
fbshipit-source-id: ea8880ceedfc04cda217ee17ba140475d003172c
Summary:
When building as a framework these headers get automatically added to the framework umbrella header for React-Core. Instead of converting all the React sources to ObjC++ files and still forcing external users that build native source (and link against a framework build) to also compile as ObjC++, this makes the attribution related methods that were added in https://github.com/facebook/react-native/commit/fdcdca4 opt-in to ObjC++ builds.
This is also the reason for the current failure of the CI `test_ios_frameworks` run.
## Changelog
I’m unsure if this change really warrants an entry in the CHANGELOG, as it’s more of an amendment of the (afaik) unreleased [change](https://github.com/facebook/react-native/commit/fdcdca4).
[iOS] [Fixed] - Make framework builds work again by making `RCTImageLoader` C++ requirement opt-in
Pull Request resolved: https://github.com/facebook/react-native/pull/27730
Test Plan:
I tested static and dynamic (framework) builds and ran the test suite.
This change should make the `test_ios_frameworks` CI run _build_ again, ~~but it may still fail overall as in my local testing one of the tests leads to a segfault (which I will try to address separately)~~.
Reviewed By: PeteTheHeat
Differential Revision: D19348846
Pulled By: fkgozali
fbshipit-source-id: 8a74e6f7ad3ddce2cf10b080b9a5d7b399bd5fc0
Summary:
Changelog: [Internal]
I went over the ownership model in this call `_state->getData().getImageRequest().getImageInstrumentation().didSetImage();`
1. `getData()` returns reference to an object that is copied to state.
2. `getImageRequest()` returns a reference to an object that is strongly owned by `ImageState`.
3. `getImageInstrumentation()` returns a reference to an object that is strongly owned by `ImageRequest`.
I don't think any of these can cause a crash, however `_state` can be nullptr.
Reviewed By: shergin
Differential Revision: D19599258
fbshipit-source-id: 317f03cd9a53d83f64ccbb9f9abfce10fcc1fae5
Summary:
## Context
When a `VirtualizedList` contains a cell which itself contains more than one `VirtualizedList` of the same orientation as the parent list, we log an error if sibling lists in a cell don't have unique `listKey`s (e.g. when the `listKey` prop isn't explicitly set). In release builds, this error does not have a component stack - nor a useful call stack - so it can be hard to track down the true source of the error in complex applications.
## This diff
Here, in addition to the generic error message, we also print the `listKey`, `cellKey` and orientation of each `VirtualizedList` in the hierarchy, from the child list upwards. This is done without significant overhead, by reusing the already-in-place context that `VirtualizedList`s use to manage nesting.
The assumption is that common strategies for deriving `listKey`s and `cellKey`s will make it possible to identify at least some lists in the hierarchy in common cases, and therefore help narrow down the search space even when component stacks are not available.
## Example
(See code in unit test)
```
A VirtualizedList contains a cell which itself contains more than one VirtualizedList of the same orientation as the parent list. You must pass a unique listKey prop to each sibling list.
VirtualizedList trace:
Child (horizontal):
listKey: level2
cellKey: cell0
Parent (horizontal):
listKey: level1
cellKey: cell0
Parent (vertical):
listKey: level0
cellKey: rootList
```
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D19600366
fbshipit-source-id: 73f29507ec58a6a3f9b3f6b174a32b21dcd237a1
Summary:
Migrate ReactTextinputManager to support bridgeless mode by accessing the EventDispatcher through the UIManagerHelper instead of from ReactContext.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19456326
fbshipit-source-id: 5e9643793cd764e29964f565db24cdea683ac032
Summary:
Migrating ReactImageView to use the new API for accessing the EventDispatcher (UIManagerHelper.getEventDispatcherForReactTag) that supports bridgeless mode.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D19190765
fbshipit-source-id: a958dfc9c48845270e99f8d378ce034cddc8036f
Summary:
In my app I have a case where I need to pass a very large string (45MB) between JS and native. This is obviously suboptimal, but… this is where I'm at.
The main bottleneck to doing this turned out to be `jsi`'s `JSStringToSTLString()`, which was extremely slow. In my case, 4.7s to execute. After this change, 204ms.
I don't really know C++, so I'm not sure this code is 100% correct and safe, and I bet it could be done even better by avoiding the extra memory allocation (would shave off another 70ms).
## Changelog
[General] [Changed] - Make JSStringToSTLString 23x faster
Pull Request resolved: https://github.com/facebook/react-native/pull/26955
Reviewed By: shergin
Differential Revision: D19578728
Pulled By: motiz88
fbshipit-source-id: 2fbce83166953ce928f0a6aa36eed710bfe05383
Summary:
Changelog: [internal]
1. Creates `ShadowNodeFamily` inside `ComponentDescriptor`.
2. As a side effect of this, we no longer need `ComponentDescriptor::createEventEmitter` so it is removed.
This is a step in order to merge `StateCoordinator` into `ShadowNodeFamily` and use it as target for state updates.
Reviewed By: shergin
Differential Revision: D19514906
fbshipit-source-id: 04ad3c621886be56925acd76f9b35a09d8c5e15a
Summary:
Changelog: [internal]
1. Use `ShadowNode::Shared` instead of `SharedShadowNode`.
2. Initialise `ShadowNodeFamily` before `ShadowNode`.
Why?
This is a step in order to merge `StateCoordinator` into `ShadowNodeFamily` and use it as target for state updates.
Reviewed By: shergin
Differential Revision: D19471399
fbshipit-source-id: 2f67901c901349d238c711f9eeaadb19fe7c1110
Summary:
Changelog: [internal]
1. Moves `ShadowNode::getAncestors` to `ShadowNodeFamily`.
2. Exposes shadowNode's family through `ShadowNode::getFamily()`.
# Why?
This is a first step in order to merge `StateCoordinator` into `ShadowNodeFamily` and use it as target for state updates.
Reviewed By: shergin
Differential Revision: D19465188
fbshipit-source-id: b5a3625aa21c040301259de02beedbf97e11f20e
Summary:
The FBJNI compat issue is gone so this is working now. �
Still a bit ugly to set up, but that's on our ToDo. Next: Template.
## Changelog
[Android] [Fixed] - Use modern Flipper SDK version for RNTester
Pull Request resolved: https://github.com/facebook/react-native/pull/27833
Test Plan:
```
./gradlew :RNTester:android:app:installHermesDebug
```
Reviewed By: cpojer
Differential Revision: D19513412
Pulled By: passy
fbshipit-source-id: af118bd364ab316732e2a1e657fa1b682bf7da59
Summary:
`SnapToInterval` is a Float in JavaScript, if we pass it and try to convert it to Int, it crashes in C++.
exception
> libc++abi.dylib: terminating with uncaught exception of type folly::ConversionError: Loss of precision during arithmetic conversion: (long long) 1.15
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D19580509
fbshipit-source-id: f705f92953195a9e034f6ce3fe7a077007d5212d
Summary:
Collecting Telemetry is a crucial part of building a performant UI framework; we do that but we need to improve it to make the data more reliable, actionable and trustful.
Now we collect time points as the number of milliseconds from the start of the CLOCK_MONOTONIC epoch. That's fine but it also has problems:
Sometimes a millisecond is an eternity. We have only 16 (or fewer) of them on each frame. What if some operation takes 1ms (according to telemetry) but we have to run it a dozen times? Does it mean that it's 12 ms in total? So, we lack precision.
This is not type-safe. Do you know how many milliseconds in a microsecond? I don't. We multiply that on magical constants hoping that we copied that from some other place right.
The current implementation is not cross-platform. We have ifdefs for iOS and Android and Unix and Windows (which is now implemented).
So, this diff replaces that with using `std::chrono` which is part of the standard library that designed to fix all those concerns. We also define our type-aliases on top of that to express our concrete constrains:
We use `std::chrono::steady_clock` as the base clock which is according to the standard using `clock_gettime(CLOCK_MONOTONIC, ... )` if available. So, it's fast and compatible (the same under the hood) with Android infra.
We use nanoseconds when we store time durations (TelemetryDuration type).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D19184569
fbshipit-source-id: 7a44688f4bb3bfc6e3009874f0075c531c8569a1
Summary:
Some tests which will be useful for the next diff.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D19482255
fbshipit-source-id: 3384662477f750620a37acc4a277a55c2dbd8d0e
Summary:
This is a part of migration staterted in D19390813.
There is no need to have those as `const`. The whole `*Props` object is usually `const` (and when it's not, props should not be too).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D19583582
fbshipit-source-id: 9c680268f944cdf08669fce7e997b05f23a02667
Summary:
Use newer detox version to take advantage of Android compatibility fix
Changelog:
[Internal] Updating Detox from 14.5.1 to 15.1.4
Reviewed By: TheSavior
Differential Revision: D19564679
fbshipit-source-id: adc3c9acc8b2004b201b7106045ae0d3d3e9e779
Summary:
In `XMLHttpRequest`, if the responseType is `Blob`, but the response is an empty string, we return `null` from `XMLHttpRequest.prototype.response()`. Instead, we should return an empty Blob. This is the behaviour on the web. To demonstrate, run the following HTTP server with Node:
## server.js
```
const http = require('http');
const server = http.createServer();
server.on('request', (request, response) => {
if (request.url.includes('img.png')) {
console.log('sending image');
response.end('');
return;
}
response.end('Hello World!');
});
server.listen('9000');
```
Then, open up a web browser to `http://localhost:9000`, and type the following in the console:
```
var oReq = new XMLHttpRequest();
oReq.open('GET', 'http://localhost:9000/img.png', true);
oReq.responseType = 'blob';
oReq.onload = function(oEvent) {
var blob = oReq.response;
console.warn(blob);
};
oReq.onerror = function(error) {
console.warn('Error!');
};
oReq.send();
```
This warns:
```
Blob {size: 0, type: "text/xml"}
```
Changelog:
[Both][Fixed] - [RN][XMLHttpRequest] Transform empty responses into empty Blobs
Reviewed By: sahrens
Differential Revision: D19500607
fbshipit-source-id: ec35e534b32a507c8a94a29e955b7bc4c62902a0
Summary:
Based on [this](https://stackoverflow.com/a/5259004), header names are not case sensitive.
That means that it's valid to pass a header `Origin` or `origin`.
With the current implementation. on Android only, if you pass `Origin`, it will get overwritten by the default origin.
This made me waste a lot of time debugging a problem while trying to connect to a websockets server that required an `origin` header and my implementation was working fine in iOS but not on Android, so I'm suggest changing the logic a little bit to take that into account.
## Changelog
[Android] [Fixed] - Support for case insensitive "Origin" headers for Websockets
Pull Request resolved: https://github.com/facebook/react-native/pull/27827
Test Plan:
Here's a screenshot of that shows the issue before the fix (`Origin` header set, but getting overridden)
The fix is not that easy to test since it requires a public websocket server that checks for a custom Origin header, but I think the code changes are very small and clear.
Differential Revision: D19578860
Pulled By: cpojer
fbshipit-source-id: d854e887d1b9e8e54da662b2da2ebe08ce65fdbc
Summary:
make ReactTestHelper always return a test object set to use
Hermes.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D19566604
fbshipit-source-id: 3c8fc680afbae000adb96bfcd079104d86cf06bd
Summary:
When I was testing React Native 0.62-rc.1, I noticed that console was showing a warning for Require Cycle as shown in image below
This is because ScrollResponder was importing `ScrollView` to get the `typeof ScrollView`.
I've made an export for ScrollView type in `ScrollView` so that Require cycle warning will not show up.
## Changelog
[General] [Fixed] - Remove Require cycle warning.
Pull Request resolved: https://github.com/facebook/react-native/pull/27851
Differential Revision: D19577644
Pulled By: cpojer
fbshipit-source-id: 257b9421a91244d69394375102cfbe683326bba2
Summary:
Fixes https://github.com/facebook/react-native/issues/27137
This PR fixes an issue on iOS where RCTTextView height is not calculated as it should for some fonts where font `leading` attributed is not equal to zero, which results in wrong baseline alignment behaviour.
The fix for this is by setting `usesFontLeading` property of `NSLayoutManager` to `NO`, which results is a layout behavior that is similar to `UILabel`
Probably the documentation for `usesFontLeading` describes why UILabel has a different (correct) layout behavior in that case
> // By default, a layout manager will use leading as specified by the font. However, this is not appropriate for most UI text, for which a fixed leading is usually specified by UI layout guidelines. These methods allow the use of the font's leading to be turned off.
## Changelog
[iOS] [Fixed] - Fix RCTTextView layout issue that happens on some font with `leading` attribute not equal to zero, which causes wrong base-alignment layout
Pull Request resolved: https://github.com/facebook/react-native/pull/27195
Test Plan:
Below are the test results before and after the change, and comparing that to native UILabel behavior.
The test is done with using system font and custom font (`GothamNarrow-Medium`) and font size 50
[GothamNarrow-Medium.otf.zip](https://github.com/facebook/react-native/files/3832143/GothamNarrow-Medium.otf.zip)
```js
const App: () => React$Node = () => {
return (
<View style={{flex: 1, margin: 40, flexDirection: 'row', justifyContent: 'center', alignItems: 'baseline'}}>
<View style={{width: 30, height: 30, backgroundColor: 'lightgray'}} />
<Text style={{fontSize: 50, backgroundColor: 'green', fontFamily: 'GothamNarrow-Medium'}}>{'Settings'}</Text>
</View>
);
};
```
-------
### Before the fix
<img width="962" alt="Screenshot 2019-11-11 at 16 53 26" src="https://user-images.githubusercontent.com/5355138/68601049-dd778780-04a3-11ea-879e-cc7b4eb2af95.png">
-----
### After the fix
<img width="944" alt="Screenshot 2019-11-11 at 16 55 11" src="https://user-images.githubusercontent.com/5355138/68601180-1d3e6f00-04a4-11ea-87bc-61c6fa2cdb18.png">
-----
### Using `UILabel`
<img width="805" alt="Screenshot 2019-11-11 at 16 59 28" src="https://user-images.githubusercontent.com/5355138/68601487-b2d9fe80-04a4-11ea-9a0f-c025c7753c24.png">
Differential Revision: D19576556
Pulled By: shergin
fbshipit-source-id: 4eaafdab963c3f53c461884c581e205e6426718a
Summary:
This change will keep project consistency.
This change repeat the previous commit 582738bdc8.
That was created by sammy-SC and reviewed by shergin
That changed
* `ASSERT_TRUE` -> `EXPECT_TRUE`
* `ASSERT_NEAR` -> `EXPECT_NEAR`
* `ASSERT_EQ` -> `EXPECT_EQ`
That said
> 1. Replace ASSERT_* with EXPECT_*. Assert is a fatal assertion. Expect is non-fatal assertion. So if assert fails, tests do not continue and therefore provide less information.
>
> 2. Rename tests in `RawPropsTest.cpp` from `ShadowNodeTest` to `RawPropsTest`.
>
> Source: https://github.com/google/googletest/blob/master/googletest/docs/primer.md#basic-assertions
## Changelog
[CATEGORY] [TYPE] - Message
Pull Request resolved: https://github.com/facebook/react-native/pull/27850
Differential Revision: D19568014
Pulled By: shergin
fbshipit-source-id: 7c22cd1c7ec919675e834a060bd5e681d43a8baf
Summary:
It seems like DisplayMetricsHolder doesn't have any thread safety policy, but in practice it only updates DisplayMetrics from the main thread. Let's formalize that by adding some annotations to that effect.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19417331
fbshipit-source-id: f1d464f228776197fd0df2978c9e8edbaab67850
Summary: Somehow, `RCTAppState` is still trying to send events without the bridge. This diff effectively silences the warning, since I still believe there is no point sending events to JS if the bridge is nil.
Reviewed By: fkgozali
Differential Revision: D19560149
fbshipit-source-id: 5077335f6a47fe7d1896e078668c1eb4da1339de
Summary:
The reason for this change is that it is the primary root that we want people to be using and the naming should reflect that.
#nocancel
build-break
overriding_review_checks_triggers_an_audit_and_retroactive_review
Changelog: [Internal]
Oncall Short Name: fbobjc_sheriff
Differential Revision: D19431128
fbshipit-source-id: c7208e20ed0f5f5eb6c2849428c09a6d4af9b6f3
Summary:
Fix initial width measurement of AndroidTextInput.
The lifecycle here between measure and layout is a little wacky. I put this in comments too, but:
1. Measure is called first. It's marked as const so it can't call updateStateIfNeeded.
2. Layout is called immediately after. It's not const so it calls updateStateIfNeeded.
3. The state is updated, but it's not part of a commit, it just mutates the node in-place.
4. If the node isn't dirtied again, measure won't be called again.
For completeness: I did try calling `dirtyLayout` in the `layout` method. That does not work.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19549803
fbshipit-source-id: f3798e10dca2edacb364cc5b53f58f091de5e4d0
Summary:
We should have been calling this already. Trivial fix. The intent of the view command was always to update selection, I just forgot to add it. See test videos.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19548178
fbshipit-source-id: 14a1bdc11d84c05f2435c48c3bb96b64e8c68cb4
Summary:
Since we're using `tryCommit`, there could be races between two updates to state attached to the same node, especially if a ComponentDescriptor's `createState` implementation uses previous state data to create the new state object. By creating the State object from the "old" node within the tryCommit lambda, we prevent races.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D19542908
fbshipit-source-id: 787e4aefc573adf1fa308a6fa859123976a823e7
Summary:
Since migrating to Turbomodules (8fe04cf) the addMenuItem method crashes because the NativeEventListener methods are missing from the codegen flow type. Added the same methods based on what we do in AppState which is another native module that extends NativeEventListener.
## Changelog
[Internal] [Fixed] - Add missing NativeEventListener methods to NativeDevSettings
Pull Request resolved: https://github.com/facebook/react-native/pull/27838
Test Plan:
|Before|After|
|{F226978596}|{F226978628}
Differential Revision: D19518474
Pulled By: PeteTheHeat
fbshipit-source-id: acddba9f18dd558df1d6df78b539689fdfd0062f
Summary:
Changelog: [Internal]
The inspector API doesn't really need a `HermesRuntime`, all it needs is a `jsi::Runtime` and a `Debugger &`.
Change the return type of `RuntimeAdapter::getRuntime` to be `jsi::Runtime`.
This will allow the inspector to use the tracing runtime instead of the direct hermes runtime.
Reviewed By: willholen
Differential Revision: D18973867
fbshipit-source-id: 6809e52452a35e62be9ca8143aeaba8964c98eaa
Summary:
That should help with debugging SafeAreaView-related issues (esp. to see the info inside view hierarchy recursive description).
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D19539216
fbshipit-source-id: 1bee481c2766ad2d130e435582876d9f5ed27b3c
Summary:
This diff refactors the UIManagerHelper.getUIManager to allow the caller determine if it should return null when catalyst Istance is not active.
This is necessary in order to keep backward compatibility for the getEventDispatcher method.
changelog: [internal]
Reviewed By: makovkastar
Differential Revision: D19383063
fbshipit-source-id: 8a46b61d212480be91ea78929bbfa7248d5f3ad9
Summary:
Previously, State revision number was implemented manually as part of the StateData. Now we have it as a built-in concept in State, so we can rely on that.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D19467161
fbshipit-source-id: cac907265090730cdb89207aad2b52141cda5dc6
Summary:
This diff introduces a revision concept to a State object. Every newly created State object gets a revision number which equals a source state object revision number plus one.
This functionality is useful to detect which state object is newer.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D19467162
fbshipit-source-id: fc5e165193009c9818bf124bd4df7021288b2389
Summary:
Noticed the _validateMapping call right now is a no-op, as the traverse method is never invoked. We can only really do validation once we've received a sample of an event, and can then verify the values being extracted indeed correspond with a valid key.
Changelog: [General] [Fixed] - Fix validation of event mappings for AnimatedEvent
Reviewed By: cpojer
Differential Revision: D19498971
fbshipit-source-id: e978dda895498a7e567d5e18b3181b319d88d95c
Summary:
A previous PR broke toggling between visible and non-visible password (basically once a password field was made visible, future updates to the keyboardType were effectively ignored, so the password would always be visible).
Original PR: https://github.com/facebook/react-native/pull/27523
Changelog: [Internal]
Reviewed By: mdvacca, rodrigos-facebook
Differential Revision: D19527245
fbshipit-source-id: a5ab343c8a0c6a608171dbfa5afc7536ff241826
Summary:
Files that are to be part of the user’s project shouldn’t have FB copyright notices.
There’s [one notice left](https://github.com/facebook/react-native/blob/66601e755fcad10698e61d20878d52194ad0e90c/template/android/app/src/debug/java/com/helloworld/ReactNativeFlipper.java#L2) in the `android` template, which is in a file that doesn’t seem to be intended to be changed by the user and so that seems fine to me.
## Changelog
[iOS] [Removed] - Remove copyright notices from iOS application template
Pull Request resolved: https://github.com/facebook/react-native/pull/27725
Test Plan:
```bash
npx react-native init TestTemplateUpdates --template ~/Code/ReactNative/react-native
cd ios
xcodebuild -workspace TestTemplateUpdates.xcworkspace \
-scheme TestTemplateUpdates \
-destination 'platform=iOS Simulator,OS=latest,name=iPhone 8' build
[…]
** BUILD SUCCEEDED **
```
Differential Revision: D19343386
Pulled By: TheSavior
fbshipit-source-id: a78be5e5d2fdc2477adedb51d6bb3ff19845b75f
Summary:
This diff refactors the usages of UIManagerHelper.getUIManager() to make sure we always consider null objects.
Some of the callsites were throwing a NullPointerExcetpion, now they throw a more explicit exception.
changelog: [internal]
Reviewed By: makovkastar
Differential Revision: D19383064
fbshipit-source-id: 1806a37528e80cab1c8fdff5eb631aaf47bde819
Summary:
Replace with `:container_evicting_cache_map`
Changelog: [Internal]
Rename `//xplat/folly:evicting_cache_map` to `//xplat/folly:container_eviciting_cache_map` to follow the new target name conventions
Reviewed By: JoshuaGross, nlutsenko
Differential Revision: D19374914
fbshipit-source-id: fadcaeac20fe61af79e1eecb1be5642f2ef96285
Summary:
Hand-writing a JS view config for AndroidTextInputNativeComponent.
This diff was generated by adding logging to `getNativeComponentAttributes`. Diff preview: https://our.intern.facebook.com/intern/diff/view-version/96875488/
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19456328
fbshipit-source-id: b2d5abd2fde380be182b95881c335d24481343f1
Summary:
`Element` is an abstraction layer that allows describing component hierarchy in a declarative way. Creating `Element`s themself does not create a component tree (aka `ShadowNode` tree) but describes some hierarchical structure that might be used to build an actual component tree (similar to XML Elements).
`Element<>` provides some basic type-safety guarantees: all modifications of element objects require using objects (such as Props or State) of compatible type.
For now, the only useful application of that is building tests.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D19512392
fbshipit-source-id: eb0711c2a537865fa5454dbede53412a135058cf
Summary: On iOS we don't emit the didUpdateDimensions event in JS when the first React Native screen is rendered, so let's keep the behavior the same on Android.
Reviewed By: mdvacca
Differential Revision: D19506829
fbshipit-source-id: d0122d18be79177318c3f059ed396f990eeabcb7
Summary:
This is a trivial cleanup of an unused variable.
changelog: [internal]
Reviewed By: makovkastar
Differential Revision: D19383062
fbshipit-source-id: 937c8bb6de3aeebefb07940809340104654619fc
Summary:
# Changes
1. Fixes a bug when calling `LayoutableShadowNode::getRelativeLayoutMetrics` with `this` being the same node as ancestor.
2. Refactors logic that increments `layoutMetric.frame.origin` by iterating through ancestors.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D19468690
fbshipit-source-id: 5b9e187adc26a206da035e4387bb5f528aabdbb2
Summary:
This is an easy refactor of constants in ImageResizeMode
changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D19509348
fbshipit-source-id: 2bed9e35f0c7daa04c64ec7fba6975517633bfa7
Summary:
This PR makes it possible for subclasses of `ReactTextInputShadowNode` to control the construction of the "dummy" `EditText` instance that `ReactTextInputShadowNode` internally uses to determine the expected height of the view. This PR does not change the default behavior, it just opens up that default to being overriden.
This is useful in the case of custom views that have different behavior from a "default" `EditText` instance (`new EditText(context)`). For example, it might have a different style applied.
As a side benefit, this change also makes it easy to have subclasses not apply the default theme, which can allow the custom view to avoid a longstanding crash issue (https://github.com/facebook/react-native/issues/17530).
## Changelog
[Android] [Added] - Allow overriding `EditText` construction in `ReactTextInputShadowNode`
Pull Request resolved: https://github.com/facebook/react-native/pull/27782
Test Plan: All tests pass.
Reviewed By: mdvacca
Differential Revision: D19450593
Pulled By: JoshuaGross
fbshipit-source-id: 8d2ce6117246fc3e2108623312b38583af5722b3
Summary:
This fixes a build failure with buck introduced with https://github.com/facebook/react-native/issues/27729. The internal and external buck overlays diverged in how fbjni was imported. The Buck re-export here ensures that the targets resolve both internall and externally.
## Changelog
[Android] [Fixed] - RNTester Buck Build
Pull Request resolved: https://github.com/facebook/react-native/pull/27826
Test Plan:
buck fetch rntester
buck build rntester
Reviewed By: jknoxville
Differential Revision: D19496769
Pulled By: passy
fbshipit-source-id: d699a5f64f691ed375cfc7a9d6a5a6f6e36ba283
Summary:
There is no guarantee that the pointer is not null, so we have to check for it. And particularly, the `instrumentation` pointer is null when the `ImageSource`'s type is `invalid`.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D19482208
fbshipit-source-id: e1eab02841b1594136388e51d9d5b5c881ab9366
Summary:
This is an incomplete effort to migrate from libfb to libfbjni. This is needed to restore the compatibility with Flipper and other FB Android projects that make use of FBJNI. Effectively, the outcome is that `fbjni` no longer has a checked-in copy here, but instead relies on the public artifacts published at github.com/facebookincubator/fbjni that can be deduplicated at build-time.
**A non-exhaustive list of tasks:**
* [X] Gradle builds the SDK and RNTester for Android.
* [X] Buck build for rntester works in OSS.
* [ ] Move from `java-only` release to full `fbjni` release. This requires finding a solution for stripping out `.so` files that the old `Android.mk` insists on including in the final artifacts and will clash with the full distribution.
* [ ] Import this and fix potential internal build issues.
* [ ] Verify that the changes made to the Hermes integration don't have any unintended consequences.
## Changelog
[Android] [Changed] - Migrated from libfb to libfbjni for JNI calls
Pull Request resolved: https://github.com/facebook/react-native/pull/27729
Test Plan:
- CI is already passing again for Gradle and Buck in OSS.
- After applying the following patch, RNTester builds and works with the latest Flipper SDK:
```
diff --git a/RNTester/android/app/build.gradle b/RNTester/android/app/build.gradle
index b8a6437d7..eac942104 100644
--- a/RNTester/android/app/build.gradle
+++ b/RNTester/android/app/build.gradle
@@ -170,10 +170,19 @@ dependencies {
debugImplementation files(hermesPath + "hermes-debug.aar")
releaseImplementation files(hermesPath + "hermes-release.aar")
- debugImplementation("com.facebook.flipper:flipper:0.23.4") {
+ debugImplementation("com.facebook.flipper🐬+") {
exclude group:'com.facebook.yoga'
- exclude group:'com.facebook.flipper', module: 'fbjni'
- exclude group:'com.facebook.litho', module: 'litho-annotations'
+ exclude group:'com.facebook.fbjni'
+ }
+
+ debugImplementation("com.facebook.flipper:flipper-network-plugin:+") {
+ exclude group:'com.facebook.yoga'
+ exclude group:'com.facebook.fbjni'
+ }
+
+ debugImplementation("com.facebook.flipper:flipper-fresco-plugin:+") {
+ exclude group:'com.facebook.yoga'
+ exclude group:'com.facebook.fbjni'
}
if (useIntlJsc) {
```
Reviewed By: mdvacca
Differential Revision: D19345270
Pulled By: passy
fbshipit-source-id: 33811e7f97f44f2ec5999e1c35339909dc4fd3b1
Summary:
LocalData isn't used by any components. We've moved towards State.
Changelog: [internal]
Reviewed By: shergin
Differential Revision: D19250738
fbshipit-source-id: 38ab19f63e4a249748555e9181141340729b4510
Summary:
LocalData isn't used by any components. We've moved towards State.
Changelog: [internal]
Reviewed By: mdvacca
Differential Revision: D19250737
fbshipit-source-id: 10bf0b62ffad01ad10b07d029e84df4f312780a1
Summary:
LocalData isn't used by any components. We've moved towards State.
Changelog: [internal]
Reviewed By: mdvacca
Differential Revision: D19250732
fbshipit-source-id: dd23a723c5392632165798f6365ea107b37b54cd
Summary:
LocalData isn't used by any components. We've moved towards State.
Changelog: [internal]
Reviewed By: mdvacca
Differential Revision: D19250603
fbshipit-source-id: f95da375117dcb8f6540a6c75d3a80bba630672c
Summary:
Add Native Commands handlers to TextInput.
It is intentionally done in a way so that it can be easily swapped for codegened implementation once we properly type TextInput.
We also add native commands to view managers for backwards compatibility.
Changelog: [Internal]
Reviewed By: TheSavior, shergin
Differential Revision: D19412026
fbshipit-source-id: 8dc64275cf1da599b1bd5992a41035d51dd4148f
Summary:
Adds a bare minimum test that verifies correct behaviour of `getRelativeLayoutMetrics`.
Changelog: [internal]
Reviewed By: shergin
Differential Revision: D19449128
fbshipit-source-id: afde997a770921d580575eb0cdd04fce6252cb5a
Summary:
# Logs
```
[tid:com.facebook.react.JavaScript][ConcreteViewShadowNode.h:119] width: 0 tag: 1432 debugValue: r1
[tid:com.facebook.react.JavaScript][ConcreteViewShadowNode.h:119] width: 375 tag: 1432 debugValue: r2
[tid:com.facebook.react.JavaScript][ConcreteViewShadowNode.h:119] width: 375 tag: 1432 debugValue: r2
[tid:com.facebook.react.JavaScript][UIManager.cpp:197] width: 0 tag: 1432 debugValue: r1/sealed <----------------- FIRST TAP
[tid:com.facebook.react.JavaScript][UIManager.cpp:197] width: 0 tag: 1432 debugValue: r1/sealed <----------------- FIRST TAP
[tid:com.facebook.react.JavaScript][ConcreteViewShadowNode.h:119] width: 375 tag: 1432 debugValue: r4
[tid:com.facebook.react.JavaScript][ConcreteViewShadowNode.h:119] width: 375 tag: 1432 debugValue: r5
[tid:com.facebook.react.JavaScript][ConcreteViewShadowNode.h:119] width: 375 tag: 1432 debugValue: r6
[tid:com.facebook.react.JavaScript][ConcreteViewShadowNode.h:119] width: 375 tag: 1432 debugValue: r7
[tid:com.facebook.react.JavaScript][ConcreteViewShadowNode.h:119] width: 375 tag: 1432 debugValue: r8
[tid:com.facebook.react.JavaScript][UIManager.cpp:197] width: 375 tag: 1432 debugValue: r7/sealed <----------------- SECOND TAP
[tid:com.facebook.react.JavaScript][UIManager.cpp:197] width: 375 tag: 1432 debugValue: r7/sealed <----------------- SECOND TAP
```
# What’s happening here?
Opening a *BottomSheet* and tapping the first item. As you can see before the item is tapped, it has *width* set to 375 in revision *r2*.
When the tap happens, JavaScript is requesting an old revision of ShadowNode, which still has width 0.
# My assumption.
1. Native creates node with *width* 0 and returns handle to *JS*.
2. Native *clones* the node, sets its *width* to 375, doesn’t tell *JS* about it. This update is due to state change.
3. *JS* tries to get the size of the node, but asking for first revision of the component it receives width 0.
# Other observations
1. Manually setting width to 375 in UIManager::getRelativeLayoutMetrics fixes the problem.
2. This happens only on device, I wasn’t able to reproduce this on simulator.
# Fix
Find the newest revision of ShadowNodeFamily, and return its layoutMetrics.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D19433873
fbshipit-source-id: 4558cf6e704051e9b3968e83821d8d25b3dadcda
Summary:
# Problem
The issue is in implementation of `LayoutableShadowNode::getRelativeLayoutMetrics`.
If you have view tree (A has a child B), and you call `B.getRelativeLayoutMetrics(A)`, the expected result is B's origin within A. The implementation wasn't reflecting that, it was reflecting B's origin within A + A's origin within its parent.
# Fix
When iterating over ancestors of ShadowNode, the last ancestor should be skipped.
AncestorList is a list that starts with provided ancestor and ends with parent of `this`. To skip provided ancestor we iterate to `rend() - 1`.
# Why does it work in some cases?
This function is triggered from `UIManager.getRelativeLayoutMetrics` without `ancestorShadowNode` provided, we find the RootShadowNode, which has origin `{0, 0}`.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D19447900
fbshipit-source-id: 4a9606dc1fab3fecfb85d337b014188d80e5b355
Summary:
Changelog: [Internal]
Refactor the setup code for tests to a single place.
Now there is fixed set of nodes where we test different methods of ShadowNode.
Reviewed By: shergin
Differential Revision: D19464966
fbshipit-source-id: 749e9f56ac2e5489647885b2ddcb1309eb20909a
Summary:
Changelog: [Internal]
1. Replace ASSERT_* with EXPECT_*. Assert is a fatal assertion. Expect is non-fatal assertion. So if assert fails, tests do not continue and therefore provide less information.
2. Rename tests in `RawPropsTest.cpp` from `ShadowNodeTest` to `RawPropsTest`.
Source: https://github.com/google/googletest/blob/master/googletest/docs/primer.md#basic-assertions
Reviewed By: shergin
Differential Revision: D19464967
fbshipit-source-id: add83751ebdb0a12fbf8f70b851747aa5624366a
Summary:
This fixes a crash caused by a `JSError` exception not being successfully caught in a different dynamic library from where it was thrown. Since the libraries were compiled with hidden symbols and loaded with `RTLD_LOCAL`, the exception typeinfo becomes unique to each module.
Reading on this subject:
https://gcc.gnu.org/wiki/Visibilityhttps://stackoverflow.com/questions/14268736/symbol-visibility-exceptions-runtime-error
Reviewed By: mhorowitz
Differential Revision: D19343161
fbshipit-source-id: 4eb3bc2576bbcca2c3aef4f52b5a27dfde214c6a
Summary:
This diff ensures the measurement and rendering of FB emojis is correnct in RN Android.
Before this commit we were customizing Spannable object with FB emojis right before rendering the text into the TextView, this diff ensures that the Spannable is "customized" as soon as it is created, ensuring the measurement of the Text.
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D19354107
fbshipit-source-id: 92e07cf30503404f7820f25eaa9efdc02f6bddbd
Summary:
After some more testing, I discovered a problem in D19395326 because the native map that DeviceInfoModule was storing in `mPreviousDisplayMetrics` had been consumed when the event was emitted to JS. This caused the comparison to fail, so it would emit the event again when the dimensions hadn't changed.
In this diff, I'm storing a Java-only copy of the native map before emitting the event to JS so this shouldn't happen.
Changelog: [Android][Fixed] Fix bug in updating dimensions in JS
Reviewed By: mdvacca
Differential Revision: D19462861
fbshipit-source-id: 2e47479df93377b85fe87f255972dd31e874e3a8
Summary:
ReactRootView currently caches the last seen DisplayMetrics so we can compare them against the current values in DisplayMetricsHolder to determine if the screen dimensions have changed. (If they have changed, we emit an event to notify JS of the new dimensions).
However, ReactRootView initializes these member variables with empty DisplayMetrics, which means that the first time we check against them in onGlobalLayout, we will *always* emit an event to JS.
This seems reasonable if you only have one ReactRootView, but if you create a new RRV for each RN screen in your app, then you're going to get updated dimensions on each navigation event, even though the screen dimensions have probably not changed.
In this diff, I'm no longer storing the DisplayMetrics in ReactRootView at all, but instead am using temporary variables to check the new DisplayMetrics values against the old.
Changelog: [Android][Fixed] Only update dimensions in ReactRootView if they've changed
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D19395326
fbshipit-source-id: c01aee73064764503c9b49208032c790b83a1d29
Summary:
```
Welcome to Gradle 6.1!
Here are the highlights of this release:
- Dependency cache is relocatable
- Configurable compilation order between Groovy, Java & Scala
- New sample projects in Gradle's documentation
For more details see https://docs.gradle.org/6.1/release-notes.html
```
## Changelog
[Android] [Changed] - Update Gradle wrapper to 6.1
Pull Request resolved: https://github.com/facebook/react-native/pull/27800
Test Plan: Build project
Differential Revision: D19460735
Pulled By: mdvacca
fbshipit-source-id: b5e71cf97c0208947d6e524a74907b74f6a71c8d
Summary: As titled. The work to write the spec and make this module compatible were done in D18148890.
Reviewed By: RSNara
Differential Revision: D19442016
fbshipit-source-id: 369bb4247d6590d41ec414f93c79d98d4a6bed88
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/27783
Use Xcode 11.3.0 to run tests, using an iPhone 8 simulator running iOS 13.3.
Snapshot tests disabled as they're failing on Circle CI.
Changelog:
[iOS] [Changed] - Use Xcode 11.3 and iOS 13.3 simulator in iOS tests
Reviewed By: PeteTheHeat
Differential Revision: D19411972
fbshipit-source-id: 3ddef9e6fbdbd3c35271732fc6d6d74de099230e
Summary: Changelog: [Fix] Fix status bar color not updating when navigating between two screens with the same status bar color.
Reviewed By: RSNara
Differential Revision: D19439424
fbshipit-source-id: 44388f1f94c87c12102471d72183bb6c152a46b6
Summary:
For some reason, I think this method is being optimized away, which is really strange considering that it's being used in getModule.
Changelog:
[Internal]
Reviewed By: ejanzer
Differential Revision: D19454855
fbshipit-source-id: 414b4888f7aacf730dd22939e2e2140b94dff4e7
Summary:
In bridgeless mode, `RCTTurboModuleManager` is initialized with a nil bridge. This has mostly worked, since `RCTBridge` doesn't do too many things for TMM (some notifs and perf markers). The one important thing it provides is a `_jsInvoker`.
In bridgeless mode, up until this point `_jsInvoker` has been nil, and turbo modules were not able to call functions on the JS thread. This diff fixes that.
Reviewed By: RSNara
Differential Revision: D19437174
fbshipit-source-id: 86bfc0a47bd9576e7d3203b860e86446eb0b63dd
Summary:
We should also call `TurboModuleManager.getLegacyCxxModule('foo')` when we call `TurboModuleManager.getModule('foo')` is called.
This fixes a Marketplace crash. See: D19432594
Changelog:
[Android][Fixed] - Ensure TMM.getModule also queries CxxModuleWrappers
Reviewed By: ejanzer
Differential Revision: D19434549
fbshipit-source-id: cff741cf1587d2a0dbcdc5eb95016c8aa283b727
Summary:
In order to be sure that 0.62 does not require an exact-by-default codebase, we should get rid of any `{}` occurrences inside of react-native-github. If all the object types in react-native-github are either explicitly exact `{||}` or explicitly inexact `{...}` then those object types will have consistent semantics regardless of the Flow settings in the client codebase.
Changelog: [Internal]
Reviewed By: rickhanlonii
Differential Revision: D19347283
fbshipit-source-id: 4c199bd7f1684b70df1b1c717941d0d477f67117
Summary:
Changelog: [Internal] Upgrade Chrome devtools protocol for Hermes
Update to the most recent version of the devtools protocol, r730699.
This just adds a few parameters to the stable API.
They have reasonable defaults that shouldn't break the existing functionality.
Reviewed By: willholen
Differential Revision: D19387559
fbshipit-source-id: 49d9ebf4a1a20f349ea6e46be6d5f36184ba8afb
Summary:
Changelog: [Internal]
Before, we were relying on checking out the `devtools-protocol` Github repo at a specific commit and
making special changes to the JSON file.
In order to make it easier to update, use the officially published npm package.
I found the closest package version that was published, but it had two differences:
* `Runtime.getHeapUsage` was either missing (in earlier versions) or experimental (in later versions)
* `isDefault` and `isPageContext` were removed. I'm not sure what these were used for anyway, the comment leads me to believe they're probably not necessary anymore
There were some customizations made previously to annotate `recursive` on some properties. The npm package doesn't set these,
so I wrote some checks to add it back in if it can be detected. This was mostly to handle one special case: `Runtime.StackTrace`.
The workaround seems to be fine for that case.
Reviewed By: willholen
Differential Revision: D19386890
fbshipit-source-id: db0d85f6bc71cba77ee67d85efe2f38376d7cc87
Summary:
Changelog: [Internal]
This separate `.flowconfig` file was causing versioning issues.
Delete it so that `msggen` can share the same flowconfig as the rest
of React Native.
Reviewed By: willholen
Differential Revision: D19413710
fbshipit-source-id: 748cb50a3151df1c67ee7176e57e259e48f50be7
Summary:
Re-landing the reverted change:
This removes all callsites that rely on runtime checks to detect the target deployment version. We no longer need to check for iOS 10+ in a few places. Note: for this to compile, the hosting app needs to target iOS 10.0+.
Changelog: [iOS] [Deprecated] - Deprecate iOS 9
Reviewed By: sammy-SC
Differential Revision: D19411136
fbshipit-source-id: ec0a957dc57819f0ee7d138c858209cabe3e5102
Summary:
Use correct path to testNotUTF8Convertible which is being skipped.
## Changelog
[Internal] - Use correct path to testNotUTF8Convertible which is being skipped.
Pull Request resolved: https://github.com/facebook/react-native/pull/27767
Test Plan: Circle CI
Differential Revision: D19404469
Pulled By: hramos
fbshipit-source-id: 70cf06c90dac74ac7963b9a35a543e11b21ba471
Summary:
This removes all callsites that rely on runtime checks to detect the target deployment version. We no longer need to check for iOS 10+ in a few places. Note: for this to compile, the hosting app needs to target iOS 10.0+.
Changelog: [iOS] [Deprecated] - Deprecate iOS 9
Reviewed By: hramos
Differential Revision: D19271321
fbshipit-source-id: 424ad7e2161261d148cb436cc20b4c531a4ba5b7
Summary:
`test_android`'s Test Collection step fails when it attempts to convert buck's output to the junit-compatible format that Circle CI expects. Executing the script from the `okbuck` location should help here.
## Changelog
[Internal] - Use correct location for buck_to_junit in test_android CI step
Pull Request resolved: https://github.com/facebook/react-native/pull/27766
Test Plan: Circle CI
Differential Revision: D19403837
Pulled By: hramos
fbshipit-source-id: 44e599ab653e7412340c3dcfdc45c5d37bcea1ee
Summary:
This converts all NativeModules excluding the following into TurboModules:
```
// Deleted
"fbsource/fbandroid/java/com/facebook/catalyst/modules/relaynativecache/RelayNativeCacheReaderModule.java"
// Owners of FBC will migrate these by themselves
"fbsource/xplat/fbc-mobile-app/android/app/src/main/java/com/fbc/i18n/FBCi18nAssetsModule.java"
"fbsource/xplat/fbc-mobile-app/android/app/src/main/java/com/fbc/react/CellScanResultsModule.java"
"fbsource/xplat/fbc-mobile-app/android/app/src/main/java/com/fbc/react/WiFiScanResultsModule.java"
// Don't have Buck owners
"fbsource/xplat/js/react-native-fbsdk/android/src/main/java/com/facebook/reactnative/androidsdk/FBAccessTokenModule.java"
"fbsource/xplat/js/react-native-fbsdk/android/src/main/java/com/facebook/reactnative/androidsdk/FBGraphRequestModule.java"
"fbsource/xplat/js/react-native-fbsdk/android/src/main/java/com/facebook/reactnative/androidsdk/FBLoginManagerModule.java"
"fbsource/xplat/js/react-native-fbsdk/android/src/main/java/com/facebook/reactnative/androidsdk/FBShareAPIModule.java"
"fbsource/xplat/intl/oss-fbt/__github__/react-native-fbt-android-native-module/android/src/main/java/com/reactlibrary/FbtAndroidNativeModule.java"
```
This should conclude the Android TurboModule migration.
Changelog:
[Android][Added] - Make remaining NativeModules TurboModule-compatible
Reviewed By: PeteTheHeat
Differential Revision: D19383442
fbshipit-source-id: 71beaee087f6436b197a65f0d68527d9964bb6ce
Summary:
For every untyped NativeModule Java file, we ensure that its owner depends on the owner of its JS spec.
Changelog:
[Internal]
Reviewed By: PeteTheHeat
Differential Revision: D19382937
fbshipit-source-id: 0a1d840bff2f9e8db0f06c910448e9b25415d18c
Summary:
Trivial: bump Circle CI Homebrew cache key to move past cache error in CI builds.
Changelog:
[Internal] - Bump Homebrew cache key on Circle CI
Pull Request resolved: https://github.com/facebook/react-native/pull/27764
Differential Revision: D19401723
Pulled By: hramos
fbshipit-source-id: cec18ea68ac141ab85ad694ac261d98cbf0e4440
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/27434
Pull Request resolved: https://github.com/facebook/react-native/pull/27295
- Use Xcode version 11.2.1 in both internal and external tests.
- Update snapshot reference images to use iPhone 8 test device.
Xcode 11.3.0 will be available in Sandcastle in the next week or so.
Changelog:
[Internal] - Bump Xcode version used in tests to 11.2.1.
[Internal] - Update iOS Snapshots.
Reviewed By: cs01
Differential Revision: D18849584
fbshipit-source-id: 9e3b92f080a4dc6a15dac0535b7562ff6a5c08a9
Summary:
This diff fixes the redbox error: Views nested within a <Text> must have a width and height
This error is reproducible when rendering a View with no fixed size, inside a <Text>. e.g.
```
function PlaygroundContent(props: {}) {
return (
<View style={styles.container}>
<Text>
<View>
<Image source={fbicon.filled('chevron-down', 10)} />
</View>
</Text>
</View>
);
}
```
changelog: Add support to render <View> with no fixed size nested within a <Text>
Reviewed By: shergin
Differential Revision: D19387760
fbshipit-source-id: a9cee8410e56a2d362d6b8f993e602719c416925
Summary:
In D15393464, we introduced `NativeHeapCapture`, but it had a few problems:
1. It required `JSCHeapCapture` by doing `TurboModuleRegistry.get<Spec>('HeapCapture')`, when it should have done `TurboModuleRegistry.get<Spec>('JSCHeapCapture')`.
2. It had an additional method `captureHeap`, which didn't exist on the Android NativeModule.
This diff corrects those mistakes.
Changelog:
[Both][Fixed] - Fix JSCHeapCapture
Reviewed By: PeteTheHeat
Differential Revision: D19383511
fbshipit-source-id: 30e69afbcdba673f3f32c16bde4f0342568ab97d
Summary:
In codegen we generate structs that represents events. These structs are later dispatched by generated `EventEmitter`.
They had unpleasant naming, for example `SliderOnValueChangeStruct`. This diff changes the code generated so it becomes `SliderEventEmitter::OnValueChange`, this better expresses the relationship of the two classes.
Changelog: [Internal]
Motivation: Better express relationship between EventEmitter and classes that represent events.
Reviewed By: rickhanlonii, shergin
Differential Revision: D19373850
fbshipit-source-id: a5eea085013dbc119169e2b06ba9f9fe44c7fcd9
Summary:
Adds Keyframes to interop whitelist of supported components.
In `RCTKeyframesManager.m` we look into subviews in order to find `RCTKeyframesView`, this is because the view returned from paper's `UIManager` is interop itself.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D19309355
fbshipit-source-id: f9b598ee6ad5340a4e4b3914330c70eea9f43926
Summary:
interop layer doesn't deal with `nil` being sent as event, example https://fburl.com/diffusion/t5zx6xm0.
This later triggers following assertion https://fburl.com/diffusion/dr5xzgic.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D19309356
fbshipit-source-id: 82b3841c337f949ce7ca0b875c98f608edddb599
Summary:
With plugins being used for components, there is danger that someone will remove buck target as dependency and component in the target won't be available for Fabric.
That's where `plugin_assertion` comes into play. For now I hardcoded a list of components. In the future, this list will be generated from JS components that are used in the app.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D19197548
fbshipit-source-id: 0d31f53b573c343561715a8fb6fc7f0abfdb5b76
Summary:
Fabric doesn't support setNativeProps, so we are using view commands instead.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18044169
fbshipit-source-id: d5f199b930244d02f174ea8a7ef732e9a8ef2476
Summary:
As a part of the migration from setNativeProps in Fabric and Paper, we are replacing it by view commands in the RefreshControl component on Android.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18475450
fbshipit-source-id: ad89547fada3444f725fd9b00e8482cfc8f4d7fc
Summary:
As a part of the migration from setNativeProps in Fabric and Paper, we are replacing it by view commands in the Checkbox component on Android.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18451749
fbshipit-source-id: 49d786ef3383df95b10260ba2b7f68489ad31789
Summary:
Ran `arc f` against some CPP files to be modified with the next diff
to reduce the churn on it.
## Changelog
[Android] [Changed] - Formatted cpp/h code with clang-format
Reviewed By: javache
Differential Revision: D19371785
fbshipit-source-id: b7f7b92c4cb9ec7f8da728bb577db29cf11fbb39
Summary:
This is the partial implementation of Fabric-compatible <TextInput> component on iOS. All features are supported besides those:
* `focus()`, `blur()`, `clear()` imperative calls;
* Controlled TextInput as the whole feature in general;
* Controlling selection from JavaScript side;
* `autoFocus` prop;
* KeyboardAccessoryView.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D17400907
fbshipit-source-id: 0ccd0e0923293e5f504d5fae7b7ba9f048f7d259
Summary:
RCTTextInputUtils contains a bunch of conventions and convenience functions that we use in TextInput.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D19226658
fbshipit-source-id: df72dcdc052b96b6daef2cc0839235761005d914
Summary:
This is C++ part of the implementation of Fabric-compatible <TextInput> component on iOS.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D19169987
fbshipit-source-id: e2eac9beac6d1e124b5176b4a23676b8e05490c3
Summary:
In D14244606 I "fixed" `Platform.isTesting()` in JS. By fixed, I made it return true when running SSTs.
People in OSS complained about this in discord and [github](https://github.com/facebook/react-native/issues/27010). The problem is that this call returns true whenever an RN project references Detox in the build.gradle file. In practice, this has been really annoying, because it has disabled animations in debug builds, due to D13811035.
The fix is to be more specific, and look for the exact screenshot test activity. I haven't explicitly verified this doesn't trigger from Detox, but it shouldn't. I'll coordinate on the github issue to verify.
Changelog: [Android][Fixed] Fix animations in OSS debug builds by modifying `Platform.isTesting()` behaviour
Reviewed By: TheSavior
Differential Revision: D19384098
fbshipit-source-id: 22c885219f2c00f5dcc3b930b068bfd2ad7e4b8e
Summary:
ImageState if created with default constructor is created with `imageRequest_` being nullptr.
Calling `getObserverCoordinator()` on it was causing a crash.
We create initial state data with `imageRequest` populated.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D19332711
fbshipit-source-id: 0266222551dbfb10b3f86e72a43d5306650fd09b
Summary:
On Android/when printing to logcat, output is truncated to a certain max length; outputting a massive string as a single log item will cause some of it to be truncated. In the case of the mutations list and shadow node description, most of it is truncated.
Easy fix: split into lines and log each line. This isn't necessary on iOS but works fine.
I also removed the conditional and changed to an assert. Most of the time when we're using this block of code, it's because we want to see all mutations; and unless we reintroduce a bug into the core, the assert is never hit and so (before this change) the conditional would never be true and we'd never see this output. It's more generally useful to be able to see this output if the `RN_SHADOW_TREE_INTROSPECTION` macro is defined.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19378929
fbshipit-source-id: 2f5dffeef7608823ac1ba092090d8c2ab5e965e1
Summary:
Bridgeless mode hasn't been able to load random images. I was able to repro this 100% with base64 images. Loading these images hits a particular flow in `RCTImageLoader` which relies on the bridge to access `RCTNetworking`. This diff uses the TM Lookup Delegate as a fallback.
Changelog: [iOS][Internal] Fix error in RCTImageLoader in bridgeless mode
Reviewed By: sammy-SC
Differential Revision: D19331467
fbshipit-source-id: 8239ee258425da4ed8cb9f6dcdcd7f37c162eb19
Summary:
When bridge is nil, RCTBlobManager crashes with `EXC_BAD_ACCESS`.
The fix: instead of using the bridge to find RCTNetworking, use TM lookup delegate.
Changelog: [iOS][Internal] Fix crash in RCTBlobManager in bridgeless mode
Reviewed By: mdvacca
Differential Revision: D19320136
fbshipit-source-id: 49aabb3ce53b2ec620fcc02be1c6c1b44066f440
Summary:
This fixing a crash in RCTNativeAnimatedModule caused by accessing an `RCTSurfacePreseter` instance as "Objective-C runtime associated object" which was retained with `OBJC_ASSOCIATION_ASSIGN` policy. The documentation for `OBJC_ASSOCIATION_ASSIGN` says "Specifies a weak reference to the associated object." but it's a lie ( https://stackoverflow.com/questions/16569840/using-objc-setassociatedobject-with-weak-references) ). The policy is actually `ASSIGN` (aka `unsafe-unretained`).
That's why it's crashing.
We change that to `OBJC_ASSOCIATION_RETAIN` to retain the object (which meets the expectation of the interface of the category).
We also should not have over-retaining issues because:
* SurfacePresenter does not retain a Bridge or any object that can retain a Bridge;
* SurfacePresenter is a long-living object, we don't recreate it during bridge reloading or stuff like that.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D19333869
fbshipit-source-id: 1ff03659a880f2742b909c5668c47144719eeee2
Summary:
This PR is related to https://github.com/facebook/react-native/issues/27290.
I just upgraded my project's Gradle wrapper version to 6.0.1 and I realized some files have some differences with the files in react-native `template` folder. so I create this PR to apply differences.
the main difference is in the `gradlew` file. I'm not familiar with Linux shell scripts but it seems there was a syntax error in `case` items syntax. `(` should not be used in declaring case's items. it may has building error in Linux OS.
## Changelog
[Android] [Fixed] - Applied missing changes from bumping Gradle wrapper to 6.0.1
Pull Request resolved: https://github.com/facebook/react-native/pull/27639
Test Plan: I have no Linux OS right now, so I can't directly test these changes, but because the changes have made by running `gradlew wrapper` command, it should not break CI. (I hope :) )
Differential Revision: D19341671
Pulled By: cpojer
fbshipit-source-id: ccfc3c12af3f5468671737e5ba0b1674b4491590
Summary:
The latest xcode version removed iPhone 6s, so we need to bump to the latest simulator listed that has 3d touch.
## Changelog
[General] [Fix] - Bump e2e simulator version
Pull Request resolved: https://github.com/facebook/react-native/pull/27733
Test Plan: - `yarn build-ios-e2e && yarn test-ios-e2e `
Reviewed By: hramos, sammy-SC
Differential Revision: D19345576
Pulled By: rickhanlonii
fbshipit-source-id: 428cb83ccb899409e972551f18df580174adee91
Summary:
View should reset whether we are inside of a text or not. For example, inline images should only be rendered inside text, but if we have a view inside text, then it should render a regular image, not an inline image.
This logic *should* exist in native instead of in JS, but this is an easier change for now.
I'm sad to have to turn this back into a JS component instead of just being the string 'RCTView' as this will have performance implications on all surfaces, but this is how it always used to be so maybe it's fine.
This example previously crashed, and no longer does:
```
function PlaygroundContent(props: {}) {
return (
<View style={styles.container}>
<Text>
<View style={{width: 10, height: 10}}>
<Image source={fbicon.filled('chevron-down', 10)} />
</View>
</Text>
</View>
);
}
```
Changelog:
[General][Fixed] Fixes bug where <Text><View><Image> would crash.
Reviewed By: JoshuaGross
Differential Revision: D17564510
fbshipit-source-id: 0ecf49b3d466e7adf57a46a7a097dd3798c721a4
Summary:
We're keeping the perf logging flag, but the general instrumentation flag is no longer needed (the use case isn't significant to need separate flag).
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D19304789
fbshipit-source-id: 094f7079283e4f4bf3d546dfd0ae50eb641d562e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/27539
Detox currently relies on reflection to inspect the private timers queue in the Timing module to check if React Native is idle or not. This broke when I renamed TimingModule and moved the queue to JavaTimerManager in D17260848 and D17282187. A better solution to this problem is for us to expose a public API for checking the timers queue from TimingModule, so that Detox doesn't need to access private fields.
Using similar logic to Detox's TimersIdlingResource: https://github.com/wix/Detox/blob/4f81a77baee4e4542a693922bcbde621d9d8c1a5/detox/android/detox/src/main/java/com/wix/detox/reactnative/idlingresources/TimersIdlingResource.kt#L95
Changelog: [Android] [Added] Added an API for checking if there are busy timers to TimingModule
Reviewed By: makovkastar
Differential Revision: D19128786
fbshipit-source-id: 835ae214eba58879c8343255bba680a81801ce03
Summary:
Hand writing view configs for NativeImageViewComponent so that it'll work in bridgeless mode and won't fall back to the UIManager.
Changelog: [Internal]
Reviewed By: ejanzer
Differential Revision: D19217961
fbshipit-source-id: d5a123b35a75ba3e22c57b1dde18a47893681614
Summary:
Fix for https://github.com/facebook/react-native/issues/27510.
Setting the `InputType.TYPE_CLASS_TEXT` flag when `keyboardType` is null or default breaks autoCapitalize. Handle the case when `keyboardType` is null, default, or invalid type.
## Changelog
[Android] [Fixed] - Fix setting keyboardType from breaking autoCapitalize
Pull Request resolved: https://github.com/facebook/react-native/pull/27523
Test Plan:
Added keyboardType prop to RNTester as so
```
<TextInput autoCapitalize="words" keyboardType="default" style={styles.default} />
```
Reviewed By: makovkastar
Differential Revision: D19132261
Pulled By: JoshuaGross
fbshipit-source-id: be66f0317ed305425ebcff32046ad4bff06d367f
Summary:
A UBN surfaced in v252 because [this assert](https://our.intern.facebook.com/intern/diffusion/FBS/browse/master/xplat/js/react-native-github/React/Modules/RCTEventEmitter.m?commit=e5d1e6375a640d0387bb7016d3becd262c22c327&lines=40) started firing, originating from `RCTAppState`.
This appears to be a race condition during RN teardown. RN receives a memory warning and attempts to forward to JS, but the bridge is already destroyed.
IMO, if the bridge is already destroyed, then there shouldn't be a need to send a memory warning to JS? This is just a hunch though, if anyone feels otherwise, please let me know :)
See the UBN task for further details.
Changelog: [iOS][Internal] Guard against nil bridge during teardown
Reviewed By: shergin
Differential Revision: D19293063
fbshipit-source-id: 566f21af30d3d9bcd25a673ce664f8caddc701ca
Summary:
Adding myself as a code owner for the files in the ESLint package so I get email alerts for all PRs which alter the package.
This is needed because I need to manually publish updates to the package when pull requests are merged in. They are not handled by the standard React Native release cycle.
Related discussion: https://github.com/facebook/react-native/pull/27085#issuecomment-571089097
## Changelog
[Internal] [Added] - Added mat-oakes as a CODEOWNER for the ESLint package
Pull Request resolved: https://github.com/facebook/react-native/pull/27689
Test Plan: N/A
Differential Revision: D19294768
Pulled By: cpojer
fbshipit-source-id: 3e3833261fc0b3c107b52b0e8232bd942a2ecaf4
Summary:
This is a backout of the temporary workaround.
A proper fix was landed as D19249490.
Original commit changeset: 53d19e90e080
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D19252609
fbshipit-source-id: 4a6239944440f392ef8a0e85a5038ee5f4d774f0
Summary:
Changelog: [Internal]
We are moving away from LocalData in favour of State.
LocalData isn't used on iOS anymore, this diff removes it so it can't be reintroduced
Reviewed By: shergin
Differential Revision: D19250731
fbshipit-source-id: aaa5d79b4d885b6bf9b2df2d67d80ecd3d6982bc
Summary:
Changelog: [Internal]
We are moving away from LocalData in favour of State.
Reviewed By: shergin
Differential Revision: D19250592
fbshipit-source-id: 6d2eef9a0c0e53e0146da609ba0c24fa09766433
Summary:
Changelog: [Internal]
We are moving away from LocalData in favour of State.
Reviewed By: shergin
Differential Revision: D19247031
fbshipit-source-id: 8884133b13dd111e8d9e2cd4936bf90bfc5b4932
Summary:
Instead of defining `RCTComponentViewClassWithName` in every single app. It is easier to use conditional compilation to determine whether iOS plugins are available or not.
Based on that a plugin for given name will be either come from plugin system or generated map of components.
Changelog: [internal]
Reviewed By: shergin
Differential Revision: D19168527
fbshipit-source-id: cb130fc563a15882e2b163c84ea37aaa3849c16d
Summary:
Added `react-native-community/eslint-plugin` as a dependency for `react-native-community/eslint-config`
The newly published eslint-config has `react-native-community/eslint-plugin` in its `.eslintrc`, but it's not listed under dependency, so when I try to use it in a community package, I'd have to install both `eslint-config` and `eslint-plugin`.
It would be nice to just be able to install `eslint-config` and extend that without additional package listed under devDependency.
## Changelog
[General] [Changed] - Added `react-native-community/eslint-plugin` as a dependency for `react-native-community/eslint-config`
Pull Request resolved: https://github.com/facebook/react-native/pull/27680
Differential Revision: D19287051
Pulled By: cpojer
fbshipit-source-id: 3aea54def7fb4598a21bfc087cc7938ce0662a59
Summary:
On slower devices , 0.5s is not fast enough and we frequently render a black screen. Let's bump the sync rendering timeout to 1s.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D19282619
fbshipit-source-id: 0d9ae60f4869b0de7c4523c2cb33fbbf320c6438
Summary:
NativeAnimatedModule registers itself as a listener on UIManagerModule, which doesn't exist in bridgeless mode. We now have an API on ReactContext to detect if we're in bridgeless mode, so let's just bail out when that's the case (for now).
In the future, we'll need a replacement for this API on FabricUIManager (or somewhere).
Changelog: [Internal]
Reviewed By: PeteTheHeat, mdvacca
Differential Revision: D19185762
fbshipit-source-id: 1cf53304ab58a5b985c8f4806544da51f09e8ba5
Summary:
In bridgeless mode, we use BridgelessReactContext, which overrides some methods on ReactApplicationContext like `getJSIModule` and returns true for `isBridgeless`. This is needed for things like getting the EventDispatcher, which is currently accessed from the UIManagerModule (which doesn't exist in bridgeless mode).
However, when we create Views in React Native we don't use the ReactApplicationContext directly; instead, we create a ThemedReactContext, which holds a reference to the RAC. It also initializes itself with the RAC's CatalystInstance, so that when you call methods on the TRC it can access native modules, etc.
This doesn't work in bridgeless mode, because the methods are overridden on the RAC, *not* the TRC. So in order for this work as expected, we need to delegate these methods to the RAC member variable. In this diff I'm just doing this for `isBridgeless` and `getJSIModule` so that accessing the EventDispatcher works.
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D19190760
fbshipit-source-id: 6dc38560edc1061aec782707306590fa1012d5cb
Summary:
This should resolve some of the crashes in T9871006. It's unclear if these events are being emitted before Catalyst is set up or after it's torn down, but it's likely a race between teardown and some other event.
Should be safe to just log and continue / fail silently, if this is happening after teardown.
Also upgrading logs to error so that these get logged to logviews.
Changelog: [Internal], will fail silently in a marginal number of existing edge-case crashes for events sent before startup or after shutdown
Reviewed By: mdvacca
Differential Revision: D19269891
fbshipit-source-id: 30fc28693c0be7a15bfc5b5bc7eb88e10c7b4a5a
Summary:
This diff back out the migration of events on ScrollView to be bridgeless (D18862857)
This is causing the bug: T59882485 and the migration is not necessary in production yet.
Heads-up ejanzer this diff will affect events for scroll in Venice, I will create another diff to figure it out the root cause. But we need the land and pick this diff in v252
Changelog: [internal]
Reviewed By: ejanzer
Differential Revision: D19269906
fbshipit-source-id: d61e67975d508cddafc3af34b0f7dfe83bda6bd7
Summary:
It can be a pain to debug slow network issues, especially with the iOS simulator which doesn't have a network link conditioner. This makes it really easy and predictable by simply adding a `setTimeout` around calling `sendRequest`.
Changelog:
[General] [Added] - DEBUG_NETWORK_SEND_DELAY can be used to simulate slow network.
Reviewed By: PeteTheHeat
Differential Revision: D19236911
fbshipit-source-id: 14762c7e0c6408a8364aa569c482729a7a1fe740
Summary:
It is time to target SDK version 10.0+.
Changelog: [iOS] [Deprecated] - Deprecating support for iOS/tvOS SDK 9.x, 10.0+ is now required
Reviewed By: mdvacca
Differential Revision: D19265731
fbshipit-source-id: 93b6f9e8f61c5b36ff69e80d3f18256aa96cc2c0
Summary:
After changes to the semantics of spread, this lint is no longer relevant and will be removed in an upcoming version of Flow.
Changelog: [Internal]
Reviewed By: jbrown215
Differential Revision: D19241147
fbshipit-source-id: 2cad93725055601f2ceaa2379ed3643f136ff69b
Summary:
Changes the return type of StyleSheet.create to `$ReadOnly<S>`. At runtime, it just freezes the fields in dev mode and is the identity function otherwise. This cause 423 errors due to the wrong props being passed to different styles: P124372727
I went over errors at random with Eli to get confidence in the change.
Changelog:
[General][Fixed] Fix return type of StyleSheet.create
Reviewed By: zackargyle, TheSavior
Differential Revision: D19218817
fbshipit-source-id: b7aa10700f8333372c9f0bd61bfbef371caadf97
Summary:
We see some asserts firing inside the Shadow Tree introspection.
While we are investigating what exactly went wrong it's better to disable that to stop bleading.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D19256449
fbshipit-source-id: 9920392996a00879043d9516e5bc189a1c806ead
Summary:
This fixes a deadlock caused by recursive calling of `-[RCTSurfacePresenter setMinimumSize:minimumSize:]` (because of an attempt to lock the mutex which was already locked upper the call stack).
Seems there is no reason why this operation should not be allowed. This diff replaces a regular mutex with a shared one which allows multiple shared locks and this prevents the deadlock. A Scheduler is already a thread-safe object and the mutex only protected the mutation of a pointer to it.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D19249490
fbshipit-source-id: 00e8934c6502328f34b78ea6ec004b7216665db1
Summary:
This fix should stop T59424871 from bleeding. This is just an ugly workaround, I need some time to figure out a proper solution for that.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D19244682
fbshipit-source-id: 53d19e90e080d6c3816c78869826ed2ec0c982eb
Summary:
react-native-cookie-store wants the ability to set custom cookies on Android. We use ForwardingCookieHandler to mange the cookies. Exposing the `addCookies` method will allow the module to provide the same functionality on Android.
https://github.com/safaiyeh/react-native-cookie-store/issues/1
## Changelog
[Android] [Changed] - Expose addCookies method
Pull Request resolved: https://github.com/facebook/react-native/pull/27512
Test Plan: N/A
Differential Revision: D19236309
Pulled By: cpojer
fbshipit-source-id: bf1a0730165456c34c5bf432ac370176a881cbcf
Summary:
In other part of the hello world, this replacement has been made already. The only place left this way (which make sense) is in `HelloWorld.xcodeproj/project.pbxproj`.
## Changelog
[General] [Fixed] - Adjust HelloWorld-tvOSTests/Info.plist `CFBundleIdentifier` to use PRODUCT_BUNDLE_IDENTIFIER
Pull Request resolved: https://github.com/facebook/react-native/pull/27601
Test Plan: I made this change locally on a project. No big deal as this is a test piece, not going to go on any kind of real world environment.
Differential Revision: D19235760
Pulled By: cpojer
fbshipit-source-id: 95b9936acc1eaddf3f5a86c733f46c5a80ac6423
Summary:
In https://fb.workplace.com/groups/rn.support/permalink/3132785890103338/?comment_id=3132873900094537 we identified that when Metro restarts but the app keeps the main bundle alive, the next request for a split bundle will always produce an invalid bundle. This is because we rely on module ids being stable while Metro is running and when Metro is restarted, those module ids will likely be assigned to different modules.
The fix applied here simply forces a full reload when downloading (registering) a new split bundle if the connection to Metro disappeared.
Another way to mitigate this is to use stable module ids. That's a more involved change in Metro that I'm not planning on making right now.
Changelog: [Internal]
Reviewed By: rickhanlonii
Differential Revision: D19235555
fbshipit-source-id: b8ff10590655952a2af1379bbf4e930f9eb95c1b
Summary:
This diff removes the findShadowNodeByTag_DEPRECATED method from class UIManagerBinding. This method was created on D17175953 to implement findNodeHandle in Fabric. Recently we decided that we don't need to expose findNodeHandle anymore. This diff cleans up thi code.
Changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D19216996
fbshipit-source-id: 07c16aeed28851afc09b0f5d6be338bb4440f813
Summary:
This diff implements the findNodeAtPoint API into UIManagerBinding to allow JS to call this method
changeLog: [Internal]
Reviewed By: shergin
Differential Revision: D19190284
fbshipit-source-id: 3a65a2238f964ce031b12c8cf264cdacb6cc8f2e
Summary:
This diff implements the findNodeAtPoint method to return the ShadowNode that is positioned into a Point of the screen.
What's not supported:
- Scroll position
- Transform
- return layoutable nodes that are contained inside a non-layoutable node
Changelog: [internal]
Reviewed By: shergin
Differential Revision: D19190285
fbshipit-source-id: fdc0358dc21312e9950a4eb16c36020e9e43e33f
Summary:
This diff extends Geometry class with methods to substract points and to determine if a Rect contains a Point or not
Changelog: [internal]
Reviewed By: sammy-SC
Differential Revision: D19190283
fbshipit-source-id: 7c7dd73be2cd644081ed9af8eeef7e137c618ae4
Summary:
This diff exposes eventTarget on the EventEmitter API
Changelog: [internal]
Reviewed By: shergin
Differential Revision: D19190281
fbshipit-source-id: 00dc8cf64f42b1fe176ecb7beefad59e61bd53ca
Summary:
It's not fully clear why it happens but sometimes UIKit cancels (calling some UIGersureRecognizer interface) some UITouch events that seem never previously started. That might be a bug in UIKit or in our local registry.
That happens extremely rarely but happens.
After this change, RCTSurfaceTouchHandler will ignore those touches in production but crash in debug mode (I hope we can find a repro case and fix it).
Anyway, ignoring canceling of touches that RCTSurfaceTouchHandler is not aware of should not be a big deal.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D19221204
fbshipit-source-id: 77ce773f7bcc31725bf90a182a91789fd5deeedb
Summary:
Trivial. I need this to make the next diff readable.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D19221205
fbshipit-source-id: 0f8b608866ea974272901b2b2e208e9cd88c8e0a
Summary:
Diff 1/N explained how calls to `[_bridge enqueueJSCall:]` can be replaced with `_invokeJS` in a bridgeless world.
This diff replaces RCTEventEmitter's usage of `enqueueJSCall` if the bridge isn't available.
Changelog: [Internal][iOS] Make RCTEventEmitter a RCTJSInvokerModule
Reviewed By: RSNara
Differential Revision: D18941955
fbshipit-source-id: 1b81e46585432e005cff5aa0ab4d151f50ea051b
Summary:
Problem: Certain turbo modules use the bridge to access JS directly by calling something like `[_bridge enqueueJSCall:]`. In a bridgeless world, this API no longer works.
Solution: These turbo modules can implement the new protocol defined here. This protocol provides a block during module init which can be used to call JS directly (using `ReactContext`) instead of going through the bridge.
Changelog: [Internal][iOS] - Introducing RCTJSInvokerModule, a new protocol for turbo modules which call js
Reviewed By: RSNara
Differential Revision: D18941933
fbshipit-source-id: 8d581df06be59debf83575124e7d221145c5afb8
Summary:
The concept of the class cannot guarantee that the set of delegates cannot be removed as a side-effect of calling a delegate, so we must make a copy of the delegates before calling on them.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D19213549
fbshipit-source-id: 7040b2994433d83e3148ec73820e051729be9e29
Summary:
This diff changes the signature of ComponentDescriptor constructor to make it simpler and easier to support: now all arguments are passed via struct that contains all these arguments as fields.
Now the ComponentDescriptor constructor accepts three arguments one of which is optional. This causes some confusion and the possibility of bugs in all subclasses that needs to implement a custom constructor. Mostly because in every case we need to ensure that the constructor:
* Accepts and pass down all parameters/arguments;
* Accepts the right types of those parameters (shared vs weak pointers, references vs values).
* Accepts all thee arguments and pass them (including flavor!). We failed this point several times.
Overal that makes the code simpler and allows changing the set of parameters relatively easy. (There is no plan for it!)
Look at the LOC balance: less code!
Changelog: [INTERNAL]
Reviewed By: sammy-SC
Differential Revision: D18548173
fbshipit-source-id: 5d038b135e004f6c054026b3235ed57db99c086d
Summary:
This diff fixes the rendering of TextInput component for Android 4 devices.
This bug was caused by D18196901, when we changed the base class of ReactEditText from EditText to AppCompatEditText.
The root of the problem is that AppCompatEditText wraps the ReactContext received as a parameter in the construction of the View into a ContextWrapper object. This break the implicity assumption that the method View.getContext will return the same context that was used during the construction of the view.
https://android.googlesource.com/platform/frameworks/support/+/dd55716/v7/appcompat/src/android/support/v7/widget/AppCompatEditText.java#55
Changelog: [internal]
Reviewed By: ejanzer
Differential Revision: D19204032
fbshipit-source-id: eefb562b1da22e6cc58c75845c87dd032d727f49
Summary:
We currently use `UIManager.getViewManagerConfig()` in a few places to check if a view manager exists at runtime; right now these checks fail for Venice because our DummyUIManager returns null. We don't yet have a replacement for this API for Fabric (see T59411524) so for now let's just hard code the view managers that we know exist to return something truthy here. This is hacky, but it works ok for now.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D19185957
fbshipit-source-id: e3135b45db4c9ff27fd95362deaa3c1b4340bf48
Summary:
React-native server-device connection must be via Wi-Fi. But if the OS-X server has LAN & Wi-Fi interfaces, then device bundle can be incorrectly configured to use LAN interface instead of Wi-Fi. This patch fix this issue. It greps for "baseT" (e.g. media: autoselect (1000baseT <full-duplex>)) and skip interface if it is.
## Changelog
[iOS] [Fixed] - Fix LAN instead of Wi-Fi device bundle configuration
Pull Request resolved: https://github.com/facebook/react-native/pull/27575
Test Plan:
To reproduce an issue setup Mac OS 10.15.1 with LAN and Wi-Fi active interfaces. And connect
real device (not simulator).
And "ifconfig en0" in console should display LAN interface e.g.:
```
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=50b<RXCSUM,TXCSUM,VLAN_HWTAGGING,AV,CHANNEL_IO>
ether 78:7b:8a:d8:61:42
inet 10.15.61.16 netmask 0xffffff00 broadcast 10.15.61.255
nd6 options=201<PERFORMNUD,DAD>
media: autoselect (1000baseT <full-duplex>)
status: active
```
"ifconfig eg1" in console should display WiFi interface e.g.:
```
en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=400<CHANNEL_IO>
ether 14:20:5e:03:5b:2a
inet6 fe80::10e6:1cb6:54ec:1b41%en1 prefixlen 64 secured scopeid 0x5
inet 10.15.91.27 netmask 0xffffff00 broadcast 10.15.91.255
nd6 options=201<PERFORMNUD,DAD>
media: autoselect
status: active
```
In this case device bundle in react-native-xcode.sh script wood be incorrectly configured to use en0 (LAN interface) instead of en1(Wi-Fi) interface.
My patch fixes this issue.
fragment of script output before patch:
```
...
++ ipconfig getifaddr en0
+ IP=10.15.61.16
+ '[' -z 10.15.61.16 ']
+ '[' -z 10.15.61.16 ']'
+ echo 10.15.61.16
+ [[ -n '' ]]
...
```
After start project ob device we have time lag about 20s then debug out:
`
2019-12-20 16:58:57.530538+0300 AwesomeProject[4590:1923358] Task <164D9AB0-8473-4BA3-BD1A-EC0E92887C17>.<1> finished with error [-1001] Error Domain=NSURLErrorDomain Code=-1001 "The request timed out." UserInfo={NSUnderlyingError=0x2838dc2d0 {Error Domain=kCFErrorDomainCFNetwork Code=-1001 "(null)" UserInfo={_kCFStreamErrorCodeKey=-2102, _kCFStreamErrorDomainKey=4}}, NSErrorFailingURLStringKey=http://10.15.61.16:8081/status, NSErrorFailingURLKey=http://10.15.61.16:8081/status, _kCFStreamErrorDomainKey=4, _kCFStreamErrorCodeKey=-2102, NSLocalizedDescription=The request timed out.}
`
fragment of script output after apply patch:
```
...
++ ipconfig getifaddr en0
+ IP=10.15.61.16
+ [[ -z 10.15.61.16 ]]
++ ifconfig
++ grep baseT
+ [[ -n media: autoselect (1000baseT <full-duplex>)
media: autoselect (100baseTX <full-duplex>) ]]
++ ipconfig getifaddr en1
+ IP=10.15.91.27
+ '[' -z 10.15.91.27 ']'
+ echo 10.15.91.27
+ [[ -n '' ]]
...
```
App start OK.
On iPhone /iPad simulator works too.
Differential Revision: D19200334
Pulled By: hramos
fbshipit-source-id: 22d791b657abd16a92d075515682b4fa961b489c
Summary:
This diff disables accessibility state changes of the focused view for Android API < 21.
This is necessary because the method view.isAccessibilityFocused was introduced in Android API 21
Users in Android API < 21 will not be able to hear accessibility state changes of the focused view (feature introduced by D17903205)
Changelog: disables accessibility state changes of the focused view for Android API < 21, see PR: 26624
Reviewed By: fkgozali
Differential Revision: D19199096
fbshipit-source-id: 12b349f0ac94b77e9e7328ae40e1ae1a278e8b24
Summary:
In order to enable more fine-grained control of theming in brownfield apps, this adds RCTOverrideAppearancePreference to RCTAppearance.
## Changelog:
[iOS] [Added] - Adds RCTOverrideAppearancePreference to the iOS Appearance module
Reviewed By: sammy-SC
Differential Revision: D19187657
fbshipit-source-id: 52783c497d32d36af2523fce6f040d6cfb5aac3c
Summary:
## Problem
For efficiency reasons, we'd only check whether the current class or its superclass implemented the `TurboModule` interface. However, it's possible for NativeModules to exist that use inheritance, and have their base class extend a code-generated spec. In this case, the superclass of the superclass of the NativeModule will implement `TurboModule`.
## Solution
To fix this problem, I'm relying on the `Types.isAssignable` API and checking whether the NativeModule can be assigned to the `TurboModule` interface. This is a more reliable way of knowing whether a NativeModule is a TurboModule or not.
**Note:** Had to adjust the buck dependencies of FrescoModule to make the `mTypes.isAssignable` check work.
Changelog:
[Android][Fixed] - Correct TurboModule detection logic in ReactModuleSpecProcessor
Reviewed By: fkgozali
Differential Revision: D19183671
fbshipit-source-id: ad21881453fe7027d9432048108f6ba344fd7e63
Summary:
## Problem
`DebugCorePackage` is a `TurboReactPackage`. To register a `TurboReactPackage`s NativeModules, the `NativeModuleRegistryBuilder` loops over all `ReactModuleInfo`s in the package's auto-generated `ReactModuleInfo` list. This list is generated from the `ReactModuleList` annotation of the package using our annotation processors. Because `JSDevSupport` was in its package's `ReactModuleList` annotation, we generated a `ReactModuleInfo` object for it. Therefore, `NativeModuleRegistryBuilder` registered `JSDevSupport` twice (once in `DebugCorePackage` and twice in `Fb4aReactPackage`).
## How did this work before?
`JSDevSupport` was always a part of the `ReactModuleList` annotation of `DebugCorePackage`. However, before D18974084 landed, there were two key things that made this work:
1. `DebugCorePackage` was a `LazyReactPackage`,
2. The `DebugCorePackage.getNativeModules()` did not return a `ModuleHolder` for `JSDevSupport`.
For `LazyReactPackage`s, `NativeModuleRegistryBuilder` calls `LazyReactPackage.getNativeModuleIterator()` to register NativeModules. The iterator returned from `LazyReactPackage.getNativeModuleIterator()`, in this case, loops over the NativeModules returned from `DebugCorePackage.getNativeModules()`. Therefore, we don't register any NativeModules that aren't in `DebugCorePackage.getNativeModules()`. Since `DebugCorePackage.getNativeModules()` didn't contain `JSDevSupport`, it wasn't registered for the second time.
Changelog:
[Android][Fixed] - Unregister JSDevSupport from DebugCorePackage
Reviewed By: ejanzer
Differential Revision: D19187664
fbshipit-source-id: 34141c60542179567d75705937ba09ec8a3dfc2b
Summary:
The logic in the method is only relevant if the sourceType is `UIImagePickerControllerSourceTypeCamera`. So we guard it here, to prevent NSInvalidArgumentException.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D19184818
fbshipit-source-id: 5c99dabfaed23629e22fdc888263bd09e8768c88
Summary:
If building a JSError causes a JSError, this would lead to infinite recursion. This changes the error handling path so the problem is visible to JS. There's also a few related cleanups included, and a new test case.
Changelog: [General] [Fixed] - If Error global is not callable when building an error, jsi will throw a JS exception back to JS code. #158
Reviewed By: tmikov, dulinriley
Differential Revision: D18796269
fbshipit-source-id: 57a45d144fa2ea5e78d18c27d3130611737dda96
Summary:
Test results were being written to ~/reports/, while Circle CI was configured to look for these in ~/react-native/reports/.
This simple fix makes it so that Circle CI's test result tab can now display line-by-line results without the need to dig through log spew to understand which tests failed.
## Changelog
[Internal] [Fixed] - Generate test results in discoverable location (CI)
Pull Request resolved: https://github.com/facebook/react-native/pull/27435
Test Plan:
See https://app.circleci.com/jobs/github/hramos/react-native/7112/tests
Compare with any other run, where this tab would show an error message due to lack of test results.
Differential Revision: D19185408
Pulled By: hramos
fbshipit-source-id: 5481a13874bd078deba4a58ddb83dfdfe6845151
Summary:
React Native ScrollViews are flipped upside down when the prop inverted is set to true. This is the root of a bug: tapping on the status bar in iOS should scroll the Flatlist up to the top but currently it does to the bottom.
The solution proposed is to detect natively if the ScrollView is inverted, on such case, prevent it from scrolling it to the beginning of the ScrollView (as a non-inverted ScrollView would do) and force a scroll to the end of it.
I've been careful enough not to force the scroll if the user explicitly selected not to do it or if it's happening in a nested ScrollView, as it is the default behaviour in iOS.
Fixes https://github.com/facebook/react-native/issues/21126
## Changelog
[iOS] [Fixed] - Inverted ScrollViews scroll to their bottom when the status bar is pressed
Pull Request resolved: https://github.com/facebook/react-native/pull/27574
Test Plan:
- on iOS, add a ScrollView and put enough content to overflow the screen size so it can be scrolled
- add the prop `inverted={true}` to the ScrollView
- go to the screen the Scrollview is in and press the status bar
- it should scroll to top (previously it scrolled to the bottom)
Differential Revision: D19185270
Pulled By: hramos
fbshipit-source-id: 5445093ff38f4ba4082f1d883d8ed087e9565eaf
Summary:
GitHub still marks some dependencies as vulnerable. Updating them.
Changelog: [Internal]
Reviewed By: avp
Differential Revision: D19183702
fbshipit-source-id: 9c9c815816c4fc591c77d811058234a63aeda727
Summary:
As part of the plan is splitting ShadowNodeFragment into two parts. ShadowNodeFamilyFragment is already in place. This diff removes use of `ShadowNodeFragment::eventEmitter` and goes over all call sites to change it to `ShadowNodeFamilyFragment::surfaceId`.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D19146697
fbshipit-source-id: 22cae5404b0f3098feb86c0437a4aa256d5b773e
Summary:
As part of the plan is splitting `ShadowNodeFragment` into two parts. `ShadowNodeFamilyFragment` is already in place. This diff removes use of `ShadowNodeFragment::surfaceId` and goes over all call sites to change it to `ShadowNodeFamilyFragment::surfaceId`.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D19115785
fbshipit-source-id: 5972332c3360b88ca935581ed36070f26e678b22
Summary:
As part of the plan is splitting `ShadowNodeFragment` into two parts. `ShadowNodeFamilyFragment` is already in place. This diff removes use of `ShadowNodeFragment::tag` and goes over all call sites to change it to `ShadowNodeFamilyFragment::tag`.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D19115781
fbshipit-source-id: 6ab3464a063c220d0924bf5a69b75449ca178650
Summary:
The header role is being said twice in android. Stopped that from happening.
## Changelog
[General] [Added] - removed code that would cause accessibility header role to be spoken twice
Pull Request resolved: https://github.com/facebook/react-native/pull/27496
Test Plan:
Test plan is testing in RNTester making sure the examples work
## Note:
generatedComponentApiDocs.js was modified by lint commands. I can submit a PR without it if preferred.
Differential Revision: D18973520
Pulled By: hramos
fbshipit-source-id: 9a7cc2d3fac1d0fc79dedb443d5ca365026b3b15
Summary:
I moved towards C function to return component class instead of delegate.
We need this in order to register components that are optimistically registered, such as View, Image and Text.
In D19088558, we need this in order to register Image.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D19088559
fbshipit-source-id: 061f3ba15dfb44b9acce7be2dc6828b9afbecbfa
Summary:
This diff fixes two issues with LogBox in OSS.
Changelog: [Internal]
Reviewed By: mmmulani
Differential Revision: D19165696
fbshipit-source-id: 4dd9c480ea3d2b205f8e65cb32203949b1e32e8a
Summary:
`msggen` has dependencies on some npm packages with vulnerabilities.
This diff updates the dependency list.
Changelog: [Internal]
Reviewed By: avp
Differential Revision: D19107926
fbshipit-source-id: 0526f6fe430c162322ec9ecb84f3d78604cd76bc
Summary:
Having automatic defaults/an optional arg for `convertRawProp` has caused way more problems than it is worth. Remove the default argument.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D19151594
fbshipit-source-id: 839ec8d138b2c3c083f221a2871582454004648c
Summary:
Files that are inside `xcshareddata` are meant to be "shared", and that means committed to git. These files are for example `ios/RnDiffApp.xcodeproj/xcshareddata/xcschemes/RnDiffApp.xcscheme`, and if ignored that means they are removed from the repo or are missing when cloning. These should be present. They are the shared schemes so Xcode knows what and how to build, on everyone's machine.
I noticed it being there in a new project on 0.62.0-rc.0.
## Changelog
[iOS] [Changed] - Remove the xcshareddata from .gitignore
Pull Request resolved: https://github.com/facebook/react-native/pull/27563
Differential Revision: D19166364
Pulled By: TheSavior
fbshipit-source-id: 0377dc5b08ba04d121f9ed5e4027942a7a9f463f
Summary:
I stumbled on this comment where the task was closed
Changelog: [Internal]
Reviewed By: lunaleaps, RSNara
Differential Revision: D18933260
fbshipit-source-id: 8d35e0fa19dc9aec7b811131318858c27c34accd
Summary:
This implements propagation of ScrollView's contentOffset value on Android. That allows `LayoutableShadowNode::getRelativeLayoutMetrics` (and some measure functions) return values that take that info into account.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D19027433
fbshipit-source-id: 023ff9642d023971b3d24d5cc5f7c2f4b443031e
Summary:
This diff re-enables propagation of ScrollView's content-offset value down to the ShadowTree layer and enables measure fucntions opt-in incorporating this info to result.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: zackargyle
Differential Revision: D18981891
fbshipit-source-id: a6c0f4e690703b0ee07d45efab161750cfcc4b60
Summary:
When in debug mode, PlatformConstants doesn't have a `ServerHost` constant. This wasn't captured by `NativePlatformConstants`.
Changelog:
[Android][Fixed] - Make sure ServerHost is optional in NativePlatformConstants.js
Reviewed By: rickhanlonii
Differential Revision: D19091270
fbshipit-source-id: 4b3ac73a4ab6111b3e433ecca01cc769e8cdec6b
Summary:
@public
With this, you can determine the packager location at run time before we even try to load the bundle.
Changelog: [Android] [Added] - Packager location can be determined at run time
Reviewed By: makovkastar
Differential Revision: D18940087
fbshipit-source-id: fac99f28e119a4e7a2961b5504cfe7d2d409e8f7
Summary:
`node` is passed to us from react devtools. We can call .measure on that directly instead of using findNodeHandle and UIManager. This makes this call compatible with Fabric.
Changelog:
[Internal]
Reviewed By: mdvacca
Differential Revision: D19152052
fbshipit-source-id: 05ab6d55f3a79221d99289f0341eb25352b96899
Summary:
We currently have a method in ReactContextBaseJavaModule that logs a warning if the native module is trying to access a ReactContext without an active Catalyst instance (because if you try to access it directly, it throws).
For bridgeless mode, we never have a CatalystInstance, but it's safe to call certain methods on the context that would normally require one. For this case, let's just return the context when the context is in bridgeless mode.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D19133988
fbshipit-source-id: cae0bd397aa24d9ad416491cbc32676870cc70b0
Summary:
We currently use `BatchedBridge.registerCallableModule` to call JS from platform code in a bunch of places (e.g. `RCTDeviceEventEmitter.emit()`), including some pretty essential ones - for example, Networking relies on `RCTDeviceEventEmitter` to emit events to JS for network requests and errors. In order to make the migration to bridgeless mode as easy as possible, it'd be best if we didn't have to update all the callsites in JS and platform code, at least for core JS modules like `RCTDeviceEventEmitter`. So we'd like to implement this callable module pattern for bridgeless mode as well.
In this diff, I'm installing a global variable, `RN$registerCallableModule`, which will store the JS module name and factory function in C++. This can then be called from platform code (Java/Obj-C) to invoke a JS function on a module using the existing APIs (`context.getJSModule()` on Android, `enqueueJSCall()` or similar on iOS).
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D18798852
fbshipit-source-id: fbe9eaecaf6f5cab5173beec999d3a933b13375d
Summary:
We will need to operate on instances instead of react tags. This diff passes through the instance instead of the tag.
This does not make the inspector work in Fabric, but it is a necessary refactor in that direction.
Changelog:
[Internal]
Reviewed By: mdvacca
Differential Revision: D19149647
fbshipit-source-id: 53fa35a2886bf36a146d473a496409dffc114a80
Summary:
This diff reverts D15908765 where we disabled the introspection feature because we were afraid that it leaks into prod because of some sort of misconfiguration. Seems that wasn't the case.
We need to re-enable this to get some signals if it's broken.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D19104526
fbshipit-source-id: 696c0e68bb858da270dbbb5da11032e664d75659
Summary:
We used that on iOS only before we had `ComponentDescriptorProviderRequest`. Now iOS does not use `_fallbackComponentDescriptor`.
On Android we still use `_fallbackComponentDescriptor` but set that explicitly via `ComponentDescriptorRegistry::setFallbackComponentDescriptor`.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D19103296
fbshipit-source-id: fb2a2142afb183145fd3c8e48f620cb3f316c0bb
Summary:
Some babel plugins add additional methods to `Function.prototype` (see https://github.com/MatAtBread/fast-async):
```js
Function.prototype.$asyncbind = function $asyncbind(self, catcher) {
...
```
Although undocumented, React Native allows functions to be passed to `StyleSheet.create()` for dynamic styling:
```js
const styles = StyleSheet.create({
animalItem: height => ({ height })
});
```
If there are additional custom methods on `Function.prototype`, React Native's `StyleSheetValidation.validateStyle` will loop through these properties and raise an error because those properties are not valid style keys, because it loops through _all_ properties, including inherited ones.
This PR modifies `StyleSheetValidation.validateStyle` to only loop through the style's own properties, instead of including inherited ones.
## Changelog
[General] [Fixed] - Fix stylesheet validation for functions with custom prototype methods.
Pull Request resolved: https://github.com/facebook/react-native/pull/27264
Test Plan: - Tested that non-function style properties are still validated
Differential Revision: D18694895
Pulled By: hramos
fbshipit-source-id: b36f4a62a435e7b6a689398de3bcc06d6bb14293
Summary:
In https://github.com/facebook/react-native/issues/25427, radex added initial support for running React Native projects on macOS via Catalyst. However, `RCTWebSocket` was disabled for that target because of some compilation issues. This meant that running projects via a connection to the packager wasn't possible: no live reload, and projects must be run in "Release" mode. It also meant making manual changes to Xcode projects deploying to macOS and scattering a number of conditional checks throughout the codebase.
In this change, I've implemented support for `RCTWebSocket` on the macOS target and re-enabled the affected features. Live reload and the inspector now work for macOS targets. Manual modifications of Xcode build settings are no longer necessary for react-native projects running on macOS.
### Limitations
There's no binding which displays the developer menu (since there's no shake event on macOS). We'll probably want to add one, perhaps to the menu bar.
I've chosen not to commit the modifications to RNTester which enable macOS support, since that would imply more "official" support for this target than I suspect you all would like to convey. I'm happy to add those chunks if it would be helpful.
## Changelog
[iOS] [Added] - Added web socket support for macOS (Catalyst), enabling debug builds and live reload
Pull Request resolved: https://github.com/facebook/react-native/pull/27469
Test Plan:
* Open RNTester/RNTester.xcodeproj with Xcode 11.2.1, run it like a normal iOS app -- make sure it compiles and runs correctly (no regression)
* Select "My Mac" as device target, and run. You may need to configure a valid development team to make signing work.
* RNTester should run fine with no additional configuration. Modify a file in RNTester, note that live reload is now working.
* Test the developer inspector. To display the developer menu, you'll need to manually show it; here's an example diff which does that:
```
diff --git a/RNTester/js/RNTesterApp.ios.js b/RNTester/js/RNTesterApp.ios.js
index 8245a68d12..a447ad3b1b 100644
--- a/RNTester/js/RNTesterApp.ios.js
+++ b/RNTester/js/RNTesterApp.ios.js
@@ -19,6 +19,8 @@ const React = require('react');
const SnapshotViewIOS = require('./examples/Snapshot/SnapshotViewIOS.ios');
const URIActionMap = require('./utils/URIActionMap');
+import NativeDevMenu from '../../Libraries/NativeModules/specs/NativeDevMenu';
+
const {
AppRegistry,
AsyncStorage,
@@ -143,6 +145,7 @@ class RNTesterApp extends React.Component<Props, RNTesterNavigationState> {
UNSAFE_componentWillMount() {
BackHandler.addEventListener('hardwareBackPress', this._handleBack);
+ NativeDevMenu.show();
}
componentDidMount() {
```
Reviewed By: sammy-SC
Differential Revision: D18945861
Pulled By: hramos
fbshipit-source-id: edcf02c5803742c89a845a3e5d72bc7dacae839f
Summary:
With a Picker we would like to allow accessibility labels to be passed as a prop for situations where we want go give more detail. For example if we have a number picker that will be used for a timer instead of just saying 3, we might want to say 3 hours.
## Changelog
[General] [Added] - Picker test with an accessibility label prop
[General] [Added] - Support for accessibility Label prop to the Picker component
Pull Request resolved: https://github.com/facebook/react-native/pull/27342
Test Plan: Test plan is testing in RNTester making sure the examples work
Differential Revision: D18770184
Pulled By: hramos
fbshipit-source-id: e6f8ab4a9c50f3fb46342198441ecc71394913d3
Summary:
The class was deprecated in 2016 and is blocking an upgrade to fbjni
which no longer supports the `Countable` class this extends.
Changelog:
[Android] [Removed] - NativeRunnableDeprecated
Pull Request resolved: https://github.com/facebook/react-native/pull/27529
Test Plan: No references to it in this codebase.
Reviewed By: mdvacca
Differential Revision: D19087074
Pulled By: passy
fbshipit-source-id: a4ee73be7c13cedf1d86d2643f8e788ad4a2e31f
Summary:
Added basic hook to enable image instrumentation. The hook passes information to the existing image loader, where instrumentation is done, specific for each app, if any.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19047899
fbshipit-source-id: 6c013806cce98bcf1ea240d696a7ede9697e5cd9
Summary:
The `RCTImageURLLoaderWithAttribution` protocol historically only returns a cancellation block to cancel the url request. But for more complex instrumentation, we may need to associate a requestId for the specific URL request. To do this, the protocol now returns an object that has both the unique ID and the cancellation block, so that instrumentation logic can refer to the ID in the future.
Note that the `RCTImageURLLoader` protocol is unchanged, because the request ID is only relevant for instrumentation purpose.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19047900
fbshipit-source-id: cd029f2470c32fc7bffd674b09a5353fe1dbc80b
Summary:
This diff fixes the redbox that is currently affecting initial render of RN Android apps
More details: https://fb.workplace.com/groups/rn.support/permalink/3125289967519597/
Changelog: [internal]
Reviewed By: JoshuaGross, ejanzer
Differential Revision: D19132862
fbshipit-source-id: 6833a32bae2e0dda254f1bd09520551aa41fa822
Summary:
The react-native-oss-ios job has been failing when testBundleURL gets a local filesystem URL instead of a packager URL.
Setting CI_USE_PACKAGER allows us to force the test to use the packager.
Changelog:
[Internal]
Reviewed By: mmmulani
Differential Revision: D19105213
fbshipit-source-id: a58089bf278ca0f08dd3f4df94e9fe8ce9a63376
Summary:
Motivation: in Marketplace, there's a TextInput in JS that sends { lineHeight: null } to C++. In Paper this was correctly handled as a default value, which just causes that property to not be set. In C++ in Fabric, it was being parsed incorrectly as 0 (because of incorrect defaults being passed into `convertRawProp`), causing the text to not be visible at all. The solution is to make sure that its default value is NaN, which is handled correctly, and causes the Text to render again.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D19128049
fbshipit-source-id: fe985428f3ed8b90d56cfa387fbc2d1476d19d36
Summary:
`RCTImageLoader ` needs loaders & decoders. These can be passed in through init, or looked up at runtime using the bridge. In bridgeless mode, we need to pass them in through init.
This diff just moves the assert to actually protect `_bridge` usage, since there exist other codepaths which don't use the bridge.
Changelog: [iOS][Internal] Move RCTImageLoader asserts to protect bridge usage
Reviewed By: RSNara
Differential Revision: D18990760
fbshipit-source-id: 285008e7b3f473c45381ab472c3d86e5d8e218ae
Summary:
We have assertion to ensure that `getTurboModuleWithJsInvoker:` returns non-nullptr, so conditionally returning `nullptr` is not going to work.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D19103125
fbshipit-source-id: 663850c01e4db40cca96d254950ea5a7bf6b96b7
Summary:
The coefficients in the code were incorrect: the default value of the scale should be 1, not 0.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sahrens
Differential Revision: D19101221
fbshipit-source-id: 3b4c3afc692ddb6bf32bf2344a77ec5ca34a06e4
Summary:
There was a reflective call to a non-existent class. It did, however,
exist in the template, so I copied it over from there and updated
the references accordingly.
Pull Request resolved: https://github.com/facebook/react-native/pull/27482
Test Plan:
Built it and ran it. Works again with the latest Flipper desktop app.
Reviewed By: rickhanlonii
Differential Revision: D18933530
Pulled By: passy
fbshipit-source-id: 4515d7baaad9a9fff9a4b66e1cbf8a75889e6e45
Summary:
Refactors `Pressability` so that updates to the configuration are now explicitly committed using `configure()`.
Previously, the configuration was updated implicitly because `Pressability` accepted a series of functions whose closures capture values (e.g. `this.props`). Although these changes typically happen when component instances are "atomically" updated by React, it is not a guarantee. For example, arbitrary instance variables could be used to configure `Pressability`, and they could be muted at any time.
This change makes updates to the configuration of `Pressability` more predictable.
Changelog:
[Internal]
Reviewed By: TheSavior
Differential Revision: D18742620
fbshipit-source-id: d2e96dd1e3643289daab2177199a29f80d17b0bc
Summary:
Setting `padding` for Yoga node dirties it.
In the previous implementation, we did it for all newly cloned nodes. Now we do it only if State actually changes.
This is important because usually, SafeAreaView is a container node; that means that if some descendant of SafeAreaView changes its state, the recloning of all nodes down to root node will cause dirtying SafeAreaView and cause relayout if the whole subtree.
E.g., if we put ScrollView inside SafeAreaView without the fix, onScroll events will cause Yoga relayout (because ScrollView updates own state on debounced onScroll event).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D18987158
fbshipit-source-id: a3130c607c37e54ce813113222cd4a3872c58b6a
Summary:
`selectAll:` does not work for UITextView when it's being called inside UITextView's delegate methods.
This is a bug in UIKit and this quite ugly workaround is only a known solution for it.
Changelog: [Bug][iOS] Fixed bug in implementation of <TextInput>'s selectOnFocus prop
Reviewed By: sammy-SC
Differential Revision: D18966755
fbshipit-source-id: 2ba15fa94570d463a2ea3490331fb879611dc6b8
Summary:
All these NativeModules are now: (1) type-safe, (2) TurboModule-compatible.
**Note:** We still need to update `{Catalyst,Work,Fb4a}TurboModuleManagerDelegate` to understand these TurboModules. I'll most likely write up that diff and stack this one on top of it.
Changelog:
[Android][Added] - Make NativeModules TurboModule-compatible
Reviewed By: mdvacca
Differential Revision: D18888735
fbshipit-source-id: 34df64dc70e3f3a0a0303c049861205f9d3fd2ed
Summary:
For NativeModules that don't need to be accessed from JS, we can just have them implement the TurboModule interface. This is enough to make them be instantiated via the TurboModule system.
Changelog:
[Android][Added] - Make Java only NativeModules TurboModule-compatible
Reviewed By: ejanzer
Differential Revision: D18787789
fbshipit-source-id: d513006ffd736621adbd41146ed6280a60a7437e
Summary:
Fixes https://github.com/facebook/react-native/issues/16067
The issue is due to a race between `onLayout` and `onContentSizeChange`, which in general should be fine because there is no expectation of ordering between the two, and only causes issues with certain configurations.
The bug can be triggered if `initialNumToRender` is smaller than needed to fill past the `onEndReachedThreshold` (say the default, 10, is only 580px tall, but it takes 15 to reach the threshold). This will cause an incrementally render of more items to try and fill the viewport. The problem is that if the `onLayout` comes back before the first `onContentSizeChange`, it will first do the state increment to render 20 items and then the stale `onContentSizeChange` callback from 10 items will fire and we'll think that the content size for 20 items is 580px when in fact it's 1160px (which is past the threshold). If those 20 items are also all of our available data, then we'll call `onEndReached` because we think we've rendered everything and are still within the `onEndReachedThreshold`.
The fundamental problem here is the system getting confused when a stale async `onContentSizeChange` comes in after increasing `state.last`. I wish there was a concrete timeframe, but Fabric will give us more flexibility to do things synchronously so hopefully we can avoid class of issues once that roles out.
The fix here simply adds a check to make sure `contentLength` has been set before adjusting the render window so it's not possible to increase the window size before the initial `onContentSizeChange` callback fires.
For completeness, there are a few user-code workarounds to avoid this issue entirely:
1) Provide the `getItemLayout` prop so the list doesn't have to rely on async layout data (you should do this whenever possible anyway for better perf). e.g. for the original snack example, you can just add `getItemLayout={(d, index) => ({length: 58, offset: 58 * index, index})}` since all the rows are height 58 and the issue will no longer repro. Note this is fragile and must be kept in sync with UI changes, a11y font scaling, etc - a more robust approach could be to render a single representative row offscreen and measure it with `onLayout` then use that value.
2) If `getItemLayout` is not feasible to compute for your UI, increase `initialNumToRender` to cover the `onEndReachedThreshold`.
3) And/or add your own logic to protect against extra calls to `onEndReached` as others have suggested.
Changelog:
[General][Fixed] - Fix sporadic issue with onEndReached called on load when not needed
# Test Plan
Adds a new jest test that fails without this fix and succeeds with it.
Reviewed By: TheSavior
Differential Revision: D18966721
fbshipit-source-id: de05d9f072e24a2faf351e7f5d60578a31def996
Summary:
`Fb4a` and `Workplace` use only one product-specific `ReactPackage`, but `ReactInstanceManager` also installs `CoreModulesPackage` and `DebugCorePackage`. These two packages have NativeModules that got converted to the TurboModule system. So, I've added them to the `Fb4aReactPackagesTest` and `WorkReactPackageTest` to ensure that NativeModule conversions in framework-provided packages are also tested.
Changelog:
[Internal]
Reviewed By: PeteTheHeat
Differential Revision: D18974083
fbshipit-source-id: a98ec28a882ce51597a068ddecf43f5fbb6bfdc6
Summary:
The NativeModules in DebugCorePackage are now TurboModule-compatible. Therefore, we must make this extend `TurboReactPackage`.
Changelog:
[Internal] - Make DebugCorePackage a TurboReactPackage
Reviewed By: fkgozali
Differential Revision: D18974084
fbshipit-source-id: 648b54fefe7f8952666d5a23a9d81cc6bb167b31
Summary:
We're going to migrate our NativeModules to the TurboModule system soon. Therefore, it's no longer safe to assume that all NativeModules are not TurboModules. Also, it's not a good idea to hard-code this stuff if we can calculate the correct values on the fly.
Changelog:
[Internal]
Reviewed By: PeteTheHeat
Differential Revision: D18980859
fbshipit-source-id: 399a75a72d7f57998b217502ff79d7d911cc5a1c
Summary:
Remove textColor font and textAlignment in RCTBackedTextInputViewProtocol since they're all wired up in defaultTextAttributes already
Changelog: [iOS] [Removed] Remove three properties: "textColor" "font" "textAlignment" from RCTBackedTextInputViewProtocol, unifying the usage into "defaultTextAttributes".
Reviewed By: PeteTheHeat
Differential Revision: D18954292
fbshipit-source-id: 17fd38a824d035843ae59b1b875dd9c48b3fcc9b
Summary:
Update LogBox on iOS to lazily initialize, using a synchronous RCTSurface, behind RCTSharedApplication checks.
This results in faster of LogBox, without keeping around a long lived window in the background, and only used when LogBox is used.
On Android, we still start the react app in the background but we create a dialog when it's shown and then destroy it when it's hidden. Once we have the sync APIs on android we can update it to use the same strategy.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D18925538
fbshipit-source-id: 1a72c39aa0fc26c8ba657d36c7fa7bc0ae777eb9
Summary:
This PR changes gitignore to ignore prebuilt libs in ReactAndroid as a whole, because we added 64 bit platforms and their files are showing up as changes.
## Changelog
[GENERAL] [Changed] - gitignore ReactAndroid prebuilt libs
Pull Request resolved: https://github.com/facebook/react-native/pull/27487
Test Plan: After ReactAndroid build, you won't see prebuilt lib changes in git.
Differential Revision: D18992774
Pulled By: hramos
fbshipit-source-id: 33d3e01f59945dbc18ae4d9e3e3ac4b0e5b5e764
Summary:
We can use the HostComponent type now instead of NativeComponent
Changelog:
[Internal]
Reviewed By: zackargyle, rickhanlonii
Differential Revision: D18871289
fbshipit-source-id: 3c70369c5848dedfc22ca6f6ccbb69d6d60a1330
Summary:
iOS/UIKit prop `safeAreaInsets` sometimes produces values (and calls `safeAreaInsetsDidChange`) that practically the same but differ just enough to make operator `==` return `false`. That causes an indefinite state update loop and dizzying of the interface.
We do the same in Paper component as well.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D18964089
fbshipit-source-id: 4c714d2554fdee0f6e999921f69b95676080b8fa
Summary:
It's nice to have those conversions between NSAttributedString and AttributedTextBox in some utils module because:
An empty string must be stored as an empty C++ string, not like an empty NSAttributedString. That allows deferring this property from the object without accessing Objective-C runtime;
It's nice to hide some tedious Objective-C object wrapping/unwrapping boilerplate.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18950430
fbshipit-source-id: 842c202f243da17c47bc5cca9df6722cdcec07c5
Summary:
That will allow building a custom caching table for boxed stings to cache text measurements for them in TextLayoutManager.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18950428
fbshipit-source-id: 8ceef29543dc6ed540043e32d65f3295030ae90f
Summary:
We need to use that outside of this file, in Fabric's TextInputComponentView to build `defaultTextAttributes` from C++ text attributes.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18950433
fbshipit-source-id: c48155f4340b7e9780c35f86ba5155e54f160be1
Summary:
When we designed the Fabric's event priorities we followed the model "let's assign all priorities to all events as they should theoretically be and create a flag that disables sync execution (because we were unsure that it's stable enough". After some experiments, it's clear that this model is not feasible. We realized that we were often not sure about the exact event priority that should be assigned to a particular event. We also realized that the priorities in web work differently compare to RN. And we are not sure how we should ensure ordering among events in different queues with different priorities.
At the same time, we want to use (or experiment with) sync events for in some cases when we sure about desired behavior and/or where async events make no sense.
This diff deletes the macro that disables sync priorities and explicitly assigns async priorities to events that previously had sync ones.
The actual behavior should not change.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18950431
fbshipit-source-id: 4033ef63d4e736075b525a693cd514d7b92d5bb0
Summary:
RCTBackedTextInputViewProtocol is a protocol that describes which capabilities must be exposed for some TextInput-like UIView to be compatible with the rest of TextInput infra. We use that in both implementations. In Classic React Native we use Objective-C runtime mechanisms to call many of those methods (via ViewManager's directives); that masked the problem that the protocol was incomplete.
In Fabric, we call all methods normally, so we need to declare all of them here.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18950432
fbshipit-source-id: 3cd5cb57a033f7c43fd5f2c10f9706408e8e6d0c
Summary:
Both RCTUITextField and RCTUITextView must maintain the same public interface that describes all possible features that TextInput needs. That features are declared via `RCTBackedTextInputViewProtocol`.
`scrollEnabled` is a part of this protocol. The idea behind this prop was borrowed from `UIScrollView` class (which `UITextView` extends) and implemented for `RCTUITextField` (yeah, implemented as no-op).
In this diff we change the implementation of this prop to be more consistent with original implementation in UIScrollView:
* Now the name of the getter is now `isScrollEnabled`;
* The object now retains the actual value of the prop (even if it ignores that).
We need all those features for Fabric-compatible implementation.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18950426
fbshipit-source-id: 50c399d0fbba1be31750dbe4f235a075f86e8c01
Summary:
We need to expose the `multiline` prop in View Manager class to enable Fabric component to use it.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18950429
fbshipit-source-id: 69b225b24b4512a1ea21381daacbf868a23ccf6d
Summary:
The general rule that we follow in RN is that the *exported* .h files must have only `<>` includes. That allows to use them outside of the library where they are defined. Those files are already exported technically, but without this change cannot be used as exported.
New Fabric text input implementation uses them, so we need to change those includes to have `<>` style.
Changelog: [Internal] Specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18950427
fbshipit-source-id: 96cbe4cac9e28761c123bde8ac70464a0078ee6c
Summary:
RCTAssertJSThread is a specific to RCTCxxBridge assert that ensured that the code is executed on JavaScript thread. It was here from the very beginning. Now we need to remove it.
Reasons:
- The overall concept of limiting the execution of JavaScript code to a single thread is gone. Now we think about this as some queue, not thread. Fabric heavily relies on that and that asserts fires in Fabric.
- The assert is already far from being trivial: it checks for a custom executor, and if it's not nil, it does not fire. We can introduce another special flag for Fabric that will also disable that... but that's pointless. Such kinda asserts should not be complex to be useful.
- This asserts was used only in two places, and both of them are not exposed as public API.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18946388
fbshipit-source-id: 1e5fc732abdcb4bff3cfadcba24f7a433f1a480e
Summary:
The js_coverage step has failed on some recent PRs. While we want to continue collecting coverage data, we are not rejecting PRs that decrease coverage at the moment. Failing a PR in this step sends the wrong message, therefore, we should ignore whenever js_coverage fails.
> The actual coverage failures appear to be issues related to coveralls (the coverage service) failing to map the coverage data to a specific repository, not necessarily due to a decrease in coverage.
## Changelog
[Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/27488
Test Plan: CircleCI.
Differential Revision: D18962339
Pulled By: hramos
fbshipit-source-id: 46cbe32c70ecc01324a703073f390dad0de562f4
Summary:
Same as D18048277 but for Fabric text infra.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: PeteTheHeat
Differential Revision: D18950415
fbshipit-source-id: 09701e261ecb871b3624260a36dd607fdb70e717
Summary:
Google recommends to extend AppCompat widgets, and Android Studio suggests the change. This PR changes ReactEditText to extend AppCompatEditText.
## Changelog
[Android] [Changed] - ReactEditText extends AppCompatEditText
Pull Request resolved: https://github.com/facebook/react-native/pull/27039
Test Plan: CI is green
Reviewed By: mdvacca
Differential Revision: D18196901
Pulled By: hramos
fbshipit-source-id: 1484ae3da1be5776d0431dab3d4bb7ddbe5b8b7c
Summary:
This diff refactors ReactContext to use IllegalStateException instead of RuntimeException when applicable.
Changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D18901845
fbshipit-source-id: 51ec36824c8402fa2c17e76c55578be44ec8aa15
Summary:
This diff migrates a couple of events callsites of ReactRootView and ScrollView to be compatible with Bridgeless React mode
Changelog: [internal]
Reviewed By: ejanzer
Differential Revision: D18862857
fbshipit-source-id: f8e0d2d684bfaf84e9c138746507bb7728481b18
Summary:
This diff backports warning filter handling to yellow box. I also backported the skipped warning handling so that ignored patterns do not log to the console, same as LogBox.
Changelog: [Internal]
Reviewed By: gaearon
Differential Revision: D18573288
fbshipit-source-id: 5bf8e86f754adc808313d7ed02f98daaf65de98c
Summary:
These arguments were in the wrong order. It should be x,y,width,height,pageX,pageY. It was x,y,pageX,pageY,width,height.
Changelog:
[Internal]
Reviewed By: yungsters
Differential Revision: D18940318
fbshipit-source-id: ebd757648169b1ffbf33b35dded1d505a1c80974
Summary:
ExceptionManagers are created before the `ReactApplicationContext`. Once we make them all TurboModule-compatible, they'll also subclasses `ReactContextBaseJavaModule`. This means that they'll need to be created with `ReactApplicationContext`. Since one isn't available, we'll have to call `super(null)` in their constructor.
Changelog:
[Android][Changed] - Make ReactApplicationContext nullable as the constructor argument of ReactContextBaseJavaModule
Reviewed By: PeteTheHeat
Differential Revision: D18935950
fbshipit-source-id: a643a10a42cf36a2a2d6fde87795965f16295d43
Summary:
It's possible for us to return no constants from the BlobModule. Therefore, I'm correcting the flow-type.
Changelog:
[Internal]
Reviewed By: fkgozali
Differential Revision: D18932328
fbshipit-source-id: 2b415d12effd16eda313d5591825c711a20f9ae3
Summary:
Fixes https://github.com/facebook/react-native/issues/26830 by removing version gating around `RCTUserInterfaceStyleDidChangeNotification` sent by `RCTRootView` and observing that notif for `Dimensions` changes.
Also centralizes `RCTUserInterfaceStyleDidChangeNotification` constant definition in new `RCTConstants` file.
Changelog:
[iOS] [Fixed] - `Dimensions` module now updates on initial split screen
Reviewed By: sammy-SC
Differential Revision: D18931098
fbshipit-source-id: e9784be3f544f3b10360fbc2d6ad0324273b1a8f
Summary:
UIScrollView sometimes calls its delegate during its own deallocation and that causes a crash. This change introducing nil-ing the delegate before the deallocation to prevent this.
We already had this implemented in D17924429 but D18752886 broke that. This diff fixes that one more time.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18933934
fbshipit-source-id: 8da22ff4b1fefee712ced25cf0f1c239535554da
Summary:
Outside of __DEV__ the app may still try to use LogBox. We're going to fix that but until we do, if it tries to use LogBox outside of dev render null.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D18932666
fbshipit-source-id: ef0f2542a295dc9332cae8b77faed78f8be350fe
Summary:
If redbox flag is disabled, don't initialize LogBox window even if the native module exists. This makes the module noop.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D18927309
fbshipit-source-id: 3dc6c08ed537925594cabf77d1142568d47132e9
Summary:
This diff extends the UIManagerHelper class to expose the EventDispatcher associated to a tag / UImanagerType
Changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D18862863
fbshipit-source-id: 14ce7a6a33f20a94a6296320924dbe3544eadd85
Summary:
This diff exposes the getJSIModule on the ReactContext class.
This class already has methods to obtain NativeModules and JSModules, it make sense to expose the getJSIModule method too.
Changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D18862858
fbshipit-source-id: 95fe48c065266060c96fc40a002041ba398b3134
Summary:
This method exposes a method to ReactContext to determine if we are running in Bridgeless mode or not
Changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D18901149
fbshipit-source-id: bdd5ba747381f3bde5f592276b42244ca01ccbb9
Summary:
This diff promotes the UIManagerModule.getEventDispatcher() to the interface UIManager and it implements this method in FabricUIManager class.
Changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D18862862
fbshipit-source-id: 424f0e601ed1807dbd5d33048daf7dc3bb200dcd
Summary:
`NativeImageEditor` doesn't export any constants. Therefore, `ImageEditingManager` doesn't need a `getConstants()` method. In a subsequent diff (D18888735), I rename all `ReactMethod getConstants()` methods to `Override getTypedExportedConstants()`. This raises an error because the spec for `ImageEditingManager` doesn't contain a `getTypedExportedConstants()` method.
Changelog:
[Internal] - Delete getConstants() from ImageEditingManager
Reviewed By: fkgozali
Differential Revision: D18909419
fbshipit-source-id: 7e4f84f102068aa44bb3d267c66a60c0d0d27404
Summary:
`JSDevSupport.onSuccess` is called in `JSDevSupportModule.getJSHierarchy`:
```
const JSDevSupportModule = {
getJSHierarchy: function(tag: number) {
try {
const {
computeComponentStackForErrorReporting,
} = ReactNative.__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED;
const componentStack = computeComponentStackForErrorReporting(tag);
if (!componentStack) {
JSDevSupport.onFailure(
JSDevSupport.ERROR_CODE_VIEW_NOT_FOUND,
"Component stack doesn't exist for tag " + tag,
);
} else {
JSDevSupport.onSuccess(componentStack);
}
} catch (e) {
JSDevSupport.onFailure(JSDevSupport.ERROR_CODE_EXCEPTION, e.message);
}
},
};
```
If you look at the implementation of `computeComponentStackForErrorReporting`, it returns a `string`. The Java NativeModule also accepts a `String` for the argument to `JSDevSupport.onSuccess`. So, I've changed the `NativeJSDevSupport.onSuccess` method signature to match the native implementation (i.e: accept a string).
Changelog:
[General] [Fixed] - Correct argument types of NativeJSDevSupport.onSuccess
Reviewed By: fkgozali
Differential Revision: D18908306
fbshipit-source-id: 1c9a5c6fe5b3a81b25baed520e586ebf7e2514f8
Summary:
This diff fixes an issue where symbolicated logs were getting stuck in a "pending" state if the timeout occurred before symbolication finished.
Changelog: [Internal]
Reviewed By: sahrens
Differential Revision: D18894154
fbshipit-source-id: ed225962468f67aef40e430aa798f8d426d31027
Summary:
This diff adds a new `unstable_enableLogBox` function to opt-into the new LogBox experience. If LogBox is not enabled early enough, we show an error with instructions.
With this, LogBox can be enabled with:
```
require('react-native').unstable_enableLogBox();
```
Changelog: [General] [Adds] unstable_enableLogBox
Reviewed By: zackargyle, rubennorte
Differential Revision: D18808940
fbshipit-source-id: 4b0234ddc4d1646515bf63110d5b02133780512e
Summary:
Apologies for the large diff, it was difficult to break down.
This diff is a major refactor of LogBox that:
- Separates LogBoxNotification and LogBoxInspector
- Moves them each to their own container
- Updates AppContainer to only render the notification
- Updates the native logbox root to render the inspector
- Adds withSubscription HOC to manage subscribing to LogBoxData
- Simplifies LogBox to export an object instead of a component
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D18750011
fbshipit-source-id: 639885d29e55e125892d1c2b6bbf2826f27d78db
Summary:
This diff adds a NativeLogBox module implementation on Android to manage rendering LogBox the way we render RedBox, except rendering a React Native component instead of a native view.
The strategy here is:
- initialize: will create a React rootview and render it.
- show: will add the rootview to a dialog and display the dialog.
- hide: will remove the rootview from it's parent, dismiss the dialog, and release the reference to the activity to prevent leaks.
Most of this is copied from the way RedBox works, the difference here is that we eagerly initialize the rootview with the `initialize` function so that it's warm by the time the dialog needs to render.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18768517
fbshipit-source-id: 2510d6c186ccf73153ef9372c736c9e0c71bbc7d
Summary:
This diff adds a NativeLogBox module implementation on iOS to manage rendering LogBox the way we render RedBox, except rendering a React Native component instead of a native view.
The strategy here is:
- initialize: will create a hidden window (the way redbox does) and render the LogBox to it
- show: will show the window
- hide: will hide the window
Most of this is copied from the way RedBox works, the difference here is that we eagerly initialize the window with the `initialize` function so that it's warm by the time LogBox needs to render.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D18750008
fbshipit-source-id: 013e55ded55c8572bb08e0219ff4cd0060ebe0da
Summary:
This diff stubs out registering LogBox as a renderable component. In later diffs, we'll render this component on the native side.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D18750005
fbshipit-source-id: 4db082ca2104731641d2d10de1ba83a318ab44fb
2019-12-10 02:31:37 -08:00
3118 changed files with 225613 additions and 202196 deletions
about:Report a reproducible bug or regression in React Native.
title:''
labels:'Bug'
labels:'Needs:Triage :mag:'
---
<!--
Please provide a clear and concise description of what the bug is.
Include screenshots if needed.
Please test using the latest React Native release to make sure your issue has not already been fixed: http://facebook.github.io/react-native/docs/upgrading.html
-->
Please provide all the information requested. Issues that do not follow this format are likely to stall.
React Native version:
<!--
Run `react-native info` in your terminal and copy the results here.
-->
## Description
Please provide a clear and concise description of what the bug is. Include screenshots if needed.
Please test using the latest React Native release to make sure your issue has not already been fixed: https://reactnative.dev/docs/upgrading.html
## React Native version:
Run `react-native info` in your terminal and copy the results here.
## Steps To Reproduce
Provide a detailed list of steps that reproduce the issue.
1.
2.
<!--
Issues without reproduction steps or code are likely to stall.
-->
Describe what you expected to happen:
Snack, code example, screenshot, or link to a repository:
<!--
Please provide a Snack (https://snack.expo.io/), a link to a repository on GitHub, or
provide a minimal code example that reproduces the problem.
You may provide a screenshot of the application if you think it is relevant to your bug report.
Here are some tips for providing a minimal example: https://stackoverflow.com/help/mcve. --
-->
## Expected Results
Describe what you expected to happen.
## Snack, code example, screenshot, or link to a repository:
Please provide a Snack (https://snack.expo.io/), a link to a repository on GitHub, or provide a minimal code example that reproduces the problem.
You may provide a screenshot of the application if you think it is relevant to your bug report.
Here are some tips for providing a minimal example: https://stackoverflow.com/help/mcve
about:The issue tracker is not for questions. Please ask questions on https://stackoverflow.com/questions/tagged/react-native.
title:'Question:'
labels: 'Type:Question'
---
🚨 The issue tracker is not for questions. 🚨
As it happens, support requests that are created as issues are likely to be closed. We want to make sure you are able to find the help you seek. Please take a look at the following resources.
If you have a coding question related to React Native, it might be better suited for Stack Overflow. It's a great place to browse through frequent questions about using React Native, as well as ask for help with specific questions.
## Talk to other React Native developers
### https://www.reactiflux.com/
Reactiflux is an active community of React and React Native developers. If you are looking for immediate assistance or have a general question about React Native, the #react-native channel is a good place to start.
If you want to participate in casual discussions about the use of React Native, consider participating in one of the following forums:
If you'd like to discuss topics related to the future of React Native, or would like to propose a new feature or change before sending a pull request, please check out the discussions and proposals repo:
<!-- Help reviewers and the release process by writing your own changelog entry. See https://github.com/facebook/react-native/wiki/Changelog for an example. -->
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
# Configuration for Label Actions - https://github.com/marketplace/actions/label-actions
"Type: Invalid":
close:true
"Type: Question":
comment:>
We are using GitHub issues exclusively to track bugs in React Native. GitHub may not be the ideal place to ask a question, but you can try asking over on [Stack Overflow](http://stackoverflow.com/questions/tagged/react-native), or on [Reactiflux](https://www.reactiflux.com/).
close:true
"Type: Docs":
comment:>
Please report documentation issues in the [`react-native-website`](https://github.com/facebook/react-native-website/issues) repository.
close:true
"Type: Upgrade Issue":
comment:>
Do you need help upgrading to a newer React Native version? Visit the [Upgrade Support repository](https://github.com/react-native-community/upgrade-support) or use the [upgrade helper](https://react-native-community.github.io/upgrade-helper/) to see the changes that need to be made to upgrade your app.
close:true
"Resolution: For Stack Overflow":
comment:>
We are using GitHub issues exclusively to track bugs in the core React Native library. Please try asking over on [Stack Overflow](http://stackoverflow.com/questions/tagged/react-native) as it is better suited for this type of question.
It looks like your issue may be missing some necessary information. GitHub provides an example template whenever a <a href="https://github.com/facebook/react-native/issues/new?template=bug_report.md">new issue is created</a>. Could you go back and make sure to fill out the template? You may edit this issue, or close it and open a new one.
Your issue may be missing information about your development environment. You can obtain the missing information by running <code>react-native info</code> in a console.
It looks like you are using an older version of React Native. Please <a href="https://reactnative.dev/docs/upgrading">upgrade</a> to the latest version, and verify if the issue persists. If it does not, please let us know so we can close out this issue. This helps us ensure we are looking at issues that still exist in the current release.
It looks like your issue is missing a reproducible example. Please provide a <a href="https://snack.expo.io">Snack</a> or a repository that demonstrates the issue you are reporting in a <a href="https://stackoverflow.com/help/minimal-reproducible-example">minimal, complete, and reproducible</a> manner.
@@ -58,7 +58,7 @@ Facebook has a [bounty program](https://www.facebook.com/whitehat/) for the safe
## Helping with Documentation
The React Native documentation is hosted as part of the React Native website repository at https://github.com/facebook/react-native-website. The website itself is located at <https://facebook.github.io/react-native> and it is built using [Docusaurus](https://docusaurus.io/). If there's anything you'd like to change in the docs, you can get started by clicking on the "Edit" button located on the upper right of most pages in the website.
The React Native documentation is hosted as part of the React Native website repository at https://github.com/facebook/react-native-website. The website itself is located at <https://reactnative.dev/> and it is built using [Docusaurus](https://docusaurus.io/). If there's anything you'd like to change in the docs, you can get started by clicking on the "Edit" button located on the upper right of most pages in the website.
If you are adding new functionality or introducing a change in behavior, we will ask you to update the documentation to reflect your changes.
@@ -72,18 +72,21 @@ We recommend referring to the [CONTRIBUTING](https://github.com/facebook/react-n
## Contributing Code
Code-level contributions to React Native generally come in the form of [pull requests](https://help.github.com/en/articles/about-pull-requests). The process of proposing a change to React Native can be summarized as follows:
Code-level contributions to React Native generally come in the form of [pull requests](https://help.github.com/en/articles/about-pull-requests). These are done by forking the repo and making changes locally. Directly in the repo, there is the [`rn-tester` app](/packages/rn-tester) that you can install on your device (or simulators) and use to test the changes you're making to React Native sources.
The process of proposing a change to React Native can be summarized as follows:
1. Fork the React Native repository and create your branch from `master`.
2.If you've added code that should be tested, add tests.
3. If you've changed APIs, update the documentation.
4.Ensure the test suite passes, either locally or on CI once you opened a pull request.
5.Make sure your code lints (for example via `yarn lint --fix`).
6.Push the changes to your fork.
7.Create a pull request to the React Native repository.
8.Review and address comments on your pull request.
2.Make the desired changes to React Native sources. Use the `packages/rn-tester` app to test them out.
3. If you've added code that should be tested, add tests.
4.If you've changed APIs, update the documentation, which lives in [another repo](https://github.com/facebook/react-native-website/).
5.Ensure the test suite passes, either locally or on CI once you opened a pull request.
6.Make sure your code lints (for example via `yarn lint --fix`).
7.Push the changes to your fork.
8.Create a pull request to the React Native repository.
9. Review and address comments on your pull request.
1. A bot may comment with suggestions. Generally we ask you to resolve these first before a maintainer will review your code.
9. If you haven't already, please complete the [Contributor License Agreement](https://github.com/facebook/react-native/wiki/Contributor-License-Agreement) ("CLA"). **[Complete your CLA here.](https://code.facebook.com/cla)**
10. If you haven't already, please complete the [Contributor License Agreement](https://github.com/facebook/react-native/wiki/Contributor-License-Agreement) ("CLA"). **[Complete your CLA here.](https://code.facebook.com/cla)**
If all goes well, your pull request will be merged. If it is not merged, maintainers will do their best to explain the reason why.
@@ -10,14 +10,15 @@ There are three types of stakeholders:
## Partners
Partners are companies that are significantly invested in React Native and have been for years. Informed by their use of React Native, they push for improvements of the core and/or the ecosystem around it. Facebook's partners think of React Native as a product: they understand the trade offs that the project makes as well as future plans and goals. Together we shape the vision for React Native to make it the best way to build applications.
Partners are companies that are significantly invested in React Native and have been for years. Informed by their use of React Native, they push for improvements of the core and/or the ecosystem around it. Partners think of React Native as a product: they understand the trade offs that the project makes as well as future plans and goals. Together we shape the vision for React Native to make it the best way to build applications.
Our current set of partners include Callstack, Expo, Infinite Red, Microsoft and Software Mansion. Many engineers from these companies are core contributors, and their partner responsibilities also include:
React Native's current set of partners include Callstack, Expo, Facebook, Infinite Red, Microsoft and Software Mansion. Many engineers from these companies are core contributors, and their partner responsibilities also include:
* **[Callstack](https://callstack.com/):** Manages releases, maintains the [React Native CLI](https://github.com/react-native-community/react-native-cli) and organizes [React Native EU](https://react-native.eu/)
* **[Expo](https://expo.io/):** Builds [expo](https://github.com/expo/expo) on top of React Native to simplify app development
* **[Microsoft](https://www.microsoft.com/en-gb/):** Develops [React Native Windows](https://github.com/Microsoft/react-native-windows) for the Universal Windows Platform (UWP)
* **[Facebook](https://opensource.facebook.com):** Oversees the React Native product and maintains the [React Native core repo](https://reactnative.dev/)
* **[Microsoft](http://aka.ms/reactnative):** Develops [React Native Windows](https://github.com/Microsoft/react-native-windows) and [React Native macOS](https://github.com/microsoft/react-native-macos) for building apps that target Windows and macOS
* **[Software Mansion](https://swmansion.com/):** Maintain core infrastructure including JSC, Animated, and other popular third-party plugins.
In terms of open source work, pull requests from partners are commonly prioritized. When you are contributing to React Native, you'll most likely meet somebody who works at one of the partner companies and who is a core contributor:
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Nicola Corti
Lorenzo Sciandra
Bartosz Kaszubowski
Luna Wei
Brent Kelly
Lorenzo Sciandra
Dulmandakh
Kacie Bawiec
David Vacca
Riley Dulin
ajpaulingalls
Hank Chen
Neal Poole
Mike Grabowski
Janic Duplessis
Ivan Moskalev
Héctor Ramos
empyrical
Nick Gerleman
Vladimir Morozov
Jayme Deffenbaugh
Samuel Susla
Xuan Huang (黄玄)
Steven Conaway
Dmitriy Shishkin
Koichi Nagaoka
Michał Pierzchała
Luke Walczak
Jesse Katsumata
Kevin Gozali
Micha Reiser
Joshua Gross
Helena Ford
generatedunixname89002005325676
Valentin Shergin
Peter Argany
Hans Halverson
Paige Sun
Alexey Litvinov
Pasquale Anatriello
Jason Safaiyeh
Rubén Norte
Andrei Shikov
Christoph Nakazawa
generatedunixname89002005325674
Emily Janzer
Oleksandr Melnykov
Ramanpreet Nara
Tim Yung
Rick Hanlon
Tomoaki Imai
Héctor Ramos
Liang Liu
Marc Horowitz
Keith Melmon
Hugo Cuvillier
Pieter Vanderwerff
Keion Anvaripour
Dmytro Voronkevych
Lulu Wu
Scott Kyle
Nick Gerleman
Mark Sinkovics
Panagiotis Vekris
George Zahariev
Neil Dhar
Chris Dinh
hy.harry.yu@gmail.com
Dustin Shahidehpour
Mike Vitousek
Sam Goldman
Frieder Bluemle
Joshua Selbo
Tommy Nguyen
Martin Ortega
Rob Walker
Michael Yoon (LAX)
Stanisław Chmiela
Ankit Tiwari
chirag-singhal
Eloy Durán
Makar Kotlov
Agastya Darma
generatedunixname89002005287564
Michel Weststrate
Ullrich Schäfer
S. Weatherall
Will Holen
Jayme Deffenbaugh
Mi-ZAZ
Tommy Nguyen
Nat Mote
Moti Zilberman
Ian Childs
Hamid
Shoaib Meenai
Jimmy Zhang
Andy Matuschak
Gant Laborde
Betty Ni
Jordan Brown
generatedunixname89002005287564@sandcastle995.atn2.facebook.com
Stephy Ma
Martin Sherburn
benjaminhr
Sahil Jain
Daniel Sainati
Vojtech Novak
Jiawei Lv
Benjamin Henrik Robson
Jiayan Zhuang
Marshall Roch
Oleg Lokhvitsky
Devon Deonarine
Albert Sun
Nicholas Tinsley
Yogev Ben David
Aniket Kumar
Ayush Jain
Thomas Nardone
Gijs Weterings
Anton Bryukhov
Steven Moyes
Nico Burns
Andrey Tserkus
Paito Anderson
bill2004158
Patrik Tomas Chamelo
Ashoat Tevosyan
Tom Cheung
Jayesh Kawli
Tommy Nguyen
Oleg Bogdanov
fabriziobertoglio1987
Marcel Lasaj
Matthieu Harlé
Vince Picone
makitake2013
Dan Abramov
Santiago Alfonso Muñoz Rodriguez
Rick Hanlon
Hein Rutjes
Sean Wang
Amir Shalem
almouro
TMaszko
Eli White
Chris Dadabo
Andrew Coates (REDMOND)
Marco Scabbiolo
Omer Peleg
Vitaly Potlov
Lee Callender
Daniel Andersson
Petr Bela
Richard Groves
Vijay Ramamurthy
Eddie Dugan
Mark Verlingieri
Spencer Ahrens
Ryan Tremblay
Sidharth Guglani
William Candillon
Alex Brazier
Satyajit Sahoo
Danny Yan
Jacek Burys
Christoph Purrer
Fanghao
Ishan Khot
Sakamoto, Kazunori
Daniel Weaver
duan
Ram N
Aditya Kumar
Keegan Mendonca
Martin Sherburn
Kacper Wiszczuk
Manvir Singh
Enes
João Vieira
Pieter De Baets
Yuanzhe Bian
Nikita Lutsenko
Mats Byrkjeland
zhongwuzw
Boyang Yu
James Ide
Your Name
Daiki Ihara
Mark Lord
Jakub Kinst
Jonny Burger
sunnylqm
Tom Underhill
Hein Rutjes
Zack Argyle
acton393
Lauren Tan
Pritesh Nandgaonkar
jeswinsimon
Radek Czemerys
Scott Wolchok
Bruno Barbieri
Javier Cuevas
Xiaoyu Yin
jiggag
Sebastian Markbage
Daniel Cohen Gindi
Pavlos Vinieratos
Cristiano Santos
maciej simka
Chatura Atapattu
Jacob Bower
Emilis Baliukonis
Lucas Bento
Ventsislav Dimitrov
Brian Vaughn
Pedro Barbiero
Michael Bolin
Jack Wang
Alexander Kawrykow
Max Ovtsin
Sam Mathias Weggersen
Sergio Estevao
Luna Ruan
maschad
Héctor Ramos
Miguel Bolivar
Andy Himberger
Pascal Hartig
Max Kareta
Alec Larson
David Detlefs
Adam Ernst
Chad Smith
Jon Thysell (JAUNTY)
Logan Daniels
radex
Mihai
Arjan Zuidema
Mo Gorhom
Lorenzo Sciandra
Steven Bell
Gabriel Nunes
Nikita Kraev
Rachel Nabors
Varun Patel
Saumya Mukul
Sharon Gong
Janette Cheng
Venits
Andrey Lunyov
Haozhun Jin
Andres Suarez
Shu Lin
Josh Leibsly
Pascal Hartig
Jan Kassens
Lukas Weber
Jorge Bernal
Marcus Zarra
Han Lin Yap
Mackenzie Mance
Arthur Kushka
Leo Natan
Rick Ratmansky
Sonny Piers
Nicolas Charpentier
Ahmed Ibrahim
Nikita Shanin
Yuki Ueda
Michael Lee (Engineering)
Matt Chowning
Kudo Chien
Rajat Gupta
Nate Stedman
Shubho Sadhu
SAEED
Poyan Nabati
Matt Oakes
Max Thirouin
Jason Safaiyeh
Jakub
Oleg E. Bakharev
Emilio
Kevin Gonzales
Mehdi Mulani
Freeman Latif
David T. Nguyen
Igor Sugak
brotsky
