Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51693
This moves React Native to use the Central Portal URLs rather than the legacy OSSRH ones.
See https://github.com/gradle-nexus/publish-plugin for more context.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D75673984
fbshipit-source-id: 1de6746809eed72f232eac0c3fb4d809c2046620
Summary:
XCode privacy files might not contain a `NSPrivacyAccessedAPITypes` key, which causes the following error:
```
[!] An error occurred while processing the post-install hook of the Podfile.
undefined method `each' for nil
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:111:in `block (4 levels) in get_used_required_reason_apis'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:106:in `each'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:106:in `block (3 levels) in get_used_required_reason_apis'
```
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[IOS] [FIXED] - Privacy Manifest aggregation failing due to no `NSPrivacyAccessedAPITypes` key
Pull Request resolved: https://github.com/facebook/react-native/pull/44628
Test Plan: I tested this patch on our own app and it solved the issue.
Reviewed By: christophpurrer
Differential Revision: D57618425
Pulled By: cipolleschi
fbshipit-source-id: 1a36ab5a1bb45b8507d3663b782c95258d97c8a4
Summary:
As of now, Apple does not respect privacy manifests added as cocoapods resource bundles. This forces react-native developers to manually copy `.xcprivacy` files content for each native dependency that accesses restricted reason APIs to the root file.
This PR adds an aggregation step that crawls through pod dependencies to collect all reasons into the root privacy info file.
[IOS][ADDED] – Add privacy manifest aggregation.
Pull Request resolved: https://github.com/facebook/react-native/pull/44214
Test Plan:
When run on RNTester, it appends aggregated entries (while keeping existing ones) to existing .xcprivacy file without modifing .pbxproj:

When run on RNTester with the xcprivacy file removed from xcode beforehand, it creates a new .xcprivacy file, and adds it to Compile Bundle Resources in the same way as in the new template:

When run on RNTester with an empty .xcprivacy file, it appends aggregated entries from pods AND reasons for react-native core.
When run with `privacy_file_aggregation_enabled: false` in `use_react_native`, it falls back to existing behavior:

Reviewed By: cipolleschi
Differential Revision: D56481045
Pulled By: philIip
fbshipit-source-id: 1841bad821511c734d0cc0fcff5065ed92af76d8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44185
This change will fix a symbol not found for JSC Runtime.
The `if` check was not a compile time check, therefore the symbol ended up in the binary even if it is not available.
Following this post on [Apple forum](https://forums.developer.apple.com/forums/thread/749534), this changes should do the trick.
## Changelog
[iOS][Fixed] - Fix Symbol not found: (_JSGlobalContextSetInspectable)
Reviewed By: hash3r
Differential Revision: D56425834
fbshipit-source-id: a37af51b078bd47a938e6b65d9d8e0f7506e746f
Summary:
Changelog: [iOS][Added]
this creates the RN privacy manifest in the ios build step if user has not created one yet. the reasons have been added for the following APIs:
NSPrivacyAccessedAPICategoryFileTimestamp
- C617.1: We use fstat and stat in a few places in the C++ layer. We use these to read information about the JavaScript files in RN.
NSPrivacyAccessedAPICategoryUserDefaults
- CA92.1: We access NSUserDefaults in a few places.
1) To store RTL preferences
2) As part of caching server URLs for developer mode
3) A generic native module that wraps NSUserDefaults
NSPrivacyAccessedAPICategorySystemBootTime
- 35F9.1: Best guess reason from RR API pulled in by boost
Reviewed By: cipolleschi
Differential Revision: D53687232
fbshipit-source-id: 6dffb1a6013f8f29438a49752e47ed75c13f4a5c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43370
Component stacks with files ending in .ts, .tsx, or .jsx were skipped in LogBox reporting. This diff fixes the regex.
Changelog:
[General][Fixed] - Support .tsx, .ts, and .jsx in component stacks
Reviewed By: yungsters
Differential Revision: D54638526
fbshipit-source-id: a5271daaa7b687e8e075be3f94ab9b9c03f79b66
Summary:
Problem Causes: In ReactViewGroup, there is a conflict between the zIndex attribute and the removeClippedSubviews optimization attribute. When both are used at the same time, the array mDrawingOrderIndices in ViewGroupDrawingOrderHelper that records the rendering order of subviews is not reset when super is called in the updateSubviewClipStatus method to add and remove subviews.
Solution:�Because there are many third-party components that inherit from or depend on ReactViewGroup, all methods for adding and removing subviews in ViewGroup need to be override in ReactViewGroup, and ViewGroupDrawingOrderHelper corresponding to handleAddView and handleRemoveView needs to be called in these methods. And all the precautions for directly calling super to add and remove subviews are changed to calling the overridden method by ReactViewGroup.
Special Note: All addView related methods in ViewGroup will eventually be called to the addView(View child, int index, LayoutParams params) method, except addViewInLayout. Regarding the method of adding subviews, we only need to override addView(View child, int index, LayoutParams params) and addViewInLayout(View child, int index, LayoutParams params,boolean preventRequestLayout) in ReactViewGroup.
## Changelog:
[Android] [Fixed] - Fix the crash in ReactViewGroup of https://github.com/facebook/react-native/issues/30785
Pull Request resolved: https://github.com/facebook/react-native/pull/40859
Reviewed By: NickGerleman
Differential Revision: D50321718
Pulled By: javache
fbshipit-source-id: 7fa7069937b8c2afb9f30dd10554370b1be5d515
Summary:
Cocoapods 1.15 (https://github.com/facebook/react-native/issues/42698) current breaks the build, limit to version >= 1.13 & < 1.15
This is currently broken and affecting users, we'll remove this limit once Cocopods fixes the regression. It's currently blocking 0.73.3.
## Changelog:
[iOS][Fixed] don't allow cocoapods 1.15.
Summary:
This is a continuation of my [last PR](https://github.com/facebook/react-native/pull/40914) which improved the symbolication of unhandled promise rejections.
While I was developing another library I noticed I still got an error stack of the log adding and not of the error itself. The library I'm trying to debug does not throw a standard error object but rather a custom one, but it still contains the stack field. By passing this stack field to the logbox call I was able to get a better symbolicated stack trace. The exact line of the failure is not displayed but at least the correct file is.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[GENERAL] [ADDED] - Unhandled promise rejection - attach non-standard Error object stack info if possible
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/42079
Test Plan:
Test any unhandled promise rejection with a non-standard error (line 23, toString must not return `[object Error]`) and see if the correct (or at least a better) stack trace is shown.
Here is the one I got before and after this change:
<img src="https://github.com/facebook/react-native/assets/1634213/3d07faad-9535-42c9-8032-b4d8fe407e88" width="200" />
<img src="https://github.com/facebook/react-native/assets/1634213/2c39bd82-c7a1-4f58-8ac4-5c479bb96b6e" width="200" />
Reviewed By: huntie
Differential Revision: D52431711
Pulled By: cipolleschi
fbshipit-source-id: be2172d3b1e2fc3f72812faac372c83bc6dface2
* Prevent LogBox from crashing on long messages (#38005)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38005
Fixes https://github.com/facebook/react-native/issues/32093 by guarding the expensive `BABEL_CODE_FRAME_ERROR_FORMAT` regex with a cheaper initial scan. (Longer term, we should reduce our reliance on string parsing and propagate more structured errors.)
Changelog: [General][Fixed] Prevent LogBox from crashing on very long messages
Reviewed By: GijsWeterings
Differential Revision: D46892454
fbshipit-source-id: 3afadcdd75969c2589bbb06f47d1c4c1c2690abd
* Update RNTester Podfile.lock
* Check for major ruby version
---------
Co-authored-by: Moti Zilberman <moti@meta.com>
Summary:
Since yesterday evening (why it is always friday evening???) CircleCI or Gem decided to update the default bundler version that is installed with `gem bundle install`.
Therefore, CI for iOS stopped working.
This change installs bundler's versions so that they are compatible with the Ruby version.
[Internal] - Fix CI for iOS installing versions of bundler that are compatible with Ruby
Pull Request resolved: https://github.com/facebook/react-native/pull/41962
Test Plan: CircleCI is green
Reviewed By: GijsWeterings
Differential Revision: D52230544
Pulled By: cipolleschi
fbshipit-source-id: 2f96e16ecb94159953056e8de757ea4d249f80f0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37481
ViewManagers inherit from BaseJavaModule so we should honour the same lifecycle for them as we do for native modules, which is to call `invalidate` / `onCatalystInstanceDestroy` when the ReactContext is destroyed. This allows the ViewManager to do any cleanup which cannot happen at the View level.
Changelog: [Android][Fixed] ViewManagers now receive an invalidate callback
Reviewed By: cortinico
Differential Revision: D45945678
fbshipit-source-id: 27c26d951b50a734c42eb033a46e599ef939e29f
`build_codegen!` currently assumes that `@react-native/codegen` gets
installed next to `react-native`. In a pnpm setup, it's found under
`/~/react-native/node_modules/@react-native/codegen` instead.
However, as @dmytrorykun pointed out, we don't actually need to build
it outside of this repository.
In pnpm setups, codegen will fail during build because it cannot find
its dependencies. Some of the dependencies it relies on at runtime are
currently declared under `devDependencies`. This change moves them to
`dependencies`.
Summary:
For a very long time when a promise rejects without an attached catch we get this warning screen without a correct stack trace, only some internal calls to the RN internals.
<img src="https://github.com/facebook/react-native/assets/1634213/75aa7615-ee3e-4229-80d6-1744130de6e5" width="200" />
I created [an issue for discussion](https://github.com/react-native-community/discussions-and-proposals/discussions/718) in the react-native-community repo and we figured out it was only a matter of symbolication. While it cannot be done on release without external packages and source maps, at least while developing we can provide a symbolicated stack-trace so developers can better debug the source of rejected promise.
I got the stack trace symbolicated and the correct code frame. I'm missing some help trying to display it in the warning view but at the very least I can now correctly show the line of the error and log the codeframe to the console.
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[GENERAL] [FIXED] - Show correct stack frame on unhandled promise rejections on development mode.
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/40914
Test Plan:
I simply created a throwing function on a dummy app, and checked the output of the console and the warning view:
```ts
import React from 'react';
import {SafeAreaView, Text} from 'react-native';
async function throwme() {
throw new Error('UNHANDLED');
}
function App(): JSX.Element {
throwme();
return (
<SafeAreaView>
<Text>Throw test</Text>
</SafeAreaView>
);
}
export default App;
```
Here is the output
<img src="https://github.com/facebook/react-native/assets/1634213/2c100e4d-618e-4143-8d64-4095e8370f4f" width="200" />
Edit: I got the warning window working properly:
<img src="https://github.com/facebook/react-native/assets/1634213/f02a2568-da3e-4daa-8132-e05cbe591737" width="200" />
Reviewed By: yungsters
Differential Revision: D50324344
Pulled By: javache
fbshipit-source-id: 66850312d444cf1ae5333b493222ae0868d47056
Co-authored-by: Oscar Franco <ospfranco@gmail.com>
* Fix RNTestProject testing on Android (#41172)
Summary:
While releasing RN 0.73.0-RC3, we relaized that the e2e test script was bugged for Android when used to test RNTestProject with the `-c` option.
There were 2 problems:
- The downloaded maven-local was not actually used because it doesn't work with a zip. (We were always downloading a version from Maven)
- The versions of React Native between maven-local and the locally packaged React Native were different.
This change fixes the script by:
- Downloading maven-local
- Unzipping maven-local and passing the new folder to the Android app
- Downloading the React Native version that has been packaged in CI
By unzipping maven-local and using the unzipped folder, we make sure that Android is actually using the local repository.
By downloading both the packaged react native and the maven-local from the same CI workflow, we ensure that the versions are aligned.
This also speeds-up further the Android testing.
While running this change, we also moved the `pod install` step inside the `if (iOS)` branch, so we do not install Cocoapods if we need to test
Android.
[Internal] - Fix Android E2E test script when downloading artefacts from CI
Pull Request resolved: https://github.com/facebook/react-native/pull/41172
Test Plan: Tested locally on both main and 0.73-stable, on both Android and iOS
Reviewed By: cortinico
Differential Revision: D50651448
Pulled By: cipolleschi
fbshipit-source-id: 70a9ed19072119d19c5388e8a4309d7333a08e13
* Backport e2e script changes to main (#41332)
Summary:
Last week, I modified the e2e script to make sure it was working properly with 0.73.
This change backport those changes in main
## Changelog:
[Internal] - Backport e2e script changes
Pull Request resolved: https://github.com/facebook/react-native/pull/41332
Test Plan: Tested locally
Reviewed By: dmytrorykun
Differential Revision: D51025796
Pulled By: cipolleschi
fbshipit-source-id: 89ecd3701eaac4ba4bdde2c640df45a158329158
* Use old REACT_NATIVE_MAVEN_LOCAL_REPO env var
* prettier
---------
Co-authored-by: Riccardo Cipolleschi <riccardo.cipolleschi@gmail.com>
Co-authored-by: Riccardo Cipolleschi <cipolleschi@meta.com>
* Make the interop-layer work with components with custom name (#41207)
Summary:
This should fix
https://github.com/facebook/react-native/issues/37905#issuecomment-1774851214
When working on react-native-fast-image, we realized that the interop layer does not work for components where the exported name is different from the iOS class.
To fix this, we can use the Bridge to retrieve the actual view manager, given the component name.
This solution should be much more robust than making assumptions on the ViewManager name, given the ComponentName.
On top of that, we realized tha the interop layer was not calling `didSetProps` after setting the props, so we are invoking that.
bypass-github-export-checks
[iOS][Fixed] - Add support for Components with custom names in the interop layer.
Pull Request resolved: https://github.com/facebook/react-native/pull/41207
Test Plan: Tested locally on an app created in 0.72 and 0.73 in Bridge and Bridgeless mode.
Reviewed By: cortinico
Differential Revision: D50698172
Pulled By: cipolleschi
fbshipit-source-id: 49aee905418515b0204febbbe6a67c0114f37029
* Remove references to RCTBridgeProxy
---------
Co-authored-by: Riccardo Cipolleschi <riccardo.cipolleschi@gmail.com>
Co-authored-by: Riccardo Cipolleschi <cipolleschi@meta.com>
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41009
This change should fix [#39971](https://github.com/facebook/react-native/issues/39971), computing the relative path from the App path to the pod installation root and using that instead of the absolute path to the `react-native.config.js` file
## Changelog
[Internal] - Stabilize RCTAppDelegate podspec
Reviewed By: cortinico
Differential Revision: D50323710
fbshipit-source-id: e29e62228d08c752e822d7a9ab5b1a2b5dcd6eb4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36645
This broke while changing the AnimatedInterpolation back in D40571873 and D40632443, as I assumed the native side would be able to correctly handle values such as '1rad'. However these were being sent over as strings, and were thus using the string interpolation path, which does not work here.
Instead, handle both `deg` and `rad` explicitly when generating the config in JS.
Resolves issue https://github.com/facebook/react-native/issues/36608
Changelog: [General][Fixed] Resolves Animated.Value.interpolate results in NaN when output is in radians
Reviewed By: yungsters
Differential Revision: D44406034
fbshipit-source-id: fe0f3df16f2b8ec6c31f9359e4706cacc72b9951
Summary:
The Loading.../Refreshing... indicator is currently broken on Android.
The reason is related to D42599220
We used to have a Toast shown to users on Android as a fallback, but as the
DevLoadingView is not always loaded as a module in the core package, this ends up in the banner never beign shown to the user (on RN Tester or template apps).
Changelog:
[Android] [Fixed] - Fix broken Loading/Refreshing indicator on Android
Reviewed By: cipolleschi
Differential Revision: D49876757
fbshipit-source-id: 400e002327ebca908e3e7a7f81c5066888ac4e9b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39525
Switches `EventEmitter#emit` to use `Array.from` instead of the spread operator.
This should be functionally identical (with marginally less overhead of the runtime having to determine the type of `registrations`), but there seems to be [some unexpected Babel configurations in the community](https://github.com/facebook/react-native/issues/35577#issuecomment-1723218934) that causes this line of code to do the wrong things.
Although we should independently root cause the Babel plugin configuration problems, this change might provide immediate relief and is also not any worse (e.g. in terms of code readability). This also adds a descriptive comment explaining the intention of the call to `Array.from`.
Changelog:
[Fixed][General] - Fix a potential bug in `EventEmitter` when used with certain Babel configurations that incorrectly polyfill the spread operator for iterables.
Reviewed By: javache
Differential Revision: D49389813
fbshipit-source-id: 7caf63734fc047496afe2f1ed6d918c22747258a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39828
Active Suppert released a new Gem which is incompatible with Cocoapods 1.13.0, the latest release, as they removed a method used by cocoapods.
This fix ensures that we install compatible versions of the Gem.
## Changelog:
[iOS][Fixed] - Set the max version of Active support to 7.0.8
Reviewed By: hoxyq
Differential Revision: D49949782
fbshipit-source-id: 278097502d3a416567cc8c0b90090fee4fb21503
# Conflicts:
# Gemfile
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39710
Last week Apple released Xcode 15, which required us to ship a workaround for the new linker.
Unfortunately, the previous fix was not good enough and there were some edge cases that were not covered.
For example, in some occasions the flags are read as an array and the `-Wl` and the `-ld_classic` flags were separated and not properly removed when moving from Xcode 15 to Xcpde 14.3.1.
This change fixes those edge cases, with a more robust solution where:
- We convert the flags to a string.
- We trim the string and the values properly.
- We add the flags when running `pod install` with Xcode 15 as the default iOS toolchain.
- We remove the flags when running `pod install` with Xcode <15 as the default iOS toolchain.
## Changelog:
[Internal] - Make the Xcode 15 workaround more robust.
Reviewed By: dmytrorykun
Differential Revision: D49748844
fbshipit-source-id: 34976d148f123c5aacba6487a500874bb938fe99
# Conflicts:
# packages/react-native/scripts/cocoapods/__tests__/utils-test.rb
# packages/react-native/scripts/cocoapods/utils.rb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39516
With Xcode15, Apple rewrote the C++ linker.
This is a breaking change that does not work with weak symbols.
As a workaround, apple is suggesting to add `-ld_classic` to the linker in order to readd support for weak symbols. The flag does not exists for Xcode 14.3 or lower, so we need to add it conditionally.
With this change, we introduce a couple of checks in the Hermes build logic:
1. Detect the version of Xcode that is used
2. Add the new flag to `HERMES_EXTRA_LINKER_FLAGS` if Xcode version is 15.
[Internal] - Make hermes build properly with Xcode 15
Reviewed By: cortinico, dmytrorykun
Differential Revision: D49368675
fbshipit-source-id: 62d8ed81855c426f56ed94b6a2d6da2eb882b355
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39474
When it comes to Xcode 15 RC, we are aware of two issues:
1. `unary_function` and `binary_function` not available in Cxx17
2. [Weak linking](https://developer.apple.com/documentation/xcode-release-notes/xcode-15-release-notes#Linking) is not supported anymore.
This change should fix both of the issues, adding the flags to allow for `unary_function`and `binary_function` to be called and adding the `-Wl -ld_classic` flag to `OTHER_LDFLAGS` in case Xcode 15 is detected.
[Internal] - add the `_LIBCPP_ENABLE_CXX17_REMOVED_UNARY_BINARY_FUNCTION` and the `-Wl -ld_classic` flags to projects when needed
Reviewed By: dmytrorykun
Differential Revision: D49319256
fbshipit-source-id: bb895f1e60db915db79684f71fa436ce80b42111
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39478
When testing Xcode 15, we realized that a few pods we do not control directly have the IPHONEOS_DEPLOYMENT_TARGET set to old versions of iOS.
We can update that setting to silence the warning with Cocoapods and this is what this script does.
Notice that bumping that setting generated other warning as some APIs have been deprecated.
[Internal] - Bump min IPHONEOS_DEPLOYMENT_TARGET for 3rd party pods
Reviewed By: dmytrorykun
Differential Revision: D49274837
fbshipit-source-id: 584d105c76d654daa2ecf5eb2f1b9381e70f567a
Summary:
See: http://blog.nparashuram.com/2019/10/debugging-react-native-ios-apps-with.html
When using direct debugging with JavaScriptCore, Safari Web Inspector doesn't pick up the source map over the network. Instead, as far as I can tell, it expects you to pass the source URL at the time you load your bundle: https://developer.apple.com/documentation/javascriptcore/jscontext/1451384-evaluatescript?language=objc . This leads to a very sub-par developer experience debugging the JSbundle directly. It will however, pick up an inline source map. Therefore, let's add a way to have React Native tell metro to request an inline source map.
I did this by modifying `RCTBundleURLProvider` to have a new query parameter for `inlineSourceMap`, and set to true by default for JSC.
[IOS] [ADDED] - Added support to inline the source map via RCTBundleURLProvider
Pull Request resolved: https://github.com/facebook/react-native/pull/37878
Test Plan:
I can put a breakpoint in RNTester, via Safari Web Inspector, in human readable code :D
<img width="1728" alt="Screenshot 2023-06-14 at 4 09 03 AM" src="https://github.com/facebook/react-native/assets/6722175/055277fa-d887-4566-9dc6-3ea07a1a60b0">
Reviewed By: motiz88
Differential Revision: D46855418
Pulled By: huntie
fbshipit-source-id: 2134cdbcd0a3e81052d26ed75f83601ae4ddecfe
Summary:
Currently Android fails to build on Windows, because CMake cannot work with
native Windows paths that are passed to it as build arguments. This change
converts the input paths to the CMake format.
## Changelog:
[Android] [Fixed] - Fix building Android on Windows.
Pull Request resolved: https://github.com/facebook/react-native/pull/39190
Test Plan: Build the React Native Android project on Windows. It should complete successfully.
Reviewed By: NickGerleman
Differential Revision: D48948140
Pulled By: cortinico
fbshipit-source-id: 6d584c2a10e683cdb6df0dd6dcd5875da7e06e2b
Summary:
This partially reverts commit 58adc5e4b9.
Using an absolute path in a podspec is wrong, and causes checksum issues when installs are ran on different systems.
Example:
`pod install --deployment --clean-install` breaks on non-matching checksums on CI because the absolute path is not the same in that environment.
```
Adding spec repo `trunk` with CDN `https://cdn.cocoapods.org/`
Verifying no changes
[!] There were changes to the lockfile in deployment mode:
SPEC CHECKSUMS:
React-debug:
New Lockfile: 419922cde6c58cd5b9d43e4a09805146a7dd13a8
Old Lockfile: 1ce329843d8f9a9cbe0cdd9de264b20e89586734
React-NativeModulesApple:
New Lockfile: a683b0c999e76b7d15ad9d5eaf8b6308e710a93e
Old Lockfile: f82356d67a137295d098a98a03be5ee35871b5a5
React-runtimescheduler:
New Lockfile: 79f8dff11acbe36aaeece63553680d7a8272af96
Old Lockfile: 16c5282d43a0df50d7c68ebf0218aeeb642a7086
React-utils:
New Lockfile: 4fabb3cba786651e35bc41e610b0698fa24cecff
Old Lockfile: e7e9118d0e85b107bb06d1a5f72ec5db6bddb911
ReactCommon:
New Lockfile: af30fb021799e18c85a8e30ce799e15607e82212
Old Lockfile: f04f86f33c22e05dbf875789ea522ee486dace78
```
And even tho the change fixed an issue with pnpm, the issue it introduces with cocoapods I think is a bigger one.
## Changelog:
[INTERNAL] - Revert commit that makes podfile unstable
Pull Request resolved: https://github.com/facebook/react-native/pull/39177
Test Plan: Tested locally that the hashes are stable
Reviewed By: NickGerleman
Differential Revision: D48773887
Pulled By: cipolleschi
fbshipit-source-id: 96bcdbadc17a24fa9a8669f569d004bee6a03521
Summary:
Android builds with new arch fail on Windows build host (https://github.com/facebook/react-native/issues/36475). This tiny correction fixes generation of `schema.json` (without it codegen failed to find any files, and generated empty schema). Unfortunately, does not fixes the issue with Windows host entirely, as builds still fail later (on ninja build step).
## Changelog:
[Android] [Fixed] - A bug fix for Android builds with new arch on Windows host.
Pull Request resolved: https://github.com/facebook/react-native/pull/36542
Reviewed By: NickGerleman
Differential Revision: D48563587
Pulled By: cortinico
fbshipit-source-id: acd510308ce9768fb17d3a33c7927de3237748ac
Summary:
An earlier [change](https://github.com/facebook/react-native/commit/8b1bf058c4bcbf4e5ca45b0056217266a1ed870c) I made (that huntie resubmitted) only works on Xcode 14.3+ (See more info [here](https://github.com/react-native-community/discussions-and-proposals/discussions/687)). This change adds the appropriate compiler checks so that the change is compatible with Xcode 14.2 and earlier, and therefore cherry-pickable to 0.71 and 0.72.
The check works by checking if iOS 16.4+ is defined, which is the closest proxy I could find for "Is this Xcode 14.3".
## Changelog:
[IOS] [CHANGED] - Guard `JSGlobalContextSetInspectable` behind a compile time check for Xcode 14.3+
Pull Request resolved: https://github.com/facebook/react-native/pull/39037
Test Plan: I can't actually test on Xcode 14.2 (it won't launch on my MacBook 😢), but I made a similar [PR](https://github.com/microsoft/react-native-macos/pull/1848) in React Native macOS, whose CI checks run against Xcode 14.2 and I'm getting passing checks there.
Reviewed By: huntie
Differential Revision: D48414196
Pulled By: NickGerleman
fbshipit-source-id: ba10a6505dd11d982cc56c02bf9f7dcdc104bbec
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39008
Changelog: [Internal] - Adjust RawPropsPropNameLength's type to account for increased number of props
While investigating why we needed to back out D48288752 I discovered that the root cause was that the `items_` vector in `RawProsKeyMap` was now a size greater than 255 which becomes an issue because `items_`'s indices are statically cast to `RawPropsPropNameLength` (previously alias to `uint8_t`).
This diff updates `RawPropsPropNameLength` to be an alias to `uint16_t` so the current issue is resolved as well as adding an assert to ensure (however unlikely) that this happens again.
Reviewed By: rozele
Differential Revision: D48331909
fbshipit-source-id: f6bc3e4825f2f293d79d8cd90c40ced7cba0e3c5
Summary:
`mFirstVisibleView` is a weak ref so it can also be null when dereferencing.
This was reported on the original PR here https://github.com/facebook/react-native/pull/35049#discussion_r1288195469
## Changelog:
[ANDROID] [FIXED] - Fix null crash when using maintainVisibleContentPosition on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/38891
Test Plan: Not sure exactly in what cases this can happen, but the fix is trivial and makes sense.
Reviewed By: cortinico
Differential Revision: D48192154
Pulled By: rshest
fbshipit-source-id: 57a38a22a0e216a33603438355bde0013c014fbf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38857
`hitSlop` must be passed into the `usePressability` hook in order for it to take effect. It's a no-op if no hit slop is present
Changelog:
[Internal][Fixed] - Propagate hit slop prop to TextInput pressability config
Reviewed By: NickGerleman
Differential Revision: D48124538
fbshipit-source-id: a910fdcec55e67d37c84facca297428556ef777e
Summary:
Hello! This PR is a fix for one merged some time ago (https://github.com/facebook/react-native/pull/36216). In the PR check for `nullptr` value of `newRootShadowNode` just after performing commit hooks was overlooked. This PR restores previous behaviour of conditional commit cancellation after commit hook execution.
## Changelog:
[INTERNAL] [FIXED] - Restore checking shadow tree commit cancellation after commit hook execution
Pull Request resolved: https://github.com/facebook/react-native/pull/38715
Test Plan: Just register a commit hook that return `nullptr`. In that case current code crashes due to `nullptr` dereference.
Reviewed By: sammy-SC
Differential Revision: D47972245
Pulled By: ryancat
fbshipit-source-id: 7599ad11ed4b2dcaf25e53f676ec4530e37410d5
Summary:
This PR aims to fix an issue where installing iOS pods from a different directory causes the `hermes-engine` `:tag:` not to be properly resolved.
Ever since https://github.com/facebook/react-native/issues/37148 was merged, the `setup_hermes` script tries to resolve the `node_modules/react-native/sdks/.hermesversion` file and use its content to generate the pod tag, in order to verify when it changes over time.
This works perfectly when installing pods within the `ios` folder, as the `react_native_path` should point to the correct relative folder (`../node_modules/react-native` by default).
However, when installing pods from a different directory (the project root, for example) and leveraging the `--project-directory` flag, the file fails to resolve, as the current working directory is considered when resolving the `.hermesversion` file.
### Quick Example:
- `react_native_path`: `../node_modules/react-native` (the default config)
**Installing pods from the `ios` folder:**
- `cd ios`
- `bundle exec pod install`
- `hermestag_file` resolved path: `$project_root/node_modules/react-native` ✅
- `hermes-engine` `:tag:`: `hermes-2023-03-20-RNv0.72.0-49794cfc7c81fb8f69fd60c3bbf85a7480cc5a77` ✅
**Installing pods from the `$project_root` folder**
- `bundle exec pod install --project-directory=ios`
- `hermestag_file` resolved path: `$parent_folder/$project_root/node_modules/react-native` ❌
- `hermes-engine` `:tag:`: `''` ❌
### The fix
Turns out that the same file had a resolved reference to the `react-native` folder, assigned to the `react_native_dir` variable:
```ruby
react_native_dir = Pod::Config.instance.installation_root.join(react_native_path)
```
By resolving the `.hermesversion` using that folder, we guarantee that the relative path will always reference the directory where the `Podfile` is defined, which is the expected behaviour.
## Changelog:
[Internal] - Fix an issue where installing pods from a different directory would fail to resolve `hermes-engine` tags correctly.
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/38754
Test Plan:
- Init a new `react-native` repo
- Remove the generated `Podfile.lock` file
- Navigate to the project root folder
- `bundle exec pod install -project-directory=ios`
- Check that the `hermes-engine` entry has a properly populated `:tag:` attribute:
**Before:**
```
hermes-engine:
:podspec: "../node_modules/react-native/sdks/hermes-engine/hermes-engine.podspec"
:tag: ''
```
**After:**
```
hermes-engine:
:podspec: "../node_modules/react-native/sdks/hermes-engine/hermes-engine.podspec"
:tag: hermes-2023-03-20-RNv0.72.0-49794cfc7c81fb8f69fd60c3bbf85a7480cc5a77
```
Reviewed By: cortinico
Differential Revision: D48029413
Pulled By: cipolleschi
fbshipit-source-id: 82d465abd5c888eeb9eacd32858fa4ecf4f8c217
Summary:
This PR is a result of this PR, which got merged but then reverted:
- https://github.com/facebook/react-native/pull/37913
We are trying to implement a workaround for https://github.com/facebook/react-native/issues/35350, so react-native users on android API 33+ can use `<FlatList inverted={true} />` without running into ANRs.
As explained in the issue, starting from android API 33 there are severe performance issues when using scaleY: -1 on a view, and its child view, which is what we are doing when inverting the ScrollView component (e.g. in FlatList).
This PR adds a workaround. The workaround is to also scale on the X-Axis which causes a different transform matrix to be created, that doesn't cause the ANR (see the issue for details).
However, when doing that the vertical scroll bar will be on the wrong side, thus we switch the position in the native code once we detect that the list is inverted, using the newly added `isInvertedVirtualizedList` prop.
This is a follow up PR to:
- https://github.com/facebook/react-native/pull/38071⚠️ **Note:** [38071](https://github.com/facebook/react-native/pull/38071) needs to be merged and shipped first! Only then we can merge this PR.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[ANDROID] [FIXED] - ANR when having an inverted FlatList on android API 33+
Pull Request resolved: https://github.com/facebook/react-native/pull/38073
Test Plan:
- Check the RN tester app and see that scrollview is still working as expected
- Add the `internalAndroidApplyInvertedFix` prop as test to a scrollview and see how the scrollbar will change position.
Reviewed By: cortinico
Differential Revision: D47848063
Pulled By: NickGerleman
fbshipit-source-id: 4a6948a8b89f0b39f01b7a2d44dba740c53fabb3
Summary:
This PR is a result of this PR, which got merged but then reverted:
- https://github.com/facebook/react-native/pull/37913
We are trying to implement a workaround for https://github.com/facebook/react-native/issues/35350, so react-native users on android API 33+ can use `<FlatList inverted={true} />` without running into ANRs.
This is the native part, where we add a new internal prop named `isInvertedVirtualizedList`, which can in a follow up change be used to achieve the final fix as proposed in https://github.com/facebook/react-native/pull/37913
However as NickGerleman pointed out, its important that we first ship the native change.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[ANDROID] [ADDED] - Native part of fixing ANR when having an inverted FlatList on android API 33+
Pull Request resolved: https://github.com/facebook/react-native/pull/38071
Test Plan:
- Check the RN tester app and see that scrollview is still working as expected
- Add the `isInvertedVirtualizedList` prop as test to a scrollview and see how the scrollbar will change position.
Reviewed By: rozele
Differential Revision: D47062200
Pulled By: NickGerleman
fbshipit-source-id: d20eebeec757d9aaeced8561f53556bbb4a492e4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38256
Add RECEIVER_EXPORTED/RECEIVER_NOT_EXPORTED flag support to DevSupportManagerBase for Android 14 change. See
https://developer.android.com/about/versions/14/behavior-changes-14#runtime-receivers-exported for details.
Without this fix, app crashes during launch because of :
```SecurityException: {package name here}: One of RECEIVER_EXPORTED or RECEIVER_NOT_EXPORTED should be specified when a receiver isn't being registered exclusively for system broadcasts```
Changelog:
[Targeting SDK 34] Added RECEIVER_EXPORTED/RECEIVER_NOT_EXPORTED flag support in DevSupportManagerBase
Reviewed By: javache
Differential Revision: D47313501
fbshipit-source-id: 12e8299559d08b4ff87b4bdabb0a29d27763c698
Summary:
We had to disable the envinfo command on test_windows to get the CI back to green.
The reason why it started failing is because they released 7.9.0 which does not seem to have the executable on Windows, so `npx` fails to find what to run.
This fix restore the command in a way that it should display the envinfo using an older version of the package. I also added a task to come back to this periodically.
## Changelog:
[Internal] - Restore envinfo on windows
Pull Request resolved: https://github.com/facebook/react-native/pull/38062
Test Plan: - CircleCI: test_windows stays green
Reviewed By: cortinico
Differential Revision: D47016995
Pulled By: cipolleschi
fbshipit-source-id: 368367caed7ea49d7419475580a39f9406c54757
# Conflicts:
# .circleci/config.yml
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38223
Before this change, the InteropLayer was adding the view to the registry right before invoking a command and right after the command was invoked. This model was too strict as some view commands may have async behaviors that make the lookup in the registry fail.
After this change, we are going to register the view when it's created and we are going to remove it when the view is deallocated.
## Changelog:
[iOS][Changed] - Update logic to add and remove views in the view registry for the interop layer.
Reviewed By: sammy-SC
Differential Revision: D47262664
fbshipit-source-id: 503f4e29e03bfc7ad861c1502129822b383ffcc0
Summary:
Fixes a regression added [on merge of https://github.com/facebook/react-native/issues/37531](https://github.com/facebook/react-native/commit/260bcf7f1bf78022872eb2f40f33fb552a414809#diff-16a358d6a9dea8469bfdb899d0990df1c32b8c3b1149c86685bec81f50bd24beR179) (though oddly I don't see it in [https://github.com/facebook/react-native/issues/37531's diff](https://github.com/facebook/react-native/pull/37531/files#diff-16a358d6a9dea8469bfdb899d0990df1c32b8c3b1149c86685bec81f50bd24beR179), so perhaps added during conflict resolution?) where multiple arguments in `$EXTRA_COMPILER_ARGS` are now incorrectly wrapped in quotes, including RN's own sourcemap support:
```
runner@SeansMacBookGo sampleapp % /Users/runner/builds/y_x6gsp4/0/sampleapp/ios/Pods/hermes-engine/destroot/bin/hermesc -emit-binary -max-diagnostic-width=80 '-O -output-source-map' -out /Users/runner/builds/y_x6gsp4/0/sampleapp/ios/build/derived-data/Build/Intermediates.noindex/ArchiveIntermediates/sampleapp/BuildProductsPath/Release-iphoneos/sampleapp.app/main.jsbundle /Users/runner/builds/y_x6gsp4/0/sampleapp/ios/build/derived-data/Build/Intermediates.noindex/ArchiveIntermediates/sampleapp/BuildProductsPath/Release-iphoneos/main.jsbundle
hermesc: Unknown command line argument '-O -output-source-map'. Try: '/Users/runner/builds/y_x6gsp4/0/sampleapp/ios/Pods/hermes-engine/destroot/bin/hermesc -help'
hermesc: Did you mean '-output-source-map'?
```
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[IOS] [FIXED] - Fix build error when there are multiple EXTRA_COMPILER_ARGS
Pull Request resolved: https://github.com/facebook/react-native/pull/38147
Test Plan: Removing the quotes and running the command results a successful run of `hermesc` (exit code 0 and the expected files produced).
Reviewed By: rshest
Differential Revision: D47254412
Pulled By: cipolleschi
fbshipit-source-id: 96b71bb05c7a6939088816e76a9a2d02e89ed768
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38212
This mirrors the same logic that the Hermes team has on facebook/hermes.
Practically, we want to pass the CMake config flag `HERMES_ENABLE_DEBUGGER=False` only for Release
so that their CMake build is configured correctly.
Their build always enables the Debugger and allows us to selectively turn it off only for release
builds.
More context: https://github.com/facebook/hermes/commit/eabf5fcd25
Changelog:
[Internal] [Changed] - Compile hermes-engine with -DHERMES_ENABLE_DEBUGGER=False on Release
Reviewed By: cipolleschi
Differential Revision: D47252735
fbshipit-source-id: 9b5cd801dea3b540a3f80b0d0975e05984f1d9b9
Summary:
Fix build failure on iOS with pnpm and use_frameworks! due to cocoapods copying symlinked headers to wrong paths
When using pnpm all packages are symlinked to node_modules/.pnpm to prevent phantom dependency resolution. This causes react-native iOS build to fail because Cocoapods copies headers to incorrect destinations when they're behind symlinks. The fix resolves absolute paths to the header_mappings_dir at pod install time. With absolute paths cocoapods copies the headers correctly.
This commit also adds a few missing header search paths in use_frameworks! mode.
Fixes https://github.com/facebook/react-native/issues/38140
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[IOS] [FIXED] - Build failure with pnpm and use_frameworks! due to incorrect header paths
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/38158
Test Plan:
1. `pnpm pnpx react-native@latest init AwesomeProject`
2. `cd AwesomeProject`
3. `rm -rf node_modules yarn.lock`
4. `mkdir patches`
5. copy [react-native@0.72.1.patch](https://github.com/facebook/react-native/files/11937570/react-native%400.72.1.patch) to `patches/`
6. Add patch to package.json
```
"pnpm": {
"patchedDependencies": {
"react-native@0.72.1": "patches/react-native@0.72.1.patch"
}
}
```
7. `pnpm install`
8. `cd ios`
9. `NO_FLIPPER=1 USE_FRAMEWORKS=static pod install`
10. `cd ..`
11. `pnpm react-native run-ios`
Hopefully an automated test of building with `pnpm` can be added to CI. I don't know how to make that happen, hopefully someone at facebook can do it.
Reviewed By: dmytrorykun
Differential Revision: D47211946
Pulled By: cipolleschi
fbshipit-source-id: 87640bd3f32f023c43291213b5291a7b990d7e1f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38205
Enable the preprocessor flag to allow debugging when in a debug build. This flag influences the Hermes headers included in the inspector, and causes them to include the debugging functionality.
Changelog:
[General][Fixed] - Re-enabled debugging for debug builds
Reviewed By: lunaleaps, cortinico
Differential Revision: D47243235
fbshipit-source-id: 7982c69ab554335a9ad985394e4416ed69831137
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38129
changelog: [iOS] Disable NSTextStorage caching in OSS
A [bug was reported](https://github.com/facebook/react-native/issues/37944) for NSTextStorage caching. Even thought I fixed the bug in D47019250, I want to disable the feature in OSS until the fix is verified in Facebook app.
My plan is to pick this commit for 0.72.1 and reenable NSTextStorage caching once the fix is validated.
Reviewed By: NickGerleman
Differential Revision: D47127912
fbshipit-source-id: 97694e383eb751e89b776c0599969f2c411bac6f
Summary:
This fixes a bug that started with React Native 0.72.0 when using the new architecture and installing a native lib that has Swift code (in my case, `datadog/mobile-react-native`).
Running `pod install` errors with the following output (`DatadogSDKReactNative` is the pod containing the Swift code):
```
[...]
Analyzing dependencies
Downloading dependencies
Installing DatadogSDKReactNative 1.8.0-rc0
[!] The following Swift pods cannot yet be integrated as static libraries:
The Swift pod `DatadogSDKReactNative` depends upon `React-Fabric`, `React-graphics`, `React-utils`, and `React-debug`, which do not define modules. To opt into those targets generating module maps (which is necessary to import them from Swift when building as static libraries), you may set `use_modular_headers!` globally in your Podfile, or specify `:modular_headers => true` for particular dependencies.
```
Indeed, this pods were added as dependencies in `packages/react-native/scripts/cocoapods/new_architecture.rb` but do not define modules contrary to the other pods in the list.
This PR is solving a problem that already occured in the past and was solved here: https://github.com/facebook/react-native/pull/33743
It's a new implementation for the PR initially opened here: https://github.com/facebook/react-native/pull/38039
## Changelog:
[IOS] [FIXED] - Fix pod install for libraries using Swift code when the new architecture is enabled
Pull Request resolved: https://github.com/facebook/react-native/pull/38121
Test Plan:
1. Clone [this](https://github.com/louiszawadzki/react-native) repo
2. From `main`, add a Swift file to the `MyNativeView` native module in the RN tester app (see inspiration from [this commit](https://github.com/fortmarek/react-native/commit/26958fccf4b4ac90d0bf9bb3699f12760a6b2b58))
3. Try to run `RCT_NEW_ARCH_ENABLED=1 USE_HERMES=0 bundle exec pod install` inside the `packages/rn-tester`
4. Observe errors
5. Apply [the commit](https://github.com/facebook/react-native/commit/7b7c3ff530cae07daccc5b5ea6b72d239f913be0) from this PR
6. Both pod install and the subsequent build should succeed.
7. Revert the changes and repeat steps 2 to 6 with `RCT_NEW_ARCH_ENABLED=1 USE_HERMES=1 bundle exec pod install`
Reviewed By: cortinico
Differential Revision: D47127854
Pulled By: cipolleschi
fbshipit-source-id: bf7f65e0d126195a76a0fafbe2f3172f00d5adc1
# Conflicts:
# packages/react-native/ReactCommon/react/renderer/debug/React-rendererdebug.podspec
Summary:
We've been encountering a crash in `runAnimationStep` with "Calculated frame index should never be lower than 0" https://github.com/facebook/react-native/issues/35766 with OnePlus/Oppo devices as well, but don't have one on hand to test.
This just works around the issue: if the time is before the start time of an animation, we shouldn't do anything anyways, so we just log a message instead of throwing while in production. We still throw in debug mode though for easier debugging.
### Hypothesis of the root cause
Based on stacktrace in https://github.com/facebook/react-native/issues/35766 (which is the same one we see)
Normally, this should happen
1. Choreographer.java constructs a FrameDisplayEventReceiver
2. FrameDisplayEventReceiver.onVSync gets called, which sets the `mTimestampNanos`
3. FrameDisplayEventReceiver.run gets called, which then eventually calls our `doFrame` callback with `mTimestampNanos`. This then causes `FrameBasedAnimationDriver.runAnimationStep` to be called with the same timestamp
I suspect what's happening on OnePlus devices is that the `onVSync` call either doesn't happen or happens rarely enough that the `mTimestampNanos` when `run` is called is sometime in the past
### Fix
1. Add logging so we get the parameters to debug more if we end up getting this error
2. In production, just ignore past times instead of throwing an Error
## Changelog:
Pick one each for the category and type tags:
[ANDROID] [FIXED] - Prevent crash on OnePlus/Oppo devices in runAnimationStep
Pull Request resolved: https://github.com/facebook/react-native/pull/37487
Test Plan: Ran our app using patched version and verified no issues showed up when using it
Reviewed By: cipolleschi
Differential Revision: D46102968
Pulled By: cortinico
fbshipit-source-id: bcb36a0c2aed0afdb8e7e68b141a3db4eb02695a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38089
This change add a warning if a component is registered in both the New Renderer and in the Interop layer.
This can help users migrating their components once the library has been migrated.
[iOS][Added] - Add warning to help users migrate away from the interop layer.
Reviewed By: cortinico
Differential Revision: D47053556
fbshipit-source-id: cc2ba09db16aaa370947a77173b6ea6a0acfa519
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38093
In [this issue](https://github.com/facebook/react-native/issues/37905), the community detected a strict assumption in the interop layer for which, given a component `XXXView`, its ViewManager must be called `RCTXXXViewManager`.
That's not the case for some components, for example, `BVLinearGradient`, which View manager is `BVLinearGradientManager` and not `RCTBVLinearGradientManager`.
This diff adds a secondary lookup logic:
1. We look for the `RCTXXXViewManager`.
2. If not found, we look for `XXXViewManager`.
We will assess whether to generalize this logic once and for all or to expand other lookup cases on an example/failure basis as it's not a goal to have a 100% accurate interop layer. The Goal is to cover most use cases.
[iOS][Added] - Allow to lookup for ViewManager without the RCT prefix in the Interop Layer
Reviewed By: sammy-SC
Differential Revision: D47055969
fbshipit-source-id: 1d31f3f4bc6f1f543edbd157ce04ad9daf23dbc6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38075
changelog: [internal]
`SharedFunction<>` is created with nullptr for its internal `std::function`. If called after created with default constructor, it crashes app. It also does not have API to check if its internal function is not nullptr.
With image cancelation, there is a race between when native component calls `imageRequest.cancel()` and when cancelation function is set in `RCTImageManager`.
To fix this, this diff adds a nullptr check inside SharedFunction. So it is always safe to call.
Reviewed By: javache
Differential Revision: D47022957
fbshipit-source-id: 0a04a87cd1ffe6bf3ca2fded38f689f06cc92ca9
Summary:
Installing `react-native` 0.72.x causes a warning about `react-test-renderer` because `react-native/virtualized-lists` has declared a peer dependency on it. As far as I know, it is not used for anything but tests.
```
➤ YN0002: │ react-native@npm:0.72.0-rc.6 [292eb] doesn't provide react-test-renderer (p5a2fb), requested by react-native/virtualized-lists
```
Note that while many package managers default to warnings in this case, there are still a number of users out there for which this is an error.
## Changelog:
[GENERAL] [FIXED] - `react-native/virtualized-lists` does not need `react-test-renderer` at runtime
Pull Request resolved: https://github.com/facebook/react-native/pull/37955
Test Plan: n/a
Reviewed By: rshest
Differential Revision: D46871536
Pulled By: NickGerleman
fbshipit-source-id: 1e5e15608ab394bc43cd4e6ac727a74734874642
Summary:
[skip-ci]
I noticed that; when a _new_ RN App is created using RN CLI there is ***NO*** *README* file added to the project.
Having a simple README file explaining what type of project it is, for example how other web projects do it, such as long lived `create-react-app`, now widely used `create-next-app`, etc.
Why not for React Native App then?
This PR; Adds README file to RN Template App ⚡, which should be added to the project when a new project is created using RN CLI.
### Website PR: https://github.com/facebook/react-native-website/pull/3732🚀😇
bypass-github-export-checks
## Changelog:
[INTERNAL] [ADDED] - Add README to RN Template App ⚡
Pull Request resolved: https://github.com/facebook/react-native/pull/37521
Test Plan: - The README file should be included in the newly created RN App using RN CLI
Reviewed By: NickGerleman
Differential Revision: D46075719
Pulled By: cipolleschi
fbshipit-source-id: efcccc09d72c57a065b36de6e787594082000e15
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37832
This parameter is currently unused and is causing Android builds to fail
as they compile with `-Wall`
This is a follow-up to https://github.com/facebook/react-native/pull/37454/ as that PR updated only the `fromJs` and not the `toJs` method as well.
Changelog:
[Internal] [Changed] - Remove CallInvoker parameter from toJs method in Codegen
Reviewed By: rshest
Differential Revision: D46647110
fbshipit-source-id: 1f3e22aca7a3df11ac02b5c4b89c9311b8b1798c
Summary:
When trying to build an app using 0.72.0-RC.5 inside a project that uses `.xcode.env.local` the `[CP-User] Generate Legacy Components Interop` Phase script fails to run due to a `Permission denied` error. That's because `.xcode.env.local` is not being loaded, resulting in `NODE_BINARY=" "` and then the `React-RCTAppDelegate` script tries to run `generate-legacy-interop-components.js` directly.
E.g

In order to fix this we should run the `with-environment.sh` script instead of directly loading `.${PODS_ROOT}/../.xcode.env`
## Changelog:
[IOS] [FIXED] - Fix loading `NODE_BINARY` inside Generate Legacy Components Interop
Pull Request resolved: https://github.com/facebook/react-native/pull/37802
Test Plan: Make sure you don't have a `.xcode.env` file and run locally a project that uses React-RCTAppDelegate
Reviewed By: cortinico
Differential Revision: D46596246
Pulled By: cipolleschi
fbshipit-source-id: 5616395f39b0fae7b2fa9e59bd72c70f39198b4d
Summary:
Attempting to fix the issue https://github.com/facebook/react-native/issues/33418
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[ANDROID] Fixed inconsistent styling for text nodes with many children
Pull Request resolved: https://github.com/facebook/react-native/pull/36656
Test Plan:
No test plan yet. I'd like to ask for help with creating one.
##
Putting template aside, I'd like to ask for a review of the approach I'm suggesting.
React Native as-is (at least in some cases) [messes up the styles](https://github.com/facebook/react-native/issues/33418#issuecomment-1485305556) for text nodes with more than 85 children, just like that.

All of this text should be blue.
The root cause is that code (on Android) assumes it can assign as many `Spannable` span priority values as we'd like, while in reality, it has to be packed in an 8-bit-long section of the flags mask. So 255 possible values. In the scenario I produced, React generates three spans per text node, and for 85 text nodes, it sums up to 255. For each span, a new priority value is assigned.
As I understand it, we don't need that many priority values. If I'm not mistaken, these priorities are crucial only for ensuring that nested styles have precedence over the outer ones. I'm proposing to calculate the priority value "vertically" (based on the node's depth in the tree) not "horizontally" (based on its position).
It would be awesome if some core engineer familiar with `ReactAndroid` shared their experience with this module, especially if there are any known cases when we _know_ that we'd like to create overlapping spans fighting over the same aspects of the style.
Reviewed By: cortinico
Differential Revision: D46094200
Pulled By: NickGerleman
fbshipit-source-id: aae195c71684fe50469a1ee1bd30625cbfc3622f
Summary:
Currently when using a TextInput with a controlled selection prop the Copy / Paste menu is constantly getting dismissed and is impossible to use. This is because Android dismisses it when certain method that affect the input text are called (https://cs.android.com/android/platform/superproject/+/refs/heads/master:frameworks/base/core/java/android/widget/Editor.java;l=1667;drc=7346c436e5a11ce08f6a80dcfeb8ef941ca30176?q=Editor, https://cs.android.com/android/platform/superproject/+/refs/heads/master:frameworks/base/core/java/android/widget/TextView.java;l=6792;drc=7346c436e5a11ce08f6a80dcfeb8ef941ca30176). The solution to fix this is to avoid calling those methods when only the selection changes.
I also noticed there are a lot of differences on how selection is handled in old vs new arch and a lot of the selection handling can actually be removed as it is partially the cause of this issue.
This implements 2 mitigations to avoid the issue:
- Unify selection handling via commands for old arch, like fabric. Selection is currently a prop in the native component, but it is completely ignored in fabric and selection is set using commands. I removed the selection prop from the native component on Android so now it is exclusively handled with commands like it is currently for fabric. This makes it so that when the selection prop changes the native component no longer re-renders which helps mitigate this issue. More specifically for the old arch we no longer handle the `selection` prop in `ReactTextInputShadowNode`, which used to invalidate the shadow node and cause the text to be replaced and the copy / paste menu to close.
- Only set placeholder if the text value changed. Calling `EditText.setHint` also causes the copy / paste menu to be dismissed. Fabric will call all props handlers when a single prop changed, so if the `selection` prop changed the `placeholder` prop handler would be called too. To fix this we can check that the value changed before calling `setHint`.
## Changelog:
[ANDROID] [FIXED] - Fix copy / paste menu and simplify controlled text selection on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/37424
Test Plan:
Tested on new and old arch in RNTester example.
Before:
https://github.com/facebook/react-native/assets/2677334/a915b62a-dd79-4adb-9d95-2317780431cf
After:
https://github.com/facebook/react-native/assets/2677334/0dd475ed-8981-410c-8908-f00998dcc425
Reviewed By: cortinico
Differential Revision: D45958425
Pulled By: NickGerleman
fbshipit-source-id: 7b90c1270274f6621303efa60b5398b1a49276ca
# Conflicts:
# packages/react-native/ReactAndroid/src/main/java/com/facebook/react/views/textinput/ReactTextInputShadowNode.java
Summary:
changelog: [internal]
`setNativeState` is not implemented in JSC. Let's stick to host objects for now.
Reviewed By: cipolleschi
Differential Revision: D46193786
fbshipit-source-id: 9d36801bb9faa5c144a461bcbe623762bf6947b1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37501
This is the iOS side of the fix for https://github.com/facebook/react-native/issues/36794.
That issue aside for the moment, the high-level idea here is to conceptually separate the bundle *request URL*, which represents a request for the *latest* bundle, from the *source URL* passed to JS engines, which should represent the code actually being executed. In future, we'd like to use this to refer to a point-in-time snapshot of the bundle, so that stack traces more often refer to the code that was actually run, even if it's since been updated on disk (actually implementing this isn't planned at the moment, but it helps describe the distinction).
Short term, this separation gives us a way to address the issue with JSC on iOS 16.4 by allowing Metro to provide the client with a [JSC-safe URL](https://github.com/react-native-community/discussions-and-proposals/pull/646) to pass to the JS engine, even where the request URL isn't JSC-safe.
We'll deliver that URL to the client on HTTP bundle requests via the [`Content-Location`](https://www.rfc-editor.org/rfc/rfc9110#name-content-location) header, which is a published standard for communicating a location for the content provided in a successful response (typically used to provide a direct URL to an asset after content negotiation, but I think it fits here too).
For the long-term goal we should follow up with the same functionality on Android and out-of-tree platforms, but it's non-essential for anything other than iOS 16.4 at the moment.
For the issue fix to work end-to-end we'll also need to update Metro, but the two pieces are decoupled and non-breaking so it doesn't matter which lands first.
Changelog:
[iOS][Changed] Prefer `Content-Location` header in bundle response as JS source URL
Reviewed By: huntie
Differential Revision: D45950661
fbshipit-source-id: 170fcd63a098f81bdcba55ebde0cf3569dceb88d
Summary:
Limit diagnostics width output by `hermesc` as they may cause slowdowns or even crashes in Gradle/Xcode when a minified bundle is used as input. This occurs because Hermes is unable to determine the terminal width when executed by Gradle/Xcode, and falls back to "unlimited". If the input is a minified bundle, Hermes will output the whole bundle for each warning.
See issues filed:
- https://github.com/microsoft/rnx-kit/issues/2416
- https://github.com/microsoft/rnx-kit/issues/2419
- https://github.com/microsoft/rnx-kit/issues/2424
## Changelog:
[GENERAL] [FIXED] - Limit diagnostics width output by `hermesc`
Pull Request resolved: https://github.com/facebook/react-native/pull/37531
Test Plan: See listed issues for repros.
Reviewed By: cipolleschi
Differential Revision: D46102686
Pulled By: cortinico
fbshipit-source-id: 1b821cad7ef0d561a5e1c13a7aedf9b10164620a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37452Fixes#37428
We do have cache poisoning for hermesc on Windows and Linux due to reusing the same cache key among different
React Native version. This fixes it by specifying a cache key which is version dependent + it invalidates the
caches by defining a new key.
Changelog:
[Internal] [Fixed] - Make CircleCI caches for hermesc be version dependent
Reviewed By: cortinico
Differential Revision: D45909178
fbshipit-source-id: 830c87ae45739c7053342a68dac2ee7581945c1d
# Conflicts:
# .circleci/config.yml
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37517Fixes#35778
We got reports of regressions on `useEffect` starting from 0.69+ when on Hermes.
The issue seems to be caused by a bump of the `scheduler` package from 0.20 to 0.21.
In scheduler@0.21, the method `setImmediate` gets called if available
(see https://github.com/facebook/react/pull/20834). This causes React Native to use Microtasks
which ends up in changing the semantic of useEffect.
The solution is to use the Native RuntimeScheduler properly.
On Paper specifically, we never initialized it as it's effectively initialized by the
TurboModuleManagerDelegate. Here I trigger the initialization of it on Paper as well.
Changelog:
[Android] [Fixed] - Make sure the Native RuntimeScheduler is initialized on Old Arch
Reviewed By: sammy-SC
Differential Revision: D46024807
fbshipit-source-id: d72cd774df58410467644cddeaaf37e3c227b505
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37516
This will fail build failures from apps which are using libraries which imports
```
#include <react/renderer/graphics/conversions.h>
```
That's just a warning but our usage of `-Wall -Werror` is causing this to fail user builds.
More context on this issue here:
https://github.com/reactwg/react-native-releases/discussions/54#discussioncomment-5968545
We can revert this `-Wno-error` once we're on 0.73 as that specific #warning will be entirely
removed from the codebase.
Changelog:
[Internal] [Changed] - Add -Wno-error=cpp on App's default Cmake file
Reviewed By: dmytrorykun
Differential Revision: D46071400
fbshipit-source-id: 4937fb1255df3f2765f645dfd59f5c58526dee42
Summary:
For 3rd party libraries to work with a React Native fork (such as the TV repo) that uses a different Maven group for `react-android` and `hermes-android` artifacts, an additional dependency substitution is required.
## Changelog:
[Android][fixed] RNGP dependency substitutions for fork with different Maven group
Pull Request resolved: https://github.com/facebook/react-native/pull/37445
Test Plan:
- Manual tested with an existing project
- Unit tests pass
Reviewed By: rshest, dmytrorykun
Differential Revision: D45948901
Pulled By: cortinico
fbshipit-source-id: 4151a1d3616172a92c68812c3a0034c98b330d67
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37451
It seems like starting from AGP 7.4, Android is not including the `-DANDROID` flag
anymore from the NDK toolchain.
As we do have several `#ifdef` logic that takes care of having this macro set,
I'm going to make sure it's always set for both ReactAndroid, hermes-engine
and the template.
Changelog:
[Android] [Fixed] - Make sure the -DANDROID compilation flag is always included
Reviewed By: javache
Differential Revision: D45908787
fbshipit-source-id: 07284712d7bcce73dc8ea0dffd4a9d00af4de1d2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36936
I'm removing `POST_NOTIFICATION` as that's a typo as it should be `POST_NOTIFICATIONS`
We had both in version 0.71 so we can remove the wrong one as it's misleading for users.
Changelog:
[Android] [Removed] - Remove deprecated POST_NOTIFICATION from `PermissionsAndroid`
Reviewed By: sshic
Differential Revision: D45054310
fbshipit-source-id: be733811a1ee8e7c9d6e4986c0303eed7c07c35b
Summary:
Since v0.71 the autoComplete prop on TextInput is available on iOS ([release notes](https://reactnative.dev/blog/2023/01/12/version-071#component-specific-behavior)). However, this change is not reflected in the types.
Original types PR here - https://github.com/DefinitelyTyped/DefinitelyTyped/pull/65144 by chwallen
## Changelog:
[GENERAL] [FIXED] - Fix autoComplete type for TextInput
Pull Request resolved: https://github.com/facebook/react-native/pull/36931
Test Plan: Setting the autoComplete prop on TextInput to `nickname`, `organization`, `organization-title`, or `url` should not result in typescript errors.
Reviewed By: NickGerleman
Differential Revision: D45052350
Pulled By: javache
fbshipit-source-id: 40993833b4ed14f91e3bf3521a264ea93517a0c9
Summary:
The [React Native TV repo](https://github.com/react-native-tvos/react-native-tvos) shares most of the same Android code as the core repo. Beginning in 0.71, it needs to also publish Android Maven artifacts for the `react-android` and `hermes-android` libraries.
In order to avoid conflicts, it needs to publish the artifacts to a different group name. However, `react-native-gradle-plugin` uses a hardcoded group name (`com.facebook.react`).
Solution: read the group name from the existing `GROUP` property in `ReactAndroid/gradle.properties`.
## Changelog:
[Android] [Fixed] - read GROUP name in gradle-plugin dependency code
Pull Request resolved: https://github.com/facebook/react-native/pull/37204
Test Plan:
- Android unit tests have been added for the new code and new method in `DependencyUtils.kt`.
- Existing tests should pass
- The new code defaults to the correct group (`com.facebook.react`) so no functional change is expected in the core repo.
Reviewed By: luluwu2032
Differential Revision: D45576700
Pulled By: cortinico
fbshipit-source-id: 6297ab515b4bdbb17024989c7d3035b0a2ded0ae
# Conflicts:
# packages/react-native-gradle-plugin/src/main/kotlin/com/facebook/react/ReactPlugin.kt
Summary:
An out-of-the-box react-native init project no longer enables Flipper properly as of 0.72.0-rc1.
## Changelog:
[IOS] [FIXED] Fix Flipper by moving podfile modification of preprocessor def `FB_SONARKIT_ENABLED` from React-Core to React-RCTAppDelegate where it is now used.
Pull Request resolved: https://github.com/facebook/react-native/pull/37240
Test Plan: Generated an app and verified Flipper cannot see the app. Made the modification and generated another app and verified Flipper now sees it and can enable plugins. Verified that runtime (non-test) use of FB_SONARKIT_ENABLED is limited to Libraries/AppDelegate in this project.
Reviewed By: dmytrorykun
Differential Revision: D45563282
Pulled By: cipolleschi
fbshipit-source-id: d760c5ae123cc7c967b19c6c626801d6db28d052
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37228
As discussed offline, the current approach for the Hermes profiler is not the right one.
I'm partially reverting [the commit](https://github.com/facebook/react-native/commit/dce9d8d5de381fe53760ddda0d6cbbdfb5be00e4) which introduced it.
The commit did also a bit of refactoring to improve the quality of the cocoapods scripts we would like to keep.
## Changelog:
[iOS][Removed] - Remove support of Hermes profiler as that's not the right approach.
Reviewed By: cortinico
Differential Revision: D45527507
fbshipit-source-id: acea5f8b610d8b67ee7a6a91993bb8e4592d093f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37222
changelog: [internal]
User defined destructor does not make sense here. ImageRequest is owned by ImageState, which is owned by ImageShadowNode. ImageShadowNode requires garbage collection from the runtime to be destroyed. Calling cancel in dtor is not deterministic and that is undesired.
bypass-github-export-checks
Reviewed By: javache
Differential Revision: D45524705
fbshipit-source-id: 410def2100f479b68682620b2c43071fdfb86715
Summary:
`maintainVisibleContentPosition` is broken when using virtualization and the new content pushes visible content outside its "window". This can be reproduced in the example from this diff. When using a large page size it will always push visible content outside of the list "window" which will cause currently visible views to be unmounted so the implementation of `maintainVisibleContentPosition` can't adjust the content inset since the visible views no longer exist.
The first illustration shows the working case, when the new content doesn't push visible content outside the window. The red box represents the window, all views outside the box are not mounted, which means the native implementation of `maintainVisibleContentPosition` has no way to know it exists. In that case the first visible view is https://github.com/facebook/react-native/issues/2, after new content is added https://github.com/facebook/react-native/issues/2 is still inside the window so there's not problem adjusting content offset to maintain position. As you can see Step 1 and 3 result in the same position for all initial views.
The second illustation shows the broken case, when new content is added and pushes the first visible view outside the window. As you can see in step 2 the view https://github.com/facebook/react-native/issues/2 is no longer rendered so there's no way to maintain its position.
#### Illustration 1

#### Illustration 2

To fix `maintainVisibleContentPosition` when using `VirtualizedList` we need to make sure the visible items stay rendered when new items are added at the start of the list.
In order to do that we need to do the following:
- Detect new items that will cause content to be adjusted
- Add cells to render mask so that previously visible cells stay rendered
- Ignore certain updates while scroll metrics are invalid
### Detect new items that will cause content to be adjusted
The goal here is to know that scroll position will be updated natively by the `maintainVisibleContentPosition` implementation. The problem is that the native code uses layout heuristics which are not easily available to JS to do so. In order to approximate the native heuristic we can assume that if new items are added at the start of the list, it will cause `maintainVisibleContentPosition` to be triggered. This simplifies JS logic a lot as we don't have to track visible items. In the worst case if for some reason our JS heuristic is wrong, it will cause extra cells to be rendered until the next scroll event, or content position will not be maintained (what happens all the time currently). I think this is a good compromise between complexity and accuracy.
We need to find how many items have been added before the first one. To do that we save the key of the first item in state `firstItemKey`. When data changes we can find the index of `firstItemKey` in the new data and that will be the amount we need to adjust the window state by.
Note that this means that keys need to be stable, and using index won't work.
### Add cells to render mask so that previously visible cells stay rendered
Once we have the adjusted number we can save this in a new state value `maintainVisibleContentPositionAdjustment` and add the adjusted cells to the render mask.
This state is then cleared when we receive updated scroll metrics, once the native implementation is done adding the new items and adjusting the content offset.
This value is also only set when `maintainVisibleContentPosition` is set so this makes sure this maintains the currently behavior when that prop is not set.
### Ignore certain updates while scroll metrics are invalid
While the `maintainVisibleContentPositionAdjustment` state is set we know that the current scroll metrics are invalid since they will be updated in the native `ScrollView` implementation. In that case we want to prevent certain code from running.
One example is `onStartReached` that will be called incorrectly while we are waiting for updated scroll metrics.
## Changelog
[General] [Fixed] - Fix VirtualizedList with maintainVisibleContentPosition
Pull Request resolved: https://github.com/facebook/react-native/pull/35993
Test Plan:
Added bidirectional paging to RN tester FlatList example. Note that for this to work RN tester need to be run using old architecture on iOS, to use new architecture it requires https://github.com/facebook/react-native/pull/35319
Using debug mode we can see that virtualization is still working properly, and content position is being maintained.
https://user-images.githubusercontent.com/2677334/163294404-e2eeae5b-e079-4dba-8664-ad280c171ae6.mov
Reviewed By: yungsters
Differential Revision: D45294060
Pulled By: NickGerleman
fbshipit-source-id: 8e5228318886aa75da6ae397f74d1801d40295e8
Summary:
Hey,
`adjustCellsAroundViewport` function was checking if `props.initialScrollIndex` is truthy and -1 was returning true. This caused bugs with rendering for tvOS: https://github.com/react-native-tvos/react-native-tvos/pull/485 There are warnings in the code about `initalScrollIndex` being smaller than 0 but this if statement would still allow that.
## Changelog:
[General] [Fixed] - Make sure initialScrollToIndex is bigger than 0 when adjusting cells
Pull Request resolved: https://github.com/facebook/react-native/pull/36844
Test Plan: Pass -1 as initialScrollToIndex. Check that this code is executed.
Reviewed By: cipolleschi
Differential Revision: D44856266
Pulled By: NickGerleman
fbshipit-source-id: 781a1c0efeae93f00766eede4a42559dcd066d7d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37195
Updates the Dev Menu header on Android.
- Small alignment related to D44872456.
- Add subheading label showing current JS executor description (matching iOS) (note: on Android this is unformatted (but informative), e.g. `JSIExecutor+HermesRuntime`).
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D45142924
fbshipit-source-id: 5c95fc85e6d3b6879287440f76165b02957283e5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37148
This should fix https://github.com/facebook/react-native/issue/36945, which is also causing annoyance when doing the releases
## Changelog:
[iOS][Changed] - Use contents of sdks/.hermesversion to let cocoapods recognize Hermes updates.
Reviewed By: cipolleschi
Differential Revision: D45394241
fbshipit-source-id: 972fbee8f954b90f7087bb232f922761c1639e06
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37152
Those files are unncessary and can be removed from RNTester.
* Proguard file is empty
* Signing config is unnecessary and we can use the debug one also for release.
Changelog:
[Internal] [Changed] - Remove unnecessary files in RN-Tester
Reviewed By: hoxyq
Differential Revision: D45399388
fbshipit-source-id: fd1c6cccaef668e688a699e31045bdc8103ea98e
Summary:
I accidentally turned off New Architecture on RN-Tester while shipping the Fabric Interop. This reverts it.
Changelog:
[Internal] [Changed] - Re-enable newArch on RN-Tester
Reviewed By: cipolleschi
Differential Revision: D45398914
fbshipit-source-id: 2c36f3d0440f147189de644821e1704c00353bac
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37139
This dependency is unnecessary. React Native already exposes a `api` dependency on
`androidx.swiperefreshlayout:swiperefreshlayout` so every consumer will also get it.
This is just another line in the template we can effectively remove.
Changelog:
[Android] [Changed] - Do not explicitely depend on androidx.swiperefreshlayout:swiperefreshlayout
Reviewed By: cipolleschi
Differential Revision: D45390819
fbshipit-source-id: cce34c6a09100d36ee5eb003bb30323f64f0bb9c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37059
This diff introduces InteropEventEmitter, a re-implementation of RCTEventEmitter that works with Fabric and allows to support events on the Fabric Interop for Android.
Thanks to this, users can keep on calling `getJSModule(RCTEventEmitter.class).receiveEvent(...)` in their legacy ViewManagers and they will be using the EventDispatcher
under the hood to dispatch events.
The logic is enabled only if the `unstable_useFabricInterop` flag is turned on. I've turned this on for the template setup and for RN Tester.
On top of this, this diff takes care also of event name "normalization".
On Fabric, all the events needs to be registered with a "top" prefix. With this diff, we'll be adding the "top" prefix at registration time, if the user hasn't added them.
This allows to use legacy ViewManagers on Fabric without having to ask users to change their event name.
Changelog:
[Android] [Added] - Add support for Events on the Fabric Interop Layer
Reviewed By: mdvacca
Differential Revision: D45144246
fbshipit-source-id: 63d4060153907c05977c976379b90574d1f69866
Summary:
Upgrades React Native to `deprecated-react-native-prop-types@4.1.0`, which includes many of the new prop types in React Native v0.72.
See: https://github.com/facebook/react-native-deprecated-modules/blob/main/deprecated-react-native-prop-types/CHANGELOG.md
Changelog:
[General][Changed] - Upgrade to deprecated-react-native-prop-types@4.1.0
Reviewed By: rickhanlonii
Differential Revision: D45155955
fbshipit-source-id: 36e715c2338b667755bd1e522b7d5a2611103779
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36981
We are (following a quick internal RFC) looking to standardise the term "[in-app] [Developer|Debug] menu" to "Dev Menu" in the React Native Debugging docs (and all docs references). (Indeed, the prevalent existing use in docs was already "Developer menu".) This PR aligns naming in the `RCTDevMenu` component on iOS.
See also https://github.com/facebook/react-native-website/pull/3692.
Changelog:
[iOS][Changed] - Rename "Debug Menu" title to "Dev Menu"
Reviewed By: christophpurrer
Differential Revision: D44872456
fbshipit-source-id: c222bb2c551a4f434a1dc0efbb8d4f75c785aa11
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36957
Fixes https://github.com/facebook/react-native/issues/36830
This bumps the version of tsconfig/react-native to inform TypeScript of more libraries provided by Hermes/React Native. See https://github.com/tsconfig/bases/commit/eee5f19ce8c6a9a8d8baed5ce42588b95262b1a8.
I did the search off of current Hermes/RN main branch, but I think the new config should be valid as far back as 0.71. It doesn't make sense to change the new app template for an old version though, so instead I think we should include this new version in 0.72.
Changelog:
[General][Changed] - Bump tsconfig/react-native to 3.0.0
Reviewed By: cortinico
Differential Revision: D45085932
fbshipit-source-id: 448f1103ef13f76fa95884f790a3cccd9ff75b2f
# Conflicts:
# packages/react-native/template/package.json
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36632
Discovered when bumping the RN documentation to typecheck against 0.72, https://github.com/facebook/react-native/pull/36109 removed the `EmitterSubscription` type which should be kept public.
Changelog:
[General][Fixed] - Export EmitterSubscription TypeScript Type
Reviewed By: cortinico
Differential Revision: D44375081
fbshipit-source-id: c8dbd5694d3a728a0a2091210894d27c9d84a012
Summary:
Implement a few missing bits for `maintainVisibleContentPosition` to work with fabric. The main thing needed is to add 2 fabric renderer listener methods to allow to hook into specific parts of the rendering process. We need some code to execute before view updates are executed and after view updates are executed. The current methods that are exposed do not work for this case. `willDispatchViewUpdates` is called from JS thread, and there doesn't seem to be a way to add UI blocks that will be executed at the right time like we do in paper. `didDispatchMountItems` is called for every frame which we don't want and will cause lots of overhead.
After that we simply need to call the right methods in the new renderer listener methods.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID] [ADDED] - Add fabric support for maintainVisibleContentPosition on Android
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/35994
Test Plan: Tested in RN tester maintainVisibleContentPosition example on Android with fabric enabled.
Reviewed By: cipolleschi
Differential Revision: D44131763
Pulled By: cortinico
fbshipit-source-id: 32c0b5867d460537b18a70d472fd58052da6cf80
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36796
As the title says, this fixes a instacrash on template when `createRootView` is invoked with
a bundle being null. The crash was happening as the parameter, despite being not used, is
specified as `Bundle` and is not nullable. When the Java caller passes `null`, the app crashes.
Changelog:
[Android] [Fixed] - Fix a crash new app template when `createRootView` is invoked with null bundle
Reviewed By: cipolleschi
Differential Revision: D44668305
fbshipit-source-id: 1150ddac26f19765e7340878c8850d8462c6f3fd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36771
Changelog: [internal]
Previously, when `NSTextStorage` was cached, we were not accounting for case where text which was aligned to centre or left, was used to size its container.
The result was that it was painted outside of its container, therefore invisible. To fix this, we adjust the offset to make sure text is painted correctly.
This bug only happens if:
- Text is not aligned to left in right to left writing system.
- The canvas where text is drawn is not stretched to full width of its parent.
- The offset needs to be large enough for this to matter, otherwise the text is just slightly off.
- Because of the caching mechanism, it had to be a piece of text that was rendered before. Otherwise it would work.
This complexity is worth the trouble to avoid invalidation of layout inside NSTextContainer, which is expensive.
Reviewed By: cipolleschi
Differential Revision: D44624085
fbshipit-source-id: 1bb8ef88933a49b478a2606dba6bf16b4e728b2b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36773
Changelog: [internal]
Do not construct `NSAttributedString` if `NSTextStorage` exists. Creating `NSAttributedString` is expensive and it isn't needed to measure text if `NSTextStorage` `exists`
Reviewed By: cipolleschi
Differential Revision: D44620292
fbshipit-source-id: 0827c514e40fcbd9626d2b7d7b6d28a3332d9aa1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36759
On Thursday the 30th, Apple Released Xcode 14.3.0.
This Version of Xcode enforce some version checks for which React-Codegen, which supported iOS 11 as minimum supported version, could not be build anymore.
This change ensue that React-Codegen is always aligned to the min version supported by React Native.
Plus, it moves CircleCI's Xcode to 14.3.0, to keep this problem in Check.
While working on this, I figured that, with the monorepo, Ruby tests stopped working because they were in the wrong folder: I moved them in the right one.
## Changelog:
[iOS][Fixed] - Make React Native build with Xcode 14.3.0 and fix tests
Reviewed By: blakef
Differential Revision: D44605617
fbshipit-source-id: 3ec1f5b36858ef07d9f713d74eb411a1edcccd45
Summary:
Changelog: [Internal]
Okay, so before the monorepo migration we had to use two scripts separately:
1. Bumping every package with `npm run bump-all-updated-packages`
2. Aligning other packages versions with `npm run align-package-versions`
The reason for it is that *before the monorepo* in a release branch cutoff process we had a step, which was removing `workspaces` keyword from `react-native` package. Without this keyword all new versions of packages will be resolved from npm (where they will be not available yet, because we have to publish them prior to it)
This is not the case for our current setup, and we can actually bump packages versions and they will be resolved as a workspaces successfully
Differential Revision: D44261057
fbshipit-source-id: 6095209c8183f6d84e2697fda2e9a21f8a57f73e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36724
Similarly to iOS, this adds some examples of direct manipulation on Android using
all the various methods.
Changelog:
[Internal] [Changed] - Add examples of Direct Manipulation in Fabric Intrerop
Reviewed By: cipolleschi
Differential Revision: D44541437
fbshipit-source-id: b6e10ac0a815f41ff3c980236b7d8c6937e92065
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36725
This diff adds an example of using `dispatchViewManagerCommand` for the Fabric Intreop on Android.
Changelog:
[Android] [Added] - Add example for dispatchViewManagerCommand on Fabric Interop
Reviewed By: cipolleschi
Differential Revision: D44540951
fbshipit-source-id: 85bc65ad0eb3a951fbb37d61ca26532ec3cc53b7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36692
Similar to the iOS counterpart,
this changes adds an example to RNTester to verify that the Interop Layer can process bubbling events in Fabric as it used to do in Paper.
Changelog:
[Internal] [Changed] - Add Fabric Interop event example
Reviewed By: cipolleschi
Differential Revision: D44467555
fbshipit-source-id: 1f1af27583c402641c549bc2926a64469dcd7b3f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36693
Similar to #36417, this changes adds an example to RNTester to verify that the Interop Layer can process constants in Fabric as it used to do in Paper for Android.
Changelog:
[Android] [Added] - Add Fabric Interop constants example
Reviewed By: cipolleschi
Differential Revision: D44466391
fbshipit-source-id: 74e654319b93e60b415297dcdddc98eb100913df
Summary:
X-link: https://github.com/facebook/metro/pull/955
Pull Request resolved: https://github.com/facebook/react-native/pull/36584
Changelog:
[General][Changed] - Default condition set for experimental Package Exports is now `['require', 'react-native']`
The [Exports RFC](https://github.com/react-native-community/discussions-and-proposals/blob/main/proposals/0534-metro-package-exports-support.md) had assumed that supporting the `"import"` condition was a syntax-only difference, given we are not in a Node.js environment — and so was worthwhile to support for maximal ecosystem compatibility.
{F915841105}
This assumption is similar to [`--moduleResolution bundler` in TypeScript 5.0](https://github.com/microsoft/TypeScript/pull/51669):
> bundlers and runtimes that include a range of Node-like resolution features and ESM syntax, but do not enforce the strict resolution rules that accompany ES modules in Node or in the browser
> -- https://github.com/microsoft/TypeScript/pull/51669#issue-1467004047
However, robhogan has rightly pointed out that **we should not do this!**
- ESM (once transpiled) is **not** simply a stricter subset of in-scope features supported by CJS. For example, it supports top-level async, which would be breaking at runtime.
- We recently made the same change for our Jest environment:
- https://github.com/facebook/react-native/commit/681d7f8113d2b5e9d6966255ee6c72b50a7d488a
As such, we are erring on the side of correctness and supporting only `['require', 'react-native']` in our defaults. At runtime, all code run by React Native is anticipated to be CommonJS. `"exports"` will instead allow React Native to correctly select the CommonJS versions of modules from all npm packages.
Metro changelog: [Experimental] Package Exports `unstable_conditionNames` now defaults to `['require']`
Reviewed By: robhogan
Differential Revision: D44303559
fbshipit-source-id: 0077e547e7775e53d1e4e9c3a9d01347f4fb7d4a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36686
After the recent changes of Metro and Metro-Config, we need to update the path used to load the bundle in RNTester
## Changelog:
[General][Fixed] - Use the right path to load RNTester bundle
Reviewed By: cortinico
Differential Revision: D44465418
fbshipit-source-id: 96170194579792f9a5d8a141328d43e45a4db973
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36717
After D43711737 landed, it turns out that Fabric is always disabled for both
RN-Tester and new app from template (so for 0.72 also RC0).
The reason is that a new method `createRootView(Bundle)` was introduced inside
`ReactActivityDelegate`. Both RN Tester and the template were using the
old `createRootView()` method which is not called anymore at this stage
(should potentially be deprecated?).
This diff fixes it by overriding both method inside `DefaultReactActivityDelegate`
so that both methods are setting the Fabric renderer.
Changelog:
[Android] [Fixed] - Re-enable Fabric in the default app template/RN-Tester
Reviewed By: cipolleschi
Differential Revision: D44536222
fbshipit-source-id: d22a0c522f011a8fe4d27b5d8f2fcf5dd13c3058
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36610
This change add to RNTester examples of a legacy Native Component, loaded in the New Architecture through the Interop Layer, that uses the APIs described in the [Direct Manipulation](https://reactnative.dev/docs/direct-manipulation) sectioon of the website.
[iOS][Added] - Added examples of direct manipulation
Reviewed By: sammy-SC
Differential Revision: D43978674
fbshipit-source-id: 1cbc56f28034f84f309166e3e392ad97a8164e64
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36578
This change brings to the Fabric Interop Layer the possibility to directly call native methods on the View Manager, something that was not possible before and that we can use to simplify the migration to the New Architecture.
[iOS][Added] - Native Components can now call native methods in Fabric when they are loaded through the Interop Layer
Reviewed By: sammy-SC
Differential Revision: D43945278
fbshipit-source-id: fe67ac85a5d0db3747105f56700d1dbba7ada5f1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36702
With the monorepo changes we broke the build from source for users.
This fixes it so that folks can just follow the guide:
https://reactnative.dev/contributing/how-to-build-from-source
Changelog:
[Android] [Fixed] - Fix the setup to allow the build-from-source on host projects
Reviewed By: cipolleschi
Differential Revision: D44502428
fbshipit-source-id: 3ad8fb114f5e2f7ffdf6fffa617ceaa45334f5f3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36575
This is part of a series of changes to minimize the number of spans committed to EditText, as a mitigation for platform issues on Samsung devices. See this [GitHub thread]( https://github.com/facebook/react-native/issues/35936#issuecomment-1411437789) for greater context on the platform behavior.
D23670779 addedd a previous mechanism to add spans for measurement caching, like we needed to do as part of this change. It is called in more specific cases (e.g. when there is a text hint but no text), but it edits the live EditText spannable instead of the cache copy, and does not handle nested text at all.
We are already adding spans back to the input after this, behind everything else, and can replace it with the code we have been adding.
Changelog:
[Android][Fixed] - Mimimize EditText Spans 9/9: Remove `addSpansForMeasurement()`
Reviewed By: javache
Differential Revision: D44298159
fbshipit-source-id: 1af44a39de7550b7e66e45db9ebc3523ae9ff002
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36577
This is part of a series of changes to minimize the number of spans committed to EditText, as a mitigation for platform issues on Samsung devices. See this [GitHub thread]( https://github.com/facebook/react-native/issues/35936#issuecomment-1411437789) for greater context on the platform behavior.
This change allows us to strip CustomStyleSpan. We already set all but `fontVariant` on the underlying EditText, so we just need to route that through as well.
Note that because this span is non-parcelable, it is seemingly not subject to the buggy behavior on Samsung devices of infinitely cloning the spans, but non-parcelable spans have different issues on the devices (they disappear), so moving `fontVariant` to the top-level makes sense here.
Changelog:
[Android][Fixed] - Minimize EditText Spans 8/N: CustomStyleSpan
Reviewed By: javache
Differential Revision: D44297384
fbshipit-source-id: ed4c000e961dd456a2a8f4397e27c23a87defb6e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36576
This is part of a series of changes to minimize the number of spans committed to EditText, as a mitigation for platform issues on Samsung devices. See this [GitHub thread]( https://github.com/facebook/react-native/issues/35936#issuecomment-1411437789) for greater context on the platform behavior.
This change addresses some minor CR feedback and removes the temporary list of spans in favor of applying them directly.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D44295190
fbshipit-source-id: bd784e2c514301d45d0bacd8ee6de5c512fc565c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36548
This is part of a series of changes to minimize the number of spans committed to EditText, as a mitigation for platform issues on Samsung devices. See this [GitHub thread]( https://github.com/facebook/react-native/issues/35936#issuecomment-1411437789) for greater context on the platform behavior.
This change lets us set `letterSpacing` on the EditText instead of using our custom span.
Changelog:
[Android][Fixed] - Minimize EditText Spans 6/N: letterSpacing
Reviewed By: rshest
Differential Revision: D44240777
fbshipit-source-id: 9bd10c3261257037d8cacf37971011aaa94d1a77
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36544
This is part of a series of changes to minimize the number of spans committed to EditText, as a mitigation for platform issues on Samsung devices. See this [GitHub thread]( https://github.com/facebook/react-native/issues/35936#issuecomment-1411437789) for greater context on the platform behavior.
This change makes us apply strikethrough and underline as paint flags to the underlying EditText, instead of just the spans. We then opt ReactUnderlineSpan and ReactStrikethroughSpan into being strippable.
This does actually create visual behavior changes, where child text will inherit any underline or strikethrough of the root EditText (including if the child specifies `textDecorationLine: "none"`. The new behavior is consistent with both iOS and web though, so it seems like more of a bugfix than a regression.
Changelog:
[Android][Fixed] - Minimize Spans 5/N: Strikethrough and Underline
Reviewed By: rshest
Differential Revision: D44240778
fbshipit-source-id: d564dfc0121057a5e3b09bb71b8f5662e28be17e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36545
This is part of a series of changes to minimize the number of spans committed to EditText, as a mitigation for platform issues on Samsung devices. See this [GitHub thread]( https://github.com/facebook/react-native/issues/35936#issuecomment-1411437789) for greater context on the platform behavior.
This adds ReactForegroundColorSpan to the list of spans eligible to be stripped.
Changelog:
[Android][Fixed] - Minimize Spans 4/N: ReactForegroundColorSpan
Reviewed By: javache
Differential Revision: D44240780
fbshipit-source-id: d86939cc2d7ed9116a4167026c7d48928fc51757
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36547
This is part of a series of changes to minimize the number of spans committed to EditText, as a mitigation for platform issues on Samsung devices. See this [GitHub thread]( https://github.com/facebook/react-native/issues/35936#issuecomment-1411437789) for greater context on the platform behavior.
This adds `ReactBackgroundColorSpan` to the list of spans eligible to be stripped.
Changelog:
[Android][Fixed] - Minimize Spans 3/N: ReactBackgroundColorSpan
Reviewed By: javache
Differential Revision: D44240782
fbshipit-source-id: 2ded1a1687a41cf6d5f83e89ffadd2d932089969
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36546
This is part of a series of changes to minimize the number of spans committed to EditText, as a mitigation for platform issues on Samsung devices. See this [GitHub thread]( https://github.com/facebook/react-native/issues/35936#issuecomment-1411437789) for greater context on the platform behavior.
This change generalizes `stripAttributeEquivalentSpans()` to allow plugging in different spans.
Changelog:
[Internal]
Reviewed By: rshest
Differential Revision: D44240781
fbshipit-source-id: 89005266020f216368e9ad9ce382699bd8db85a8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36543
This is part of a series of changes to minimize the number of spans committed to EditText, as a mitigation for platform issues on Samsung devices. See this [GitHub thread]( https://github.com/facebook/react-native/issues/35936#issuecomment-1411437789) for greater context on the platform behavior.
We cache the backing EditText span on text change to later measure. To measure outside of a TextInput we need to restore any spans we removed. Spans may overlap, so base attributes should be behind everything else.
The logic here for dealing with precedence is incorrect, and we should instead accomplish this by twiddling with the `SPAN_PRIORITY` bits.
Changelog:
[Android][Fixed] - Minimize Spans 1/N: Fix precedence
Reviewed By: javache
Differential Revision: D44240779
fbshipit-source-id: f731b353587888faad946b8cf1e868095cdeced3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36541
We only know where the last focused cell lives after it is rendered. Apart from dead refs handled in D43835135, this means items added or removed before the focused cell will lead to a stale last index for the next state update.
We don't have a good way to correlate cells after data change. This effects the implementation for [`maintainVisibleContentPosition`](https://github.com/facebook/react-native/pull/35993) as well, but needs some thought on the right way to handle it. For now, we bail when we don't know where the last focused cell lives.
Changelog:
[General][Fixed] - Bail on realizing region around last focused cell if we don't know where it is
Reviewed By: yungsters
Differential Revision: D44221162
fbshipit-source-id: 8fc7e726fe13c62b98870600563857bb89290280
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36571
Changelog: [Internal]
The problem is related to the way we use `js_srcs_dir` & `output_dir` options, one requires just relative path from current ruby script, other requires relative path from iOS root project (where the Podfile located)
output_dir was introduced in D43304641
resulted into the issue, described in https://discord.com/channels/514829729862516747/1087736932953509958
allow-large-files
Reviewed By: cipolleschi
Differential Revision: D44294112
fbshipit-source-id: 47fcf510e203d0880e1f92ab6ead09f4b79cb4dd
Summary:
changelog: [internal]
`setNativeProps` have been implemented in Fabric but require a React change to be accessible from JavaScript components. For React sync to be imported in OSS builds, React needs to have have a new release in NPM.
To work around this limitation, I manually copied over lines of code that glue together setNativeProps to OSS build.
Reviewed By: cortinico, cipolleschi
Differential Revision: D44216496
fbshipit-source-id: b34b598c1a317bdc03cc5a4cadb3f7c610059709
Summary:
This diff optimizes text measurement by adding a layer of caching per shadow node.
When ReactFeatureFlags.enableTextMeasureCachePerShadowNode is enabled, we will cache and reused measurements per shadow node.
This optimization showed a 2x improvement on text rendearing when a screen contains a big amount of text components.
Changelog: [Internal] Internal
Reviewed By: sammy-SC
Differential Revision: D44221170
fbshipit-source-id: c3e7ba1ad216929826a99585874981717c90e13b
Summary:
> [Codegen 92] The getCommandOptions function in parsers/typescript/components/options.js and parsers/flow/components/options.js is the same. move it in parser-commons and use it in the original files. If the file two options.js files are empty, delete them.
> [Codegen 93] The getOptions function in parsers/typescript/components/options.js and parsers/flow/components/options.js is the same. move it in parser-commons and use it in the original files. If the file two options.js files are empty, delete them.
Part of Issue https://github.com/facebook/react-native/issues/34872
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal][Changed] - Move getCommandOptions and getOptions to parsers commons from parsers components options
Pull Request resolved: https://github.com/facebook/react-native/pull/36413
Test Plan: `yarn jest react-native-codegen`
Reviewed By: rshest
Differential Revision: D43957023
Pulled By: cipolleschi
fbshipit-source-id: 4f8bf6f8fe69b20d0fb976afee7da244ef634e12
Summary:
> [Codegen 78 - Assigned to Pranav-yadav] It depends on [Codegen 75][Codegen 76][Codegen 77] Extract the logic that emits Partial values in an emitPartial function, which takes the Parsers as parameter.
>[Codegen 79 - Assigned to Pranav-yadav] It depends on [Codegen 78] Extract the basic cases logics (case Stringish, case Int32, case Double, ..., case Partial. `Flow` lines and `TypeScript` lines into a function emitCommonTypes in `parsers-primitives.js`. Make sure that the default case returns `null`. Call this function in the default: case `Flow`, `TypeScript` of the `index.js` file: if the function return something, return that from the default case; otherwise if the `emitCommonTypes` returns `null`, keep the current default implementation (throw the error).
### Changes
- merged TS & Flow parsers' logic for `Partial` case to `emitPatial` fn
- merged TS & Flow parsers' logic for below cases:
- `Stringish`
- `Int32`
- `Double`
- `Float`
- `UnsafeObject`
- `Object`
- `Partial`
- into an `emitCommonTypes` fn into `parsers-primitives.js`
- add **_tests_** for `emitPartial` and `emitCommonTypes` fn's
- add `getAnnotatedElementProperties` fn to parser & impl to both TS & Flow parsers
## Changelog:
[INTERNAL] [CHANGED] - Merge TS & Flow parsers' logic for `Partial` case to `emitPatial` fn & `commonTypes` cases into `emitCommonTypes` fn
Pull Request resolved: https://github.com/facebook/react-native/pull/36450
Test Plan: - `yarn lint && yarn run flow && yarn jest react-native` ⇒ �
Reviewed By: rshest
Differential Revision: D44132308
Pulled By: cipolleschi
fbshipit-source-id: f965e85ecc5d94e57ad85334ce565a55c512fde4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36534
Changelog: [Internal]
- Added option to include react-native package in forEachPackage func
- Used this in align-package-versions.js
Reviewed By: cortinico
Differential Revision: D44152939
fbshipit-source-id: da173e78945d8185ae7e35e29d08926de1700fa4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36533
Changelog: [Internal]
Its better to have one source of truth, so we won't loose any changes if one of the files will be updated
Reviewed By: cortinico
Differential Revision: D44138311
fbshipit-source-id: 9bd938c1abe33ea1f791f7624efd57f1b37e813b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36531
Changelog: [Internal]
In order to make `react-native/tester` imports work, adding this package to `xplat/js/public`
Also moving devDependecies from `react-native/tester/package.json` to root package json to avoid checking in dev dependencies in `xplat/js/public/node_modules`
Reviewed By: cortinico
Differential Revision: D44030539
fbshipit-source-id: b06e49869cdad6e511b1675d1063a1ceac56e3e6
Summary:
This change does two things:
1) Moves RNTester on iOS to use an `.xctestplan` to configure its tests. This moves the test configuration out of the `.xcscheme` file, and into a new json file that Xcode likes. It also allows you to run the same tests multiple times with different configurations. This was done by clicking the focused button below.

Note: this is partially me upstreaming a change from React Native macOS (https://github.com/microsoft/react-native-macos/pull/190/), though at some point our Xcode project got messed up and we were no longer referencing them ��.
2) Enables Address Sanitizer and Udefined Behavior Sanitizer through the xctestplan
This should help catch some extra vulnerabilities should they ever show up while our tests run.
Notably, I did not _also_ add a configuration to run Thread Sanitizer, because tests start failing with that enabled 😅.
## Changelog:
[IOS] [SECURITY] - Enable Address and Undefined Behavior Sanitizers on RNTester
Pull Request resolved: https://github.com/facebook/react-native/pull/36443
Test Plan: CI should pass
Reviewed By: cortinico
Differential Revision: D44213517
Pulled By: cipolleschi
fbshipit-source-id: 0646174c4b416413a563e8178aa2cfca230b5e66
Summary:
This just creates the class structure for `ReadOnlyNode`, `ReadOnlyElement` and `ReactNativeElement`, with all methods throwing as unimplemented.
These classes will be gated behind a feature flag, so merging incomplete work is ok.
This doesn't add the future setters that will log warnings / throw errors when used.
See: https://github.com/react-native-community/discussions-and-proposals/pull/607
Changelog: [internal]
Reviewed By: rickhanlonii, yungsters
Differential Revision: D44060539
fbshipit-source-id: e489532fd365d9aa2bb8308847a35eb715d675e7
Summary:
This implements a basic version of DOMRectList that's close to the spec but diverges in some things (e.g.: methods could be called with an instance created through `Object.create`, etc.).
This will be used soon to implement `ReadOnlyelement.getClientRects()` (behind a flag).
See: https://github.com/react-native-community/discussions-and-proposals/pull/607
Changelog: [internal]
Reviewed By: yungsters
Differential Revision: D44060540
fbshipit-source-id: ad29b5c41f2778864e7dd7ece9223dcf73cd5d6c
Summary:
This implements a basic version of NodeList that's close to the spec but diverges in some things (e.g.: methods could be called with an instance created through `Object.create`, etc.).
This will be used soon to implement `ReadOnlyNode.childNodes` (behind a flag).
See: https://github.com/react-native-community/discussions-and-proposals/pull/607
Changelog: [internal]
Reviewed By: yungsters
Differential Revision: D44055911
fbshipit-source-id: 10b435b06ea6f75eaead85f01c2703e05bb3bd37
Summary:
This implements a basic version of HTMLCollection that's close to the spec but diverges in some things (e.g.: methods could be called with an instance created through `Object.create`, etc.).
This will be used soon to implement `ReadOnlyElement.children` (behind a flag).
See: https://github.com/react-native-community/discussions-and-proposals/pull/607
Changelog: [internal]
Reviewed By: yungsters
Differential Revision: D44055912
fbshipit-source-id: 37bcd7c12916b95a258e6b2e5717a642f478abdf
Summary:
These 3 methods are defined in the binding in native, but not in the type definition in JS.
Changelog: [internal]
Reviewed By: yungsters
Differential Revision: D44139730
fbshipit-source-id: 5ce74c61a424ece8091046425b9cd5598f14bbf1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36523
`jest/private/preprocessor.js` is only used to run tests on the workspace itself, it's not part of our exported Jest preset and is specifically excluded from publication in the `react-native` package.
Now that we have the monorepo setup, this belongs at the workspace root.
- `metro-react-native-babel-transformer` moved from RN `dependencies` to root `devDependencies` because it's only used by the preprocessor
- `jest/create-cache-key-function` added to `devDependencies` - it's also used by the `assetTransformer` in the public preset.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D44197879
fbshipit-source-id: 0bbd9e2f500f53fa4f16562f05374dc601b67df6
Summary:
I added missing type `lineBreakStrategyIOS` for Text and TextInput. ([Text docs](https://reactnative.dev/docs/text))
## Changelog
[GENERAL] [FIXED] - add `lineBreakStrategyIOS` prop type for Text and TextInput
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/36526
Test Plan: Ran `yarn test-typescript` and `yarn test-typescript-offline` with no errors.
Reviewed By: jacdebug
Differential Revision: D44213791
Pulled By: javache
fbshipit-source-id: 8d0d44e2cdd1fa362c54935326e86dde88c5ba0b
Summary:
With Metro symlink support coming soon, users will expect isolated `node_modules` resolution and hoisted `react-native` to work. Currently, we make some fragile assumptions in Ruby scripts about the location of `node_modules` packages - in particular `react-native` and `react-native-community/cli-platform-ios`.
This change invokes `node` to resolve those paths, which should allow these scripts to work in any Node JS-compliant setup.
There's a small (sub-second) performance penalty involved in invoking node, but two of these in the context of `pod install` seems reasonable. Also, these scripts [already invoke `node`](https://github.com/react-native-community/cli/blob/fb78fe8ea2fabe8e6d43f5042ecbb92e8e484e12/packages/cli-platform-ios/native_modules.rb#L26), so this isn't an additional dependency or point of failure.
*This is probably the first Ruby I've written in >10 years, review suggestions welcome!*
Changelog:
[iOS][Added] - Support workspace and isolated setups with `pod install`
Pull Request resolved: https://github.com/facebook/react-native/pull/36485
Test Plan: `pod install` succeeds on a PNPM workspace setup where `react-native-community/cli` was not at the path previously expected by this script.
Reviewed By: cipolleschi
Differential Revision: D44097440
Pulled By: robhogan
fbshipit-source-id: 8300144888d8da019451b3f792b30eabc3a568cf
Summary:
## Changelog:
[Internal] -
While merging a Contributor PR in D43816768, I got curious whether such things as detecting/fixing typos could be automated.
There is a tool called [typos](https://github.com/crate-ci/typos), which, as it turns out, works very well on source code files.
The amount of false positives was minimal, most of the suggestions were valid ones.
And the total amount of typos found and fixed was **more than 300**, which is... quite a bit :)
### Methodology
* Run `typos` separately on `ReactCommon`, `Libraries`, `React`, `ReactAndroid` and `scripts` folders inside `packages/react-native`, e.g.:
```
$ typos -w --config ~/tmp/_typos.toml ~/fbsource/xplat/js/react-native-github/packages/react-native/ReactAndroid
```
Contents of the `_typos.toml` config file:
```
[default.extend-words]
collapsable = "collapsable"
NDK = "NDK"
inout = "inout"
```
(yeah, it really didn't like the "collapsable" word, for some reason ;))
* Inspect all the changes manually and revert false positives (as mentioned, their amount was minimal)
Note that most of the changes are inside things like comments and error messages, however there are a few among identifier name fixes (`typos` is actually quite smart at understanding naming conventions in code) - I kept the suggestions in cases that are local and not part of a public API. There are also misspelled file name changes in a couple of cases.
Reviewed By: NickGerleman
Differential Revision: D44172494
fbshipit-source-id: 86e27edbbb99e09135e3cdd5d7cea8ffeb8307f4
Summary:
Nightly builds are broken at the moment - at least in the first instance this looks to be because a reference to `template/package.json` was missed in the monorepo PR. This repairs it.
Changelog: [Internal]
Reviewed By: GijsWeterings
Differential Revision: D44205810
fbshipit-source-id: c810b7a211db7162569a67fca26771fce79d4f9d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36522
We don't need to register Babel for internal tests, Jest takes care of hooking require. This resolves an internal require-clobbering issue.
Changelog: [Internal]
Reviewed By: GijsWeterings
Differential Revision: D44197281
fbshipit-source-id: ee076d431b0c49ae4a2da609d964cdd66bca27f8
Summary:
Changelog: [Internal] - Ensure pointercancel events have zeroed location properties
When looking at the pointercancel test the remaining assertion failures were from the expectation that pointercancel events should be reported at [0, 0]. This diff ensures this occurs.
Reviewed By: NickGerleman
Differential Revision: D43886424
fbshipit-source-id: dda37153bd077500599f35db99f114c1a0823120
Summary:
Changelog: [Internal] - Ensure trailing leave/out pointer events are fired after a cancel event
The pointercancel test checks that pointerleave/pointerout events are fired after a pointercancel which preivously wasn't occuring so this added call ensures so.
Reviewed By: NickGerleman
Differential Revision: D43886121
fbshipit-source-id: 9ea801e8f5fcd5855832cfac973bda6ba905998d
Summary:
That's a first step to make sure our C++ tests can effectively run.
Here I'm setting up the pipeline to at least compile those tests and make sure they can be executed on a Android Emulator
Changelog:
[Internal] [Changed] - Setup CMake to run the GTest suite
Pull Request resolved: https://github.com/facebook/react-native/pull/36477
Test Plan: CI needs to be green.
Reviewed By: rshest
Differential Revision: D44066754
Pulled By: cortinico
fbshipit-source-id: f963e0d7d4d9473eada53d7feecfabc21f3c3196
Summary:
On Android `AccessibilityInfo.isReduceMotionEnabled()` returns false even when "Disable Animations" is enabled. This fixes https://github.com/facebook/react-native/issues/31221.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[ANDROID] [FIXED] - Fix check of "reduce motion" setting on android
Pull Request resolved: https://github.com/facebook/react-native/pull/36508
Test Plan: Have some code logging the value of `AccessibilityInfo.isReduceMotionEnabled()` or using it to change the UI. Run that code on Android without and with "Disable Animations" enabled. See the value is always `false` without the fix, but changes to `true` when "Disable Animations" is enabled with the fix.
Reviewed By: cortinico, rshest
Differential Revision: D44163583
Pulled By: javache
fbshipit-source-id: ad239454ea68b381e0c7f024df797b3646aeefd7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36515
Buck is using a older version of Robolectric which doens't have
`RuntimeEnvironment.getApplication()`. Reverting to the older
accessor.
Changelog:
[Internal] [Changed] - Fix test_buck by using RuntimeEnvironment.application
Reviewed By: cipolleschi
Differential Revision: D44171240
fbshipit-source-id: d2b49e3b08ffd737bc70ea3e0cb6b291cc36425f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36510
This sets up a small offline mirror for Robolectric tests
and allows to run them both on CircleCI and on the internal CI.
allow-large-files
Changelog:
[Internal] [Changed] - Make robolectric tests run in offline mode
Reviewed By: cipolleschi
Differential Revision: D44066692
fbshipit-source-id: 3974d92169ed5c8947f72c953e83a7bf6fadca54
Summary:
We can now use the `build` lifecycle task rather than a custom buildAll.
This task will also run linters and other checks on our builds.
Speficially I realized we were missing some permission in the manifest of RN-Tester
which were missed once we bumped to SDK 33.
Changelog:
[Internal] [Changed] - Use the default `build` task rather than `buildAll`
Reviewed By: cipolleschi
Differential Revision: D44055845
fbshipit-source-id: c9adbbeaaaf7ab8a8000fc1dce84ec39427fb26e
Summary:
This makes sure all the tests are executed inside the `ReactAndroid/src/test` folder.
Currently, we're not executing those tests as they're broken. In this diff I took care of:
- Re-enabling them as much as I could
- Ignoring the ones that are ignored also on BUCK
Those tests will have to be entirely re-written as they're using PowerMock which is
unmaintained and not working well with JDK 17+ (that's also why I had to add
the `--illegal-access=permit` and the `--add-opens` directing to allow mocking).
In general, I believe this is a net positive change as it allows us to add new JUnit tests
that are effectively executed, while the current status is ignoring all of them.
Changelog:
[Internal] [Changed] - Enable JVM Unit Tests for Gradle
Reviewed By: cipolleschi
Differential Revision: D41523697
fbshipit-source-id: dc9f2c4c93d0e6b231e8240a583ca31220152d3f
Summary:
##Changelog:
[Internal] -
There are small typos in:
- Libraries/Core/setUpTimers.js
- Libraries/LogBox/Data/LogBoxData.js
- Libraries/Pressability/Pressability.js
- Libraries/Renderer/implementations/ReactFabric-dev.js
- Libraries/Renderer/implementations/ReactNativeRenderer-dev.js
- ReactCommon/react/nativemodule/core/platform/ios/RCTBlockGuard.h
Fixes:
- Should read `snapshot` rather than `snapsho`.
- Should read `symbolication` rather than `sybolication`.
- Should read `polyfilled` rather than `polyfiled`.
- Should read `instance` rather than `instace`.
- Should read `gesture` rather than `gestute`.
Semi-automated pull request generated by
https://github.com/timgates42/meticulous/blob/master/docs/NOTE.md
Pull Request resolved: https://github.com/facebook/react-native/pull/36372
Reviewed By: cortinico, cipolleschi
Differential Revision: D43816768
Pulled By: rshest
fbshipit-source-id: 1346cb3a26748c41d72a3c388d81713ddf2272ed
Summary:
```javascript
// workaround https://github.com/nodejs/node/issues/31481
// todo: remove the ENOENT error check when we drop node.js 13 support
case 'ENOENT':
case 'EACCES':
```
Well, there was a TODO comment asking to remove `ENOENT` error check when react native drop nodejs 13 support since nodejs 14 has fixed the bug that motivated this check. Now react native minimum nodejs version supported is nodejs 14, so this check is not needed anymore.
## Changelog
[Internal] [Fixed] - Removes `ENOENT` error check
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/36448
Reviewed By: NickGerleman
Differential Revision: D44025087
Pulled By: cortinico
fbshipit-source-id: f42cb7105a088e2eea207da12d4e63c6d26f3c77
Summary:
Changelog: [iOS][Internal] - Refactor PointerEvent emitting into its own gesture recognizer
In doing some exploration of a full e2e implementation of the click event I found pretty early on the necessity of addressing the pointerCancel on scroll functionality which, to implement properly without degrading the existing touch gesture handler — involves extracting all the pointer event handling code written so far into its own gesture handler so it can "fail" (when a scroll view wants to take priority) without affecting the existing touch handlers.
This diff is only a refactor and doesn't add/change any new functionality.
allow-large-files
Reviewed By: sammy-SC
Differential Revision: D43372806
fbshipit-source-id: e16f75121fd121d3f82ab43cfc6fab0629654f26
Summary:
Changelog: [Internal] - Add platform test for pointercancel events caused by touch scrolling
This diff adds a new ported Web Platform Test which [verifies that pointercancel events are properly emitted once a touch causes scrolling](https://github.com/web-platform-tests/wpt/blob/master/pointerevents/pointerevent_pointercancel_touch.html).
Reviewed By: lunaleaps
Differential Revision: D43855277
fbshipit-source-id: 94a106058ba2c5e5fe4c1980519ceceddb2bb389
Summary:
>[Codegen 95] Extract the `defaultExports.forEach(statement =>` (Flow, TS) function in `parser-commons`, so that it accept a Parser parameter to unify the behaviors between flow and typescript. The Parser object needs to be enriched with all the methods to extract the required information from the Node, if they are not there yet.
### Changes
- merged TS & Flow parsers' logic for `defaultExports.forEach(statement =>` of `/components/index.js:findComponentConfig()` into;
- `findNativeComponentType` fn to `parsers-commons.js`
- add `getTypeArgumentParamsFromDeclaration` & `getNativeComponentType` fn's
- add **_tests_** for getTypeArgumentParamsFromDeclaration & `getNativeComponentType` fn's
## Changelog
[INTERNAL] [CHANGED] - Merge `defaultExports.forEach(statement => ...` (Flow, TS) to `findNativeComponentType` fn in `parser-commons.js`
Pull Request resolved: https://github.com/facebook/react-native/pull/36466
Test Plan: - `yarn lint && yarn run flow && yarn jest react-native` ⇒ �
Reviewed By: rshest
Differential Revision: D44088862
Pulled By: cipolleschi
fbshipit-source-id: 91bf0edcd53b2e054160af34d7c128355c178b26
Summary: Changelog: [iOS][Changed] - Give precedence to `textContentType` property for backwards compat as mentioned in https://github.com/facebook/react-native/issues/36229#issuecomment-1470468374
Reviewed By: necolas
Differential Revision: D44106291
fbshipit-source-id: 5702d7f171735d1abe6cfbc9ca1ad8f21751d51e
Summary:
The supported `CodegenTypes` aren't provided in the docs, which leads to many issues for developers working to transition native components to support Fabric.
However, explicit error messages are provided in many cases (e.g., to use specific numeric types instead of `number` attributes or to remove nested optionals in arrays).
This isn't the case for the common use case of TypeScript functions, which are very commonly used for event handlers in native components (such as `onChange`), forcing devs to search their way through the `react-native` codebase until they find [this file](https://github.com/facebook/react-native/blob/681d7f8113d2b5e9d6966255ee6c72b50a7d488a/Libraries/Types/CodegenTypes.js#L18).
By providing an explicit error message, we can significantly improve developer experience for those working to transition libraries/components, leading to higher Fabric adoption.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[GENERAL] [ADDED] - Create explicit error message for TypeScript functions used as props in Codegen components, redirecting devs to the supported function types `BubblingEventHandler` and `DirectEventHandler`.
Pull Request resolved: https://github.com/facebook/react-native/pull/36498
Test Plan:
* `yarn run lint` shows no errors
* no impact on `yarn && yarn jest react-native-codegen`, which failed 362 tests before and after my changes.
Reviewed By: cipolleschi, sshic
Differential Revision: D44132960
Pulled By: dmytrorykun
fbshipit-source-id: d805ec8403613bf4e070cbd2904ff5a2648ec5fc
Summary:
- Add .d.ts files for generators
- export each generators because `react-native-windows` need its own selection of generators.
## Changelog
[GENERAL] [CHANGED] - Add minimum necessary .d.ts files to react-native-codegen (2)
Pull Request resolved: https://github.com/facebook/react-native/pull/36397
Test Plan:
`npm run build` in `packages/react-native-codegen` and see all .d.ts files appear in `lib`.
Checked .d.ts file in typescript playground.
Reviewed By: rshest
Differential Revision: D43941811
Pulled By: cipolleschi
fbshipit-source-id: 28f5bd56f27531ecf25223620a580358018b779d
Summary:
Updates the default set of `"exports"` condition names in our `ReactNativeEnv` for Jest, so that it aligns with the defaults in React Native CLI (https://github.com/react-native-community/cli/pull/1862).
Also includes a subtle update to how this is accomplished. Instead of overriding `exportConditions()`, we assign to the underlying class property — this allows users (once https://github.com/facebook/jest/pull/13989 is merged) to override `customExportConditions` via [`testEnvironmentOptions`](https://jestjs.io/docs/configuration#testenvironmentoptions-object).
```js
preset: 'react-native',
testEnvironmentOptions: {
customExportConditions: ['test', 'react-native'],
},
```
Changelog: [Internal]
Reviewed By: jacdebug
Differential Revision: D43879056
fbshipit-source-id: 86fffe2b5fdf9d8492d25b8b12a78be75b5fa3be
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36471
The previous native web socket API, `RCTSRWebSocket`, appears to be an older version of the one provided as part of [SocketRocket](https://github.com/facebookincubator/SocketRocket). The latter has several improvements, such as the ability to respect proxy settings, which has been requested by a user of a React Native app.
Everything translates over pretty easily, and considering that SocketRocket is already a dependency of Flipper, there doesn't seem to be much additional cost to swapping out the libraries. If we wanted to make things even slimmer, it may even be possible to make the WebSocket library be optional for release builds.
## Changelog
[IOS] [CHANGED] - Use SocketRocket for web socket library
Pull Request resolved: https://github.com/facebook/react-native/pull/36347
Test Plan:
Validated the following:
* The WebSocket test page in RNTester
* Live reloading
Reviewed By: cortinico
Differential Revision: D43768835
Pulled By: javache
fbshipit-source-id: 11e1ac2700bc92991897c594622e6687339bfcbf
Summary:
`Partial` is the new name of `$Partial`
Changelog: [Internal]
Reviewed By: SamChou19815
Differential Revision: D43993220
fbshipit-source-id: 38e8a6bcfa559857b2ab88efee6b904b387bdc0d
Summary:
There's some problem in the last sync that changes the memoization behavior in some product code. We'll revert and investigate.
Changelog: [internal]
Reviewed By: bvanderhoof
Differential Revision: D44100907
fbshipit-source-id: 233b478dd6f2f29121ac05323047ab6099b6b56c
Summary: Changelog: [Android][Fixed] Fixed text measurement issue related to hyphenation frequency
Reviewed By: makovkastar
Differential Revision: D44093758
fbshipit-source-id: 71b7b6cd862586b673a49f5e6efaf9aeeb25c6e1
Summary:
The `FabricUIManager` module was providing access to the global binding defined by Fabric, adding proper typing for it.
The problem about this module is that it only evaluated the global binding once (during module evaluation) and it cached the result. If this module happened to be loaded before the binding is defined, which can happen in apps using the legacy renderer and Fabric together, this modules caches an `undefined` value indefinitely.
This refactors the module as a getter function to make sure this lazy behavior is handled correctly in the callsites.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D44065186
fbshipit-source-id: 7c5cfe674605f03ecb8ca0dabc4c823e0013da6b
Summary:
Part of Codegen Issue https://github.com/facebook/react-native/issues/34872
> [Codegen 88] Move the Visitor.js file from parsers/flow/Visitor.js to parser-promitives.js. Copy the TSInterfaceDeclaration(node: $FlowFixMe) function and add it to the Visitor.js just copied. Remove the parsers/typescript/Visitor.js. Make sure we use the same Visitor in both parsers. (We will end up with a Visitor that is the union of the two, being able to handle both Flow and TS. In this specific case, this trade-off make sense as it allows us to remove one file, several duplicated lines for a small price.)
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal][Changed] - Extract Visitor function to parsers primitives and remove both parsers visitor files
Pull Request resolved: https://github.com/facebook/react-native/pull/36459
Test Plan:
```
yarn jest
yarn flow
yarn lint
yarn format-check
```
Reviewed By: cortinico
Differential Revision: D44021825
Pulled By: cipolleschi
fbshipit-source-id: ea465404830402c44081143ee0539107dc75776c
Summary:
Recent integration from Windows brought in PerformanceApiExample that uses relative pathing to access react-native library. This causes us to have to override the file since our file structure is different. https://github.com/microsoft/react-native-windows/issues/11373
This PR changes the example to use module pathing instead.
## Changelog
[GENERAL] [CHANGED] - Change PerformanceApiExample to use ModulePathing
Pull Request resolved: https://github.com/facebook/react-native/pull/36478
Test Plan: Tested and passed Windows tests
Reviewed By: rshest
Differential Revision: D44089501
Pulled By: javache
fbshipit-source-id: 99993a4f81556b4fef7c5d15af26b20df960ebf9
Summary:
This PR adds a `functionTypeAnnotation` function to the codegen Parser class and implements it in the Flow and TypeScript parsers as requested on https://github.com/facebook/react-native/issues/34872, refactoring the `throwIfModuleTypeIsUnsupported` function to accept a `Parser` instead of a `ParserType` and use the newly created function instead of the `if (language)` logic.
## Changelog
[Internal] [Added] - Add `functionTypeAnnotation` to codegen Parser class
Pull Request resolved: https://github.com/facebook/react-native/pull/36468
Test Plan:
Run `yarn jest react-native-codegen` and ensure CI is green

Reviewed By: cipolleschi
Differential Revision: D44056853
Pulled By: rshest
fbshipit-source-id: f22b9efe53df16f7916eb1a9cea8b9531f1194f5
Summary:
## Changelog:
[Internal] -
Now that Performance API implementation is getting close to the final stage, it should be safe to replace the `global.performance` instance with the corresponding new implementation. This is done *only* if the actual native implementation is present, however (otherwise the behaviour will be exactly the same as before). Currently this is the case for all VR apps, Catalyst and very soon will be the case for fb4a/ios.
Reviewed By: cipolleschi
Differential Revision: D44057951
fbshipit-source-id: 7ccff4a4930175def69ef4d8a44335fbbd4a5df4
Summary:
For the TurboModule interop layer, we'll pass in a second ModuleProvider. We'll default that second parameter to null, when the interop layer is disabled. This change will make that easier.
Changelog: [General][Changed] - Re-organize the parameters of TurboModuleBinding::install()
Reviewed By: javache, cortinico
Differential Revision: D43993199
fbshipit-source-id: 2d339cab1f9bfe481f4b72401caa203cd7536da1
Summary:
CellRendererComponent can be given a more useful description, and more constrained type, to ensure it is used more correctly.
Changelog:
[General][Fixed] - Fix types + documentation for CellRendererComponent
Reviewed By: yungsters
Differential Revision: D43925572
fbshipit-source-id: 26aae6a2df989993c97709ffbf1544df7cbae036
Summary:
There is a rounding issue in layout calculation when using onTextLayout method in Text component on Android.
As you can see in the example below onTextLayout returns 3 lines, but in fact text is rendered in 2 lines:
<img width="775" alt="Screenshot 2023-02-19 at 23 48 53" src="https://user-images.githubusercontent.com/8476339/220177419-de183ccd-a250-4131-ad05-907fdb791c75.png">
This happens because `(int) width` casting works like `Math.floor`, but after changing it to `Math.round` we get correct result:
<img width="775" alt="Screenshot 2023-02-19 at 23 51 11" src="https://user-images.githubusercontent.com/8476339/220177859-93474c43-ed87-4c1b-986c-2817b29b78be.png">
## Changelog
[ANDROID] [FIXED] - Fix layout width calculation in onTextLayout
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/36222
Test Plan:
This issue can be tricky to reproduce as width calculation depends on device width. I'm attaching code that I used to reproduce it. You need to tap on the screen to run through different sentences and sooner or later you will get the one with this rounding issue.
<details>
<summary>Code to reproduce</summary>
```js
import React, { useState, useEffect } from 'react'
import { SafeAreaView, Text, View } from 'react-native'
function App() {
const [state, setState] = useState({
index: 0,
lines: [],
sentences: [],
})
const onTextLayout = (event) => {
const lines = event.nativeEvent.lines
console.log(JSON.stringify(lines, null, 2))
setState(state => ({ ...state, lines }))
}
useEffect(() => {
fetch('https://content.duoreading.io/20-the-adventures-of-tom-sawyer/translations/english.json')
.then(response => response.text())
.then(response => {
setState(state => ({ ...state, sentences: JSON.parse(response) }))
})
}, [])
return (
<SafeAreaView style={{ flex: 1, padding: 30 }}>
<View style={{ flex: 1 }} onTouchStart={() => setState(state => ({ ...state, index: state.index + 1 }))}>
<Text style={{ fontSize: 22 }} onTextLayout={onTextLayout}>
{state.sentences[state.index]}
</Text>
{state.lines.map((line, index) => (
<View
key={index}
style={{
position: 'absolute',
top: line.y,
left: line.x,
width: line.width,
height: line.height,
opacity: 0.3,
backgroundColor: ['red', 'yellow', 'blue'][index % 3],
}}>
</View>
))}
</View>
</SafeAreaView>
)
}
export default App
```
</details>
Reviewed By: christophpurrer
Differential Revision: D43907184
Pulled By: javache
fbshipit-source-id: faef757e77e759b5d9ea26da21c9e2b396dc9ff1
Summary:
This change updates the offline mirrors and remove the need for destinations in Sandcastle jobs, to mitigate the problem with the oss jobs we are facing.
allow-large-files
## Changelog:
[internal] - update offline mirror and don't run tests on simulators
Reviewed By: robhogan, dmytrorykun
Differential Revision: D44056468
fbshipit-source-id: c4db37a715eb1307a01a33b1917573f67ed0e2a7
Summary:
The contract here is that `initialScrollIndex` only applies once, right after the components mount. There is other code still relying on live `initialScrollIndex`, which is allowed to become stale. E.g. after removing items.
I looked at a larger change of only ever using `initialScrollIndex` in the start, so we have a consistent value. We also ideally should fix up the logic relying on it for the scroll to top optimization.
That series of changes is more involved than I want to spend time on, so this just avoids the check once we have triggered a scroll, where the rest of the code is UT'd to be permissive if it drifts out of allowed.
Changelog:
[General][Fixed] - Allow out-of-range initialScrollIndex after first scroll
Reviewed By: yungsters
Differential Revision: D43926656
fbshipit-source-id: bd09bd9a9aa6b3b5f07209dac8652c9374a762c4
Summary:
After https://github.com/facebook/react-native/pull/36122 we have two of these. This change consolidates the two category methods to be part of the base RCTConvert class instead.
Changelog:
[iOS][Fixed] - Fix duplicate [RCTConvert UIUserInterfaceStyle:]
Reviewed By: cipolleschi
Differential Revision: D44050929
fbshipit-source-id: dd216545e6194446c593cd693072f3959d653d7f
Summary:
This adds a feature flag to enable all the new DOM traversal and layout APIs (in https://github.com/react-native-community/discussions-and-proposals/pull/607).
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D43981608
fbshipit-source-id: 77bb1ee4faaaf30cfc8bb2e493763b168702f498
Summary:
We shouldn't be accessing `nativeFabricUIManager` directly because it's untyped and makes it harder to mock the values.
This migrates all existing usages to the `FabricUIManager` module.
In the long term, we should refactor this global binding as a TurboModule.
Changelog: [internal]
Reviewed By: yungsters
Differential Revision: D44029301
fbshipit-source-id: d8300acb5dabe4ba27c7f0242230e203c0e8c674
Summary:
This diff is reverting PR https://github.com/facebook/react-native/pull/33468
Due to an increase of java.lang.IllegalStateException caused by the PR
Original commit changeset: cd80e9a1be8f
Original Phabricator Diff: D38410635
Changelog:
[Android][Fixed] - removed logic that calls the [AccessibilityNodeInfo#setError][10] and [#setContentInvalid][13] method to display the error message in the TextInput - Revert of PR https://github.com/facebook/react-native/pull/33468
Reviewed By: NickGerleman, makovkastar
Differential Revision: D44032331
fbshipit-source-id: 732ed0cf23e4f30ae00c51dace851a3fdfe65c01
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36461
This change breaks a dependency cycle between `ReactCommon` and `React-Core`.
`React-Core` depends on `ReactCommon` to have access to the various `TurboModule` native files.
`ReactCommon` depends on `React-Core` because the content of the `core/platform/ios` folder and the `samples` folder needs to access the `RCTBridge` and other files in Core.
To break the circular dependency, we introduced two new `podspecs`:
* `React-NativeModulesApple` for the content of `core/platform/ios`.
* `ReactCommon-Samples` for the content of the `samples` folder.
In this way, the new dependencies are linear as `React-NativeModulesApple` and `ReactCommon-Samples` depends on `React-Core` and `ReactCommon` and `React-Core` only depends on `ReactCommon`.
While doing this, we also make sure that all the include path are aligned, to limit the amount of breaking changes.
## Changelog:
[iOS][Breaking] - Split the `ReactCommon/react/nativemodule/core/platform/ios` and `ReactCommon/react/nativemodule/samples` in two separate pods to break circular dependencies.
Reviewed By: mdvacca
Differential Revision: D44023865
fbshipit-source-id: a97569506350db5735ac5534b1592471de196cbe
Summary:
Changelog: [Internal]
Implements a shim for the NativePerformance TurboModule, which can be used as a mock to unit test the JS side of WebPerformance functionality (in particular, the higher level API logic of `Performance` and `PerformanceObserver` implementations in JS) without need to have the native NativePerformance implementation available (which would otherwise require running some heavy weight e2e tests).
Reviewed By: rubennorte
Differential Revision: D43985454
fbshipit-source-id: da10387c1d70cb0300c077972d3925bc2fad4f5e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36438
This makes the `react-native` repository compatible with the next sync from react after the changes in https://github.com/facebook/react/pull/26321 land.
That PR is changing the format of the Fabric instance and we have a few instances where we assume the internal structure of that instance in the repository.
Changelog: [internal]
Reviewed By: yungsters
Differential Revision: D43980374
fbshipit-source-id: 718b504ff7c5bb6088c553e0256489b04d92b653
Summary:
## Rationale
JavaTurboModule holds the module object as a JTurboModule. With the TurboModule inteorp layer, JavaTurboModule will also need to hold NativeModule objects.
## Changes
So, this diff makes JavaTurboModule hold the module object as a jobject instead.
This shouldn't impact method dispatch, because method dispatch doesn't rely on the JTurboModule interface.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D43918939
fbshipit-source-id: 7cc43dfe2df7571e39bcf4d6f362dde0e500e2fe
Summary:
## Rationale
Better separation of concerns. Less confusion. All the logic around TurboModule HostFunction management is in TurboModule::get(). And TurboModule::createHostFunction() is only responsible for creating the HostFunction. Also, there aren't two TurboModule::get functions, each with different/unclear responsibilities.
## Motivation
The interop layer (i.e: D43918998) will have to override TurboModule::createHostFunction():
- TurboModule::createHostFunction() relies on static functions for method dispatch.
- The interop layer cannot use static functions for method dispatch: interop modules' methods are only be discoverable at runtime.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D43918940
fbshipit-source-id: f2ffd210329a10967e9b2f0c925f4990cb470083
Summary:
TurboModuleManager.getOrCreateModule() is responsible for creating TurboModules.
In the future, we'll need this method to create interop NativeModules (i.e: NativeModules that don't implement TurboModule). So, this diff changes the implementation of the method to create NativeModule objects.
In the future, we'll extend the TurboModule create algorithm to create legacy NativeModules, by integrating with TurboModuleManager.getLegacyModule(): D43751055
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D43801536
fbshipit-source-id: d86ef915248d40bea56c6103796a37dd7fb5992a
Summary:
In the future, we'll re-use this interface to create NativeModule objects as well.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D43801529
fbshipit-source-id: 90376086744dc996274663792289e3eba7be56c1
Summary:
- Right now, in the TurboModuleManager, "module" refers to TurboModules.
- In the future, we'll use this cleanup lock for interop modules as well (i.e: NativeModules that don't conform to TurboModule).
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D43801535
fbshipit-source-id: cecccf8d0005ef11bb0c864515fd284292582e64
Summary:
- Right now, in the TurboModuleManager, "module" refers to TurboModules.
- In the future, we'll use this cleanup lock for interop modules as well (i.e: NativeModules that don't conform to TurboModule).
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D43801534
fbshipit-source-id: 1ece9faa1ed564b7024098406deaa60b8a904478
Summary:
- Right now, in the TurboModuleManager, "module" refers to TurboModules.
- In the future, we'll use this cleanup lock for interop modules as well (i.e: NativeModules that don't conform to TurboModule).
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D43784169
fbshipit-source-id: dca227374e8d7de319f4fd5556d200ba8b9ac77c
Summary:
The New Architecture Validation logging should output an error whenever ReactInstancePackages are used. These packages get access to the ReactInstanceManager, which isn't available in Bridgeless mode.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D43255702
fbshipit-source-id: 1df8c2941805bb773a127408fbf7871674b0cb7c
Summary:
Make the TurboModule system understand ReactPackages.
**Note:** The TurboModule system can only create TurboModules in LazyReactPackages.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D43255701
fbshipit-source-id: 74d034732d0a6fb32197b15bb54cac9161abc294
Summary:
Make the TurboModule system understand LazyReactPackages.
**Note:** The TurboModule system can only create TurboModules in LazyReactPackages.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D43254982
fbshipit-source-id: 4260cc7dc1d28b1ad6268087720c6e02cfc20d32
Summary:
## Problem
The TurboModule system can only create modules in TurboReactPackages. We want to change this. The TurboModule system should integrate with all of React Native's ReactPackages.
## Changes
ReactPackageTurboModuleManagerDelegate integrates the TurboModule system with React Native's ReactPackage infra.
This diff refactors ReactPackageTurboModuleManagerDelegate, so that it can eventually support many different types of ReactPackages.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D43066961
fbshipit-source-id: d793e14353382dc4cf9ea4af5a7ffe5c83e3baf6
Summary:
The TurboModule interop layer is a new mode for the TurboModule system.
Goal: Make the TurboModule system incrementally adoptable in **Bridgeless mode.**
What it does: Run all legacy modules through the TurboModule system in Bridgeless mode.
How to enable it:
1. Enable Bridgeless Mode: ReactFeatureFlags.enableBridgelessArchitecture = true.
2. Set ReactFeatureFlags.useTurboModuleInterop = true.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D43715758
fbshipit-source-id: 89470a28d1f37b9010beb84e43f62425473de8b5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36402
## Changelog:
[Internal] -
Makes `GlobalPerformanceLogger` (`IPerformanceLogger` API), additionally use the native WebPerformance implementation (`Performance` and `PerformanceObserver` APIs) to log points/timespans as marks/measures correspondingly.
This will ultimately help to converge performance logging facilities across platforms and language boundaries.
In a shorter term, it can serve as a good case study of using the Web Performance API implementation.
Note that this implementation is disabled by default (controlled by the RN feature flag), and will be enabled separately via na experiment.
Reviewed By: rubennorte
Differential Revision: D43873560
fbshipit-source-id: 22e2d787c8f22d2f67556dfe4bf175743eca2caf
Summary:
Fix circle CI failure, error:
```
stderr: : warning: unknown enum constant androidx.annotation.RestrictTo.Scope.LIBRARY_GROUP_PREFIX
: warning: unknown enum constant kotlin.annotations.jvm.MigrationStatus.STRICT
reason: class file for kotlin.annotations.jvm.MigrationStatus not found
/root/react-native/ReactAndroid/src/main/java/com/facebook/react/ReactActivityDelegate.java:105: error: local variable launchOptions is accessed from within inner class; needs to be declared final
return ReactActivityDelegate.this.createRootView(launchOptions);
^
/root/react-native/ReactAndroid/src/main/java/com/facebook/react/ReactInstanceManager.java👎 note: Some input files use or override a deprecated API.
/root/react-native/ReactAndroid/src/main/java/com/facebook/react/ReactInstanceManager.java👎 note: Recompile with -Xlint:deprecation for details.
/root/react-native/ReactAndroid/src/main/java/com/facebook/react/CoreModulesPackage.java👎 note: Some input files use unchecked or unsafe operations.
/root/react-native/ReactAndroid/src/main/java/com/facebook/react/CoreModulesPackage.java👎 note: Recompile with -Xlint:unchecked for details.
Errors: 1. Warnings: 2.
```
https://app.circleci.com/pipelines/github/facebook/react-native/20239/workflows/31711cb5-6603-432e-a869-d76c9391536e/jobs/473257?invite=true#step-107-261
Changelog:
[Android][Changed] - Fix circle CI failure
Reviewed By: cipolleschi
Differential Revision: D43976548
fbshipit-source-id: 2d50d37bbc78cb1264af9d6fffbfe60f24326cec
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36417
This changes adds an example to RNTester to verify that the Interop Layer can process constants in Fabric as it used to do in Paper.
## Changelog:
[iOS][Added] - Add example in the Interop Layer to use constants
Reviewed By: cortinico
Differential Revision: D43911916
fbshipit-source-id: 1d4b630d45d21904c53d85b97607ebb7fb8a62fc
Summary:
This changes adds an example to RNTester to verify that the Interop Layer can process bubbling events in Fabric as it used to do in Paper.
## Changelog:
[iOS][Added] - Add example in the Interop Layer to use events
Reviewed By: sammy-SC
Differential Revision: D43911390
fbshipit-source-id: ae75db25078669676e5a609e090f1e9674026391
Summary:
Make Venice available in Catalyst Android, to enable set ```ReactFeatureFlags.enableBridgelessArchitecture``` to true in CatalystApplication.java
**Note**: right now not every piece works with Venice enabled, but the main functionalities (Fabric components, playground) mostly work, the rest issues will be gradually fixed.
Changelog:
[Internal][Changed] - Enable Venice in Catalyst Android
Reviewed By: NickGerleman
Differential Revision: D43711737
fbshipit-source-id: 6ecb7e2b09c5b7feaa00b90076a2a894c08affc9
Summary:
The original diff D43711708 was reverted due to a problem caused on Ads Manager App Android. Re-land while make sure Ads Manager not broken.
Changelog:
[Android][Changed] - Re-land "Migrate packages to not eager initialize view managers"
Reviewed By: RSNara
Differential Revision: D43907600
fbshipit-source-id: 92f99fd3f9ba90d1798d4ec9c03feff00070a47c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36421
Changelog: [Internal]
Adding an extra choice for commit question, user can now choose between three options:
1. Commit with generic message, no further actions needed
2. Commit with custom message, intercative VIM input will open
3. Not committing anything
Reviewed By: cortinico
Differential Revision: D43943526
fbshipit-source-id: 014215105d192961486b7d1c697f491697492812
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36419
After migrating to Xcode 14.2.0, some contributors were receiving CircleCI Machines that were not able to install Ruby 3.2.0.
This change should improve the robustness of the pipelines, ensuring that `ruby-build` can always find the version of Ruby it needs
## Changelog:
[internal] - Make sure CircleCI always find the right version of Ruby
Reviewed By: cortinico
Differential Revision: D43944878
fbshipit-source-id: 89d9fcc6ae346003e96c2a8f4103a83a7d2f3204
Summary:
Refactor the startup performance API so that we are not using a vector to store only a few startup metrics values. This makes the metrics more strictly typed and concise.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D43860049
fbshipit-source-id: 2c2102de2b64e2c5cda509ac26f0d1d072287083
Summary:
Adds changelog for new patch.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - add changelog entry for 0.71.4
Pull Request resolved: https://github.com/facebook/react-native/pull/36405
Test Plan: N/A
Reviewed By: christophpurrer
Differential Revision: D43910075
Pulled By: cipolleschi
fbshipit-source-id: 4f0b7fb45c07895dbddedd08553b84460043c948
Summary:
VirtualizedList today will keep refs to cells around, long after they have been unmounted. This leaks memory, and is not needed.
Changelog:
[General][Fixed] - Delete refs to unmounted CellRenderers
Reviewed By: yungsters
Differential Revision: D43835135
fbshipit-source-id: 2104cae977a4e2e9e1a2738e1523ac1796293b4f
Summary:
This adds `librrc_legacyviewmanagerinterop.so` to the pickFirst block inside RNGP.
While testing the Fabric Interop layer, I realized that I forgot to add it here and now the build
fires a warning as follows:
```
> Task :app:mergeDebugNativeLibs
2 files found for path 'lib/arm64-v8a/librrc_legacyviewmanagerinterop.so'. This version of the Android Gradle Plugin chooses the file from the app or dynamic-feature module, but this can cause unexpected behavior or errors at runtime. Future versions of the Android Gradle Plugin may throw an error in this case.
Inputs:
- /private/tmp/RNNightly/android/app/build/intermediates/cxx/Debug/194810a4/obj/arm64-v8a/librrc_legacyviewmanagerinterop.so
- /Users/ncor/.gradle/caches/transforms-3/ba1c1d3560a64e70d8218910c5a43605/transformed/jetified-react-android-0.0.0-20230302-2110-caf80d442-SNAPSHOT-debug/jni/arm64-v8a/librrc_legacyviewmanagerinterop.so
```
Changelog:
[Internal] [Changed] - RNGP - Add librrc_legacyviewmanagerinterop to pickfirst config block
Reviewed By: cipolleschi
Differential Revision: D43772845
fbshipit-source-id: cf34bb128b76f18e802a94c41c773f7cb2b7ec4a
Summary:
Faacebook:
For both Paper and Fabric, at least on Android, RNTester TextInputs using the default style render as collapsed. This seems to be an interaction between the TextInputs being set as `flex: 1`, and being rooted in a ScrollView.
The issue still seems to happen when the outer container is large enough, but non-scrolling, which seems like a layout bug. But we can for now root the E2E container in a ScrollView (which we probably want to do anyway to allow long examples).
Changelog:
[Internal]
Reviewed By: mdvacca
Differential Revision: D43714494
fbshipit-source-id: ef1f8929ceeaef0d2c87262cf0446e0c6644cc9d
Summary:
changelog: [internal]
This diff introduces a mechanism to cache NSTextStorage on Paragraph's state. The old renderer already has caching for NSTextStorage: https://github.com/facebook/react-native/blob/main/Libraries/Text/Text/RCTTextShadowView.m#L21
Fabric will store `NSTextStorage` inside `ParagraphLayoutManager` which is owned by state.
There is one notable change which is not gated: Paragraph's state strongly owns `TextLayoutManager`, not `ParagraphShadowNode` like previously. This shouldn't change anything
Reviewed By: mdvacca
Differential Revision: D43692171
fbshipit-source-id: efe6077222a30ab6d89abd9916534b9a96e745d4
Summary:
This is a change upstreamed from our fork, React Native macOS: https://github.com/microsoft/react-native-macos/pull/1088
Original description:
>We hit some crashes where replacing the chars in the string in the description was happening at an invalid range. That caused investigation into what these description methods are doing. We shouldn't have code assuming super's description will return in a certain format. Instead, just append any additional info we want to add to the end of the description.
## Changelog
[IOS] [CHANGED] -Remove assumptions on super's description
Pull Request resolved: https://github.com/facebook/react-native/pull/36374
Test Plan: CI should pass
Reviewed By: cipolleschi
Differential Revision: D43906367
Pulled By: javache
fbshipit-source-id: f83a67c5890ad1f8a73bc644be1f0f8b22b1a371
Summary:
glog logging was being sent to adb logcat twice since `fbgloginit` uses `force_static = True` and was being linked as two separate copies.
Changelog: [Internal]
Reviewed By: sshic
Differential Revision: D43842295
fbshipit-source-id: da4233d29dbddc2b3cefdca979c873479672b11c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36385
This change moves the `graphics/conversions.h` files from `ReactCommon/react/renderer/graphics` to `ReactCommon/react/renderer/core`, renaming it to `graphicsConversions.h`.
This is required because React-Fabric imports graphics, but graphics imports React-Fabric due to this file.
The change would be breaking, but we don't want to break the ecosystem without even a warning. So, we put back the `conversions.h` file, which now just `include` the new one and outputs a warning when building. This actually maintain the dep cycle for the current version, but at least users are warned.
## Changelog:
[iOS][Deprecated] - Deprecate the `ReactCommon/react/renderer/graphics/conversions.h` in favor of `ReactCommon/react/core/graphicsConversions.h`
Reviewed By: cortinico, dmytrorykun
Differential Revision: D43836261
fbshipit-source-id: ffe53a8ce2b0ea2dd1e1e5aaf6b3d3c5b57ad46d
Summary:
This change updates the way in which we consume the list of components from the `react-native.config.js` files so that it is aligned to what Android does.
## Changelog:
[iOS][Changed] - Update how the `react-native.config.js` is consumed to add elements in the interop layer.
Reviewed By: cortinico
Differential Revision: D43875395
fbshipit-source-id: e359c98a9144f4efe62967096d48318491718958
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36345
`exactOptionalPropertyTypes` is a TypeScript 4.4+ option set by users which changes behavior of optional properties, to disable accepting explicit `undefined`.
This is not enabled when using `--strict`, and is stricter than Flow, leading to most of the typings having an `| undefined` unique to TypeScript (added with https://github.com/DefinitelyTyped/DefinitelyTyped/commit/694c663a9486dbe7794d5eb894a691ee9ded318a).
We have not always followed this (I have myself previously assumed the two are equivalent). We can enforce that the convention is followed with a plugin `eslint-plugin-redundant-undefined`. This forces us to declare that every optional property accepts an explicit undefined (which Flow would allow). Alternatively, if we do not want to support this, we can enable the existing dtslint rule `no-redundant-undefined`.
Changelog:
[General][Fixed] - Enforce compatibility with `exactOptionalPropertyTypes`
Reviewed By: lunaleaps
Differential Revision: D43700862
fbshipit-source-id: 996094762b28918177521a9471d868ba87f0f263
Summary:
This diff refactors performance memory API and the RN Tester example.
- The returned value from C++ is number, so no need to cast
- Reuse `MemoryInfo` in RNTester example
Changelog:
[General][Internal] - Code refactor for performance memory API implementation
Reviewed By: rubennorte
Differential Revision: D43523878
fbshipit-source-id: 37d1f6a829a8eac45f7e3791ad36be0c199c6041
Summary:
Previously, the touch area could never extend past the parent view bounds. Thus, hitSlop would not have any effect if it extended beyond any ancestor view's view bounds.
In this diff, we apply hitSlop when calculating overflowInset. Specifically, we make sure to union the hit slop areas of all children when calculating the contentFrame.
overflowInset is then used for hit testing (as in [TouchTargetHelper.java](https://www.internalfb.com/code/fbsource/[b0f630bb24271d8ed543e98ff144590290e19805]/xplat/js/react-native-github/ReactAndroid/src/main/java/com/facebook/react/uimanager/TouchTargetHelper.java?lines=195)).
A risk is that other optimizations that may potentially rely on overflowInset beyond hit testing (such as clipToBounds) may not be as efficient with a large hitSlop.
Changelog:
[General][Fixed] - Fix touch handling so that hitSlop can extend beyond parent view bounds.
Reviewed By: javache
Differential Revision: D43854774
fbshipit-source-id: 160bef135b8487c28c4ada662577c35a7a36f484
Summary:
In CricleCI we are still using Xcode 14.0.1.
This version will be removed from CircleCI this Thursday, so we have to update it.
## Changelog
[Internal] - Bump xcode in CircleCI to 14.2.0
Pull Request resolved: https://github.com/facebook/react-native/pull/36388
Test Plan: CircleCI should be Green
Reviewed By: dmytrorykun
Differential Revision: D43873750
Pulled By: cipolleschi
fbshipit-source-id: 8b796c0961647fce103d2659036bf5f9037fe90a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36395
NativeState is a lighter-weight alternative to HostObject, which may simplify some of our use-cases of interacting with JS in the renderer. The down-side is that this approach doesn't allow exposing custom props or functions.
This diffs adds new feature flags to enable experimenting with this functionality and measure any perf impact.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D41553421
fbshipit-source-id: 3065bd7b60f0fa7b63c390e92a785582eee7e613
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36202
This changes all of the in-built dependencies in react native app components upon hermes from HermesAPI to HermesAPIFullOrLean.
HermesAPI (full) includes the bytecode compiler and thus has support for eval().
HermesAPILean does not include the bytecode compiler. It throws at runtime if eval is called. The native dependencies are significantly smaller without the bytecode compiler.
The HermesAPIFullOrLean target toggles between full and lean modes based on the value of buckconfig field `hermes.lean_vm` (default is false). Therefore, without overriding this config option, this change is a no-op and should result in react native apps being built with exactly the same dependencies as before.
If you do specify it, you lose eval support at runtime and gain an apk size savings of a few hundred kB after compression.
This also removes the vestigial `hermes_api_dep()` build macro.
skip-frl-buck-targeting
Reviewed By: javache
Differential Revision: D43283200
fbshipit-source-id: 0157be4a9339f70e73d29d694c18b31805107000
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36391
This include isn't required and was causing issues in the Cocoapods build.
Changelog: [iOS][Fixed] Unbreak cocoapods build
Reviewed By: cipolleschi
Differential Revision: D43870523
fbshipit-source-id: 7e31049d19ef025e9e16284712fb2a80dbdf235e
Summary:
Reland of https://github.com/facebook/react-native/issues/35319 with a fix for custom pull to refresh components.
Custom pull to refresh component in fabric will need to conform to the `RCTCustomPullToRefreshViewProtocol` protocol, this way we know that the view is a pull to refresh and not the content view.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[IOS] [ADDED] - Add fabric support for maintainVisibleContentPosition on iOS
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/36095
Test Plan:
This will need to be tested internally in the product the crash happened.
Take a local build of Wilde open Marketplace.
Reviewed By: jacdebug
Differential Revision: D43128163
Pulled By: cipolleschi
fbshipit-source-id: 6cf8ddff92aeb446072a3d847434e21b9e38af61
Summary:
A previous version of this experiment saw crashes on iOS once rolled out. Switching to WeakObject to make sure we're not accessing invalid references, and setting up the ability to experiment with this on iOS.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D41552667
fbshipit-source-id: dc0c54edc2ad18c1947941119ffd50038a47c5f6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36367
* Don't iterate over JSI Value to get args, convert each of the args individually instead
* Make LongLivedObjectCollection constructor private
* allowRelease does not need to be virtual
* Move away from const-ness as a thread-safety indicator
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D43354535
fbshipit-source-id: eaf8eb931ab6ec307a3dc2690eabeb34bb6afa77
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36384
## Changelog:
[Internal] - Adds more test coverage to PerformanceEntryObserver functionality related to buffering of the marks/measures, as well as making fixes for certain corner cases handled incorrectly (which are now covered by tests).
Reviewed By: rubennorte
Differential Revision: D43835928
fbshipit-source-id: fc8adbd6c2a2b6b201f1f14bdf51245268c5eabd
Summary:
There was a JSDoc mismatch in `Clipboard.setString` method, `the` was considered as a parameter name, not `content`. Added correct param name and kept the same description as before, separated with a hyphen.
## Changelog
[GENERAL] [FIXED] - Fixes JSDoc in Cliapboard setString
Pull Request resolved: https://github.com/facebook/react-native/pull/36381
Test Plan: No tests needed
Reviewed By: yungsters
Differential Revision: D43839086
Pulled By: cortinico
fbshipit-source-id: 126035d9796e66938402704eaf9bc8646ee9b78b
Summary: This will cause the library to be included multiple times in different dynamic libraries, leading to potentially different values of `CoreFeatures`.
Reviewed By: christophpurrer
Differential Revision: D43772552
fbshipit-source-id: 4590bb9aef7c2330b6e488fa1640eda2720b6e7b
Summary:
This is a change we have implemented in React Native macOS that I am now upstreaming: https://github.com/microsoft/react-native-macos/pull/1257
The library `ocMock` is currently imported as a checked in binary by RN-Tester to help run unit tests on iOS. That binary is only compiled for x86 on macOS, which meant we could not run tests on M1 / M2 Macs. Switching it so that we import from source as a pod should make maintenance easier for both iOS and macOS! :)
Original change notes:
>Previously, we've been unable to test RNTester for macOS on an M1 machine. This is because we were using a framework that was prebuilt for Intel architecture, so the test components would fail to build.
>
> The fix is to build OCMock from source directly instead of using a prebuilt version.
>
> This is only necessary on macOS. The iOS version is already built for ARM architecture, as iOS devices have been running exclusively on ARM for a while now.
## Changelog
[INTERNAL] [CHANGED] - Import OCMock as a pod
Pull Request resolved: https://github.com/facebook/react-native/pull/36239
Test Plan: CI should pass as it did before.
Reviewed By: dmytrorykun
Differential Revision: D43732219
Pulled By: cipolleschi
fbshipit-source-id: 028b5a7f384042145bf1966c8c2730d7437940ec
Summary:
## Changelog:
[Internal] - Add unit tests for the WebPerformance library (PerformanceEntryReporter)
This sets up a C++ unit test suite for `PerformanceEntryReporter` (the core part of the native side of WebPerformance) and adds test coverage for its core functionality.
Reviewed By: sammy-SC
Differential Revision: D43771370
fbshipit-source-id: ad3e0f3f206701c2ea6a5c9386458a76699e7c80
Summary:
Currently the hermes tarball will be re-downloaded every time we run pod update even if the file already exists. This adds a check to avoid downloading it if it already exists. To avoid partial downloads causing issues (if the script is interrupted) we download first to a different file and rename it when done.
## Changelog
[IOS] [FIXED] - Don't download hermes nightly tarball if it exists
Pull Request resolved: https://github.com/facebook/react-native/pull/36368
Test Plan: Tested in an app using nightly builds that the download is only done once when running multiple pod update.
Reviewed By: sshic
Differential Revision: D43815772
Pulled By: cipolleschi
fbshipit-source-id: 9dedb79cab1f1cb37cd82b425d93515c6e1728c1
Summary:
This change add more tests for iOS, using different versions of Ruby
## Changelog
[iOS][Added] - Added smoke tests for iOS with Ruby 2.7.7 and 3.2.0
Pull Request resolved: https://github.com/facebook/react-native/pull/36376
Test Plan: CircleCI must be green.
Reviewed By: blakef
Differential Revision: D43825344
Pulled By: cipolleschi
fbshipit-source-id: 8d3f5a2d9688f4d58f0ad5573d7b21e059cab523
Summary:
Starting from RN 0.72, we would like to be more permissive in which version of Ruby our users can use. This means that we have to make sure that our pipeline works with various
versions of Ruby, especially the lowest one, which is 2.6.10.
This change make sure that we run all the CI jobs with version 2.6.10
## Changelog
[IOS] [CHANGED] - Use Ruby 2.6.10 in CI
Pull Request resolved: https://github.com/facebook/react-native/pull/36361
Test Plan: CircleCI must be green
Reviewed By: blakef
Differential Revision: D43824143
Pulled By: cipolleschi
fbshipit-source-id: ecbeb66667a29d9ed07b86c099ad424380a934a7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36360
This change is the iOS equivalent of D43731219 (https://github.com/facebook/react-native/commit/ab55e123da8749d982964f2aee6ce6b0bffdc7fc), but only for what concerns the RNTester example as the interop layer was already present in the codebase and exposed to the OSS.
## Changelog
[internal] - Add example on how to consume a Legacy component in Fabric with the interop layer
Reviewed By: cortinico
Differential Revision: D43735699
fbshipit-source-id: 6cb5a3591e7e4a606c274566226025af91849c16
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36335
This change depends on [this PR](https://github.com/react-native-community/cli/pull/1849) of the CLI that introduces the `unstable_reactLegacyComponent` field in the `react-native.config.js` file.
This change introduce a JS script that reads that fields and generated a method in an object to return a list of components to be registered. The `RCTAppDelegate` has been updated to read those components and to automatically register them into the interop layer.
Notice that a user can just update the `react-native.config.js` and rebuild the app to integrate these changes, there is no need to reinstall the pods.
The idea behind this logic is to let the user know which components they are using with the interop layer, rather than rely on some black magic that could leave them blind to the need of actually migrate their apps.
## Changelog:
[iOS][Changed] - Implement mechanism to register legacy components in the iOS Fabric interop layer
Reviewed By: cortinico, dmytrorykun
Differential Revision: D43665973
fbshipit-source-id: b4e8d71fa1bbed7a6130ee4f83a6221394d5306e
Summary:
Tweaking stale bot to have labels that bypass the stale bot.
## Changelog
[INTERNAL] - Add labels to bypass stale bot
Pull Request resolved: https://github.com/facebook/react-native/pull/36365
Test Plan: n/a
Reviewed By: cipolleschi
Differential Revision: D43771191
Pulled By: cortinico
fbshipit-source-id: 55962a9fe4480e962f94cb0456501e09d88f00da
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36364
## Changelog
[Internal] -
Fixes dependencies, so we don't pull in unneeded iOS ones when we don't care about them (in this case, when running C++ tests for the RN core).
The iOS dependencies came from the `ReactCommon/react/utils` library, that was including ObjectiveC files unconditionally.
Reviewed By: cortinico, dmytrorykun
Differential Revision: D43769718
fbshipit-source-id: e6414e9ee8c5464754a12901f39668331817396e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36366
## Changelog:
[General][Fixed] -
https://github.com/facebook/react-native/pull/36346 added some typing improvements, however there was a typo in `AnimatableStringValue` type definition, that broke tests on CI.
Reviewed By: cortinico, cipolleschi, hoxyq
Differential Revision: D43770412
fbshipit-source-id: 7b4f234b5cf04df9271e0c98cf51655c87e3bebb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36346
1. Remove Paper native assertions for converting DimensionValue string to Yoga unit, and fix a case where Fabric could throw on invalid value.
2. Move DimensionValue types in TypeScript to use template literal types, to show malformed strings in-editor, during typechecking. Update min TS version to allow this (in conformance with the min TS version used by DefinitelyTyped).
Changelog:
[General][Added] - Improve handling of invalid DimensionValue usage
Reviewed By: javache
Differential Revision: D43153075
fbshipit-source-id: db4e813df6e81cbd3158edad7c07c7a90c009803
Summary:
This diff adds the `performance.reactNativeStartupTiming` API to the performance global object for RN. This property does not exist in web, and we are free to make up our own list of properties in the startup metrics to track RN app startup process. In our case, we have the following six properties to begin with (we may extend and add more to this list in the future):
```
- `(start|end)Time`: The time ‘zero’ for the startup timing and the end of app startup. RN has no knowledge of app start time, which will be provided by the platform. The `endTime` will be the time when the first JS bundle finishes executing (Note that RN supports multiple JS bundles, which can be loaded async)
- `executeJavaScriptBundleEntryPoint(Start|End)`: The time for RN to execute the JS entry point (and finish all sync job)
```
Changelog:
[General][Added] - Add new JS performance API to support getting RN app startup timings
Reviewed By: rshest
Differential Revision: D43326564
fbshipit-source-id: 7b4c7cae70ff64ba1714a1630cd5e183df6c06b0
Summary:
Adds unit tests to test multiple animated values that connect to either transform, style, or props, to verify that the create operations are queued before connect operations. See D43717819 (https://github.com/facebook/react-native/commit/c72c592ecd9d31ec1661958d4e5f77f8dfb37cac) for context.
Changelog:
[Internal] - Add unit tests for proper order of create and connect operations for native animated
Reviewed By: mdvacca
Differential Revision: D43741191
fbshipit-source-id: 9143ba1fce86b546bc5a5a781c08ef0ca2d946d6
Summary:
This bumps all the usages of the packages in the monorepo to the latest published.
## Changelog
[INTERNAL] - Bump all the usages of published packages
Pull Request resolved: https://github.com/facebook/react-native/pull/36356
Test Plan: n/a
Reviewed By: jacdebug
Differential Revision: D43735714
Pulled By: cortinico
fbshipit-source-id: 746af2a2f34e65e1093d0670cd79dae5484f21c2
Summary:
Changelog[Internal]:
[iOS][Fixed] - Fix crash from calling setProperty in RCTTurboModule
The crash is caused by passing a utf8 encoded string to a Object::setProperty overload which only allows ascii inputs.
Reviewed By: RSNara
Differential Revision: D43705999
fbshipit-source-id: b3f1b3fd27d43d40fe0a170d4c2e60faecc26dad
Summary:
## Issue
You will run into an exception like:
Animated node with tag (child) [8] does not exist
when attempting to convert an Animated node (or starting a native animation) to native when there are multiple non-style props that have AnimatedValues (this should be a very rare case, unless you have a custom native component, as most animated props are in style).
## Root cause
Due to how __makeNative is recursively called up and down the node graph, in a specific case where multiple AnimatedValues have an AnimatedProps as their child, the "connect" operation will occur before the "create" operation for the AnimatedProps node. For example:
- When a native animation is fired via Animated.timing().start(), __makeNative is called on the AnimatedValue (call this node AnimatedValueA) that is being animated. This results in the following sequence of events:
- AnimatedValueA iterates through its children (in this case, AnimatedProps) and calls child.__makeNative
- AnimatedProps iterates through all props with AnimatedValue values and calls __makeNative on them (call these nodes AnimatedValueB and AnimatedValueC).
- AnimatedValueA.__makeNative is called again, but this time, the call early exits and does not do anything.
- AnimatedValueB.__makeNative is called. This in turn calls AnimatedProps.__makeNative, which early exits (ROOT CAUSE OF BUG).
- connectAnimatedNodes is queued (undesired)
## Fix
Short of completely refactoring of how we handle converting the DAG to native (which we should do at some point - the current implementation is error prone and suboptimal. Tracking in T146991336), for now we can make AnimatedProps.__makeNative behavior consistent with AnimatedTransform and AnimatedStyle by just avoiding the early exit, so that the connectAnimatedNodes calls all occur after all native nodes have been created
Changelog:
[General][Fixed] - Fixed error during native DAG creation when there are multiple AnimatedValue props
Reviewed By: rshest
Differential Revision: D43717819
fbshipit-source-id: 258682300a2be65935646b499591acf41eabc56e
Summary:
Part of Umbrella https://github.com/facebook/react-native/issues/34872
> [**Codegen 84** - assigned to Pranav-yadav] It depends on [Codegen 83] export the parseModuleName anonymous function (Flow, TypeScript) in a common parseModuleName function in the parsers-commons.js file.
- merged Parse Module-Name _**anon**_ fn of `Flow` & `TS` parsers; into a common `parseModuleName` fn in the `parsers-commons.js`
- added **tests** for `parseModuleName` fn from `parsers-commons.js`
- added `callExpressionTypeParameters` method to **_parsers_**
- added **tests** for `callExpressionTypeParameters` method of _parsers_
- used `parser.callExpressionTypeParameters` method in `parseModuleName` fn
PS: fixed merge conflicts several times :(
Overall :)
## Changelog
[INTERNAL] [CHANGED] - Merge Parse-Module-Name anon fn of `Flow` & `TS` and add `callExpressionTypeParameters` method to **_parsers_**
Pull Request resolved: https://github.com/facebook/react-native/pull/36297
Test Plan: - `yarn lint && yarn run flow && yarn test react-native-codegen` ==> ✅
Reviewed By: rshest
Differential Revision: D43694563
Pulled By: cipolleschi
fbshipit-source-id: 99cf40ada0a567cd9ff91078f66fd4ac3684f7cc
Summary:
This will publish several changes we have pending on main, specifically changes to React Native Gradle Plugin which are needed to unblock nightlies.
#publish-packages-to-npm
## Changelog
[INTERNAL] - Bumping all the changes we have on main
Pull Request resolved: https://github.com/facebook/react-native/pull/36355
Test Plan: n/a
Reviewed By: hoxyq
Differential Revision: D43733634
Pulled By: cortinico
fbshipit-source-id: 9c041f7557cd8e494dfc942ae89e13e55353bb48
Summary:
This adds the `UnstableReactLegacyComponentDescriptor`, part of the Fabric Interop Layer for Android.
Summary of the changes are:
* Expose a new `rrc_legacyviewmanagerinterop` native module via prefab
* Extend default App Cmake setup so `rrc_legacyviewmanagerinterop` is exposed by default
* Add a sample legacy component inside RN Tester
Changelog:
[Internal] [Changed] - Expose UnstableReactLegacyComponentDescriptor inside react/renderer/core
Reviewed By: cipolleschi
Differential Revision: D43731219
fbshipit-source-id: ee26d7e9d7eff5ef6a3e22853f8ea363b9198567
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36348
Changelog: [Internal]
Turns out that Phabricator strips `@` symbol from `@...` tags when exports commits to GitHub. Proposing to use `#` instead.
#publish-packages-to-npm
Reviewed By: cortinico
Differential Revision: D43712415
fbshipit-source-id: 86fc728eb0cb63afb6a9fe592a9ae998da2ce2e4
Summary:
Currently, `EventEmitter#addListener` defines the type (via TypeScript and Flow) of its second argument as a non-nullable function, and the implementation of `EventEmitter#emit` depends on this.
However, not everyone may be using a static type system. We're seeing some people encounter a poor developer experience when they supply non-function values to `EventEmitter#addListener`, because the type mismatch is not surfaced as an error until `EventEmitter#emit` throws later on.
This changes `EventEmitter#addListener` so that it throws when the second argument is not a function. This will make it easier for developers to identify the problematic call site because the stack trace will include the source of the non-function `listener` parameter.
Changelog:
[General][Changed] - `EventEmitter#addListener` now throws if the 2nd argument is not a function.
Reviewed By: rshest
Differential Revision: D43705465
fbshipit-source-id: 34ca91ac92862b31435bd12b7c9cb6da870a2a32
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36344
This adds the `UnstableReactLegacyComponentDescriptor`, part of the Fabric Interop Layer,
inside the `react/renderer/components/legacyviewmanagerinterop` module so that it can be included by the user externally.
If we wish to place it somewhere else, I'm more than happy to move it around.
Changelog:
[Internal] [Changed] - Expose UnstableReactLegacyComponentDescriptor inside react/renderer/components/legacyviewmanagerinterop
Reviewed By: mdvacca, cipolleschi
Differential Revision: D43500868
fbshipit-source-id: acfcd89efc42ff7a4ee6cb0a1cbd71d69f79721f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36325
A lot of the code in YogaLayoutableShadowNode expects a 1:1 mapping from ShadowNode children to Yoga Node children, which is not always the case, e.g. for `RawTextShadowNode` (if text, or a number coerced to text, is rendered outside a Text component).
In S323291 we saw this cause memory corruption due to later invalid static_cast. I changed the casting mechanism to terminte instead of corrupting memory, but there is logic here that we need to make permissive (I think D29894182 (https://github.com/facebook/react-native/commit/d3e836245b5fab2e0299dd06901de74dff767b63) also tried to previously do this?).
Normally Text will be rendered inside of a ParagraphShadowNode, where "Text" from React is mapped to ParagraphShadowNode (which is layoutable), "VirtualText" is mapped to TextShadowNode (which is also not layoutable), then finally the text fragment is mapped to "RawTextShadowNode". Arguably React renderer behavior should be not to send anything to native, but we can provide a generalized solution in YogaLayoutableShadowNode to handle any other cases of this issue.
This solution works by filtering ShadowNode children to those which are YogaLayoutable, then only ever operating on that list of children. This means a guaranteed invariant of the nodes we operate on being layoutable (vs the adhoc error handling right now for when they are not), and means we maintain the index based mapping of ShadowNode children to Yoga Node children.
Note, there is another similar API, `getLayoutableChildNodes()` which is protected and returns a filtered list of LayoutableShadowNode. This is public, to allow querying/setting layout results, whearas the similar operations in YogaLayoutableShadowNode are instead an implementation detail.
Changelog:
[General][Fixed] - Fix YogaLayoutableShadowNode handling of non-layoutable children
Reviewed By: sammy-SC
Differential Revision: D43657405
fbshipit-source-id: 8ed136b03b4da15a5e7dfbdd5539b04a2952420d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36341
See https://github.com/react-native-community/discussions-and-proposals/issues/602 for more context.
TL;DR: this flag is used for an edge case. We should not expose it to every users but move it to a guide.
I'll publish a guide on the website on how to achieve the same feature.
Changelog:
[Android] [Changed] - Remove the enableSeparateBuildPerCPUArchitecture from the template entirely
Reviewed By: cipolleschi
Differential Revision: D43695574
fbshipit-source-id: a4f2df755f1d7bd0319a8e418c4ce96b541009ed
Summary:
VirtualizedList refactoring moved [a call of `_updateViewableItems`](https://www.internalfb.com/code/fbsource/[a9d4ad3cf149][history][blame]/xplat/js/react-native-github/Libraries/Lists/VirtualizedList.js?lines=1431-1447) to the inside of a state update.
This call may trigger an `onViewableItemsChanged`, which is normally not an issue (minus changing timing), but creates problems if the users callback then calls imperative methods on the VirtualizedList, since the batched state update may be in the process of changing the props/state the imperative method is reading. See https://github.com/facebook/react-native/issues/36329 for what I suspect is an example of this.
This moves the `_updateViewableItems` call to before the state update, like the previous version of VirtualizedList.
Changelog:
[General][Fixed] - Avoid VirtualizedList viewability updates during state updates
Reviewed By: javache
Differential Revision: D43665606
fbshipit-source-id: 9398273c5209e371e69aafb02bac173c69874273
Summary:
The version using `jest.spyOn()` stopped working at some point. Couldn't find any relevant setup changes, but this form seems to work.
Changelog:
[Internal]
Reviewed By: christophpurrer
Differential Revision: D43669469
fbshipit-source-id: 89d207117e9a56ae3374aed47a8a75fdf2e644fd
Summary:
This PR is task 74 from https://github.com/facebook/react-native/issues/34872:
> Move getTypes functions from utils.js to specific Parsers. Right now we have two Parser classes that takes care of the language specific details and two utils files that contains similar logic. We would like to move everything under the Parsers classes for better OOP architecture and to encourage code-reuse.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - Replace getTypes functions with parser specific methods
Pull Request resolved: https://github.com/facebook/react-native/pull/36225
Test Plan: I tested using Jest and Flow commands.
Reviewed By: rshest
Differential Revision: D43453454
Pulled By: cipolleschi
fbshipit-source-id: 0eebcb55e1af3319e2c35bb462980046329a2c09
Summary:
Found that we may do multiple allocations of the same ViewManager instance since ViewManagers are both accessed from the UI thread (mounting views) and from the Fabric background thread (for measuring Text), which could lead to multiple instances of the same ViewManager to be created.
As far as I can tell, this issue was harmless since our ViewManager constructors don't have side-effects, but not ideal.
Changelog: [Internall]
Reviewed By: rshest
Differential Revision: D43661306
fbshipit-source-id: 37ef82d41d43c334fdc6cfbeffb225bba87c668e
Summary:
Looked at the top soft exceptions firing from this codepath. Most of these should use `getReactApplicationContext` instead of `getReactApplicationContextIfActiveOrWarn` to do their cleanup on invalidation.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D43661307
fbshipit-source-id: 27094a6e8dfcf4748eb916531c4998f1c9ee8713
Summary:
Pre-initializing ViewManagers is not as valuable now that we've rolled out StaticViewConfigs on the new architecture. This was primarily used to pre-allocate constants and the `preInitializeViewManagers` was already deprecated.
Changelog: [Android][Removed] UIManager.preInitializeViewManagers
Reviewed By: rshest
Differential Revision: D43661304
fbshipit-source-id: 391c5207ec876a70ddd4bda30a58267090da3ff1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36314
## Changelog:
[Internal] - Added support for W3C Performance API extension (Performance,getEntries*)
See [here for the details](https://www.w3.org/TR/performance-timeline/#extensions-to-the-performance-interface).
This only supports `mark` and `measure` performance entry types (not `events`, as those are not supported by browsers either, they recommend using the `PerformanceObserver` API instead).
From the implementation perspective, we already maintained persistent buffer for `mark` entry types, which was required in order to look up measures.
The buffer is circular, limited to 1K entries by default.
I basically mimic the same behavior for `measure` entry types as well, since it's the simplest way of doing it at this point,
If we happen to want adding some other entry types that would be available via `Performance.getEntries*` API in the future, we may want to iterate on the internal data structures representation inside `PerformanceEntryReporter`, but for now I believe this approach should work just fine, and whatever changes we may want to do will be purely internal implementation detail.
Reviewed By: rubennorte
Differential Revision: D43625488
fbshipit-source-id: dd315b3f8488e910749a8e2a4158246e94d76f99
Summary:
## Changelog:
[Internal] -
Noticed this when setting up C++ unit tests for WebPerformance - the change in this diff both makes sure there is no "global constructor" warning generated when `-Wglobal-constructors` is enabled, and also makes this bit potentially a little bit more efficient, as we don't pay for the registry construction if we don't use the WebPerformance API.
Reviewed By: christophpurrer
Differential Revision: D43663521
fbshipit-source-id: 59952f2415f49bb455a3443b3bfd8971108ac72b
Summary:
Min Android API level is 21, this diff is removing code for Android API level < 21
changelog: [RN][Android] removing code for Android API level < 21
Reviewed By: cortinico, RSNara
Differential Revision: D43544497
fbshipit-source-id: 1ece1143a37a038826361b55ff08a8160f03108d
Summary:
I was working on `Animated.FlatList` and found some types missing as below

also `Animated.SectionList`

So I refactored type definition for `Animated.FlatList` and `Animated.SectionList` using `abstract class`.
## Changelog
[GENERAL] [FIXED] - add missing FlatList types for Animated FlatList
[GENERAL] [FIXED] - add missing SectionList types for Animated SectionList
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/36292
Test Plan: Ran `yarn test-typescript` and `yarn test-typescript-offline` with no errors.
Reviewed By: lunaleaps
Differential Revision: D43673884
Pulled By: NickGerleman
fbshipit-source-id: 7ccab5997fa2f22226fb0e106672cee98e568ba4
Summary:
Changelog: [Internal] - Remove all imports back to CJS for changelog in 0.72
We are reverting these imports as it may regress perf as we don't have a recommended inlining solution for ES modules at the current time.
Reviewed By: NickGerleman
Differential Revision: D43630911
fbshipit-source-id: ff3bb80009f327c4d51dad21f2cd287ce46d5964
Summary:
This is just a minor bump before 0.72 and it brings AGP up to date
with the latest stable.
allow-large-files
Changelog:
[Internal] [Changed] - AGP to 7.4.2
Reviewed By: cipolleschi
Differential Revision: D43659180
fbshipit-source-id: d57ea8fb6ae902412b542e0125d3b15168d0e123
Summary:
I'm gating this workflow to run only upstream as I'm receiving notifications that it fails on my fork. We don't want to run this workflow on forks at all hence we can add a `if:` there.
## Changelog
[INTERNAL] - Do not attempt to comment on PRs when on forks
Pull Request resolved: https://github.com/facebook/react-native/pull/36316
Test Plan: If Github Actions UI is green, we're good to go
Reviewed By: cipolleschi
Differential Revision: D43657315
Pulled By: cortinico
fbshipit-source-id: 8fb260d142a43375bd9a3b10eac235550a6aecb0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36321
This change bumps Cocoapods to 1.12.0. This last release fixes a bug for which cocoapods was not working with Ruby 3.2.0
## Changelog
[iOS][Changed] - Bumbed version of Cocoapods to support Ruby 3.2.0
Reviewed By: blakef
Differential Revision: D43655787
fbshipit-source-id: 6954ac8271daa7894e57f6d6104ed4d549490695
Summary:
## Changelog:
[Internal] - Refactor Android/iOS/C++ TurboModule examples
~~This makes sure that both native and pure C++ (NativeCxx) TurboModule examples could be run from the Catalyst app.~~
EDIT: See the discussion - this removes the `Playground (NativeModules)` app from Catalyst, as it's already available from the `RNTester Browser` and doesn't provide the C++ counterpart.
Also, there are some tweaks and code factoring in styles, to make it all fit on the screen nicely.
Reviewed By: javache
Differential Revision: D43605250
fbshipit-source-id: 44ee694660f3ad524b8362149ebe617ee495225e
Summary:
Both Android and iOS allow you to set application specific user interface style, which is useful for applications that support both light and dark mode.
With the newly added `Appearance.setColorScheme`, you can natively manage the application's user interface style rather than keeping that preference in JavaScript. The benefit is that native dialogs like alert, keyboard, action sheets and more will also be affected by this change.
Implemented using Android X [AppCompatDelegate.setDefaultNightMode](https://developer.android.com/reference/androidx/appcompat/app/AppCompatDelegate#setDefaultNightMode(int)) and iOS 13+ [overrideUserInterfaceStyle](https://developer.apple.com/documentation/uikit/uiview/3238086-overrideuserinterfacestyle?language=objc)
```tsx
// Lets assume a given device is set to **dark** mode.
Appearance.getColorScheme(); // `dark`
// Set the app's user interface to `light`
Appearance.setColorScheme('light');
Appearance.getColorScheme(); // `light`
// Set the app's user interface to `unspecified`
Appearance.setColorScheme(null);
Appearance.getColorScheme() // `dark`
```
## Changelog
[GENERAL] [ADDED] - Added `setColorScheme` to `Appearance` module
Pull Request resolved: https://github.com/facebook/react-native/pull/36122
Test Plan:
Added a RNTester for the feature in the Appearance section.
Three buttons for toggling all set of modes.
Reviewed By: lunaleaps
Differential Revision: D43331405
Pulled By: NickGerleman
fbshipit-source-id: 3b15f1ed0626d1ad7a8266ec026e903cd3ec46aa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36312
## Changelog:
[Internal] -
`clearMarks` and `clearMeasures` methods are incidental to the `NativePerformance` TurboModule functionality, as in reality this responsibility belongs more on the `NativePerformanceObserver` and `PerformanceEntryReporter` side.
This is something that [the standard indirectly suggests](https://www.w3.org/TR/user-timing/#clearmarks-method) as well (referencing [performance entry buffer](https://www.w3.org/TR/performance-timeline/#dfn-performance-entry-buffer)).
The new implementation should be also a little bit more efficient, as it avoids calling the predicate for each entry.
Finally (and frankly, the main reason for this change, from my perspective), it will simplify mocking/testing the JS part of the PerfAPI code.
Reviewed By: rubennorte
Differential Revision: D43621174
fbshipit-source-id: c4217a0da1d8ecbce797240627f7b4f057d85b97
Summary:
Ahead of cut of RN 0.72, I'm upgrading CLI and Metro according to https://github.com/react-native-community/cli/releases/tag/v11.0.0-alpha.2
~While working on it, I noticed that run-ios has some changes that make the e2e test script not work super well, so I'll be checking in with the CLI team to figure out what's wrong. Let's not merge it until that's address it. (also, there's already a bump for Metro that we need https://github.com/react-native-community/cli/commit/8d18baef554423904c036cbeaa5a1ea92603ff5d so I'll probably change the version to latest CLI and Metro once more)~ (all addressed)
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[GENERAL] [CHANGED] - bump CLI to 11 alphav2 and metro to 0.75.1
Pull Request resolved: https://github.com/facebook/react-native/pull/36271
Test Plan: Test CI, and locally I've used the e2e test script to ensure everything still works.
Reviewed By: NickGerleman
Differential Revision: D43625952
Pulled By: cipolleschi
fbshipit-source-id: dad940b65c56a586ae82acc2e7c16a918b872ee5
Summary:
I've noticed that `UIManagerCommitHooks` are applied after calling `layoutIfNeeded`, meaning that if a commit hook makes some changes to the tree, it needs to calculate the layout again, effectively making the first calculation redundant.
This PR swaps the order of these two operations and moves `shadowTreeWillCommit` call before `layoutIfNeeded`. Thanks to this change, commit hooks don't need to manually trigger layout calculations as well as can potentially operate on unsealed nodes which can make it more efficient in some cases.
Finally, this PR eliminates a crash on `emitLayoutEvents(affectedLayoutableNodes);` when commit hook actually modifies the tree and thus de-allocates old shadow nodes.
cc sammy-SC
## Changelog
[GENERAL] [CHANGED] - Run commit hooks before layout calculation
Pull Request resolved: https://github.com/facebook/react-native/pull/36216
Test Plan: The only `UIManagerCommitHook` I could find in the OSS repo is [`TimelineController`](https://github.com/facebook/react-native/blob/8bd3edec88148d0ab1f225d2119435681fbbba33/ReactCommon/react/renderer/timeline/TimelineController.h#L26).
Reviewed By: cipolleschi
Differential Revision: D43569407
Pulled By: sammy-SC
fbshipit-source-id: 9ab1de0954cac2eb00346be7af8c9b3572bd2c88
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36269
This bumps our project to build on Gradle 8.x
All the necessary issues have already been resolved so everything should be green.
Gradle version has been bumped also inside the template and RNGP.
Changelog:
[Android] [Changed] - Bump Gradle to 8.x
allow-large-files
Reviewed By: cipolleschi
Differential Revision: D43534184
fbshipit-source-id: ca1fd6799ff6d776743de2b2d809fc54bc533440
Summary:
In [this commit](https://github.com/facebook/react-native/commit/e6cba997443ad72961cee1eee39346f80b48184e), we renamed `Geometry.h` to `Vector.h`.
This is the last change of a series of updates that progressively altered the shape of `Geometry.h` from its [original version](https://github.com/facebook/react-native/blob/0.71-stable/ReactCommon/react/renderer/graphics/Geometry.h).
This is a breaking change as several libraries in the OSS are depending on Geometry.h and we removed it without deprecating it.
This change aims to put the file back, with a deprecation message, so that we can safely remove it in the next version.
## Changelog
[General][Fixed] - Restore Geometry.h to avoid breaking change
Reviewed By: cortinico
Differential Revision: D43621983
fbshipit-source-id: 96b976901f7ec337f2ec64c592e4b4d19d89ab11
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36311
Currently, we get the apiVersion/languageVersion for Kotlin that Gradle carries over.
So what happens is that on older version of Gradle, we try to compile RNGP with older versions of Kotlin.
There we have some functions missing (like `.uppercase()`) and the user will fail to build because of this.
Here I'm setting `apiVersion` and `languageVersion` to Kotlin 1.5. Even if we compile with Kotlin 1.7,
the compiler will make sure our code is compatible to be executed in a Kotlin 1.5 environment.
Fixes#36246
Changelog:
[Internal] [Changed] - RNGP - Add apiVersion/languageVersion to 1.5
Reviewed By: cipolleschi
Differential Revision: D43621083
fbshipit-source-id: d74700ff7ef7ac9691965626c2bd0128459fec9b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36258
This fixes a few instances where YogaLayoutableShadowNode (or general shadownode casting) could offer better memory safety.
1. The reference form of traitCast() now terminates on invalid cast, instead of debug assert, since it is better to crash in production than to corrupt memory (which will crash somewhere later, in a much more confusing way).
2. We use traitCast() in more places where we previously would static_cast. This means needing to formally add a mutable version.
3. We bounds-check yoga children access in a single place by using `std::vector` `at()` instead of `[]`.
4. Removed `Trait::UnreservedTrait1` API, since multiple libraries using it can collide and we lose the memory safety benefits of `traitCast`.
This change is in response to a bug where `YogaLayoutableShadowNode` may perform an invalid `static_cast` of `RawTextShadowNode` if a text or number is rendered directly inside of a `<View>` (instead of a `<Text>` element).
This does not yet fix the underlying logic of YogaLayoutableShadowNode to act gracefully when a RawTextShadowNode makes its way into children. We just terminate, instead of corrupting memory.
Changelog:
[General][Breaking] - Better Fabric ShadowNode Memory Safety (Removes `Trait::UnreservedTrait` API)
Reviewed By: javache
Differential Revision: D43271779
fbshipit-source-id: 727c1230f72664bf4d261871c66ca61ddf0d5ffa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36310
As part of the preparation for 0.72, this reduces the amount of breaking changes we expose in the template for the user.
Specifically it re-introduces the 4 param ctor for `DefaultReactActivityDelegate` and marking it with Deprecated,
so the build log and the IDE will instruct the user to move away from it (if they forgot to follow the upgrade helper).
Changelog:
[Internal] [Changed] - Reduce breaking changes with DefaultReactActivityDelegate
Reviewed By: cipolleschi
Differential Revision: D43619184
fbshipit-source-id: a98f7c67201a2860e7c2221e646f45f1ebec4678
Summary:
add print yoga node AllEdge value when debug mode, the old logic just print four edgeValue including top left bottom and right
but when we set the same value to these edge, we use YGAllEdge, this will be more convenient debug code
so I open this pull request to add it
X-link: https://github.com/facebook/yoga/pull/948
Reviewed By: cortinico
Differential Revision: D43525328
Pulled By: NickGerleman
fbshipit-source-id: 59dde363e6ee8433d10ecf27e440ea7d54000bc1
Summary:
This backs out https://github.com/facebook/react-native/pull/36241 for causing screenshot failures in an app still using Paper.
Changelog:
[iOS][Removed] - Back out "[react-native][PR] feat: Add iOS Paper implementation of inset logical properties"
Reviewed By: motiz88, rshest
Differential Revision: D43621612
fbshipit-source-id: 0fc01d6c6ae5c5bfb2813bd60b25e9315e42e3c3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36307
[Changelog][Internal]
Noticed some JS linter warnings during CircleCI tests being run, this disturbed my OCD, so here's a fix for them.
Reviewed By: cipolleschi
Differential Revision: D43619403
fbshipit-source-id: 779a1d2e197298275d06a2597cfef7554017016f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36305
This change automate settings some search paths for 3rd parties libraries that are not using our `install_modules_dependencies` helper.
This will make the `use_frameworks!` changes less breaking.
## Changelog:
[iOS][Changed] - Automatically update Search Path on pods
Reviewed By: dmytrorykun
Differential Revision: D43596808
fbshipit-source-id: 9c5d7ff60a1e4cf73afbfd70b2499f03825cd764
Summary:
This change updates the Offline mirrors so that the `react-native-oss-ios` jobs pass.
It also updates the legocastle script so that it won't check for a specific version of Ruby as right now we decided to support multiple versions.
allow-large-files
## Changelog
[internal] - update iOS mirrors and legocastle
Reviewed By: cortinico, rshest
Differential Revision: D43619512
fbshipit-source-id: dcd95318de72e0dca159da98ead0ef0f375197c1
Summary:
This Change remove the need to have a specific version of Ruby installed. We are now supporting a wider range of Ruby versions, starting from Ruby 2.6.10 (the ruby installed on MacOS by default).
We are still using a Gemfile to control the version of cocoapods that needs to be installed.
## Changelog
[IOS] [CHANGED] - Remove `.ruby-version` and update Gemfile to support a wider range of Ruby versions
Pull Request resolved: https://github.com/facebook/react-native/pull/36281
Test Plan:
- Tested locally on RNTester and an app from template, switch across different versions of Ruby
- CircleCI is green on the commit
Reviewed By: cortinico
Differential Revision: D43567660
Pulled By: cipolleschi
fbshipit-source-id: e7edfe5806a898a83ba39cb58b1318ebde56a57c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36237
This changes the data parameter type for `getItemLayout` from a mutable array (too lenient, even before), to `ArrayLike`, which is now the most constrained subset of data which may be passed to a FlatList.
We could do something more exact by adding another generic parameter to FlatList, but that would be likely be noticeably more breaking, since during testing I couldn't manage a pattern that both kept the same minimum number of generic arguments while keeping inference working.
Changelog:
[General][Breaking] - Constrain data type in `getItemLayout` callback
Reviewed By: javache
Differential Revision: D43466967
fbshipit-source-id: 7a1ce717e7d5cc96a58b8d3ad9def6cf6250871f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36236
D38198351 (https://github.com/facebook/react-native/commit/d574ea3526e713eae2c6e20c7a68fa66ff4ad7d2) addedd a guard to FlatList, to no-op if passed `data` that was not an array. This broke functionality where Realm had documented using `Realm.Results` with FlatList. `Real.Results` is an array-like JSI object, but not actually an array, and fails any `Array.isArray()` checks.
This change loosens the FlatList contract, to explicitly allow array-like non-array entities. The requirement align to Flow `ArrayLike`, which allows both arrays, and objects which provide a length and indexer. Flow `$ArrayLike` currently also requires an iterator, but this is seemingly a mistake in the type definition, and not enforced.
Though `Realm.Results` has all the methods of TS `ReadonlyArray`, RN has generally assumes its array inputs will pass `Array.isArray()`. This includes any array props still being checked [via prop-types](https://github.com/facebook/prop-types/blob/044efd7a108556c7660f6b62092756666e39d74b/factoryWithTypeCheckers.js#L548).
This change intentionally does not yet change the parameter type of `getItemLayout()`, which is already too loose (allowing mutable arrays). Changing this is a breaking change, that would be disruptive to backport, so we separate it into a different commit that will be landed as part of 0.72 (see next diff in the stack).
Changelog:
[General][Changed] - Make FlatList permissive of ArrayLike data
Reviewed By: yungsters
Differential Revision: D43465654
fbshipit-source-id: 3ed8c76c15da680560d7639b7cc43272f3e46ac3
Summary:
This PR adds Paper support to `inset` logical properties on iOS as requested on https://github.com/facebook/react-native/issues/34425. This implementation includes the addition of the following style properties
- `inset`, equivalent to `top`, `bottom`, `right` and `left`.
- `insetBlock`, equivalent to `top` and `bottom`.
- `insetBlockEnd`, equivalent to `bottom`.
- `insetBlockStart`, equivalent to `top`.
- `insetInline`, equivalent to `right` and `left`.
- `insetInlineEnd`, equivalent to `right` or `left`.
- `insetInlineStart`, equivalent to `right` or `left`.
Android changes are in a separate PR to facilitate code review https://github.com/facebook/react-native/pull/36242
## Changelog
[IOS] [ADDED] - Add Paper implementation of inset logical properties
Pull Request resolved: https://github.com/facebook/react-native/pull/36241
Test Plan:
1. Open the RNTester app and navigate to the `View` page
2. Test the new style properties through the `Insets` section

Reviewed By: lunaleaps
Differential Revision: D43525110
Pulled By: NickGerleman
fbshipit-source-id: b70b0ef183dcf192b2c3547422bbe161b7bdba50
Summary:
This PR fixes the initialization path of RNTester when it is run with the Old Arch and Fabric enabled
## Changelog
[iOS][Fixed] - Make sure to initialize the contextContainer in the Old Arch with Fabric enabled
Pull Request resolved: https://github.com/facebook/react-native/pull/36283
Test Plan:
Tested manually on RNTester
CircleCI is green
Reviewed By: sammy-SC
Differential Revision: D43568205
Pulled By: cipolleschi
fbshipit-source-id: cddba97629b542a044191da14221f3300a9d879f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36282
RN Tester is currently red as `TraceUpdateOverlay` is not registered in the Fabric Core Component Registry.
Changelog:
[Internal] [Changed] - Add TraceUpdateOverlayComponentDescriptor to CoreComponentsRegistry
Reviewed By: cipolleschi
Differential Revision: D43567915
fbshipit-source-id: ceb4b9b674a969f260caf810eade30ae23ce2ce8
Summary:
While testing `use_frameworks! :linkage => :static`, I encountered nullability warnings that were previously suppressed because we always build with `-Werror`. I'm not sure why the suppressions no longer work, but they should just be fixed.
## Changelog
[IOS] [FIXED] - Fix nullability warnings
Pull Request resolved: https://github.com/facebook/react-native/pull/36247
Test Plan: iOS build should succeed.
Reviewed By: cipolleschi
Differential Revision: D43531887
Pulled By: javache
fbshipit-source-id: cae0617a20c8d215042cf4c5be2cbb17c801bb41
Summary:
We don't support Lambda in OSS yet, Lambdas were introduced as root of a stack of diffs, so we need to revert the whole stack
## Changelog:
[internal] - revert changes that broke CircleCI
Reviewed By: GijsWeterings
Differential Revision: D43566129
fbshipit-source-id: feae3c3065ed83463c9d887d7ff488c29993e0ae
Summary:
We don't support Lambda in OSS yet, Lambdas were introduced as root of a stack of diffs, so we need to revert the whole stack
## Changelog:
[internal] - revert changes that broke CircleCI
Reviewed By: GijsWeterings
Differential Revision: D43566121
fbshipit-source-id: 5c4fe8272ca220d8914eb64b3ab395589c007198
Summary:
We don't support Lambda in OSS yet, Lambdas were introduced as root of a stack of diffs, so we need to revert the whole stack
## Changelog:
[internal] - revert changes that broke CircleCI
Reviewed By: GijsWeterings
Differential Revision: D43566086
fbshipit-source-id: 95b8ed404edd6f711fbbb5ae3913010c653a2c28
Summary:
The previous fix for -DNDEBUG required to install the pods with PRODUCTION=1 in order to add the flag. The flag was added also to Debug configurations, which is not ideal.
With this change, we remove the requirement of running `PRODUCTION=1 pod install` and we install the -DNDEBUG flag to all the release configurations.
## Changelog:
[iOS][Changed] - Install the -DNDEBUG flag on Release configurations, without requiring PRODUCTION=1 flag
Reviewed By: cortinico
Differential Revision: D43535620
fbshipit-source-id: af97bef06f267dddd5ce13a466bbc8d9a5eb2b0b
Summary:
While looking into android code i noticed a bug removing the incorrect key from a map.
changelog: [internal] internal
Reviewed By: RSNara
Differential Revision: D43544499
fbshipit-source-id: 15224e90cc46af358fb822e85accfae9aa9f7d11
Summary:
We can now use Java 8, this diff i'm replacing old callbacks by lambdas
changelog: [internal] internal
Reviewed By: RSNara
Differential Revision: D43544498
fbshipit-source-id: 4c5ab8473b3d9d512853c02e81652fdce1838a48
Summary:
Task from https://github.com/facebook/react-native/issues/34872
> [Codegen 82] Move isModuleInterface function (Flow, TypeScript) to the Flow and TypeScript parsers.
## Changelog
[INTERNAL] [CHANGED] - Moved isModuleInterface function to to the Flow and TypeScript parsers.
Pull Request resolved: https://github.com/facebook/react-native/pull/36268
Test Plan: ` yarn test react-native-codegen`
Reviewed By: christophpurrer
Differential Revision: D43535948
Pulled By: rshest
fbshipit-source-id: 7a2db05008783499168b0ce3fa58fedbac2b4e79
Summary:
Add performance API example to RN tester, start with the `performance.memory` API.
- Update `RNTesterList` file for both android and ios
Changelog:
[General][Internal] - Add `performance.memory` API example to RNTester
Reviewed By: rshest
Differential Revision: D43326565
fbshipit-source-id: adeb18ce9f1f90d9e9ecf66b533307028bc02df8
Summary:
changelog: [internal]
Move initialisation to `init` function. This allows subclasses of `RCTAppDelegate` to use new architecture when overriding `didFinishLaunchingWithOptions`
Reviewed By: cipolleschi
Differential Revision: D43535602
fbshipit-source-id: 32adb5416e67a63ad168f0ed2480287bf178a6a6
Summary:
Adding automatic RN version checking github workflow, which will verify the version of RN listed on all new issues filed in the repository.
Additionally, this change refactors the existing labeler workflow to make it re-usable by the version check workflow. The change also creates a logical place to add future automatic detection checks, like auto-verification of repro, template, etc.
This is technically not new functionality, as the react-native-bot does this _sometimes_, but this should be a lot more reliable.
The logic for valid release checking follows what is listed in the documentation - valid versions are current and N-2 minors, with the highest available patches.
## Changelog
[INTERNAL] [FIXED] - Made the automated RN version checking workflow more reliable
Pull Request resolved: https://github.com/facebook/react-native/pull/36075
Test Plan:
I have verified a variety of different versions on issues here: https://github.com/SlyCaptainFlint/react-native/issues
I have also re-verified all the tags that were previously handled by the labeler workflow, since I have refactored it. Please take a look at both the open and closed issues in the linked repo for examples.
Reviewed By: cortinico
Differential Revision: D43089150
Pulled By: SlyCaptainFlint
fbshipit-source-id: 7da67f5cb2a4875f22e1f9e46d7ca07d43f3e135
Summary:
Changelog:
[Android][Internal] - Fix EventAnimationDriverMatchSpec to match against the view that generated the event for non-bubbling pointer events. This should have no effect if you are not using PointerEvents
Reviewed By: mdvacca
Differential Revision: D43413771
fbshipit-source-id: 31ac751b3d3d55eb44d3a9ab54e5fb387dcaa9b3
Summary:
After reviewing the doc [`Image`](https://reactnative.dev/docs/image), the typescript compiler doesn't know the following properties:
- src
- srcSet
- referrerPolicy
- tintColor
- objectFit
But after reviewing the source code and this [`commit`](https://github.com/facebook/react-native/commit/b2452ab216e28e004dc625dd8e1ad32351a79be9), the `objectFit` property isn't one related to the Image component but to the `style` props, making the official doc outdated. So, an [`issue in the react-native-website repo`](https://github.com/facebook/react-native-website/issues/3579) have been created and I decided to not include the objectFit prop in this PR.
So, this PR includes those properties: sec, secSet, referrerPolicy and tintColor
## Changelog
[GENERAL][FIXED] Add src, srcSet, referrerPolicy, tintColor to Image.d.ts declaration file
Pull Request resolved: https://github.com/facebook/react-native/pull/36214
Reviewed By: NickGerleman
Differential Revision: D43437894
Pulled By: rshest
fbshipit-source-id: 497426490134aba0a474c49bf8bab9131f2e5845
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36177
react_native_assert calls C `assert()`, where XCode does not have a built-in breakpoint navigator to hook to assertion failures (though you can add a symbolic breakpoint to "abort()" to get the effect). This changes the Apple implemented of `react_native_assert()` to use `NSCAssert` under the hood. This is safe to use in C functions, but will be trapped by the default XCode exceptions breakpoint navigator.
Changelog:
[iOS][Fixed] - Use NSCAssert() in react_native_assert instead of C assert()
Reviewed By: cipolleschi
Differential Revision: D43275024
fbshipit-source-id: 43c4e4f1ae6b99f32634d4b1880bce712c3ae8f6
Summary:
Opts `fbsource//xplat/js/react-native-github/packages/rn-tester:RNTesterIntegrationTests` out of Buck2 runs as the target fails in the analysis stage due to some flavor issues.
I did experiment with just resolving the flavor issues but several more nontrivial issues show up in the build graph the deeper you go and I think this target is going to require a bit more of a deep dive, so just disabling it to unblock buck2 CI rollout for now.
Reviewed By: bujar
Differential Revision: D43505883
fbshipit-source-id: 672dc6aea345a8c0396f6a0e3d549016fe1f7c45
Summary:
When developing the changes to support `use_frameworks!`, I may have forgotten to update the script that generate the `FabricComponentProvider` for the open source (and I may have changed directly that file manually to make everything work).
This change restore the generator, using the right `#import statement`
allow-large-files
## Changelog
[internal] - Update plugin generator
Reviewed By: arushikesarwani94
Differential Revision: D43504184
fbshipit-source-id: a89455b62115f6dc2054f804241fd3834056f1b3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36253
Another build warning that got converted into a failure in Gradle 8.x
Specifically here as we're running 4 native builds in parallel for RN Tester, but they all originate
from 2 CMake intermediates files (one set for Debug and one for Release), Gradle raises a warning.
Here I'm fixing this warning by specifying an explicit ordering between those tasks.
Changelog:
[Internal] [Changed] - Gradle 8.x prep - specify task dependency between mergeNativeLibs and external native builds
Reviewed By: cipolleschi
Differential Revision: D43501128
fbshipit-source-id: bb40ae902157ce97683f42124ec65f2bc0d73405
Summary:
I'm widening the exclude for GenerateCodegenSchemaTask input files.
This is needed before we can migrate to Gradle 8.x as one of the build warning we have is
now converted to a build failure.
The reason why this is needed is because GenerateCodegenSchemaTask ends up picking up a file that
gets generated by `react-native bundle`. While the file is ignored by the Codegen, Gradle
detects a clash between the two tasks.
This solves the issue completely.
Changelog:
[Internal] [Changed] - RNGP - GenerateCodegenSchemaTask should exclude all of `**/build/[generated|intermediate]**`
Reviewed By: cipolleschi
Differential Revision: D43501129
fbshipit-source-id: 49311b833d6b59d4e67e87c535a424a1db1321e6
Summary:
I've just tested the nightly and the build from source is broken as the `repositories{}` block is missing.
Normally RNGP will take care of setting repositories for everyone, but this is triggered by the app-module.
When building from source, the app module of the user is isolated from the included build of React Native,
therefore the repositories{} definitions are not passed over.
Without this, the build fails with:
```
Cannot resolve external dependency ... because no repositories are defined
```
Changelog:
[Internal] [Changed] - Re-add repositories{} block to allow for build-from-source
Reviewed By: cipolleschi
Differential Revision: D43501011
fbshipit-source-id: b41c56c62839163ad210e7e303940dec0a9001da
Summary:
I noticed this stale directory and snapshot tests for RN-Tester. We might as well just remove them.
## Changelog
[INTERNAL] [REMOVED] - Remove more tvos remnants
Pull Request resolved: https://github.com/facebook/react-native/pull/36240
Test Plan: CI should pass.
Reviewed By: cipolleschi
Differential Revision: D43495264
Pulled By: cortinico
fbshipit-source-id: 7286cf6805e12249db5d71bcaa9a91bc947102ca
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36227
This is needed for the next Gradle major (8.x) and re-aligns us with the
Kotlin version in fbsource
Changelog:
[Android] [Changed] - Kotlin to 1.7.22 for Gradle
allow-large-files
Reviewed By: rybalkinsd
Differential Revision: D43445999
fbshipit-source-id: 85be1bbb4b5ac1664b5090688b688a4e50c3d80a
Summary: Changelog: [Android][Fixed] Resolved bug with Text components in new arch losing text alignment state.
Reviewed By: mdvacca
Differential Revision: D34108943
fbshipit-source-id: 3992e9406345be919b5e3595fc1f9e61cf67a699
Summary:
Simple optimization to exit before iterating through the hit path if the event name doesn't match.
Changelog:
[Android][Internal] - Optimization for natively-driven Animated PointerEvents to early exit during matching in EventAnimationDriverMatchSpec. This should have no effect if you are not using PointerEvents
Reviewed By: lunaleaps
Differential Revision: D43400457
fbshipit-source-id: fe8d811d371c78622cd4f3f9cd469cff9ccce585
Summary:
[Changelog][Internal]
This adds a method, `emitDeviceEvent` to the C++ API of TurboModules, which allows to make calls to JS's `RCTDeviceEventEmitter.emit` from a C++ TurboModules.
This is a very common pattern, specifically for the VR apps, but not only for them - e.g. Desktop fork also has a [custom implementation for this](https://www.internalfb.com/code/fbsource/third-party/microsoft-fork-of-react-native/react-native-utils/RCTEventEmitter.cpp).
Note that my original intent was to actually backport the latter, however there are some complications with wiring things in a robust way, without exposing too much stuff and relying on singletons or folly::dynamic.
So I ended up adding it to the TurboModule API itself and use the scheduler/JSI facilities instead.
This approach is arguably well self-contained, uses high level APIs, and shouldn't be abusable much.
Since I was trying to avoid usage of folly::dynamic in this case, I used a kind of "value factory" pattern instead in order to send the arguments to the JS thread in a thread safe way (see [the discussion here](https://fb.workplace.com/groups/rn.fabric/permalink/1398711453593610/)).
Reviewed By: christophpurrer
Differential Revision: D43466326
fbshipit-source-id: a3cb8359d08a46421559edd0f854772863cb5c39
Summary:
This adds a series of examples for TextInput styles to screenshot test, specifically the ones which are projected to Android as spans. This will be used in refactoring to verify we do not change visual output.
Changelog:
[Internal][Added] - Add "Text Styles" TextInput Example
Reviewed By: cortinico
Differential Revision: D43158004
fbshipit-source-id: adaecf0e37941e66e280db282e2631a95b08b27a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36232
Seems like RN Tester is crashing for JSC debug/release.
This happens because RN Tester ends up fetching JSC from Maven Central which contains older versions
of the artifacts (r17) which are not compatible with our setup AND are missing `libjsc.so`.
This is happening as our file layout is a bit different than a regular NPM project so
the repository declaration for JSC, being `../jsc-android/dist` from React Native root ends
in the wrong folder.
In this specifically I:
- Add an excludeModule for "org.webkit:android-jsc" on Maven Central inside RNGP
- Remove the allproject{repositories{}} block which was overriding RNGP configuration
- Add a specific repository declaration inside RN Tester to point to where JSC effectively lives
Changelog:
[Internal] [Changed] - RNGP - Fix RNTester crashing for JSC and safeguard against fetching JSC from Maven Central
Reviewed By: sshic
Differential Revision: D43462015
fbshipit-source-id: db830d7567bbf7dd91412df417418aa61a0ca8fe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36209
ThisChange automatically enable the RuntimeScheduler when the new architecture is enabled, both on RNester and in the Template app.
Note that no migration steps are required.
## Changelog
[iOS][Changed] - Automatically install the RuntimeScheduler
Reviewed By: sammy-SC
Differential Revision: D43392059
fbshipit-source-id: 609ded9bdc3db13a0d54ff44d0d4687dfc8617a5
Summary:
> [Codegen 85] The parses/flow/components/schema.js and parses/typescript/components/schema.js are the same. Move the schema.js from the one of the two folders to the parsers common root. Delete the other. Update the references to use the shared file.
Part of the Codegen ☂️ Issue https://github.com/facebook/react-native/issues/34872
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - Consolidated the schema.js files for parses/flow/components and parses/typescript/components to a common root.
Pull Request resolved: https://github.com/facebook/react-native/pull/36219
Test Plan: Run ```yarn jest react-native-codegen```
Reviewed By: christophpurrer
Differential Revision: D43444666
Pulled By: cipolleschi
fbshipit-source-id: 24d791fd3a8110730d3f6054497ea3a31549a5a5
Summary:
Callling `getReactApplicationContextIfActiveOrWarn` from `invalidate` will always warn because the context is deactivated, which is preventing us from cleaning up these listeners.
Changelog: [Internal]
Reviewed By: jehartzog
Differential Revision: D43352929
fbshipit-source-id: f29564a290a6c93b2304865d445829f5e486d84f
Summary:
Having custom commit message script is not an option for `main` branch, because we have internal tooling, which strips `[x]` tags from commit messages before merging them into `main` branch.
Instead of constant commit message, we are now using a tag which will be concatenated with the commit message, which was entered via interactive commit dialog, see demo below.
## Changelog
[Internal] - updated validation in bumping packages script
Pull Request resolved: https://github.com/facebook/react-native/pull/36220
Test Plan: https://user-images.githubusercontent.com/28902667/220163767-015bf37b-6914-4df2-84d9-aa25fb2887d3.mov
Reviewed By: cortinico
Differential Revision: D43443597
Pulled By: hoxyq
fbshipit-source-id: 08e5e08524a1d934fbb35529e025358d7bf3b203
Summary:
Relative path in conditional IF in settings.gradle.kts doesn't work when it try to build (`yarn install-android-jsc`) a package that isn't in root dir and needs of react-native-gradle-plugin or when it try to run rn-tester.
When trying to compile rn-tester (`yarn install-android-jsc` command) the error below:
```Shell
arthur@assuncao � ~/projects/react-native-test/react-native/packages/rn-tester � � main � yarn install-android-jsc
yarn run v1.22.19
$ ../../gradlew :packages:rn-tester:android:app:installJscDebug
Starting a Gradle Daemon (subsequent builds will be faster)
FAILURE: Build failed with an exception.
* What went wrong:
Project directory '/home/arthur/projects/react-native-test/react-native/packages/rn-tester' is not part of the build defined by settings file '/home/arthur/projects/react-native-test/react-native/settings.gradle.kts'. If this is an unrelated build, it must have its own settings file.
* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
* Get more help at https://help.gradle.org
BUILD FAILED in 8s
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
```
## Changelog
[INTERNAL] [FIXED] - Fix conditional to include rn-tester and react-native-gradle-plugin in settings.gradle.kts.
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/36188
Test Plan:
Execute rn-tester like [(RN-Tester Readme)](https://github.com/facebook/react-native/blob/main/packages/rn-tester/README.md).
After my changes, the output of `yarn install-android-jsc` is:
```Shell
[... many of the other tasks completed above]
> Task :packages:rn-tester:android:app:compileJscDebugJavaWithJavac
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
> Task :packages:rn-tester:android:app:stripJscDebugDebugSymbols
Unable to strip the following libraries, packaging them as they are: libicu_common.so.
> Task :packages:rn-tester:android:app:installJscDebug
Installing APK 'app-jsc-arm64-v8a-debug.apk' on 'ASUS_Z01KD - 8.0.0' for :packages:rn-tester:android:app:jsc-debug
Installed on 1 device.
BUILD SUCCESSFUL in 31m 53s
121 actionable tasks: 121 executed
Done in 1913.92s.
```
This PR Resolves https://github.com/facebook/react-native/issues/36187
Reviewed By: rshest
Differential Revision: D43393440
Pulled By: cortinico
fbshipit-source-id: 824644aa77147b3747007908db11fe9c120ad92f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36148
This change enables 4 noew tests to make sure that `use_frameworks!` with the New Architecture don't break
Note: We may have to publish the codegen to make this work on CircleCI properly
## Changelog:
[iOS][Added] - Added tests for use_frameworks! with the new architecture
Reviewed By: cortinico, dmytrorykun
Differential Revision: D43271625
fbshipit-source-id: fe1fa4be660f933e0113f44a0467eaa1fa3669ca
Summary:
By leveraging the `PUBLIC_HEADERS_FOLDER_PATH` build settings of Xcode, we can instruct cocoapods to generate the frameworks Headers in a specific folder, for example the `React` folder.
This allows us to maintain the `#include`/`#import` structure, even if the framework has a different name.
However, we need to update the search paths to take into account this extra folder.
## Changelog:
[iOS][Changed] - Generate RCTFabric framework's headers in the React folder
Reviewed By: sammy-SC, dmytrorykun
Differential Revision: D43425677
fbshipit-source-id: 94a4f3a3c7de86341b3ce3457704e6b8fb9a588e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36210
One of the circular dependencies we have in OSS was between React-Codegen and React-Fabric.
React-Codegen generates component which has to depends on React-Fabric because they need to use the files contained in the `react/renderer/view` folder.
React-Fabric contains some components that depends on RNCore, which was generated inside the React-Codegen folder.
This change generates the RNCore components inside the `ReactCommon/react/renderer/components/rncore` folder, breaking the dependency as `rncore` folder is now contained by React-Fabric itself.
**Fun Fact:** That's how it always should have been. There was already a line in the `.gitignore` to exclude the content of `ReactCommon/react/renderer/components/rncore` folder. I guess that with some of the refactoring/previous projects on Codegen, this requirements has slipped.
## Changelog:
[iOS][Breaking] - generates RNCore components inside the ReactCommon folder and create a new pod for platform-specific ImageManager classes
Reviewed By: sammy-SC, dmytrorykun
Differential Revision: D43304641
fbshipit-source-id: ebb5033ce73dbcd03f880c3e204511fdce04b816
Summary:
This diff update the Cocoapods scripts to install the proper dependencies and search paths when `use_frameworks!` is declared together with the New Architecture.
Practically, it adds the right search paths to the codegen and the project files and makes sure that third party dependencies that leverage the `install_modules_dependencies` are populated with the right search paths for Frameworks.
It also adds unit tests for the changes and the new methods introduced.
## Changelog:
[iOS][Changed] - Properly install dependencies with `use_frameworks!`
Reviewed By: sammy-SC, dmytrorykun
Differential Revision: D43089869
fbshipit-source-id: 1981b6853f774fdb3dbe8d17ea37fd5154c54b25
Summary:
Update podspecs with the right search paths to include the required framework by every module.
## Changelog:
[iOS][Changed] - Update search paths to support `use_frameworks!` with Fabric
Reviewed By: sammy-SC, dmytrorykun
Differential Revision: D43089372
fbshipit-source-id: 4bbfc4b98bd289d66ce4015429d581856d9c05b3
Summary:
This change solve a Circular Dependency where
- `React-Core` depends on `ReactCommon` because `RCTAppSetupUtils.h` (in Core) imports the `RCTTurboModuleManager` (from ReactCommon)
- `RCTTurboModuleManager` in `ReactCommon` depends on `React-Core` because it imports several classes from it (e.g. the `RCTBridge` class)
## Changelog:
[iOS][Breaking] - Moved the RCTAppSetupUtils to the AppDelegate library to break a dependency cycle
Reviewed By: sammy-SC, dmytrorykun
Differential Revision: D43089183
fbshipit-source-id: d7fc36a50811962caf7cff77bb45d42b8cdd4575
Summary:
[Changelog][Internal]
A follow-up, based on javache comments on D43398416 (https://github.com/facebook/react-native/commit/9aac13d4dc95925b57f03e7964fc7add6834e518) (post-land) - just some minor potential improvements for locking efficiency.
Reviewed By: javache
Differential Revision: D43438414
fbshipit-source-id: 0cf807a045a1f132d5481d3f6115a97869e93d65
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36217
## Bump minimum Node JS version to 16 via `react-native/package.json#engines`
In https://github.com/facebook/react-native/pull/35443 we stopped running CI in Node 14 - this follows up by formally making Node 16 the minimum supported version ahead of the 0.72 cut.
Node 14 [ends maintenance releases in April](https://github.com/nodejs/release#release-schedule), and bumping this minimum will allow other associated Node JS tools (CLI, Metro, Jest) to reduce their support burden.
## Insert `engines` into `template/package.json`
The constraint at `react-native/package.json#engines` ensures the minimum at install/init time, with package managers providing an actionable error or warning if the constraint is not met. However, it doesn't help guide users to a supported version if on an existing project they run (e.g.) `yarn start`.
Adding a constraint to the template helps prevent accidental use of an older version, as well as providing a clear reference for the current minimum.
Insertion of `engines` below existing `package.json` fields is consistent with [`sort-package-json`](https://github.com/keithamus/sort-package-json/blob/main/defaultRules.md) and [`prettier-package-json`](https://github.com/cameronhunter/prettier-package-json/blob/main/src/defaultOptions.ts) - and keeps it out of the way of fields RN developers are likely to be more concerned about.
## Docs PR
https://github.com/facebook/react-native-website/pull/3580
## Changelog:
[General][Breaking] Bump minimum Node JS version to 16
Reviewed By: jacdebug
Differential Revision: D43436883
fbshipit-source-id: 0b369487fe44fe777e6fedc2299973a5fddd06b2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36208
IMO, there's no value in having `.node-version` files either in the repository or the template.
I don't believe it's standard practice, the support from tooling is patchy (at least `nvm` [ignores it](https://github.com/nvm-sh/nvm/issues/794), and Node is often used without a version manager), and it's unnecessarily restrictive when it is actually enforced. In every other case, it's potentially misleading noise.
Libraries should use `package.json#engines` to specify their Node JS compatibility ranges, as indeed `react-native` [already does](https://github.com/facebook/react-native/blob/1629b9f0a11f42ff12c6dd06a20afb80067e4958/package.json#L10). React Native users may wish to add one to their own projects according to their own setup or team, but we shouldn't confuse the issue by including an arbitrary one in the template.
Changelog:
[General][Removed] Remove `.node_version` from app template.
Reviewed By: jacdebug, blakef
Differential Revision: D43421085
fbshipit-source-id: 37a9b0fb7701f06fffb867dbc7ecac479b4d9c95
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36215
When we introduced the RCTAppDelegate library, we prepared some template methods for the user to customise their views.
However, after they customized their view, we were chaing the background color to match the system background. This would actually override the background color they set in their own customisation step.
This change make sure that we set the background color before they apply their customisations. In this way, we set the background color and, if they want, they can change it and that changw would be honoured.
This change also fixes [this issue](https://github.com/facebook/react-native/issues/35937)
## Changelog
[iOS][Fixed] - Honour background color customisation in RCTAppDelegate
Reviewed By: cortinico
Differential Revision: D43435946
fbshipit-source-id: cdbdbd5b07082ae7843a4dab352dd1195c69e036
Summary:
When building from source, the PrivateReactExtension is getting no defaults (or missing defaults).
Specifically root should point to ../../ (as the build from source will originate
from `./node_modules/react-native`).
Without that root specified, all the subsequent paths are broken,
specifically, the default being `../` causes the codegen to be searched inside:
```
project/node_modules/node_modules/react-native/codegen
```
which is broken
Changelog:
[Internal] [Changed] - RNGP - Fix defaults for PrivateReactExtension
Reviewed By: cipolleschi
Differential Revision: D43435590
fbshipit-source-id: 2ed5e26c1d63fd808fc2d559ea83d6d39d106ff6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36197
[Changelog][Internal]
This turns NativePerformance* module dependencies into "TurboModule plugins", which allows for more streamlined client integration (as it makes them register automatically once the dependency is there).
Reviewed By: rubennorte
Differential Revision: D43353204
fbshipit-source-id: 01d0089750a4873088dc4aefe34fd48693ee9791
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36201
[Changelog][Internal]
Guard call to the C++ ReadableNAtiveMap.importValues with a lock.
Note that all the occurrences in this class (together with importTypes) already were protected by a lock, except of this one, which with the very high chance caused crashes in T145271136.
My corresponding comment from the task, for justification:
> If callstack to be trusted, the crash happens on the C++ side, in ReadableNativeMap::importValues().
It throws ArrayIndexOutOfBoundsException, which, looking at the code, seems to be only possible due to a corrupted data or race conditions.
> Now, looking at the Java side of ReadableNativeMap, and the particular call site... it's very dodgy, since all other occurrences of calling to native importTypes/importValues are guarded by locks, but the one crashing isn't.
NOTE: A couple of `importKeys()` instances appears to suffer from the same problem as well.
Reviewed By: javache
Differential Revision: D43398416
fbshipit-source-id: 0402de5dc723a2fba7d0247c8ad4aeff150d8340
Summary:
changelog: [iOS][Fixed] Fix a crash when reloading JS bundle
Do not crash if self is nil.
Reviewed By: blakef
Differential Revision: D43352039
fbshipit-source-id: dd53677ca152d4021e43ed8d0f1b51c071ca3365
Summary:
This updates all the package usages after the recent bump on main.
## Changelog
[INTERNAL] - Update all package usage on main after a bump
Pull Request resolved: https://github.com/facebook/react-native/pull/36200
Test Plan: Relying on CI
Reviewed By: hoxyq
Differential Revision: D43397084
Pulled By: cortinico
fbshipit-source-id: 06a13772a627f812d7d39931f32071fa3eaa59f9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36192
Builds are failing on CI because brew bails out when it tries installing Python 3.1. The image already has an existing version of Python 3, which we should overwrite.
{F876436464}
This seems to be a known issue [1] with Brew. In this case it seems safe to overwrite.
Changelog:
[General][Changed] - Brew overwrites system Python 3.
[1] https://github.com/actions/setup-python/issues/577#issuecomment-1431468702
Reviewed By: cipolleschi
Differential Revision: D43391941
fbshipit-source-id: 9b0cb234eeb0b7473b17b5ebfa6ed12c6448760f
Summary:
We do have a lot of changes on `main` to ship to nightlies. This change bump all the packages with pending changes.
## Changelog
[INTERNAL] [CHANGED] - [ci][monorepo] bump package versions
Pull Request resolved: https://github.com/facebook/react-native/pull/36184
Test Plan: Will rely on CI run.
Reviewed By: hoxyq
Differential Revision: D43363981
Pulled By: cortinico
fbshipit-source-id: eba5152dbe007eb3fad43f9088d145b3741fd94e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36162
Changelog: [Internal]
Adds a dedicated screen to RNTester to help manually test the handling of various invalid prop values.
Reviewed By: huntie
Differential Revision: D43270626
fbshipit-source-id: 3fbf452955b2caace7a09fbb9c83960703fd974f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36191
Brew commands used to be piped to /dev/null. We weren't able to investigate brew install failures because of this.
# Changelog:
[General][Changed] - log out brew stdout messages in CircleCI
Reviewed By: robhogan, cortinico
Differential Revision: D43389785
fbshipit-source-id: 4dc56125ef5fb87b181ad0b8f9069995ad896812
Summary:
changelog: [internal]
Making a copy of shared_ptr is order of magnitude more expensive than moving it. This diff avoids two redundant copies in commit phase.
Reviewed By: rubennorte, cipolleschi
Differential Revision: D43306245
fbshipit-source-id: cfa942cc67b1e5c91be47803b80f7c8cda2e32d8
Summary:
changelog: [internal]
C++17 has implementation of shared_mutex in standard library. Let's use it instead of folly.
Reviewed By: cipolleschi
Differential Revision: D43275493
fbshipit-source-id: d766251226aa230110011aca94b4e697fe0d31a1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36152
[Changelog][Internal]
By [the W3C standard](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceObserver/observe), `PerformanceObserver.observer` can optionally take a `durationThreshold` option, so that only entries with duration larger than the threshold are reported.
This diff adds support for this on the RN side, as well as unit tests for this feature on the JS side.
NOTE: The standard suggests that default value for this is 104s. I left it at 0 for now, as for the RN use cases t may be to too high (needs discussion).
Reviewed By: rubennorte
Differential Revision: D43154319
fbshipit-source-id: 0f9d435506f48d8e8521e408211347e8391d22fc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36181
[Changelog][Internal]
Implements EventCounts API (`Performance.eventCounts`) for Web Performance, according to the W3C standard, see the specs here: https://www.w3.org/TR/event-timing/#eventcounts
The rationale for why we need it is to support some advanced metrics computations, such as a ratio of "slow events" to total event count, per event type.
Reviewed By: rubennorte
Differential Revision: D43285073
fbshipit-source-id: 2c53d04d9a57c1301e37f2a5879072c8d33efbbf
Summary:
Before this change, the only way to update the offline mirror was to run it on a devmachine
(OD won't work either due to network restriction).
Developer's laptop also won't work as they would download AAPT2 for MacOS.
In the offline mirror instead we need AAPT2 for Linux as that's Sandcastle runner type.
This relaxes this requirement so the next time a developer has to update the offline
mirror they will see the message on the diff with the command to execute, and they should
be able to run the command locally (or on their devbox).
Changelog:
[Internal] [Changed] - Allow for Android offline mirrors to be executed on developer's laptops
allow-large-files
Reviewed By: cipolleschi
Differential Revision: D43344651
fbshipit-source-id: 3e91adb2db45cf94d3f947aaab501d98580dc43d
Summary:
This diff adds new performance API `memory`, which is a read-only property that gets the current JS heap size from native side.
Note that the JSI API returns an unordered map with unknown list of memory information, which is different from the [web spec](https://fburl.com/p0vpbt33). We may enforce specific memory info type on the JSI API so that it can be properly translate to the web spec.
- Update the JS spec
- Update Native implementation and return memory information with JSI API `jsi::instrumentation()::getHeapInfo()`
- Add native performance module to catalyst package
Changelog:
[General][Added] - Add performance memory API with native memory Info
Reviewed By: rubennorte
Differential Revision: D43137071
fbshipit-source-id: 319f1a6ba78fce61e665b00849ecf2579094af83
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36164
Changelog:
[General][Fixed] - Invalid prop values no longer trigger assertion failures in Fabric
## Context
Fabric has historically been very strict about prop parsing. It originally `abort()`ed on any prop value that failed to parse according to the expected type; this was replaced with dev-only assertions in D27540903 (https://github.com/facebook/react-native/commit/cb37562f8355b624e271c5b74416c257b0e62a00). We've received feedback that C++ assertions (and other similar mechanisms in the legacy renderer) are still too aggressive and disruptive as a diagnostic for developers working on JS code.
We are changing React Native to behave more like a browser in this regard, reflecting a new principle that **bad style values are not runtime errors**. (See e.g. D43159284 (https://github.com/facebook/react-native/commit/d6e9891577c81503407adaa85db8f5bf97557db0).) The recommended way for developers to ensure they are passing correct style values is to use a typechecker (TypeScript or Flow) in conjunction with E2E tests and manual spot checks.
More broadly, values passed from JS product code should not be able to crash the app, which is why we're not strictly limiting this change to style props. From now on, if a JS developer can trigger an internal assertion in React Native simply by writing normal application code, that is a bug.
## This diff
This diff introduces a new macro called `react_native_expect` which serves as a drop-in replacement for `react_native_assert`, but logs (to glog / logcat / stdout) instead of asserting. This way we don't need to fully delete the existing call sites. This will be helpful if we decide that we want to repurpose these checks for a new, more visible diagnostic.
I'm *intentionally* opting for the simplest possible improvement here, which is to silence the assertions - not to print them to the JS console, not to convert them to LogBox warnings, etc. The hypothesis is that this is already strictly an improvement over the previous behaviour, will help us get to feature parity between renderers faster, and allow us to design improved diagnostics that are consistent and helpful.
## Next steps
1. There are still places where Fabric can hit an unguarded assertion in prop conversion code (e.g. unchecked casts from `RawValue` with no fallback code path). I will fix those in a separate diff.
2. Paper on iOS needs a similar treatment as it calls `RCTLogError` liberally during prop parsing (resulting in a native redbox experience that is nearly as bad as an outright crash). I will fix that in a separate diff.
3. I'll add some manual test cases to RNTester to cover these scenarios.
4. We will eventually need to take a clear stance on PropTypes, but since they provide reasonable, non-breaking diagnostics (recoverable JS LogBox + component stack) it is less urgent to do so.
Reviewed By: sammy-SC
Differential Revision: D43184380
fbshipit-source-id: 0c921efef297d935a2ae5acc57ff23171356014b
Summary:
This util class was introduced in D42978852 (https://github.com/facebook/react-native/commit/611f9c615ebad7d53c1eb1274fe82e36d915165e), but the Long type was not ported over. Not sure if this was intentional or not, but this is used from return values from DeviceConfig, where number values are encoded as Long types.
Changelog:
[Internal] - internal
Differential Revision: D43323851
fbshipit-source-id: 6a8a27b75b1738f2f87dd56ee814316af323c258
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36160
Changelog:
[Android][Fixed] - Invalid prop values no longer trigger Java exceptions in the legacy renderer
## Context
We are changing React Native to behave more like a browser in the sense that **bad style values are not runtime errors**. (See e.g. D43159284 (https://github.com/facebook/react-native/commit/d6e9891577c81503407adaa85db8f5bf97557db0), D43184380.) The recommended way for developers to ensure they are passing correct style values is to use a typechecker (TypeScript or Flow) in conjunction with E2E tests and manual spot checks.
## This diff
This change is similar to D43184380, but here we target the legacy renderer on Android by (1) replacing exceptions with logging calls, (2) adding fallback values (equivalent to resetting the respective props to `null`) where needed, and (3) replacing `null` checks in `ReactProp` converters with `instanceof` checks.
Leaving the logging call sites in place (as opposed to deleting them) will be helpful if we decide that we want to repurpose these checks for a new, more visible diagnostic (though we would likely only build such a diagnostic in Fabric at this point).
Reviewed By: javache
Differential Revision: D43274525
fbshipit-source-id: 9d1e7ca3b6299dd827e8667e3d542433ec896c0e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36161
Changelog:
[iOS][Fixed] - Invalid prop values no longer trigger redbox in the legacy renderer
## Context
We are changing React Native to behave more like a browser in the sense that **bad style values are not runtime errors**. (See e.g. D43159284 (https://github.com/facebook/react-native/commit/d6e9891577c81503407adaa85db8f5bf97557db0), D43184380.) The recommended way for developers to ensure they are passing correct style values is to use a typechecker (TypeScript or Flow) in conjunction with E2E tests and manual spot checks.
## This diff
This change is similar to D43184380, but here we target the legacy renderer on iOS by removing the redboxes from most of `RCTConvert`'s methods.
I'm intentionally going with the simplest possible improvement which is to downgrade the redboxes to `RCTLogInfo` ( = log to stdout but not the JS console). Leaving the call sites in place (as opposed to deleting them) will be helpful if we decide that we want to repurpose these checks for a new, more visible diagnostic (though we would likely only build such a diagnostic in Fabric at this point).
Reviewed By: javache
Differential Revision: D43184379
fbshipit-source-id: 5a3d12f5d884372c7dc8743227d58d403caf24e3
Summary:
`setComponentDescriptorProviderRequest` is only used on iOS for dynamic registration of additional components. This variable is not default initialized, so will point to invalid memory when a component is missing and thus crash.
Changelog: [Internal] Fix Android crash when component is missing
Reviewed By: rubennorte
Differential Revision: D43305656
fbshipit-source-id: 70dd2973d50abbfcc19e051bd24c1deb90883941
Summary:
This page is not up to date anymore:
https://reactnative.dev/contributing/how-to-build-from-source
I'm pushing those changes to make it easier to consume our build when building from source.
I'll update the page those change lands.
## Changelog
[Internal] [Changed] - Make it easier for users to build from source if needed
Pull Request resolved: https://github.com/facebook/react-native/pull/36165
Test Plan: If the CI is green, we should be good to merge this
Reviewed By: cipolleschi
Differential Revision: D43303867
Pulled By: cortinico
fbshipit-source-id: c0080b06cbcbf872ee92fcfa82a9f823d5b247f4
Summary:
The `rrc_root` was not exposed via prefab. I'm adding it to make possible for Reanimated to integrate on top of React Native via prefab. Based on https://github.com/facebook/react-native/issues/35643.
## Changelog
[ANDROID] [CHANGED] - Expose `rrc_root` via prefab.
Pull Request resolved: https://github.com/facebook/react-native/pull/36166
Reviewed By: cipolleschi
Differential Revision: D43304302
Pulled By: cortinico
fbshipit-source-id: 1c4a7013a33b48a8a7a445a78430630542420f4d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36116
[Changelog][Internal]
Add a minimal/reference JavaScript implementation for NativePerformanceObserver - the purpose is both unit testing (JS and native sides separately) and potentially shimming the part of functionality that is not dependent on native side.
This is both a setup for adding general unit tests for the Performance* APIs, but also to be able to do non-trivial changes on JS side for WebPerformance (such as in (D43154319).
Reviewed By: rubennorte
Differential Revision: D43167392
fbshipit-source-id: 213d9534d810dece1dd464f910e92e08dbf39508
Summary:
`xcpretty` is no longer maintained. Let's switch to `xcbeautify`, which is faster and is maintained. I'm also biased because `xcpretty` hid an error from me that `xcbeautify` did not.
## Changelog
[INTERNAL] [CHANGED] - Move CI from `xcpretty` to `xcbeautify`
Pull Request resolved: https://github.com/facebook/react-native/pull/36131
Test Plan:
Locally yarn `yarn test-ios` and got output that looks like this:
<img width="1245" alt="Screenshot 2023-02-11 at 9 34 07 PM" src="https://user-images.githubusercontent.com/6722175/218291538-07760f94-7e52-4919-b603-8a35a623fc9a.png">
I also confirmed a junit report that looks like this was generated:
```xml
<testsuites name="Selected tests" tests="193" failures="0">
<testsuite name="RCTLoggingTests" tests="1" failures="0">
<testcase classname="RCTLoggingTests" name="testLogging" time="0.175" />
</testsuite>
<testsuite name="RCTUIManagerScenarioTests" tests="3" failures="0">
<testcase classname="RCTUIManagerScenarioTests" name="testManagingChildrenToAddRemoveAndMove" time="0.001" />
<testcase classname="RCTUIManagerScenarioTests" name="testManagingChildrenToAddViews" time="0.000" />
<testcase classname="RCTUIManagerScenarioTests" name="testManagingChildrenToRemoveViews" time="0.001" />
</testsuite>
...
```
Reviewed By: cortinico
Differential Revision: D43232774
Pulled By: cipolleschi
fbshipit-source-id: fda4e217d4df55b5088026d6911d3dc6c8c9e824
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36158
To properly setup the Header Search Paths for `use_frameworks!`, we need to move the files that are in the `.../textlayoutmanager/platform/ios` folder into the `.../textlayoutmanager/platform/ios/react/renderer/textlayoutmanager` folder.
This mimic the same folder structure we have also `android`
## Changelog
[iOS][Changed] Moved the files from `.../textlayoutmanager/platform/ios` to `.../textlayoutmanager/platform/ios/react/renderer/textlayoutmanager`
Reviewed By: cortinico
Differential Revision: D43088586
fbshipit-source-id: 9589fe62f36fbff2744fdfbf3475e95954424232
Summary:
To properly setup the Header Search Paths for `use_frameworks!`, we need to move the files that are in the `.../imagemanager/platform/ios` folder into the `.../imagemanager/platform/ios/react/renderer/imagemanager` folder.
This mimic the same folder structure we have also `android`
## Changelog
[iOS][Changed] Moved the files from `.../imagemanager/platform/ios` to `.../imagemanager/platform/ios/react/renderer/imagemanager`
Reviewed By: cortinico
Differential Revision: D43088421
fbshipit-source-id: c3b86a95e67cc1ab9531997bb1bfbf011b7f730f
Summary:
To properly setup the Header Search Paths for `use_frameworks!`, we need to move the files that are in the `.../textinput/iostextinput` folder into the `.../textinput/iostextinput/react/renderer/components/iostextinput` folder.
This mimic the same folder structure we have also `android`
## Changelog
[iOS][Changed] Moved the files from `.../textinput/iostextinput` to `.../textinput/iostextinput/react/renderer/components/iostextinput`
Reviewed By: cortinico
Differential Revision: D43084639
fbshipit-source-id: fe0f55d9f372bda0fbd59c6c567ac747ca308a69
Summary:
To properly setup the Header Search Paths for `use_frameworks!`, we need to move the files that are in the `.../nativemodule/xxx/platform/ios` folder into the `.../nativemodule/xxx/platform/ios/ReactCommon` folder.
We have two folders to migrate: `core` and `sample`.
As a cleanup, `sample` should be extracted from the codebase and moved to RNTester or a library as it can be used as an example to add more examples in the codebase that we ship to our users.
This mimic the same folder structure we have also in `cxx` and `android`
## Changelog
[iOS][Changed] Moved the files from `.../nativemodule/xxx/platform/ios` to `.../nativemodule/xxx/platform/ios/ReactCommon`
Reviewed By: cortinico
Differential Revision: D43082851
fbshipit-source-id: 414426274d9a5ab20cc0e76cdada0c2977264b5f
Summary:
To Properly setup the Header Search Paths for `use_frameworks!`, we need to move the files that are in the `react/renderer/graphics/platform/ios` folder into the `react/renderer/graphics/platform/ios/react/renderer/graphics` folder.
This mimic the same folder structure we have also in `cxx` and `android`
## Changelog:
[iOS][Changed] - Moved the files from `.../platform/ios` to `.../platform/ios/react/renderer/graphics`
Reviewed By: sshic
Differential Revision: D43082032
fbshipit-source-id: 519d2e12eb7edd50b5f71bac5b1c618c6bf89919
Summary:
This diff adds `TraceUpdateOverlay` native component to RN `AppContainer.js`. This will enable the overlay when the build is in DEV environment and the DevTools global hook exists. It also closed gap between the JS dev mode and native dev support flag, so that the native component will be available when used by JS.
## Update (2/13/2023)
Instead of the original approach where I put a default value to the devsupport manager flag, I did ui manager check from JS and make sure the native component exists before using it. This is cleaner.
## Problem
Since the `AppContainer` is being used by all RN apps, we need to make sure the native component is registered in UI Manager of the RN app when it's used. Currently, the native component lives in the `DebugCorePackage.java`, which is added to the RN app [when the `DevSupportManager` is used](https://fburl.com/code/muqmqbsa). However, there's no way to tell if an app is using dev support manager in JS, hence there are gaps when the JS code uses `TraceUpdateOverlay`, vs when the native code registered the native component. This issue caused test error in [ReactNativePerfTest](https://fburl.com/testinfra/j24wzh46) from the [previous diff](https://fburl.com/diff/bv9ckhm7), and it actually prevents Flipper from running this properly as shown in this video:
https://pxl.cl/2sqKf
The errors shown in Flipper indicates the RN surface from the plugin is also missing `TraceUpdateOverlay` in its UI Manager:
{F869168865}
## Solution
To fix this issue, we should find a way to expose if the app is using dev support manager in JS. Or we should set to use DevSupportManager whenever it's a dev build as claimed in JS. I will try to find some way to achieve either one of this. I am open to suggestions here for where I should add the native component to. Given that it's used in the AppContainer, and any app could be built in development mode, I don't want to make people to manually add this native component themselves.
## Alternatives
There are some other approaches that could mitigate the issue, but less ideal:
For the test issue
1) Add `setUseDeveloperSupport(true)` to [ReactNativeTestRule.java](https://fburl.com/code/7jaoamdp). That will make the related test pass by using the DevSupportPackages, which has the native component. However, it only fixes tests using that class.
2) Override the package for [ReactNativeTestRule.java](https://fburl.com/code/b4em32fa), or `addPackage` with more packages including the native component. Again this only fixes this test.
3) Add the native component to the [`MainReactPackage`](https://fburl.com/code/nlayho86), which is what I did here in this diff. This would fix more cases as this package is [recommended to be used](https://fburl.com/code/53eweuoh) for all RN app. However, it may not fix all the cases if the RN app didn't manually use it.
4) Add the native component in the [`CoreModulesPackage`](https://fburl.com/code/lfeklztl), which will make all RN apps work, but at the cost of increase package size when this feature is not needed. Or, we could argue that we want to have highlights on trace updates for production build as well?
Changelog:
[Internal] - Enable TraceUpdateOverlay to RN AppContainer
Reviewed By: rubennorte
Differential Revision: D43180893
fbshipit-source-id: a1530cc6e2a9d8c905bdfe5d622d85c4712266f8
Summary:
There are two different ways of getting the ReactModuleInfoProvider from LazyReactPackage:
1. static LazyReactPackage.getReactModuleInfoProviderViaReflection(LazyReactPackage)
2. LazyReactPackage.getReactModuleInfoProvider()
The first way calls into codegen that only works within Meta's infra. This code-path is *now* dead. Therefore, this diff deprecates the first path, to make LazyReactPackage less confusing.
This diff simplifies the implementation to return an empty ReactModuleInfoProvider for the v0.72 cut.
In the v0.73 cut, we'll just outright delete this method.
Changelog: [Android][Changed] - Deprecate LazyReactPackage.getReactModuleInfoProviderViaReflection()
Reviewed By: sshic
Differential Revision: D43066800
fbshipit-source-id: 2145c3265ff2bd24e6828b193577ba1f500bce49
Summary:
This diff pays the duty in T126215968 where we should move the util methods to a shareable place. ~~I cannot find a good util namespace so I created on under `com.facebook.react.panelapp`.~~ This lives under `com.facebook.react.bridge` next to the `Arguments` class.
- Create ~~`ReadableDataParser.java`~~ `JSONArguments.java`
- Reuse in multiple places within `react-panellib`
Changelog:
[Internal] - Code refactor on JSON and ReadableMap conversion
Reviewed By: javache
Differential Revision: D42978852
fbshipit-source-id: e00a5c4cefcf6114d9a5d947cb00e3ff7f0dccaa
Summary:
currently, using TS, this is a valid import:
`import { EventEmitter } from 'react-native';`
However, looking at the [index file](https://github.com/facebook/react-native/blob/main/index.js) we can see that there is no such export.
I first thought I'd add the EventEmitter export in order to get the `index.js` in line with the types, but it appears that the Event Emitter will become a separate package at some point https://github.com/facebook/react-native/pull/34401 so removing it from the types seems to be better for future.
## Changelog
fix: remove unavailable EventEmitter TS export
Pick one each for the category and type tags:
[INTERNAL] [CHANGED] - remove unavailable EventEmitter TS export
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/36109
Test Plan: tested locally: using `import { EventEmitter } from 'react-native';` correctly gives `TS2305: Module '"react-native"' has no exported member 'EventEmitter'.`
Reviewed By: javache, cortinico
Differential Revision: D43155568
Pulled By: NickGerleman
fbshipit-source-id: b9e8c3f4be9812637c8588d14a9ce4edf188ed36
Summary:
This removes the null-check on Yoga config added (we think we root-caused the issue), and adds an assertion to the public API accepting a config that it is non-null.
There are more changes to config setting that will come later.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D43273456
fbshipit-source-id: cba498352d114a3fa2694f3a144f5f01a83d3190
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36146
Changelog: [Internal]
- While working on 0.71.3, it was discovered that `react-native-codegen` package is being published almost empty (without `lib` folder)
- The reason for it is that `prepare` script is not being executed
- The main reason for it is npm v6, which requires adding `unsafe-perm` flag for it: https://www.vinayraghu.com/blog/npm-unsafe-perm
- Instead of using this flag, changing executor to `nodelts`, which has node v18 and npm v8
- Also adding `run_yarn` before running the script, because `react-native/codegen` uses external dependencies (such as rimraf) for its build scripts
Reviewed By: cipolleschi
Differential Revision: D43248175
fbshipit-source-id: d12b93decbf408713e309fe8be75d8d5ec994868
Summary:
When the node version could not be found there is an error message shown to help what can be done to fix this issue (for example in the error logs in xcode)
The problem was that the backtick symbol is interpreted as running commands in terminals so the parts that were in backticks were run and the error message was printed incompletely. Also there were other errors added (.xcode.env command not found, for example) which makes it harder to understand what is going on.
In bash / zsh single quotes does not expand commands and variables unlike double quotes which does this.
## Changelog
[IOS] [FIXED] - Fix missing node error message not printed correctly when deprecated `find-node-for-xcode.sh` is used.
Pull Request resolved: https://github.com/facebook/react-native/pull/36140
Test Plan:
I just ran the xcode build again after updating it manually in the node_modules folder.
The log output changed from this
```
[Warning] You need to configure your node path in the environment. You can set it up quickly by running: echo 'export NODE_BINARY=/Users/uloco/Library/Caches/fnm_multishells/78434_1676301546457/bin/node' > .xcode.env in the ios folder. This is needed by React Native to work correctly. We fallback to the DEPRECATED behavior of finding . This will be REMOVED in a future version. You can read more about this here: https://reactnative.dev/docs/environment-setup#optional-configuring-your-environment
```
to this
```
[Warning] You need to configure your node path in the `".xcode.env" file` environment. You can set it up quickly by running: `echo export NODE_BINARY=$(command -v node) > .xcode.env` in the ios folder. This is needed by React Native to work correctly. We fallback to the DEPRECATED behavior of finding `node`. This will be REMOVED in a future version. You can read more about this here: https://reactnative.dev/docs/environment-setup#optional-configuring-your-environment
```
Reviewed By: cortinico, cipolleschi
Differential Revision: D43258623
Pulled By: rshest
fbshipit-source-id: 7db0d983b204e59504666686be78311c4c2fb993
Summary:
Adds changelog for new patch.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - add changelog entry for 0.71.3
Pull Request resolved: https://github.com/facebook/react-native/pull/36149
Test Plan: N/A
Reviewed By: dmytrorykun
Differential Revision: D43272716
Pulled By: cipolleschi
fbshipit-source-id: 58ca3f598aa6a23092902ab6317b01d6915e74e9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36143
Changelog: [Internal]
Currently, some `__tests__` are included in `react-native/virtualized-lists`, added them to ignore list, so that we will remove it in the next publish
Reviewed By: christophpurrer
Differential Revision: D43159337
fbshipit-source-id: 27ed0adf85387a2e8ac902da57888f0b188b0b91
Summary:
This diff adds `TraceUpdateOverlay` native component to render highlights when trace update is detected from React JS. This allows a highlight border to be rendered outside of the component with re-renders.
- Created `TraceUpdateOverlay` native component and added to the `DebugCorePackage`
- Added to C++ registry so it's compatible with Fabric
- Added to `AppContainer` for all RN apps when global devtools hook is available
Changelog:
[Android][Internal] - Add trace update overlay to show re-render highlights
Reviewed By: javache
Differential Revision: D42831719
fbshipit-source-id: 30c2e24859a316c27700270087a0d7779d7ad8ed
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36030
Generate enum types in c++ turbo modules.
For enums in the ts schema file such as:
```
export enum NumEnum {
ONE = 1,
TWO = 2,
}
```
This would export enums and the relevant Bridging to js and from js code to the spec H files such as:
```
#pragma mark - SampleTurboModuleCxxNumEnum
enum SampleTurboModuleCxxNumEnum { ONE, TWO };
template <>
struct Bridging<SampleTurboModuleCxxNumEnum> {
static SampleTurboModuleCxxNumEnum fromJs(jsi::Runtime &rt, int32_t value) {
if (value == 1) {
return SampleTurboModuleCxxNumEnum::ONE;
} else if (value == 2) {
return SampleTurboModuleCxxNumEnum::TWO;
} else {
throw jsi::JSError(rt, "No appropriate enum member found for value");
}
}
static jsi::Value toJs(jsi::Runtime &rt, SampleTurboModuleCxxNumEnum value) {
if (value == SampleTurboModuleCxxNumEnum::ONE) {
return bridging::toJs(rt, 1);
} else if (value == SampleTurboModuleCxxNumEnum::TWO) {
return bridging::toJs(rt, 2);
} else {
throw jsi::JSError(rt, "No appropriate enum member found for enum value");
}
}
};
```
That code would allow us to use these enums in the cxx files like this:
```
NativeCxxModuleExampleCxxEnumInt getNumEnum(
jsi::Runtime &rt,
NativeCxxModuleExampleCxxEnumInt arg);
```
Changelog: [General] [Added] Generate enum types that would be allowed to be used as well as string/number in c++ turbo modules generators
Reviewed By: christophpurrer
Differential Revision: D42884147
fbshipit-source-id: d34d1fc7ba268b570821dc108444196f69a431b2
Summary: Changelog: [Internal] - Ensure pointer move tracking is applied to movement while the pointer is pressed
Reviewed By: javache
Differential Revision: D42977052
fbshipit-source-id: 2d48c35a908449d0b2338c33273fb75a430bc393
Summary:
Hi 👋
I'm one of the Expo contributors. When upgrading the Stripe dependency in Expo for SDK48 release on Android, we noticed the following error:
```java.lang.ClassCastException: android.view.ContextThemeWrapper cannot be cast to android.app.Activity```
With Kudo we narrowed it down to an underlying issue in the following cast in `ReactRootView` done during checking for keyboard events:
```((Activity) getContext())```
The `getContext()` is actually a `ContextThemeWrapper` for `ExperienceActivity`, so we should not cast it to an `Activity` directly - instead, we unwrap it using `getBaseContext()`.
Implementing the following fix into the Expo fork fixed the crash for us:
https://github.com/expo/react-native/commit/0e2c9cada120a3709e8285ab4bcdaa1c5c446732
## Changelog
[ANDROID] [FIXED] - Fixed crash occurring in certain native views when handling keyboard events.
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/36121
Test Plan:
Tested manually by comparing two builds before and after this change. The main branch build crashes when the [Stripe 0.23.1](https://github.com/stripe/stripe-react-native) Card Element from the example app is mounted on screen. Applying the change fixed the issue.
Happy to make a more isolated reproduction if necessary.
---
Full stack trace:
```
AndroidRuntime D Shutting down VM
E FATAL EXCEPTION: main
E Process: host.exp.exponent, PID: 8849
E java.lang.ClassCastException: android.view.ContextThemeWrapper cannot be cast to android.app.Activity
E at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.checkForKeyboardEvents(ReactRootView.java:937)
E at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.onGlobalLayout(ReactRootView.java:913)
E at android.view.ViewTreeObserver.dispatchOnGlobalLayout(ViewTreeObserver.java:1061)
E at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:3352)
E at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:2286)
E at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:8948)
E at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1231)
E at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1239)
E at android.view.Choreographer.doCallbacks(Choreographer.java:899)
E at android.view.Choreographer.doFrame(Choreographer.java:832)
E at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1214)
E at android.os.Handler.handleCallback(Handler.java:942)
E at android.os.Handler.dispatchMessage(Handler.java:99)
E at android.os.Looper.loopOnce(Looper.java:201)
E at android.os.Looper.loop(Looper.java:288)
E at android.app.ActivityThread.main(ActivityThread.java:7898)
E at java.lang.reflect.Method.invoke(Native Method)
E at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
E at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:936)
```
Reviewed By: cortinico
Differential Revision: D43186530
Pulled By: javache
fbshipit-source-id: 2143495f6b0c71f342eba6d5abb2bfa4a529fbdd
Summary:
This diff upgrade dependencies to `react-devtools-core` to 4.27.2, which includes changes I need to unblock trace update highlights.
- Update package.json file for dependencies in all existing deps with latest version (4.26.1): https://fburl.com/code/litgze0m
- Run `yarn` under `xplat/js` and `xplat/js/public`
Changelog:
[General][Internal] - Upgrade react-devtools-core to 4.27.2
Reviewed By: javache
Differential Revision: D43176345
fbshipit-source-id: 8bd5a9eca286bbfbb1630cb92c15f9653fa3534a
Summary:
[Changelog][Internal]
`NativePerformanceObserver` TurboModule API would get the type for performance entries as strings in one direction (`start/stopReporting`) and as integers in another direction (inside `RawPerformanceEntry`, for optimization on the native side).
This makes is symmetrical and consistent, all the conversions are now handled on the JS side.
Reviewed By: christophpurrer
Differential Revision: D43236466
fbshipit-source-id: 08e1b62df90e6d26a11577d6b6b1d91a6bce8339
Summary:
This annotation is missing it's retention policy which should be `SOURCE` as it's an IntDef and not used at runtime.
Changelog:
[Internal] [Changed] - Add missing retention policy on EventCategoryDef annotation
Created from CodeHub with https://fburl.com/edit-in-codehub
Reviewed By: cipolleschi
Differential Revision: D43187398
fbshipit-source-id: d00bc3a5cf74d2eb983fa7369905e2260db80142
Summary:
Our stale bot is at capacity and reaches quota, resulting in marking as stale 2/3 issues a day.
I'm increasing the frequency of the bot to 4 times a day.
## Changelog
Changelog:
[Internal] [Changed] - Stale issues more frequently (4 times a day)
Pull Request resolved: https://github.com/facebook/react-native/pull/36130
Test Plan: nothing to test
Reviewed By: cipolleschi
Differential Revision: D43207979
Pulled By: cortinico
fbshipit-source-id: 1de45315e724ddf9afdb9426eddc639875ba0b24
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36137
This change stabilize the build for Hermes in CI, making it more robust in case the rename step fails or the wrong params are passed to hermes.
## Changelog:
[internal] - Update Hermes build logic
Reviewed By: cortinico
Differential Revision: D43232941
fbshipit-source-id: 1121716c69dd3ca247ffeaed57e0d4dfd5daca84
Summary:
Our first party modules are still using `namespace`. This cleans this up.
The Manifest file for ReactAndroid is also not needed anymore. The one
from hermes-engine can also be removed from facebook/hermes in a separate diff.
Changelog:
[Internal] [Changed] - Use namespace for ReactAndroid and hermes-engine
Reviewed By: cipolleschi
Differential Revision: D43198514
fbshipit-source-id: d988cfa81ecc4484b6b2add4ae2c1d9376febc3e
Summary:
Add minimum necessary .d.ts files to react-native-codegen.
I found .d.ts files will be copied to `lib` so I guess no additional script is needed.
## Changelog
[GENERAL] [CHANGED] - Add minimum necessary .d.ts files to react-native-codegen
Pull Request resolved: https://github.com/facebook/react-native/pull/36102
Test Plan: `npm run build` in `packages/react-native-codegen` and see all .d.ts files appear in `lib`.
Reviewed By: cortinico
Differential Revision: D43157233
Pulled By: cipolleschi
fbshipit-source-id: 6f122f0f4cda693ba22af6dd534e9d34d069ecac
Summary:
See code comment. D42282358 (https://github.com/facebook/react-native/commit/e55277c3310d8f6b712a57f80589cfe91ed35553) added usage of `YGConfigIsExperimentalFeatureEnabled` during layout, in a place where we sometimes encounter a Yoga node from RN which has an unexpectedly null config.
This is a hack to stop the bleed while we add logging to figure out where the null config is coming from in RN.
Changelog: [Internal]
Reviewed By: rozele
Differential Revision: D43203521
fbshipit-source-id: 2a21143a45c712ca00d16172f734fb116d165926
Summary:
After a [change](https://github.com/facebook/hermes/commit/4ff7c31fb43f534947cca591e1f156d8c45aef9c) that landed on Hermes, the build script for Hermes generated an invalid dSYM name for Catalyst builds, which make our CI fail.
This PR aims to patch it while the Hermes team works on a long term fix for it.
The CI will go back to red as soon as that happen, but in that case, we will just need to revert this change. But, at least, we can go back to a green state for CircleCI.
## Changelog
[Internal] - update Hermes build script to be more resilient from dSYM names
Pull Request resolved: https://github.com/facebook/react-native/pull/36126
Test Plan: CircleCI is green
Reviewed By: cortinico
Differential Revision: D43193705
Pulled By: cipolleschi
fbshipit-source-id: a349dde8556564dacf4852f050610ae59139ffd8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36128
This commit fixes a problem which is making harder to use the New Architecture in monorepos.
Specifically if a user specifies a `codegenDir` in their app, libraries should honor it.
This is not the case today.
The fix is to register an extension on the root project which will "pass" values from app
to libraries.
I've also cleaned up some of the logic in `readPackageJsonFile` function restricting
the access to those functions only to `.root` which is the only field they're accessing.
Fixes#35495
Changelog:
[Android] [Fixed] - Better Monorepo support for New Architecture
Reviewed By: cipolleschi
Differential Revision: D43186767
fbshipit-source-id: 5c5ca39397306120b6b6622cb728633bd331e021
Summary:
In our build logic we're mixing `plugins{}` and `buildscript{}`
which have unpredictable side-effect on the build classpath.
I'm moving over everything to use `plugins{}`. This is possible now
that we don't use build from source for New Architecture anymore.
Changelog:
[Internal] [Changed] - Do not use a mixture of plugins{} and buildscript{}
allow-large-files
Reviewed By: cipolleschi
Differential Revision: D43186768
fbshipit-source-id: dcd115bd9d7aadf5cb837b3a28598e274a092873
Summary:
changelog: [internal]
There was a bug in prop parsing where `accessibilityRole` and `accessibilityTraits` had wrong default value. Instead of falling back to sourceProps, they would set role to empty and trait to none. The fix is to fall back to sourceProps.
The issue surfaces with Animated, which clones props.
Reviewed By: cipolleschi
Differential Revision: D43190775
fbshipit-source-id: ec6b48c082c1dcc5b6e81dbff4f92b3a58a41da2
Summary:
Changelog:
[Internal] [Changed] - Remove unused variable in a test in RNGP
Created from CodeHub with https://fburl.com/edit-in-codehub
Reviewed By: cipolleschi
Differential Revision: D43185910
fbshipit-source-id: b1f328592e0b38654fd2e0a36304ce8f1d433b44
Summary:
When working on Dynamic Type, I accidentally referred to it as "Dynamic Text" in some of the documentation. This is just a minor cleanup bit.
## Changelog
[IOS] [FIXED] - Fix typo in documentation
Pull Request resolved: https://github.com/facebook/react-native/pull/36113
Test Plan: Non-functional change, no testing should be needed :-)
Reviewed By: javache
Differential Revision: D43184999
Pulled By: cortinico
fbshipit-source-id: ed057e48289ae6037637bacecb20b8dd58c1d8b5
Summary:
Fix typo in the initialNumToRenderOrDefault description's comment : function's parameter should be this.props.initialNumToRender instead of this.props.initialNumToRenderOrDefault
## Changelog
[GENERAL] [FIXED] - Fixed typo in the initialNumToRenderOrDefault description's comment
Pull Request resolved: https://github.com/facebook/react-native/pull/36110
Test Plan: Typo in a comment - no testing required
Reviewed By: christophpurrer
Differential Revision: D43160548
Pulled By: cortinico
fbshipit-source-id: 0555c7752102f431fb327b920434faaf4de4ff81
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36107
Having concurrentRoot disabled when Fabric is enabled is not recommended.
This simplifies the setup and makes sure that both are either enabled or disabled.
Changelog:
[Android] [Breaking] - Hardcode concurrentRootEnabled to true when Fabric is enabled
Reviewed By: cipolleschi
Differential Revision: D43127625
fbshipit-source-id: 88e5e800b55d5df228fb072bedf8533b0ab6c20d
Summary:
Changelog: [Internal] Replace assert calls with RCTAssert in RCTSurfaceTouchHandler
We've been recieving crash report tasks related to these calls but it appears (based on D19221204 (https://github.com/facebook/react-native/commit/23d2a6248c9ce1e3b969e3b8fae0ae43c549db93)) that the expectation was that these should be stripped in production and don't cause real problems. RCTAssert does not have that same issue.
Reviewed By: fkgozali
Differential Revision: D43167817
fbshipit-source-id: 45b1b4a3060cfd1e01356c003d63fa4b91c4222a
Summary:
I encountered build error when using performance API in catalyst android mobile app. The error message P617433618 points at using non-const `std::strlen` API in a `constexpr`.
```
$ buck install catalyst-android
...
stderr: xplat/js/react-native-github/Libraries/WebPerformance/PerformanceEntryReporter.cpp:208:13: error: constexpr constructor never produces a constant expression [-Winvalid-constexpr]
constexpr StrKey(const char *s)
^
xplat/js/react-native-github/Libraries/WebPerformance/PerformanceEntryReporter.cpp:209:39: note: non-constexpr function 'strlen' cannot be used in a constant expression
: key(folly::hash::fnv32_buf(s, std::strlen(s))) {}
```
Changelog:
[General][Fixed] - Fixed string key calculation in constexpr from Performance C++ native module.
Reviewed By: javache
Differential Revision: D43136624
fbshipit-source-id: c691671b157b507745c67a505c91f75cf6b878d1
Summary:
Changelog:
[iOS][Fixed] - Unrecognized fontFamily values no longer trigger a redbox
## Context
We are starting to roll out a new consistent approach to style errors in React Native, where malformed or semantically invalid style values will never be treated as runtime errors. Instead, bad style values will consistently fall back to known defaults; the incorrect visual rendering will serve as the main runtime diagnostic for developers. We will advise developers to rely on static types for additional diagnostics.
This work will take place over multiple commits and possibly multiple releases of React Native.
## This diff
Here we fix this issue as it applies to the `fontFamily` style prop. The legacy (Paper) renderer on iOS is the only concrete implementation that had to change. Fabric and Android already implement the correct behaviour.
h/t EvanBacon for the report: https://twitter.com/Baconbrix/status/1623039650775371792
Reviewed By: huntie
Differential Revision: D43159284
fbshipit-source-id: 6afeef3abc5781e18671708f642073d25f2347e9
Summary:
D42721684 (https://github.com/facebook/react-native/commit/be69c8b5a77ae60cced1b2af64e48b90d9955be5) left a pretty bad bug when using Fabric for Android. I missed that in Fabric specifically, on edit we will cache the Spannable backing the EditText for use in future measurement.
Because we've stripped the sizing spans, Spannable measurement has incorrect font size, and the TextInput size will change (collapsing) after the first edit. This effectively breaks any uncontrolled TextInput which does not have explicit dimensions set.
Changelog:
[Android][Fixed] - Fix measurement of uncontrolled TextInput after edit
Reviewed By: sammy-SC
Differential Revision: D43158407
fbshipit-source-id: 51602eab06c9a50e2b60ef0ed87bdb4df025e51e
Summary:
This adds the `DOMRect` and `DOMRectReadOnly` classes to React Native, mostly following the Web spec.
This is a requirement for `node.getBoundingClientRect()`, which we'll implement in React (in https://github.com/facebook/react/blob/main/packages/react-native-renderer/src/ReactFabricHostConfig.js#L134-L323).
Changelog: [General][Added] - Added Web-compatible `DOMRect` and `DOMRectReadOnly` classes to the global scope.
Reviewed By: ryancat
Differential Revision: D42963222
fbshipit-source-id: bf2ed15bfbfd71822cb6f969f8cc0a67c7834333
Summary:
This declares a few globals that were missing in our `global.js` Flow declaration file:
* `process`
* `performance` with its current definition. We'll replace it with the new API when we replace `setupPerformance` with `setupWebPerformance`.
* `navigator`
* `setImmediate`
* `clearImmediate`
Eventually we should stop including all DOM definitions that Flow provides out of the box and define only what we provide (which is pretty much this file).
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D42964772
fbshipit-source-id: 6156968e8a9d193e7068d8a5043aa682ad45bba1
Summary:
This test is flaky on Windows only on CI, so I'm disabling it as we cover this
test already on other platforms.
Changelog:
[Internal] [Changed] - Disable a /Libraries/Pressability test on Windows only
Reviewed By: yungsters
Differential Revision: D43153475
fbshipit-source-id: 861a31fbbf3c14f2af95ca3ffd40737ef975048b
Summary:
This mitigates some of the failures we're seeing inside the docker containers
where we're receiving 50x when trying to download native sources.
Changelog:
[Internal] [Changed] - Setup retries on Gradle donwload tasks
Reviewed By: cipolleschi
Differential Revision: D43155926
fbshipit-source-id: fa2266b3f5de48faefad37d6239f54f13481cd5f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36106
Having `concurrentRoot` disabled when Fabric is enabled is not recommended.
This simplifies the setup and makes sure that both are either enabled or disabled.
## Changelog:
[iOS] [Breaking] - Hardcode concurrentRootEnabled to `true` when Fabric is enabled
Reviewed By: cortinico
Differential Revision: D43153402
fbshipit-source-id: d67aeb3413dbdf2430381aa44ede47ed00db32c6
Summary:
Fixes https://github.com/facebook/react-native/issues/36097
When building RNTester with the old architecture, we skip a call to `build_codegen`, which will build the JS package at `packages/react-native-codegen`. This is needed for the Xcode Script phase `Generate Specs`. This causes a build with fabric disabled to fail. We can fix this by ensuring we call `build_codegen` in both paper and fabric.
We've had this change in React Native macOS already since 0.68: https://github.com/microsoft/react-native-macos/commit/1175372ffecf6b4e18fa27b75b68f3ec7967a384
## Changelog
[IOS] [FIXED] - Build codegen package while using old architecture
Pull Request resolved: https://github.com/facebook/react-native/pull/36098
Test Plan:
CI should suffice. Locally built RN-Tester without fabric with and without my change to show that disabling fabric will only succeed with this change included.
While running `pod install`, you should now see this extra line with the old architecture:
> [Codegen] building ./../../packages/react-native-codegen.
Reviewed By: cortinico
Differential Revision: D43152692
Pulled By: cipolleschi
fbshipit-source-id: 2cf3002f07eaad442ccb0272831fe2de58ec9c1a
Summary:
changelog: [internal]
`useLayoutEffect` has two guarantees which React Native breaks:
- Layout metrics are ready.
- Updates triggered inside `useLayoutEffect` are applied before paint. State between first commit and update is not shown on the screen.
React Native breaks the first guarantee because it uses Background Executor. Background executor moves Yoga layout to another thread. If user core reads layout metrics in `useLayoutEffect` hook, it is a race. The information might be there, or it might not. They can even read partially update information. This diff does not affect this. We already have a way to turn off Background Executor. We haven't done this because it introduces regressions on one screen but we have a solution for that.
React Native breaks the second guarantee. After Fabric's commit phase, Fabric moves to mounting the changes right away. In this diff, we queue the mounting phase and give React a chance to change what is committed to the screen. To do that, we schedule a task with user blocking priority in `RuntimeScheduler`. React, if there is an update in `useLayoutEffect`, schedules a task in the scheduler with higher priority and stops the mounting phase.
We are not delaying mounting, this just gives React a chance to interrupt it.
Fabric commit phase may be triggered by different mechanisms. C++ state update, surface tear down, template update (not used atm), setNativeProps, to name a few. Fabric only needs to block paint if commit originates from React. Otherwise the scheduling is wrong and we will get into undefined behaviour land.
Rollout:
This change is gated behind `react_fabric:block_paint_for_use_layout_effect` and will be rolled out incrementally.
Reviewed By: javache
Differential Revision: D43083051
fbshipit-source-id: bb494cf56a11763e38dce7ba0093c4dafdd8bf43
Summary:
It's cheaper to pass nullptr over JNI, and allocate an empty folly::dynamic::object on the stack.
Changelog: [Internal]
Reviewed By: genkikondo
Differential Revision: D43117216
fbshipit-source-id: e127cce7a1ccf50395073ca9c1c0469d0faa9f82
Summary:
Incorrect TS type disallows use of `hitSlop={number}`. Fixed by using Pressable's hitSlop type.
NOTE: I did not bother to change Flow types in the `.js` file, please add a commit doing that if required.
## Changelog
[GENERAL] [FIXED] - Fix touchable hitSlop type
Pull Request resolved: https://github.com/facebook/react-native/pull/36065
Test Plan: None needed
Reviewed By: christophpurrer
Differential Revision: D43117689
Pulled By: javache
fbshipit-source-id: 96e5ae650f47382c8d7fa1ddf63c76461c65dcc7
Summary:
changelog: [internal]
Passing MountingCoordinator argument by value instead of reference. Using reference does not make sense since we eventually take ownership of shared_ptr anyway. This better communicates the intent.
Reviewed By: christophpurrer
Differential Revision: D43082955
fbshipit-source-id: 29e20abb9824c10a5f0d5e0ba1049ff6d67cee98
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36093
The Test Docker Android job is flaky as sometimes fetching artifacts from remote
returns different hashes.
I'm moving the job to CircleCI (so it's faster) + I'm using the `buck_fetch.sh`
script we already have which has a retry logic.
Changelog:
[Internal] [Changed] - Move test-docker-android from GH Actions to CircleCI
Reviewed By: javache
Differential Revision: D43121477
fbshipit-source-id: 1df114fd3ad9445a4a5dc7834bf811c3476322cd
Summary:
Just got a report that we depend on `activesupport` 6.1.7 which is marked as vulnerable
as per CVE-2023-22796
https://github.com/advisories/GHSA-j6gc-792m-qgm2
I'm adding a dep on >= 6.1.7.1 in the Gemfile.
Changelog:
[Internal] [Changed] - Bump activesupport to 6.1.7.1 to address CVE-2023-22796
Reviewed By: yungsters
Differential Revision: D43117034
fbshipit-source-id: 2c925754ca32257c9523d5bd68d6cf3bb3eb31e3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36092
This test is partially disabled already, causing high flakyness of the `test_windows` CI job.
I'm taking a different approach at disabling it here (disabling the offending tests using a `Promise`
rather than disabling at the assert level).
Changelog:
[Internal] [Changed] - Reduce flakyness on InteractionManager-test
Reviewed By: cipolleschi
Differential Revision: D43120897
fbshipit-source-id: 69edee804aaaa8b6f89ff8440561254f393efae4
Summary:
Changelog: [Internal]
Caller needs to explicitly set commit options. This is for readability and making sure caller is aware of what are the options of the commit. This will be important in subsequent diff where we will add another commit option.
Reviewed By: christophpurrer
Differential Revision: D43082837
fbshipit-source-id: 1417205299c19430f902453c2b6d9bb9ca31707d
Summary:
State updates can be batched together idependent of `this.state`, so we should do any calculation deriving state from state within a `setState()` callback. This fixes a bug where we were relying on potentially stale state, a RenderMask derived from `this.state` instead of the `state` callback parameter, when triggering updates from focus.
Note that this is not exercised on Android/iOS, but it on desktop/web. I noticed this a while back while making another change, but that change got abandoned, so this is the independent fix.
Changelog:
[General][Fixed] - Calculate VirtualizedList render mask for focused cell during batched state updates
Reviewed By: javache
Differential Revision: D43073415
fbshipit-source-id: dee4197ec925a6d8d427b63fb063aa4e3b58c595
Summary:
Convert Bridge-only checks to overridable functions and make Bridgeless override them in ReactSurfaceView so that the checks will work for Bridgeless as well.
Issue fixed:
https://fb.workplace.com/groups/rn.support/permalink/24231137939841493/
Changelog:
[Android][Changed] - Convert Bridge-only calls to overridable functions
Reviewed By: javache
Differential Revision: D43063348
fbshipit-source-id: a1c181d27c1669f6033f3fb783c5a668b7c2585b
Summary:
Changelog:
[internal] - DescriptionSome tooling breaks when the JavascriptException is obfuscated. This change prevents the exception from getting obfuscated, allowing tools to detect them without symbolicating.
Differential Revision: D43091424
fbshipit-source-id: aae4768397bd78433a1d496ecac4a1442422d912
Summary:
Changelog: [internal]
Pass RuntimeScheduler to Binding in Venice.
This is needed for two reasons:
- support "callImmediates". This is a workaround to bridge the gap in scheduling until microtasks in RN are shipped.
- To block paint in case there is a state update in useLayoutEffect. Used later in this diff stack
Reviewed By: sshic
Differential Revision: D43088186
fbshipit-source-id: 8537234db5f72cbf057ad1861ca2c37a5c3dbd8b
Summary:
the current jsc-android is still built based on ndk r21, and react-native is now built based on ndk r23. the unwinder between r21 and r23 is incompatible (libgcc vs libunwind). if there's exceptions throwing from jsc, other react native libraries cannot catch these exceptions and cause runtime crash.
this pr updates jsc-android to 235231.0.0 which is the same webkitgtk version as 235230.2.1 but only built by ndk r23. the jsc-android pr is from https://github.com/react-native-community/jsc-android-buildscripts/pull/179. note that the jsc is based on ndk r23c and react-native is based on ndk r23b. the reason is that i cannot get jsc building successfully on r23b. hopefully r23b and r23c are abi safe.
there is another crash from libjscexecutor when testing the new jsc-android. to fix the issue, i have to explicitly link libunwind.a from libjscexecutor.so. supposedly ndk r23 should help to link libunwind under the hood, i still not figure out why it doesn't. but after linking libunwind.a, i can get new jsc-android work successfully.
```
E/art ( 2669): dlopen("/data/app/com.test-1/lib/x86_64/libjscexecutor.so", RTLD_LAZY) failed: dlopen failed: cannot locate symbol "_Unwind_Resume" referenced by "/data/app/com.test-1/lib/x86_64/libjscexecutor.so"...
W/System.err( 2669): java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "_Unwind_Resume" referenced by "/data/app/com.test-1/lib/x86_64/libjscexecutor.so"...
W/System.err( 2669): at java.lang.Runtime.load(Runtime.java:331)
W/System.err( 2669): at java.lang.System.load(System.java:982)
W/System.err( 2669): at com.facebook.soloader.SoLoader$1.load(SoLoader.java:558)
W/System.err( 2669): at com.facebook.soloader.DirectorySoSource.loadLibraryFrom(DirectorySoSource.java:110)
W/System.err( 2669): at com.facebook.soloader.DirectorySoSource.loadLibrary(DirectorySoSource.java:63)
W/System.err( 2669): at com.facebook.soloader.ApplicationSoSource.loadLibrary(ApplicationSoSource.java:91)
W/System.err( 2669): at com.facebook.soloader.SoLoader.doLoadLibraryBySoName(SoLoader.java:1067)
W/System.err( 2669): at com.facebook.soloader.SoLoader.loadLibraryBySoNameImpl(SoLoader.java:943)
W/System.err( 2669): at com.facebook.soloader.SoLoader.loadLibraryBySoName(SoLoader.java:855)
W/System.err( 2669): at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:802)
W/System.err( 2669): at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:772)
W/System.err( 2669): at com.facebook.react.jscexecutor.JSCExecutor.loadLibrary(JSCExecutor.java:24)
W/System.err( 2669): at com.facebook.react.jscexecutor.JSCExecutor.<clinit>(JSCExecutor.java:20)
W/System.err( 2669): at com.facebook.react.ReactInstanceManagerBuilder.getDefaultJSExecutorFactory(ReactInstanceManagerBuilder.java:363)
W/System.err( 2669): at com.facebook.react.ReactInstanceManagerBuilder.build(ReactInstanceManagerBuilder.java:316)
W/System.err( 2669): at com.facebook.react.ReactNativeHost.createReactInstanceManager(ReactNativeHost.java:94)
W/System.err( 2669): at com.facebook.react.ReactNativeHost.getReactInstanceManager(ReactNativeHost.java:41)
W/System.err( 2669): at com.test.MainApplication.onCreate(MainApplication.java:60)
W/System.err( 2669): at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1011)
W/System.err( 2669): at androidx.test.runner.MonitoringInstrumentation.callApplicationOnCreate(MonitoringInstrumentation.java:483)
W/System.err( 2669): at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4518)
W/System.err( 2669): at android.app.ActivityThread.access$1500(ActivityThread.java:144)
W/System.err( 2669): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1339)
W/System.err( 2669): at android.os.Handler.dispatchMessage(Handler.java:102)
W/System.err( 2669): at android.os.Looper.loop(Looper.java:135)
W/System.err( 2669): at android.app.ActivityThread.main(ActivityThread.java:5221)
W/System.err( 2669): at java.lang.reflect.Method.invoke(Native Method)
W/System.err( 2669): at java.lang.reflect.Method.invoke(Method.java:372)
W/System.err( 2669): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:899)
W/System.err( 2669): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:694)
```
fixes https://github.com/facebook/react-native/issues/36052
## Changelog
[ANDROID][FIXED] - Fixed jscexecutor crash on Android which is caused from NDK incompatibility
Pull Request resolved: https://github.com/facebook/react-native/pull/36062
Test Plan: tested on [jsc-android instrumented test](https://github.com/react-native-community/jsc-android-buildscripts/tree/2.26.1/test) (based on react-native 0.71.2)
Reviewed By: cipolleschi
Differential Revision: D43040295
Pulled By: cortinico
fbshipit-source-id: e0e5b8fb7faa8ee5654d4cde5f274bef4b517376
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36080
For Android release builds on Windows, gradle release build fails if there are spaces in path (https://github.com/facebook/react-native/issues/34878). This is due to gradle improperly handling arguments with spaces (this is also [an open issue](https://github.com/gradle/gradle/issues/6072) on Gradle). Since the Hermes compilation and other Gradle exec invocations involve arguments which will contain spaces (if there are spaces in your path), this also means it is hard to get around this by simply escaping the spaces (eg: by using double quotes), since these arguments are not properly handled by Gradle itself.
As a workaround, this PR uses relative paths for all Gradle commands invoked for Android. As long as there aren't any spaces in the react-native directory structure (i.e this repo), this fix should work.
## Changelog
[Android][Fixed] - Used relative paths for gradle commands
Pull Request resolved: https://github.com/facebook/react-native/pull/36076
Test Plan: `npx react-native run-android` builds and runs the app successfully on Android device, when run inside an RN0711 project with a path containing spaces (and with the changes in this PR applied) on Windows. This includes release builds (i.e with the `--variant=release` flag).
Reviewed By: cipolleschi
Differential Revision: D43080177
Pulled By: cortinico
fbshipit-source-id: 7625f3502af47e9b28c6fc7dfe1459d7c7f1362d
Summary:
Yesterday CircleCI was extremely flaky due to us trying to `apt install` extra packages. This mitigates one scenario where we try to redownload `jq` and `shellcheck`.
I've moved to use a container which contains those packages already
## Changelog
[INTERNAL] - Reduce flakyness by not downloading extra packages
Pull Request resolved: https://github.com/facebook/react-native/pull/36077
Test Plan: Will wait for a green CI
Reviewed By: cipolleschi
Differential Revision: D43080349
Pulled By: cortinico
fbshipit-source-id: 6527c5ad129f47d8b5f02bf207e1af67a095afa1
Summary:
Update setup of sourcing `asdf-vm` in `find-node-for-xcode.sh` in case of user has custom defined of `$ASDF_DIR`
by default `$ASDF_DIR` point to `$HOME/.asdf`, but if user has custom directory (like XDG convention) this script wont work without this change.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[GENERAL] [CHANGED] - Find node binary when using asdf as the node version manager with custom `$ASDF_DIR`
Pull Request resolved: https://github.com/facebook/react-native/pull/36043
Test Plan: use a defualt/custom `$ASDF_DIR` while using `asdf-vm` as node version manager then make iOS build.
Reviewed By: cortinico
Differential Revision: D42990407
Pulled By: cipolleschi
fbshipit-source-id: 1fe3fdc786bddf741ff422e7bec55a6c9cc8ed83
Summary:
Both Android and iOS allow you to set application specific user interface style, which is useful for applications that support both light and dark mode.
With the newly added `Appearance.setColorScheme`, you can natively manage the application's user interface style rather than keeping that preference in JavaScript. The benefit is that native dialogs like alert, keyboard, action sheets and more will also be affected by this change.
Implemented using Android X [AppCompatDelegate.setDefaultNightMode](https://developer.android.com/reference/androidx/appcompat/app/AppCompatDelegate#setDefaultNightMode(int)) and iOS 13+ [overrideUserInterfaceStyle](https://developer.apple.com/documentation/uikit/uiview/3238086-overrideuserinterfacestyle?language=objc)
## Changelog
[GENERAL] [ADDED] - Added `setColorScheme` to `Appearance` module
Pull Request resolved: https://github.com/facebook/react-native/pull/35989
Test Plan:
This is a void function so testing is rather limited.
```tsx
// Lets assume a given device is set to **dark** mode.
Appearance.getColorScheme(); // `dark`
// Set the app's user interface to `light`
Appearance.setColorScheme('light');
Appearance.getColorScheme(); // `light`
// Set the app's user interface to `unspecified`
Appearance.setColorScheme(null);
Appearance.getColorScheme() // `dark`
```
Reviewed By: NickGerleman
Differential Revision: D42801094
Pulled By: jacdebug
fbshipit-source-id: ede810fe9ee98f313fd3fbbb16b60c84ef8c7204
Summary:
Originally proposed in https://github.com/react-native-community/discussions-and-proposals/discussions/592
Main changes are:
- Explicitly importing the global APIs in `App.test.tsx`
- Drop `types/jest` from the devDependency list
Benefits of these changes will be:
- Keep in line with Jest's recommended practice
- Remove a dev-dependency to make dependencies slimmer
References:
- https://github.com/facebook/jest/pull/13133
- https://github.com/DefinitelyTyped/DefinitelyTyped/pull/62037
## Changelog
[GENERAL] [CHANGED] - Switch from `types/jest` to `jest/globals` for new react-native projects
Pull Request resolved: https://github.com/facebook/react-native/pull/36068
Test Plan:
1. Create a new RN project from the modified template
2. Ensure yarn test passes
3. Ensure IDEs do not complain about `App.test.tsx`
Reviewed By: cipolleschi
Differential Revision: D43080151
Pulled By: cortinico
fbshipit-source-id: c9161cb930c78f3a1eaa08ccb6483aa38d52fa3c
Summary:
A small backport to main of a local fix done in 0.71 to account for the logic for releases 0.Y.1,2,3-prerelease (meaning, not just strictly 0).
I could have done like the other logics and just remove the check for patch, but decided to at least make sure it's a digit 😅
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[INTERNAL] [FIXED] - handle patch versions after the .0 for set version
Pull Request resolved: https://github.com/facebook/react-native/pull/36020
Test Plan: Tested in 0.71-stable, without it we can't test RNTestProject.
Reviewed By: jacdebug, cortinico
Differential Revision: D42924375
Pulled By: cipolleschi
fbshipit-source-id: b003d884cc45a2602adbc14fa8b66d3f1e0c94a6
Summary:
This change reverts D41745930 (https://github.com/facebook/react-native/commit/2e3dbe9c2fbff52448e2d5a7c1e4c96b1016cf25) as part of a stack to splice back source history which was lost (Git registered the file moves as additions).
It is expected this diff will individually fail. The entire stack should be applied at once.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D43068113
fbshipit-source-id: c8398629fe5dcc1ca4bf02f550adc00c78a8487a
Summary:
This is a two step (2/2) fix to a race that could caused a DELETE...CREATE mutations being sent over to the fabric mounting layer. Such combination was assumed not possible from the differ (https://fburl.com/code/kg8z9t4w), yet it happened at least in the existence of layout animation and when certain commits happen while animation is active.
This diff fixes all potential races in the Fabric mounting layer directly. It captures all the `DELETE...CREATE` combinations and stop those from passing down to the native platforms. This should fix all such races should them not captured by the fix in the layout animation.
To help understand other races better, I also logged here to indicate such race so that future crashes will have more context.
Changelog:
[General][Fixed] - Fix edge case when layout animation caused delete and create mutations in the same batch
Reviewed By: javache
Differential Revision: D41900201
fbshipit-source-id: 280502ca32ce87a9e483cd859b11bcd3e5c4a435
Summary:
Since currently the check was for null , and that too not === check. So added a check , only for item !== undefined, since null is an assigned value, and we can have null as values in the array for flatlist,
undefined is in absence of any data, hence if its only undefined we should assign falsy to frame variable, since null is an assigned value, sometimes null can be passed to data in the dataset
Hence added a check on top of Sam's previous commit to fix it
UPDATE:
Now after discussing with NickGerleman , removed the check for item with nullish/undefined.
Now directly frames value is being controlled by _keyExtractor function
This is already an issue [https://github.com/facebook/react-native/issues/35280](url)
Currently in my project, even [0,1] -> didnt trigger onViewableItemsChanged since, it was considered as falsy value,
went to check the node modules code for flatlist, debugged this.
When pulled latest main branch, saw it was partially fixed , but for null as values it wasnt fixed. So added that check .
## Changelog
[General] [Fixed] Fix VirtualizedList onViewableItemsChanged won't trigger if first item in data is null
```
const frame =
item !== undefined ? this._frames[this._keyExtractor(item, index, props)]
: undefined;
```
in place of existing which is
```
const frame =
item != null ? this._frames[this._keyExtractor(item, index, props)]
: undefined;
```
Update:
`const frame = this._frames[this._keyExtractor(item, index, props)]`
Finally this is the one used for getting frames value
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
Pull Request resolved: https://github.com/facebook/react-native/pull/36009
Test Plan:
Checked out in my local , wrt changes , will share video if required
Update:
After the new changes too, checked in local, working fine
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
Reviewed By: NickGerleman
Differential Revision: D42934757
Pulled By: skinsshark
fbshipit-source-id: cb5622a79523bccbdfbc15470baf84422f635b33
Summary:
This is a small refactor designed to make future merges for React Native macOS easier. It was found while merging React Native 0.71 into React Native macOS.
In React Native macOS, we ifdef iOS out API's and replace them with macOS APIs, reusing as much code as possible. `CGContext` is a type that is available on both iOS and macOS, but `UIGraphicsImageRendererContext` is not. A simple refactor makes it easier to reuse this code in React Native macOS without affecting iOS :)
Resolves https://github.com/microsoft/react-native-macos/issues/1676
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[IOS] [CHANGED] - Pull out CGContext early in UIImage+Diff
Pull Request resolved: https://github.com/facebook/react-native/pull/35940
Test Plan: Build should pass.
Reviewed By: matrush
Differential Revision: D42761424
Pulled By: javache
fbshipit-source-id: 5ce79a5e7c60484dd37d0b2c3f58ff0897d662df
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36051
[Changelog][Internal]
This has been on my backlog for some time, submitting the diff to get it out of the way.
It makes the macro-based code in the "iterator-based property parsing" branch somewhat less horrible and less error prone (by removing duplication vs the default values in the class declaration).
Reviewed By: sammy-SC
Differential Revision: D42990595
fbshipit-source-id: e4b91160c6e09d3d1eab2ba70a58d390243bb335
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36044
> **Notice**: This commit does not change any behaviour.
Parse and collect enum members in module specs instead of the current behaviour of parsing enum members as 'string' / 'number' and ignoring the member names.
This commit would allow us to generate native Enums corresponding to the schema's enums.
Prior to this commit, enum params were parsed as:
```
{
'name': 'qualityParam',
'optional': false,
'typeAnnotation': {
'type': 'EnumDeclaration',
'memberType': 'StringTypeAnnotation'
}
},
```
The name of the enum type and the members of the enum type were ignored.
After this commit, parsed modules would hold a new object member called `enumMap` that would look like this:
```
'enumMap': {
'QualityEnum': {
'name': 'QualityEnum',
'type': 'EnumDeclarationWithMembers',
'memberType': 'StringTypeAnnotation',
'members': [
{
'name': 'SD',
'value': 'sd'
},
{
'name': 'HD',
'value': 'hd'
}
]
},
// ...
}
```
And enum params would be exported as:
```
{
'name': 'qualityParam',
'optional': false,
'typeAnnotation': {
'name': 'NativeModuleEnumTypeAnnotation',
'type': 'EnumDeclaration',
'memberType': 'StringTypeAnnotation'
}
},
```
Combining the two new outputs would allow us to generate Native enums in the Native generators.
Changelog: [Internal] Parse and collect enum members in turbo module specs
Reviewed By: cipolleschi
Differential Revision: D42778258
fbshipit-source-id: 56479342e085bc4e13c5a3e12b265b140e49893c
Summary:
Handling of `EnumDeclaration` was introduced in D38967241 (https://github.com/facebook/react-native/commit/745f3ee8c571560406629bc7af3cf4914ef1b211) so it is no longer a type expected to fail generators.
Changelog: [Internal] remove 'EnumDeclaration' as a type expected to throw error in module generators
Reviewed By: cipolleschi
Differential Revision: D42917947
fbshipit-source-id: 16fcb915ccd42c613ca4d30b815d6365681f5fa1
Summary:
* Added an e2e test fixture with all the supported enum variations
* Added H and C file TM generators to the TM e2e tests
Changelog: [Internal] Added an e2e test fixture for Enums and .H+.C TM e2e snapshot tests
Reviewed By: cipolleschi
Differential Revision: D42917330
fbshipit-source-id: 8e4adb86b6eb4e2b29a9e6d0cd6e4fd5b002ad1a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36042
Pull Request resolved: https://github.com/facebook/react-native/pull/36028
Use aliasMap both in parsers and generators instead of using aliasMap in half of the places and aliases in the other.
This would also allow us to introduce "enumMap" more easily in the next commit.
Changelog: [Internal] rename module exports from "aliases" to "aliasMap"
Reviewed By: christophpurrer, cipolleschi
Differential Revision: D42888752
fbshipit-source-id: cf1929fcebde994d07e5c6bda5ab71106d417b21
Summary:
This is a prototype to add circular dependencies detection on CMake for ReactCommon and ReactAndroid.
It can be enabled per module and works as follows:
```
set(ALLOWED_HEADER_IMPORT_PATHS
react/renderer/graphics
react/debug)
check_for_circular_dependencies("${ALLOWED_HEADER_IMPORT_PATHS}")
```
The allowed header import path must be manually specified as libraries are exposing wrong header search paths (so can't be reused).
The CI will be red till the circular dependency on `graphics` is resolved.
Changelog:
[Internal] [Changed] - Add macro to detect circular dependencies on Cmake
Reviewed By: cipolleschi
Differential Revision: D42927036
fbshipit-source-id: b1393dfd43fd042e2ebf1d5b46b24bd9f5e20d58
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36039
This change bumps AGP to 7.4.1 so we can remove a lot of the unnecessary changes
we had to do to support AGP 7.3.x
I've also removed the explicit version in the template as now the AGP version
is provided by RNGP. That means that the user will get the correct version they need.
This also bumps the default CMake version in user space to 3.22 which resolves a lot
of warning when users are building with the New Architecture enabled.
Changelog:
[Android] [Changed] - Bump AGP to 7.4.1
allow-large-files
Reviewed By: cipolleschi
Differential Revision: D42960353
fbshipit-source-id: 9065f975c1694d266a86b2d3fe805e6e2b1c4aa1
Summary:
- Bridgeless is using a deprecated FabricUIManager constructor which bridge doesn't use, and is the only one using it, this diff migrated bridgeless to use the same FabricUIManager constructor as bridge
- Remove static view config check (mShouldDeallocateEventDispatcher), instead use Bridgeless check since SVC is enabled in Bridgeless but not in Bridge.
Changelog:
[Android][Changed] - Align creation of FabricUIManager with bridge
Reviewed By: javache
Differential Revision: D42681489
fbshipit-source-id: b9c7c4a81a98db52e881138cc85be0e85df636d9
Summary:
Changelog: [Internal] Support hovering in/out of root views
Prior to this change, we did not have signal when an input device moved out of the root view and so our internal state would not be aware and we would not trigger enter/leave events.
This diff starts listening to `HOVER_EXIT` events as dispatched from `onInterceptHoverEvent` and assumes that's the right event to signal a cursor has moved out of the root view. We dispatch the relevant leave events for this case and update our internal state to ensure the next `HOVER_MOVE` in our rootview, will properly dispatch the enter events.
## Investigation for creating this diff
Determining the signal for when an inputDevice enters/exits our rootview wasn't straight-forward.
From my understanding Android event dispatching follows a similar capture, bubbling phase as web. With `onIntercept..` handlers to swallow events. See this explanation: https://suragch.medium.com/how-touch-events-are-delivered-in-android-eee3b607b038 and this video talk: https://youtu.be/EZAoJU-nUyI?t=929
However when trying to understand hover enter/exit events on the root view, my understanding of this logic broke down.
Here's what confused me:
* When moving a cursor from inside to outside the root view, I would receive `HOVER_ENTER/EXIT` MotionEvents on `onInterceptHoverEvent` and since we did not swallow them, we'd receive those same events on the bubble up in `onHover`. That makes sense.
* However, when I hovered from the rootview into a child view, I would receive MotionEvents of `HOVER_ENTER/HOVER_EXIT` in the `onHoverEvent` handler of the rootview without having seen them in the `onInterceptHoverEvent` (re: capture phase down). This was confusing, where was the capture down?
* What tips me off that these events (`HOVER_ENTER/EXIT`) don't follow the classic capture, bubbling model as explained in the linked article, is that I don't receive `HOVER_ENTER/HOVER_EXIT` events for each child view in the root view's `onInterceptHoverEvent`.
* Like when a cursor moves from root -> child, I'd expect to motion events 1. exit for the rootview, 2. enter for the child view. But I never receive the 2. from the root view --
* I also wonder if the wording for `HOVER_EXIT` events mean that these events are directly dispatched to the view? Re: ["This action is always delivered to the window or view that was previously under the pointer."](https://developer.android.com/reference/android/view/MotionEvent#ACTION_HOVER_ENTER)
* There also seems to be some optimizations around the dispatch path as mentioned in this video at this timestamp: https://youtu.be/EZAoJU-nUyI?t=929 for the UP gesture.. so maybe there's some optimization happening with hover events? I'm not sure how hover events are account for in gesture handling for Android.
Reviewed By: vincentriemer
Differential Revision: D42817315
fbshipit-source-id: 412c971c1d1e7afc0d67fadcc4417189967fe48c
Summary:
Adds changelog for new patch.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - add changelog entry for 0.71.2
Pull Request resolved: https://github.com/facebook/react-native/pull/36032
Test Plan: N/A
Reviewed By: cortinico
Differential Revision: D42928179
Pulled By: cipolleschi
fbshipit-source-id: 1eb7b399e58c6e78a6961dc98198fb747df5ceb3
Summary:
The [previous pull request](https://github.com/facebook/react-native/pull/35812) enables defining interfaces and using them in a turbo module, but all members are flattened, this is not the best option for codegen for object oriented languages.
In this pull request, an optional member `baseTypes` is added to aliased objects. Members are still flattened for backward compatibility, if a codegen doesn't care about that nothing needs to be changed.
### Example
```typescript
interface A {
a : string;
}
interface B extends A {
b : number;
}
```
#### Before the previous pull request
`interface` is not allowed here, you must use type alias.
#### At the previous pull request
`interface` is allowed, but it is translated to
```typescript
type A = {a : string};
type B = {a : string, b : number};
```
#### At this pull request
Extra information is provided so that you know `B` extends `A`. By comparing `B` to `A` it is easy to know that `B::a` is obtained from `A`.
## Changelog
[GENERAL] [CHANGED] - Turbo module codegen support interface with inheritance in module
Pull Request resolved: https://github.com/facebook/react-native/pull/36011
Test Plan: `yarn jest react-native-codegen` passed
Reviewed By: rshest
Differential Revision: D42882650
Pulled By: cipolleschi
fbshipit-source-id: 32d502e8a99c4151fae0a1f4dfa60db9ac827963
Summary:
While working on T143721371 I've noticed that we still have an exposed context
for `react-native-bot` which gives access to `PAT_TOKEN` and `PAT_USERNAME`.
As those two variables are unused, we can fully clean this us.
Changelog:
[Internal] [Changed] - Remove the `react-native-bot` context from CircleCI
Reviewed By: cipolleschi
Differential Revision: D42886196
fbshipit-source-id: 4eba7a53557fe7af7d87650052630eea2d2d3934
Summary:
The fixed error guides users toward the right missing dependency. The original error pointed to the old name.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[INTERNAL] [FIXED] - Display correct codegen dependency name when not found
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[INTERNAL] [FIXED] - Display correct codegen dependency name when not found
Pull Request resolved: https://github.com/facebook/react-native/pull/36013
Test Plan: This is an error message wording change.
Reviewed By: jacdebug
Differential Revision: D42881807
Pulled By: cipolleschi
fbshipit-source-id: d96fb867cfe27ae922d398ab981f5797cb51a269
Summary:
ScrollViews don't properly maintain position where they are hidden and shown. When a ScrollView's content is laid out, onLayoutChange is triggered. This is also fired when the views are hidden, which is not desirable as the layout may not be accurate when the view is hidden. Check that the scroll view is showing before attempting a scroll.
Changelog:
[Internal][Fixed] - In onLayoutChange, only scroll if the view is shown and the content view is ready
Reviewed By: sshic
Differential Revision: D42808119
fbshipit-source-id: 0197ae55fa7d80e52c2ea483609e62d512a117f3
Summary:
ScrollViews don't properly maintain position where they are hidden and shown. There is an edge case where on onLayout for a ScrollView, its content may not have been laid out yet. This happens in some cases when a scroll view is hidden via display: 'none' (resulting in setVisibility(INVISIBLE)). Check that the content view is laid out before attempting a scroll.
Changelog:
[Internal][Fixed] - In onLayout, only scroll if the content view is ready
Reviewed By: sshic
Differential Revision: D42794750
fbshipit-source-id: 654a380bcae306da2704d3e190423c8de125833d
Summary:
ScrollViews don't properly maintain position where they are hidden and shown. On iOS, when a UIScrollView (or its ancestor) is hidden, its scroll position is set to 0 (its window also becomes nil). When it is shown again, its scroll position is not restored.
When a scroll is attempted when the scroll view is hidden, we keep track of the last known offset before it was hidden. Then, in updateLayoutMetrics (which is triggered when the view is shown), we apply the pending offset if there is one. This is [consistent with Android's behavior in ReactScrollView.java](https://www.internalfb.com/code/fbsource/[2930f8c146af62ad63673c8d34e9876b77634c05]/xplat/js/react-native-github/ReactAndroid/src/main/java/com/facebook/react/views/scroll/ReactScrollView.java?lines=289).
Changelog:
[Internal][Fixed] - In onLayoutChange, only scroll if the view is shown and the content view is ready
Reviewed By: cipolleschi
Differential Revision: D42815359
fbshipit-source-id: 4b209c1e54edf3f5c0bea902b48450a1a2e9661a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35992
Fixes https://github.com/software-mansion/react-native-gesture-handler/issues/2382
I've just realized that the default value fo `jsRootDir` is not entirely correct.
That's the root of the folder where the codegen should run.
For apps, it should be defaulted to `root` (i.e. ../../)
For libraries, it should be defaulted to `../` (currently is root).
This causes a problem where libraries without either a `codegenConfig` or a `react{ jsRootDir = ... }`
specified in the build.gradle will be invoking the codegen and generating duplicated symbols.
Changelog:
[Android] [Fixed] - RNGP - Properly set the `jsRootDir` default value
Reviewed By: cipolleschi
Differential Revision: D42806411
fbshipit-source-id: ffe45f9684a22494cc2e4d0a19de9077cb341365
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35982
This reflects better what the former `emitPartial` was doing - emitting an object with set props.
Changelog: [Internal] - Renamed emitPartial to emitObject
Reviewed By: christophpurrer
Differential Revision: D42740958
fbshipit-source-id: 4f974c6911bc129e698323a8039bbd7aa7602461
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35981
This reflects better what the former `emitObject` was doing - emitting a generic object.
It would also allow us to rename `emitPartial` to `emitObject` in the next diff whence the function name `emitObject` will be free.
Changelog: [Internal] - Renamed emitObject to emitGenericObject
Reviewed By: christophpurrer
Differential Revision: D42740871
fbshipit-source-id: 1b9112464695b8abeccc95eed908b0b45a0e3bf2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36004
Changelog: [Internal]
This fixes CircleCI job, which is responsible for publishing bumped packages. We should not check for `stderr`, apparently `npm` uses it to store debug information:
- https://github.com/npm/npm/issues/118#issuecomment-325440
So we've tried to use this on 0.71-stable before and it succesfully published one package, but have exited right after it because `stderr` was not empty
Reviewed By: cortinico, cipolleschi
Differential Revision: D42836212
fbshipit-source-id: 6f2a9a512121683268fe6aae6a187fccb8d9dfbc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36003
This diff adds 4 tests in CircleCI to make sure we don't regress in the support of Dynamic Frameworks for the old architecture.
## Changelog
[iOS][Fixed] - Add CircleCI tests for dynamic frameworks with the Old Architecture.
Reviewed By: cortinico
Differential Revision: D42829895
fbshipit-source-id: 5669be45d4f55161a11a6ece161b2a2aa384a644
Summary:
I discovered that 0.69 could run React Native as Dynamic framework with Hermes and starting from 0.70 that's not possible anymore.
This diff restore that possibility.
Notice that now Hermes provisdes JSI and Dynamic Frameworks requires that all the dependencies are explicitly defined, therefore, whenever we have a pod that depended on `React-jsi`, now it also has to explicitly depends on `hermes-engine`
## Changelog
[iOS][Fixed] - Add Back dynamic framework support for the Old Architecture with Hermes
Reviewed By: cortinico
Differential Revision: D42829728
fbshipit-source-id: a660e3b1e346ec6cf3ceb8771dd8bceb0dbcb13a
Summary:
I discovered that 0.69 and 0.70 could run React Native as Dynamic framework with JSC and starting from 0.71 that's not possible anymore.
This diff restore that possibility.
## Changelog
[iOS][Fixed] - Add Back dynamic framework support for the old architecture
Reviewed By: cortinico
Differential Revision: D42829137
fbshipit-source-id: 848672f714d8bab133e42f5e3b80202b350d5261
Summary:
In a mono-repo the `react-native` package could be hoisted compared to the app directory, in which case it's not a good strategy for the `react-native-xcode.sh` script to guess the app project root relative to the location of itself. Instead I suggest to relying on a build setting provided by Xcode to derive the default app path.
I could have use the `SRCROOT` instead. According to https://stackoverflow.com/questions/36323031/what-the-different-between-srcroot-and-project-dir this is equivalent and also a bit less ambiguous as I see it. I.e. I would expect most Xcode projects to be located in the `ios` directory of the app.
As a workaround, before this merge, users can add the following to their "Bundle React Native code and images" build phase or `ios/.xcode.env` file:
```shell
export PROJECT_ROOT="$PROJECT_DIR/.."
```
This build phase can also be used for users wanting to revert this default behaviour once merged.
## Changelog
[iOS] [Changed] - Changed default `PROJECT_ROOT` (used in when bundling for iOS) to rely on the `PROJECT_DIR` build setting.
Pull Request resolved: https://github.com/facebook/react-native/pull/35970
Test Plan:
I've updated this locally and verified this does indeed pick up the correct app path - even in a mono-repo.
To verify this:
- Instantiate the template with this patch applied.
- Update the "Run scheme"'s "Build Configuration" to "Release".
- Build the app without errors.
Reviewed By: cortinico
Differential Revision: D42842636
Pulled By: cipolleschi
fbshipit-source-id: 040c31ac59a8abec5f5b38f795c8e74649420bac
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35991
Changelog: [Internal]
While cherry-picking all this logic to `0.71-stable` branch, we've discovered several issues where some packages were failing to be published on Verdaccio proxy
This was failing only on node v16+, after some research, I've noticed that there might be a race-condition and npm unable to grab this token before first `npm publish` executes
Although this still work well on `main` branch, I am backporting it to keep aligned with `0.71-stable`
Reviewed By: christophpurrer, cortinico
Differential Revision: D42806081
fbshipit-source-id: af244d26ea529e6085ed5b2d731623dfaf78a14d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35984
[Changelog][Internal]
Codegen for props parsing was failing to add a required include for the case when the type is an array of objects, which in turn use non-trivial types.
Something like:
```
export type NativeProps = $ReadOnly<{
...ViewProps,
bounds: $ReadOnlyArray<
$ReadOnly<{
height?: Float,
left?: Float,
top?: Float,
width?: Float,
}>,
>,
}>;
```
would cause compilation errors on C++ side, since the required header for the `Float` conversion wasn't included.
Reviewed By: cipolleschi
Differential Revision: D42781128
fbshipit-source-id: d5b133b931a60e414761db0b3ed09893d3fcc9aa
Summary:
I'm moving nightlies from scheduled workflow to scheduled pipeline.
We're not able to manually retrigger nightlies as they're a scheduled workflow and don't expose a parameter. Here I'm cleaning it up.
Plus I'm:
1. Removing the `main_only` reference which is unused
2. Setting up the `run_release_workflow` and `run_nightly_workflow` parameters.
## Changelog
[INTERNAL] - Migrate nightly from scheduled workflow to scheduled pipeline
Pull Request resolved: https://github.com/facebook/react-native/pull/35977
Test Plan: Will wait for CI results.
Reviewed By: cipolleschi
Differential Revision: D42776969
Pulled By: cortinico
fbshipit-source-id: d4ef9654d23cb91f85ce2b38e75e27dc0c575e95
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35953
DimensionValue is a reserved prop type that can be a number or string (such as '50%'). On Java, it will get converted to a YogaValue (converter added to this diff); on C++ it will get converted to a YGValue (converter already exists as it's used in Fabric).
Changelog:
[Internal][Added] - Add codegen support for DimensionValue for components
Reviewed By: cipolleschi
Differential Revision: D42650799
fbshipit-source-id: 1d2bc30bbd93837dedbbb4c74f814963c8140957
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35961
Pull Request resolved: https://github.com/facebook/react-native/pull/35960
This fixes#35864
This feature allows using `$Partial<Obj>` in flow and `Partial<Obj>` in TypeScript based on the spec mentioned here: https://flow.org/en/docs/types/utilities/#toc-partial.
We currently only allow passing an Obj to Partial so
```
export type SomeObj = {
a: string,
b?: boolean,
};
export type PartialSomeObj = Partial<SomeObj>;
```
should work.
and also-
```
export type PartialSomeObj = Partial<{
a: string,
b?: boolean,
}>;
```
But not
```
export type PartialSomeObj = Partial<Partial<{
a: string,
b?: boolean,
}>>;
```
This can be improved in the future by a recursive unwrapping of the value inside the `Partial` annotation.
Changelog:
[General] [Added] - Allow the use of "Partial<T>" in Turbo Module specs.
Reviewed By: christophpurrer, cipolleschi
Differential Revision: D42640880
fbshipit-source-id: 03a3fccc38ccfc7a5440fe11893beb68e77753f3
Summary:
We still see crashes for T112157805 and this diff is to add missing information to help diagnose the issue better.
We added a line of log to indicate which `mountItem` triggered the exception.
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D42556576
fbshipit-source-id: 4283c34cb18d601ca7b80d3524c9c65cc4ae3f8a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35967
In https://github.com/facebook/react-native/issues/35936 we observed that the presence of AbsoluteSizeSpan may lead to hangs when using the Grammarly keyboard on Samsung.
This mitigation makes it so that we do not emit this span in any case where it is sufficient to rely on already set EditText textSize. In simple cases, tested on two devices, it causes typing into the TextInput to no longer hang.
This does not fully resolve the issue for TextInputs which meaningfully use layout-effecting spans (or at least font size), such as non-uniform text size within the input. We instead just try to reduce to minimum AbsoluteSizeSpan possible.
Testing the first commit was able to resolve hangs in some simpler inputs tested, by me and cortinico.
Changelog:
[Android][Fixed] - Mitigation for Samsung TextInput Hangs
Reviewed By: cortinico
Differential Revision: D42721684
fbshipit-source-id: e0388dfb4617f0217bc1d0b71752c733e10261dd
Summary:
changelog: Enable Layout Animations on iOS
[LayoutAnimations](https://reactnative.dev/docs/next/layoutanimation) in New Architecture have been disabled in OSS on iOS because of unresolved crash. This crash only happens rarely. Turning on LayoutAnimations in OSS should be safe and brings New Architecture to parity with old.
Reviewed By: fkgozali
Differential Revision: D42708774
fbshipit-source-id: b0f7febee3aa4f0ddac25556644198ebe79378c1
Summary:
While buildling locally, those two warnings pop up.
- ANDROID_LD being unused by the CMake toolchain. I'm removing it.
- The Download task encountering a weak eTag. I'm updating it:
https://github.com/michel-kraemer/gradle-download-task
Changelog:
[Internal] [Changed] - Fix a couple of warnings in the ReactAndroid:hermes-engine build
Reviewed By: dmytrorykun
Differential Revision: D42738919
fbshipit-source-id: 7bd8785ad5b7431d557e2f8c8876b7c3f7294a43
Summary:
Fixes conflicts in pod build settings like the one below:
Example warning
> Can't merge user_target_xcconfig for pod targets: ["RNReanimated", "hermes-engine"]. Singular build setting CLANG_CXX_LANGUAGE_STANDARD has different values.
Background:
> The former attribute xcconfig is deprecated and will cause a linter error when pushing new versions to trunk. The new attributes are available as pod_target_xcconfig and user_target_xcconfig, which makes their effects more clear. The latter attribute (user_target_xcconfig) should be used with great care, because well designed Pods should be self-contained and make as few assumptions about their environment as possible. Furthermore, this attribute can cause conflicts when different values are specified by two Pods for a build setting which doesn't allow multiple values and so cannot be merged.
- https://blog.cocoapods.org/CocoaPods-0.38/
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[IOS] [FIXED] - Fix cocoapods warning about merging user_target_xcconfig
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/35954
Test Plan:
- Run in example app
## Related PR
- https://github.com/facebook/hermes/pull/903
Reviewed By: christophpurrer
Differential Revision: D42737921
Pulled By: jacdebug
fbshipit-source-id: 75d087a5287e660a703342d6e0ad6632f05f3c4c
Summary:
Bringing the typescript function signature in-line with the js code.
## Changelog
[GENERAL] [FIXED] - Added AlertOptions argument to the type definition for Alert.prompt to bring it into parity with the js code.
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/35957
Test Plan: Before the change, VS Code would show a typescript error when I pass AlertOptions to Alert.prompt (even though the js would execute successfully and respect the options I passed. After the change, when I use an Alert.prompt in VS code the function signature was recognized without errors.
Reviewed By: christophpurrer
Differential Revision: D42737818
Pulled By: jacdebug
fbshipit-source-id: 4d4318f38f5c7b7302aae62de5ce224db67e088a
Summary:
This is a [change](https://github.com/microsoft/react-native-macos/pull/1120) we made in our fork (React Native macOS) that we are now upstreaming to reduce the number of diffs between React Native Core and React Native macOS. Also.. one less crash �!
Resolves https://github.com/microsoft/react-native-macos/issues/1679
Original PR notes:
> We've seen a crash downstream where -[NSString stringByReplacingCharactersInRange:withString:] receives a nil value as the replacement string. This is not good, since we expect that argument to be non-null.
>
>We believe that a cause of this is that -[RCTUITextField textView:shouldChangeTextInRange:replacementString:] is being called with nil as the replacement string. (This is legal, as per [Apple's documentation](https://developer.apple.com/documentation/appkit/nstextviewdelegate/1449325-textview?language=objc).) Right now, the only check that this delegate method does is enforcing the maxLength parameter if it exists, and changes in attributes shouldn't affect the length of the string.
## Changelog
[IOS] [FIXED] - `-[RCTUITextField textView:shouldChangeTextInRange:replacementString:]` no longer crashes when we pass in a `nil` replacement string
Pull Request resolved: https://github.com/facebook/react-native/pull/35941
Test Plan: Build should pass. This change has been running in our fork in production for a while so we're fairly confident of it.
Reviewed By: cipolleschi
Differential Revision: D42705382
Pulled By: jacdebug
fbshipit-source-id: 066cd8a4ba134a681f0f4c955594b1fcda61a30e
Summary:
Similar to the issue here https://github.com/facebook/react-native/pull/34503 but this is also happening if we just use `ScrollView` and `TextInput` with `automaticallyAdjustKeyboardInsets` enabled.
When we enable `Prefer Cross-Fade Transitions` in `iOS` we get a keyboard height of `0` which causes the inset/offset miscalculation and the content jumps up when the keyboard gets hidden.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[IOS] [FIXED] - Fix ScrollView `automaticallyAdjustKeyboardInsets` not resetting when Prefer Cross-Fade Transitions is enabled and keyboard hides
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[IOS] [FIXED] - Fix ScrollView `automaticallyAdjustKeyboardInsets` not resetting when Prefer Cross-Fade Transitions is enabled and keyboard hides
Pull Request resolved: https://github.com/facebook/react-native/pull/35933
Test Plan:
Tested with brand new react native project with/without the fix
before fix `automaticallyAdjustKeyboardInsets` with enabled/disabled opening/closing keyboard
https://user-images.githubusercontent.com/6507800/214039873-33bfb016-f99f-4644-9174-20bf32cf07d6.mov
after fix `automaticallyAdjustKeyboardInsets` with enabled/disabled opening/closing keyboard
https://user-images.githubusercontent.com/6507800/214039887-4054a749-ab15-4399-b6a9-73dc9283aa6b.mov
Reviewed By: christophpurrer
Differential Revision: D42686390
Pulled By: jacdebug
fbshipit-source-id: 98488e0c9639c19a4acae1a1de1a5fde411e2462
Summary:
Just a couple of minor fixes in the `template/` folder:
- Remove a trailing space in `rn_edit_text_material.xml` (this was the _only_ trailing space present in a newly generated RN project), which results in the check against the empty tree object failing:
```
$ git diff --check 4b825dc -- template/
template/android/app/src/main/res/drawable/rn_edit_text_material.xml:23: trailing whitespace.
+ <!--
```
- Add missing newline at end of file in `.watchmanconfig` and `app.json` - Both are text files, and each line (including the last) is expected to end with a newline character (flagged by Git, and also visible as a warning on GitHub):
<img width="369" alt="image" src="https://user-images.githubusercontent.com/743291/214195867-81c8e622-2130-44d4-bdaf-588e3510c109.png">
## Changelog
[GENERAL] [FIXED] - Fix whitespace and newline at EOF in template
Pull Request resolved: https://github.com/facebook/react-native/pull/35939
Reviewed By: christophpurrer
Differential Revision: D42698256
Pulled By: rshest
fbshipit-source-id: 765fd41d4f501aec578755c754ea0ecb290ae6ca
Summary:
Added comment on Podfile under template directory.
I'm working with monorepo and didn't realize it easily to specify the path for react_native_post_install, so I thought it would be better to add this comment.
## Changelog
[IOS] [ADDED] - add comments for specifying the path to React Native
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/35931
Reviewed By: cipolleschi
Differential Revision: D42673707
Pulled By: jacdebug
fbshipit-source-id: 39e424a051d238f6dad42cb0b7748d4f4c400787
Summary:
This adds support for `maintainVisibleContentPosition` on Android. The implementation is heavily inspired from iOS, it works by finding the first visible view and its frame before views are update, then adjusting the scroll position once the views are updated.
Most of the logic is abstracted away in MaintainVisibleScrollPositionHelper to be used in both vertical and horizontal scrollview implementations.
Note that this only works for the old architecture, I have a follow up ready to add fabric support.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Android] [Added] - Add maintainVisibleContentPosition support on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/35049
Test Plan:
Test in RN tester example on Android
https://user-images.githubusercontent.com/2677334/197319855-d81ced33-a80b-495f-a688-4106fc699f3c.mov
Reviewed By: ryancat
Differential Revision: D40642469
Pulled By: skinsshark
fbshipit-source-id: d60f3e2d0613d21af5f150ca0d099beeac6feb91
Summary:
Changelog:
[Internal][Added] - Add support for props of type Array<EdgeInsetsValue>
Reviewed By: christophpurrer
Differential Revision: D42651078
fbshipit-source-id: 3b8683ab199c3d590136cec0e6a67e9e85aaa2c0
Summary:
This change aligns requestAnimationFrame implementation used in Jest environment with web standard, and with the implementation that runs in the application environment.
As per specification https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame#parameters – requestAnimationFrame callback gets a single parameter, which represents the current frame timestamp. The current polyfill maps requestAnimationFrame directly to setTimeout which makes the callback execute without any parameters.
## Changelog
[General] [Fixed] - Jest mocked requestAnimationFrame callbacks now receive a timestamp parameter
Pull Request resolved: https://github.com/facebook/react-native/pull/35919
Test Plan:
1. execute jest test suite to make sure nothing breaks
2. add the below code to one of the tests:
```
jest.useFakeTimers();
requestAnimationFrame((timestamp) => console.log("rAF", timestamp));
jest.runOnlyPendingTimers();
jest.useRealTimers();
```
this code will print `undefined` before and numer `0` representing the mocked frame time after this change.
Reviewed By: jacdebug
Differential Revision: D42676544
Pulled By: robhogan
fbshipit-source-id: 363dc506ccc4bd034408fbb35ad3151875a8d309
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35790
This diff apply to RNTester the same logic we have in the template to control the `use_framework!` setting
This is a preliminary change to solve the `use_frameworks!` problems in the New Architecture for both the Template and RNTester.
## Changelog:
[iOS][Changed] - Align RNTester usage of the USE_FRAMEWORKS flag to the template
Reviewed By: cortinico, dmytrorykun
Differential Revision: D42387701
fbshipit-source-id: 28baf5a65b727269d55382de286a17de30e8895b
Summary:
Fixed typo with the word "running" in 2 places when failing to open Flipper.
Fixes https://github.com/facebook/react-native/issues/35899 .
Changelog:
[Internal] [Changed] - Fix typo with the word "running" when failing to open Flipper
Pull Request resolved: https://github.com/facebook/react-native/pull/35910
Reviewed By: christophpurrer
Differential Revision: D42641042
Pulled By: sshic
fbshipit-source-id: acebb26ab921e98235c4f8e8535fa89be2ffa8cd
Summary:
Constructing a `JSError` currently catches all exceptions that occur,
regardless of their type, and embeds the information from them in the
newly created `JSError`. This means that the type of exceptions can be
silently changed.
This results in a bug if Hermes is built with
`HERMESVM_EXCEPTION_ON_OOM` enabled. The OOM exception will get
converted to a `JSError`, which in turn can get converted into a
regular JS exception. The regular JS exception can then be caught by JS
and ignored. This leads to the VM continuing to execute in a bad
state.
I considered three ways to fix this:
1. Add a new type of exception to JSI that is intentionally meant to be
ignored, and the Hermes OOM exception then subclasses it.
2. Propagate all exceptions that happen when constructing `JSError`.
3. Propagate all exceptions except `JSIException`s when constructing
`JSError`.
The first is technically the most surgical, but it adds complexity to
JSI, and will require some extra machinery to implement since we
wouldn't be able to throw it directly from inside the VM. I'm also not
comfortable with the idea of JSI suppressing exceptions that are
completely unrelated to JSI.
The second is the simplest, and seems to match what JS would do if
`throw new Error()` itself threw, but there is some possibility that it
is a change in behaviour for existing code.
So the third approach, which is implemented in this diff, tries to
compromise between the two. Hermes can only ever throw `JSIException`s
from regular JS operations, so there should be no change for existing
code (except code that uses exceptions on OOM, which is what we're
trying to fix). Any other exception gets passed through to the caller.
Changelog:
[Internal][Fixed] - Fixed handling of Hermes OOM exceptions in JSI.
Reviewed By: jpporto
Differential Revision: D41831616
fbshipit-source-id: 42e0dde1c4acc016ab19533941c58fc1797ba1c2
Summary: Changelog: [Internal] Infer whether a pointer supports hover or not by presence of events
Reviewed By: vincentriemer, NickGerleman
Differential Revision: D42589958
fbshipit-source-id: aa42affc98ef78ebbf9a6e420684ed098869b905
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35888
Changelog:
[Android][Removed] - For supporting Dev Loading View across multiple platforms, changed the Loading View of Android to rely on the native implementation instead of Toast. Getting rid of the JS changes relying on Toast for Dev Loading View now that the native module is released.
Reviewed By: rshest
Differential Revision: D42599220
fbshipit-source-id: ec7098b508c766c07384d48d3bffed075b092b72
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35901
[Changelog][Internal]
Partially reverts the change that was redirecting `performance` instance to the new implementation in WebPerformance, until the actual implementation becomes public and native modules are included by default.
Reviewed By: rubennorte
Differential Revision: D42607379
fbshipit-source-id: c1ce995d20b9dfe7aef8436cea00d89b81e32932
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35897
Fixes https://github.com/facebook/react-native/issues/35894
Android 11 added native support for querying whether the IME is present along with its size, as part of the WindowInsets API. D38500859 (https://github.com/facebook/react-native/commit/1e48274223ee647ac4fc2c21822b5240f3c47e4c) changed our logic for Android keyboard events to use it when available, fixing a longstanding issues where we could not reliably tell where the keyboard was open depending on softInputMode.
An androidx library WindowInsetsCompat aimed to backport some of the functionality to older versions of Android, with the same API, documenting IME queries to work down to API level 23 (Android 6). I used this, so that we would be able to remove our own logic for detecting keyboard insets once we supported 23+.
From an issue report, WindowInsetsCompat is not accurately returning whether the IME is open on at least Android 9. So this change makes it so we only use WindowInsets methods when they are provided by the OS (a tested golden path), and otherwise use the previously working heuristics on anything older.
Changelog:
[Android][Fixed] - Do not use WindowInsetsCompat for Keyboard Events
Reviewed By: christophpurrer
Differential Revision: D42604176
fbshipit-source-id: da6a0bbc34c36f8e6d4e4ac07bc96da048fd6aa8
Summary:
This removes some unused flags which will cause Yoga to layout every tree twice, then diffing the tree, reporting whether the whole tree is different. This is too expensive to run outside of local experimentation, but we have more nuanced ways to implement the `YGNodeLayoutAffectedByQuirk` I am wanting to add.
Changelog: [Internal]
Reviewed By: lunaleaps
Differential Revision: D42406917
fbshipit-source-id: b415ed02768f6b59de3a6fa90c60c750d56fd4b0
Summary:
`accessibilityLabelledBy` is missing from `AccessibilityPropsAndroid` TypeScript interface
## Changelog
[GENERAL] [FIXED] - Added missing `accessibilityLabelledBy` TypeScript type
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/35883
Test Plan: Ran `yarn test-typescript` and `yarn test-typescript-offline` and there were no errors.
Reviewed By: christophpurrer
Differential Revision: D42604287
Pulled By: NickGerleman
fbshipit-source-id: 476d24d1c0257be787b7e84c2c11bcadc3527979
Summary:
TurboModuleRegistry export functions and not a TurboModuleRegistry object. See https://github.com/facebook/react-native/blob/main/Libraries/TurboModule/TurboModuleRegistry.js#L37
## Changelog
[GENERAL] [FIXED] - Fix TurboModuleRegistry TS type
Pull Request resolved: https://github.com/facebook/react-native/pull/35885
Test Plan:
Tested that the import doesn't generate a type error when used correctly.
```ts
import * as TurboModuleRegistry from 'react-native/Libraries/TurboModule/TurboModuleRegistry';
export default TurboModuleRegistry.get<Spec>('RNCSafeAreaContext');
```
Reviewed By: christophpurrer
Differential Revision: D42604208
Pulled By: NickGerleman
fbshipit-source-id: e6259df24aaf6e37b32cc4b51947294fd655837e
Summary:
`accessibilityLanguage` is missing from `AccessibilityPropsIOS` TypeScript interface
## Changelog
[GENERAL] [FIXED] - Added missing `accessibilityLanguage` TypeScript type
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/35882
Test Plan: Ran `yarn test-typescript` and `yarn test-typescript-offline` and there were no errors.
Reviewed By: christophpurrer
Differential Revision: D42604363
Pulled By: NickGerleman
fbshipit-source-id: fb8dd4b5bba78a080473a9dc7b49a07587530229
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35875
Fixes https://github.com/facebook/react-native/issues/35871
Nested VirtualizedLists register to their parents for updates, associated to a specfific cellKey set by VirtualizedListCellContextProvider. This cellKey is usually set when rendering a cell for a data item, but we can also render a nested VirtualizedList by putting one in a ListHeaderComponent/ListFooterComponent/ListEmptyComponent.
D6603342 (https://github.com/facebook/react-native/commit/a010a0cebd4afc0d88336c2c265a5d9dbb19918f) added cellKeys when we render from a header/footer, but not ListEmptyComponent, so that association would silently fail earlier.
D39466677 (https://github.com/facebook/react-native/commit/010da67bef0c22418d0d41b7c2eae664672a4a27) added extra invariants to child list handling, that are now triggered by this case, complaining because we are trying to unregister a child list we never successfully registered, due to a missing cellKey.
This fixes the issue by providing a cellKey for ListEmptyComponent as well.
Changelog:
[General][Fixed] - Fix invariant violation when nesting VirtualizedList inside ListEmptyComponent
Reviewed By: christophpurrer
Differential Revision: D42574462
fbshipit-source-id: f76fa795bf471cb8a929c2efdbd814ea51927663
Summary:
react-native-navigation allows to register React components to be included in the navigation top bar as buttons, the way this work is by using the AppRegistry. When the ViewTreeObserver executes the `CustomGlobalLayout` we are checking for the RootWindowInsets in the `checkKeyboardEvents` which in the case for the top bar component it returns null and the **WindowInsetsCompat.toWindowInsetsCompat** function throws if the insets are null causing the app to crash.
Interestingly in the function `checkForKeyboardEventsLegacy` the null value is being checked, so I guess it was overlooked in the newer function.
## Changelog
[ANDROID] [FIXED] - Fix ReactRootView crash when root view window insets are null
Pull Request resolved: https://github.com/facebook/react-native/pull/35869
Test Plan:
The following videos show how the app crashes as soon as we attempt to pop a screen that contains a react component as a button in the navigation top bar and how it correctly pops to the previous screen after applying the fix
| Crash | Fix |
| -- | -- |
| https://user-images.githubusercontent.com/6757047/213116971-fe693989-f978-438c-b8f9-fc56f2a477c8.mp4 | https://user-images.githubusercontent.com/6757047/213118352-fe258f28-07aa-4d17-98d2-97136464ffd5.mp4 |
Reviewed By: cipolleschi
Differential Revision: D42580156
Pulled By: cortinico
fbshipit-source-id: 4dbd656d7c8148df67668a2a50913206bc35c07f
Summary:
Changelog: [IOS][ADDED] - Add explicit support for M2 iPad Apple Pencil hovering in the Pointer Events implementation
I personally am not a huge fan of how this has to be implemented but it's literally the way Apple suggests to differentiate between mouse and pen hover events.
Reviewed By: lunaleaps
Differential Revision: D40962916
fbshipit-source-id: a6fb5bcfe19bcf500021922baac3fa7c4375a874
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35857
It seems like there is an incompatibility between NDK 23 (shipped in 0.71)
and the usage of custom `CMAKE_BUILD_TYPE` we do for Hermes.
Specifically the `-DCMAKE_BUILD_TYPE=Release` we specify for the debug
variant of Hermes is partially ignored by the new Android native build toolchain.
See https://github.com/android/ndk/issues/463 for mentions on how the
toolchains requires CMake 3.20+
As AGP 7.3 defaults to use CMake 3.18 unless specified, and NDK 23 unless specified.
AGP 7.4 defaults to use CMake 3.22 unless specified, and NDK 23 unless specified.
See: https://developer.android.com/studio/releases/gradle-plugin#7-4-0
Here I'm:
1. Bumping the docker image to an image that contains the CMake 3.22
2. Updating the logic for building `react-native` & `hermes-engine` to use 3.22
3. Provide fallbacks if the user specified `CMAKE_VERSION`
Template tests will run on AGP 7.3 and will still use CMake 3.18, but I forecast
no problem there as the user is not supposed to specify custom `CMAKE_BUILD_TYPE`.
This is only a problem as we build `hermes-engine` with custom build types.
Changelog:
[Android] [Fixed] - Bump CMake to 3.22.1 to properly honor CMAKE_BUILD_TYPE
Reviewed By: cipolleschi
Differential Revision: D42544864
fbshipit-source-id: efd0f51120370fb808337c201df31d71f4ddfdbc
Summary:
While working on 0.71 branch I encountered a problem in testing locally. Basically, I was getting hit by a silent error caused by recent work https://github.com/facebook/react-native/pull/35296 that didn't account for the shape of E2E local script for the release, `0.71.0-20230116-1649`.
This scripts fixes both aspects: the error now gets thrown "better" and the logic accounts for the E2E shape.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[INTERNAL] [FIXED] - add logic for version scripts to account for local E2E test versioning
Pull Request resolved: https://github.com/facebook/react-native/pull/35846
Test Plan: Tested via the other PR: https://github.com/facebook/react-native/pull/35847
Reviewed By: cortinico
Differential Revision: D42543200
Pulled By: cipolleschi
fbshipit-source-id: 727eb887fcbd183ec56d8a9b7e98241eaacb1d98
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35872
When downgrading from AGP 7.4 to 7.3 we were forced to resort to older APIs
to bundle resources. It seems like we haven't properly wired the task to make sure
resources generated by Metro are correctly accounted before the generation of
release app bundles/apks.
This fixes it. This fix can also be removed once we are on AGP 7.4
Fixes#35865
Changelog:
[Android] [Fixed] - Fix for resources not correctly bundlded on release appbundles
Reviewed By: cipolleschi
Differential Revision: D42573450
fbshipit-source-id: a810924315f72e02e4c988ae86112bf0a06a9ce5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35860
I've just realized that the `--active-arch-only` is not correctly passed down
to RNGP to set up an abiFilter so users on 0.71 on New Architecture end up
building all the architectures even if `--active-arch-only` is set.
This fix makes sure the `abiFilters` is applied if the user specified
either the `--active-arch-only`, the `reactNativeArchitectures` property
and is not using the Split ABI feature.
Changelog:
[Android] [Fixed] - RNGP - Honor the --active-arch-only when configuring the NDK
Reviewed By: cipolleschi
Differential Revision: D42547987
fbshipit-source-id: 5a34e7087bb4f89de74cc52f9c505e36896fbf03
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35851
Yoga moved away from fbjni, to use vanilla JNI. This removes fbjni, and proguard annotations (see last stack) as Yoga dependencies from the OSS RN Buck build.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D42538671
fbshipit-source-id: c940d370d9d34bdb905c5dc9331e0bd57b5d49db
Summary:
Hi there,
While upgrading to 0.71 we realised the RCTAppDelegate doesn't offer a way to set custom `initProps` that would depend on `launchOptions`.
This PR adds an `initialProps` property to the RCTAppDelegate. This would let us set this property based on `launchOptions` in our implementation of `didFinishLaunchingWithOptions` before calling `[super didFinishLaunchingWithOptions]`
Thanks !
## Changelog
[IOS] [ADDED] - Add `initialProps` property to `RCTAppDelegate`
Pull Request resolved: https://github.com/facebook/react-native/pull/35848
Reviewed By: rshest
Differential Revision: D42543027
Pulled By: cipolleschi
fbshipit-source-id: 55374914890445f8193c12a06a943b7796edb457
Summary:
According to: https://jestjs.io/docs/configuration
> It is recommended to define the configuration in a dedicated JavaScript, TypeScript or JSON file. The file will be discovered automatically, if it is named jest.config.js|ts|mjs|cjs|json.
react-native projects have the jest config in package.json, this change aims to follow jest recommendations and have a dedicated file for jest configs.
Originally suggested here: https://github.com/react-native-community/discussions-and-proposals/discussions/583
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[GENERAL] [CHANGED] - Moved jest config from package.json to dedicated jest.config.js file
Pull Request resolved: https://github.com/facebook/react-native/pull/35856
Test Plan:
1. cd template
2. yarn
3. yarn test
The test should (still) pass
Reviewed By: christophpurrer
Differential Revision: D42544351
Pulled By: robhogan
fbshipit-source-id: e27d1dad2b52d757777c40a77d0639f381557c88
Summary:
Fix wording to make it clear that the issue / PR is marked stale because of inaction.
Changelog:
[Internal] - Fix wording that was meant to go in on D42531703 (https://github.com/facebook/react-native/commit/474c0edafea6d8fad4874a22bfd777bacf30a1f7)
Reviewed By: cortinico
Differential Revision: D42547980
fbshipit-source-id: 01e624ae66348d2528fa1f5bbbc2aacb24ddd865
Summary:
The `scrollEventThrottle` prop is documented as only applying to iOS, but in [this commit](https://github.com/facebook/react-native/commit/cf55fd587e6cc82a73079be6076d244ab72fa359) it was also implemented for Android, but the documentation was not updated.
## Changelog
[GENERAL] [CHANGED] - Removed iOS flag from `scrollEventThrottle` docs
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/35840
Test Plan: I've not been able to find how to build the docs locally, so I don't have a screenshot of the changes :(
Reviewed By: cipolleschi
Differential Revision: D42530943
Pulled By: sammy-SC
fbshipit-source-id: 2948eca2621712ccd832f4f99f1aab0cbd4af2d0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35849
Users will provide issues or examples that use unsupported versions of React Native. Provide label to track and ask them to update example / issue to currently mainted version.
Changelog:
[Internal] - Support 'unsupported version' tag comment
Reviewed By: cortinico
Differential Revision: D42531703
fbshipit-source-id: 5577943a329e17147269b9e5a5da2b2c16a6ae3e
Summary:
Remove deprecated `File.exists` method which was removed in later Ruby versions. Spotted during a brew upgrade [here](https://github.com/software-mansion/react-native-reanimated/pull/3919).
https://rubyapi.org/2.5/o/file#method-c-exist-3F
```
Fetching podspec for `hermes-engine` from `../node_modules/react-native/sdks/hermes-engine/hermes-engine.podspec`
[!] Failed to load 'hermes-engine' podspec:
[!] Invalid `hermes-engine.podspec` file: undefined method `exists?' for File:Class.
# from [..]/node_modules/react-native/sdks/hermes-engine/hermes-engine.podspec:46
```
## Changelog
[IOS] [FIXED] - Migrated `File.exists` from Hermes podspec for non-deprecated `File.exist`.
Pull Request resolved: https://github.com/facebook/react-native/pull/35853
Test Plan: Valid CI via CircleCI.
Reviewed By: dmytrorykun
Differential Revision: D42543148
Pulled By: cipolleschi
fbshipit-source-id: 5ed30d8cc3e4c91a6e86d51f7d44a125bf85f7e8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35841
X-link: https://github.com/facebook/litho/pull/928
X-link: https://github.com/facebook/yoga/pull/1216
The Yoga JNI bindings use Reflection, so we need to let ProGuard know not to strip certain annotated fields.
This is done internally using a single copy of `com.facebook.proguard.annotations` from fbandroid (sometimes), which is then repackaged externally, and published as its own whole Yoga specific package. We never actually inform the stock Gradle project of the rules for the annotations though, so apps must add these manually.
This simplifies the setup, where Yoga has its own self-contained annotations/rules. The rules are exposed for Gradle/Buck dependencies, but RN and Litho both consume Yoga via dirsync + custom Gradle logic, so we need to duplicate the proguard rules to them instead of them being propagated automatically.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D42406641
fbshipit-source-id: c2b12fd498f93f144e5651917ca878d2a5050e08
Summary:
X-link: https://github.com/facebook/yoga/pull/1217
This updates the CMake build present for being able to share options, fixing up flags, etc. A GTest build is added as well, along with a script and VSCode debug target so that OSS contributors can very easily run and debug tests on any OS.
Note that this isn't completely done (need to revise Windows, Mac, documentation), but should be finished enough otherwise for review.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D42406686
fbshipit-source-id: 95e7ba5e4751c496a171785490e85cf0097fa839
Summary:
Fixes an error in the `reactConsoleErrorHandler` comment
## Changelog
[GENERAL] [FIXED] - Fixed a typo in the `reactConsoleErrorHandler` comment
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/35830
Test Plan: No tests needed
Reviewed By: cipolleschi
Differential Revision: D42529639
Pulled By: cortinico
fbshipit-source-id: 89a01838bae6c260f510a9bedcc48b157fcf859b
Summary:
The starter test file when creating a `create-react-app` project is `App.test.js`, while in react-native its `App-test.js`_(recently changed to `.tsx` instead of `.js`)_
This aims to unify the naming convention between `create-react-app` and `react-native init`.
Originally suggested here: https://github.com/react-native-community/discussions-and-proposals/discussions/570
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[GENERAL] [CHANGED] - Renamed App-test.tsx to App.test.tsx to unify naming convention with create-react-app
Pull Request resolved: https://github.com/facebook/react-native/pull/35826
Test Plan:
1. cd template
2. yarn
3. yarn test
The test inside `__tests__/App.test.tsx` should (still) pass
Reviewed By: cipolleschi
Differential Revision: D42527535
Pulled By: NickGerleman
fbshipit-source-id: 5247c5a65760973afe39a4b37abb5a6b52c1fadc
Summary:
Upgrades Danger to the latest available version to mitigate the jsonwebtoken security vulnerability.
Changelog:
[Internal] [Changed] - Upgrade Danger to 11.2.1 to mitigate jsonwebtoken security vulnerability
Reviewed By: cortinico
Differential Revision: D42505940
fbshipit-source-id: 740edc7316791e5afe894ecdd1e05e13d2ef1f2c
Summary:
On Fabric, `onContentSizeChange` of `TextInput` component was never fired on `iOS`, since the logic dispatching it was implemented in `RCTBaseTextInputShadowView` on Paper: https://github.com/facebook/react-native/blob/0f8dc067ac079f7b14696cfcafa37e3ec19a0409/Libraries/Text/TextInput/RCTBaseTextInputShadowView.m#L105. This class is not used on Fabric, therefore the event was never dispatched. On Paper, it was dispatched in `dirtyLayout` method, so I added dispatching of this event based on the change of content size in `layoutSubviews` method, since this method seems the closest one on Fabric. I am not sure if it is the best place for it though.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[IOS] [ADDED] - dispatch `onContentSizeChange` event on Fabric.
Pull Request resolved: https://github.com/facebook/react-native/pull/35816
Test Plan:
Try to use `onContentSizeChange` callback in `TextInput` component:
```tsx
import React from 'react';
import {TextInput, SafeAreaView} from 'react-native';
const App = () => {
return (
<SafeAreaView style={{flex: 1, backgroundColor: 'red'}}>
<TextInput
multiline={true}
placeholder="type here"
onContentSizeChange={e => console.log(e)}
/>
</SafeAreaView>
);
};
export default App;
```
Reviewed By: christophpurrer
Differential Revision: D42499974
Pulled By: sammy-SC
fbshipit-source-id: 3e010ff096cf91cb3e7b87ed2753e9d0e7be9650
Summary:
Turbo module codegen support interface like alias in module.
In typescript, interface allows inheritance, but the codegen schema doesn't have such information. In this PR the codegen schema is not changed, interfaces are flattened.
In the next change, I will update the codegen schema so that it allows inheritance, in order to generate more precise C++ code.
## Changelog
[GENERAL] [CHANGED] - Turbo module codegen support interface like alias in module
Pull Request resolved: https://github.com/facebook/react-native/pull/35812
Test Plan: `yarn jest react-native-codegen` passed
Reviewed By: cortinico
Differential Revision: D42475368
Pulled By: cipolleschi
fbshipit-source-id: 26025f8a55b600dfea27026c998cd8b5fe752af4
Summary:
Adds changelog for new release.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - add changelog entry for 0.71.0
Pull Request resolved: https://github.com/facebook/react-native/pull/35200
Test Plan: N/A
Reviewed By: dmytrorykun
Differential Revision: D42477941
Pulled By: cipolleschi
fbshipit-source-id: be91742d8800051b9b167b66592b43e715b9a893
Summary:
Update the CircleCI configuration to use the proper `exclude` parameter of matrix rather then bootstrap a machine and then kill it.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
## Changelog
[Internal] - Use the `exclude` parameter of matrices to avoid spinning up unnecessary machines
Pull Request resolved: https://github.com/facebook/react-native/pull/35794
Test Plan: The number of jobs on CircleCI should decrease.
Reviewed By: dmytrorykun
Differential Revision: D42475445
Pulled By: cipolleschi
fbshipit-source-id: 3d733ac459a3bc9747440a62cb2caecb7a235fec
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35810
Changelog: [Internal]
`bump-all-updated-packages` script now supports `release-branch-cutoff` argument
If this argument is provided, the script will bump each public package to next minor version
Updated [wiki](https://github.com/facebook/react-native/wiki/Release-and-its-automated-processes) with relevant information about how to use it
Reviewed By: cortinico
Differential Revision: D42455329
fbshipit-source-id: a40d2f5dc356f22d3182da3a118c6383b634817d
Summary:
There is a large amount of autogenerated files in the coverage folder when running `jest --coverage`.
This folder is also in .gitignore for react projects created with `create-react-app`
Originally suggested here: https://github.com/react-native-community/discussions-and-proposals/discussions/569
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[GENERAL] [ADDED] - Added "coverage" folder generated på `jest --coverage` to .gitignore
Pull Request resolved: https://github.com/facebook/react-native/pull/35809
Test Plan:
1. cd template
2. yarn
3. yarn test --coverage
Im not sure why many of the files in the template folder have an underscore(_) in the filenames instead of a dot(.). When creating a react-native project they have a dot. So if you run the above commands, the coverage folder will not be ignored since its not in `.gitingore` but in `_gitignore`. However, if you temporarily create a `.gitignore` file, you will see that the coverage folder is ignored.
4. Temporarily create `.gitignore` file to verify that coverage folder is ignored
Reviewed By: cortinico
Differential Revision: D42454560
Pulled By: jacdebug
fbshipit-source-id: 0be007d3ba3dde47814c0ce0fb8b0ff9f67d637b
Summary:
Changelog: [Internal]
just a small cleanup, moved all tests related to monorepo scripts under `/scripts/monorepo`
Reviewed By: cortinico
Differential Revision: D42308455
fbshipit-source-id: 7743a2af1381ff748556c15b89cf980f8f907674
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35767
Changelog: [Internal]
Introducing a script, which can be used to identify all packages inside `/packages`, which contain any changes after the last time its version was changed
How it works step by step:
```
check that no git changes are present
for each package:
if package is private -> skip
grep id of the last commit that changed package
grep id of the last commit that changed version of the package
if these ids are different:
bump package patch version
commit changes if required
```
Can be executed only in git environment and by running: `node ./scripts/bump-all-updated-packages`
---
Also adding a separate script `align-package-versions.js`, which can be used to update versions of packages inside consumer packages
```
check that no git changes are present
for each package x:
for each package y:
if y has x as dependency:
validate that y uses the latest version of x
if some changes were made:
run yarn
```
---
Q: Why `run_yarn` step was removed from CircleCI flow?
A: For *-stable branches, there are no yarn workspaces and all packages are specified as direct dependencies, so if we update `react-native/assets-registry` to the next version, we won't be able to run `yarn` for react-native root package, because updated version is not yet published to npm
To avoid this, we first need publish new versions and then update them in consumer packages
---
The final flow:
1. Developer uses `node ./scripts/bump-all-updated-packages` to bump versions of all updated packages.
2. Commit created from step 1 being merged or directly pushed to `main` or `*-stable` branches
3. A workflow from CircleCI publishes all updated versions to npm
4. Developer can use `align-package-versions.js` script to create required changes to align all packages versions
Reviewed By: cortinico
Differential Revision: D42295344
fbshipit-source-id: 54b667adb3ee5f28d19ee9c7991570451549aac2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35792
This Diff fixes a problem we have when running Ruby tests.
The previous approach was monkey-patching the Ruby File and Dir classes to override some behaviours we needed during tests. However, these classes are also used by the test runners to properly read and run the tests, therefore when the tests were failing, the stream weren't closed properly and we received the wrong errors.
This problem was also preventing us from adopting other Ruby tools like SimpleCov to compute code coverage.
## Changelog:
[internal] - refactor Ruby tests not to monkey patch Dir and File
Reviewed By: dmytrorykun
Differential Revision: D42414717
fbshipit-source-id: 879b9928da1a083ebf9c81b1f510eaa039376042
Summary:
This is always enabled internally, so we should just turn it on everywhere.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D42406509
fbshipit-source-id: c9cdd4fcf907d66cd276e0aec608a2e7db7ca5fb
Summary:
Fixes https://github.com/facebook/yoga/issues/850https://github.com/facebook/yoga/issues/850 describes a conformance issue where positioning of an absolute child using percentages is not calculated against the correct box size.
This takes the fix for that in https://github.com/facebook/yoga/pull/1028, regenerates tests, and fixes tests so that the experimental feature can be enabled. Goal is to run this as an experiment internally to see if we can enable by default.
Changelog:
[Internal]
X-link: https://github.com/facebook/yoga/pull/1201
Reviewed By: yungsters
Differential Revision: D42282358
Pulled By: NickGerleman
fbshipit-source-id: 57c0dd9b0f1c47cb9335ff6e13d44b4646e5fa58
Summary:
Removing a stale configuration that was configuring username/password before publishing to NPM. This is effectively unused + the Github Token there is invalid therefore can be removed.
## Changelog
[INTERNAL] - Remove unused .netrc file from CircleCI
Pull Request resolved: https://github.com/facebook/react-native/pull/35785
Test Plan: n/a
Reviewed By: cipolleschi
Differential Revision: D42385163
Pulled By: cortinico
fbshipit-source-id: 0dbbf44459d59f792da4221d6100800a2f4efda2
Summary:
This PR implements logical border-radius as requested on https://github.com/facebook/react-native/issues/34425. This implementation includes the addition of the following style properties
- `borderEndEndRadius`, equivalent to `borderBottomEndRadius`.
- `borderEndStartRadius`, equivalent to `borderBottomStartRadius`.
- `borderStartEndRadius`, equivalent to `borderTopEndRadius`.
- `borderStartStartRadius`, equivalent to `borderTopStartRadius`.
## Changelog
[GENERAL] [ADDED] - Add logical border-radius implementation
Pull Request resolved: https://github.com/facebook/react-native/pull/35572
Test Plan:
1. Open the RNTester app and navigate to the `RTLExample` page
2. Test the new style properties through the `Logical Border Radii Start/End` section
https://user-images.githubusercontent.com/11707729/206623732-6d542347-93f9-40da-be97-f7dcd5f66ca9.mov
Reviewed By: necolas
Differential Revision: D42002043
Pulled By: NickGerleman
fbshipit-source-id: a0aa9783c280398b437aeb7a00c6eb3f767657a5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35777
As Flipper version is a bit old, let's bump it to the latest stable: 0.174.0.
This is a follow-up from D41492705 (https://github.com/facebook/react-native/commit/db3ac93001f65bad84b748ec257fe79b79432976).
At the time, it wasn't possible to update to the latest stable Flipper as crashes were observed due to NDK mismatch.
allow-large-files
Changelog:
[iOS] [Changed] - Bump Flipper to 0.174.0
Reviewed By: cortinico, cipolleschi
Differential Revision: D42345736
fbshipit-source-id: 501e068aebfc25f6a50332391a7940aa9eec6fd6
Summary:
[Changelog][Internal]
The diff changes underlying storage types used by different enums that are used in ViewProps data structure, together with some eventual field rearranging to reduce padding overhead.
This **shaves off 128 bytes** from each `ViewProps` instance, which is **a ~10% improvement**.
Given that an average RN app may have thousands of shadow tree nodes, and correspondingly `ViewProps` instances in flight (e.g. Oculus Store has 2-3K of them nominally), the overall memory win is about **300K+** for this change only. Plus slightly better cache locality, which never a bad thing either.
Reviewed By: mdvacca
Differential Revision: D42372127
fbshipit-source-id: d3a832af2b2e89f50a5b8e04d24d0df92869ea4d
Summary:
Changelog: [Internal]
`MapBuffer` already has a move constructor but did not have a move assignment operator prior to this diff. Changing this requires removing the `const` qualifier from `bytes_`, but this seems OK in practice as it will still be treated as `const` by all the `const` accessors on `MapBuffer`.
Reviewed By: RSNara
Differential Revision: D42369493
fbshipit-source-id: f0fcce533d8e0883dcf85d7262620ea77f377644
Summary:
Changelog: [Fixed][General] Filter out Hermes internal bytecode frames (Promise implementation) from error stack traces
Currently, React Native strips native frames from call stacks reported via ExceptionsManager / LogBox. This diff does the same for *internal bytecode* frames in Hermes, which are functionally similar to native frames: they are implementation details of the engine for which source code isn't readily available.
In particular this change will avoid confusing symbolication tools that may otherwise try to treat `InternalBytecode.js` frames as belonging to the main React Native bundle (and produce garbage output).
Reviewed By: GijsWeterings
Differential Revision: D42367135
fbshipit-source-id: b7904f10c7ff6956e7b736b575dde1ce45028200
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35709
This change refactors the logic to choose which version of hermes we have to pick
## Changelog:
[iOS][Changed] - Refactor hermes choosing logic
Reviewed By: cortinico, dmytrorykun
Differential Revision: D42211405
fbshipit-source-id: d19c0f2c523c5596d18a1f904e3b26d96ea1a77a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35773
Changelog:
[Android][Added] - For supporting Dev Loading View across multiple platforms, changing the Loading View of Android to rely on the native implementation instead of Toast while keeping backwards comptability.
Reviewed By: rshest
Differential Revision: D42286466
fbshipit-source-id: 38749cdbc11208b81a6199467bac00cbc1850c92
Summary:
On iOS 13.0+, app may use SceneDelegate for multiple windows support or CarPlay support. RCTAlertController can't find the correct root vc in such scene based apps.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[iOS] [Fixed] - Fix RCTAlertController not showing when using SceneDelegate on iOS 13.0+.
Pull Request resolved: https://github.com/facebook/react-native/pull/35716
Reviewed By: cipolleschi
Differential Revision: D42253653
Pulled By: makovkastar
fbshipit-source-id: ae4e833abca2af7af8028f3af9bd8d3f60ebd392
Summary:
Repair when RCTRedBoxGetEnabled is false , the red box will still be on display,It resolve that I send test-pack to QA with Xcode Archive on DEBUG env.
## Changelog
[General] [Changed] - Append RCTRedBoxGetEnabled() in RCTExceptionsManager.mm
Pull Request resolved: https://github.com/facebook/react-native/pull/35576
Test Plan: Xcode Archive on DEBUG env, the red box will be not on display.
Reviewed By: cipolleschi
Differential Revision: D41809649
Pulled By: skinsshark
fbshipit-source-id: 7d6be3479decf369c415f6a08dec9611b1441b1d
Summary:
[Changelog][Internal]
Use the [list of supported events](https://www.w3.org/TR/event-timing/#sec-events-exposed) explicitly to both filter and transform reported event types, which makes this both more robust and less ambiguous.
The mapping is using a compile-time hash/lookup, similarly to how we do it with the ViewProps in the RN core.
Reviewed By: rubennorte
Differential Revision: D42342655
fbshipit-source-id: 3d0b2465fd5611db110c4792913e0a92e76cd067
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35771
[Changelog][Internal]
Based on the internal discussion, we don't want to report `first-input` event types for RN (just use plain `event` instead), in the way that [Event Timing API standard suggests](https://www.w3.org/TR/event-timing), as this is doesn't have that clear semantics in the context of RN, also to keep it simpler.
Reviewed By: rubennorte
Differential Revision: D42341923
fbshipit-source-id: eff2487dee17ef082604e4c807b4d41485328114
Summary:
Add `onStartReached` and `onStartReachedThreshold` to `VirtualizedList`. This allows implementing bidirectional paging.
## Changelog
[General] [Added] - Add onStartReached and onStartReachedThreshold to VirtualizedList
Pull Request resolved: https://github.com/facebook/react-native/pull/35321
Test Plan: Tested in the new RN tester example that the callback is triggered when close to the start of the list.
Reviewed By: yungsters
Differential Revision: D41653054
Pulled By: NickGerleman
fbshipit-source-id: 368b357fa0d83a43afb52a3f8df84a2fbbedc132
Summary:
Enhancing native iOS modules and preventing crashes inside the RCTAlertController
## Changelog
[iOS][Fixed] - Handle properly a `nil` `keyWindows` in the AlertController
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[IOS] [SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/35689
Reviewed By: cipolleschi
Differential Revision: D42179169
Pulled By: ryancat
fbshipit-source-id: 05a6788f610db1d222e3c10b3c774c75edaf55f5
Summary:
This diff fixes accessibility value setter in BaseViewManager.java when the accessibility value is null. This is needed when we reset the value and would like to make sure the content description reflects the expected state, instead of the stale state when the value is set last time.
Changelog:
[Android][Fixed] - Reset accessibility value when it gets a null value
Reviewed By: NickGerleman
Differential Revision: D42160904
fbshipit-source-id: a8115a268461c8340d38350ab6fd3f21e4b14959
Summary:
- there was a bug when `contentOffset` was set to {x:0, y:0} and there were items lazy loaded in with prop changes- the View would consistently scroll back to the top after loading in new items
- to avoid this, we store the offset value when it's first set, and only run the `scrollTo` logic then
Changelog:
[Internal][Fixed] - Fix contentOffset forcing scroll to top behavior
Reviewed By: fkgozali, mdvacca
Differential Revision: D42089871
fbshipit-source-id: 3968d98341728a45bec28e8783c9977e91dd4d2c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35768
Changelog: [Internal]
This implements native side mechanics for reporting user events timing to JS (PerformanceObserver API).
See the standard for more details: https://www.w3.org/TR/event-timing/
The events are only logged when there are any active subscriptions (via `PerformanceObserver.observe`), also we only log "discrete events" (i.e. no likes of mouse move), so the overhead is non-existing.
There are two main metrics of interest for an event lifecycle:
* Time the event is spent in the queue, i.e. the time between it's created and dispatched
* Time that is spend in the event handler on the JS side (event dispatch), or processing time
Both of these are measured, and the corresponding fields are populated.
Reviewed By: sammy-SC
Differential Revision: D42294947
fbshipit-source-id: 4fd7938c04b942400befa4057d4929fb2763cee1
Summary:
Fixes incorrect logging that I found whilst debugging
## Changelog
[Android] [FIXED] - Fixed incorrect logging of `isCatalystInstanceAlive` in exception handler
Pull Request resolved: https://github.com/facebook/react-native/pull/35708
Test Plan: N/A as change is related to logging
Reviewed By: christophpurrer
Differential Revision: D42233178
Pulled By: robhogan
fbshipit-source-id: f48e5abc036393a40f836cf0bf8c1d69f03ca848
Summary:
This PR slightly improves the implementation of `dispatchCommand` method of `UIManagerBinding` to use existing variable `shadowNode` instead of calling `shadowNodeFromValue` again.
## Changelog
[INTERNAL] [CHANGED] - Eliminated double call of `shadowNodeFromValue` in `dispatchCommand`
Pull Request resolved: https://github.com/facebook/react-native/pull/35695
Test Plan: Launch RNTester with Fabric enabled and check if `scrollTo` or some other command works properly.
Reviewed By: christophpurrer
Differential Revision: D42233216
Pulled By: robhogan
fbshipit-source-id: db152206060ff599962f47c43fda8ea797f2a8cb
Summary:
Changelog: [General][Security]
The parse method of the `JSON5` library before and including `2.2.1` does not restrict parsing of keys named `__proto__`, allowing specially crafted strings to pollute the prototype of the resulting object. This vulnerability pollutes the prototype of the object returned by JSON5.parse and not the global Object prototype, which is the commonly understood definition of Prototype Pollution. However, polluting the prototype of a single object can have significant security impact for an application if the object is later used in trusted operations.
This vulnerability could allow an attacker to set arbitrary and unexpected keys on the object returned from `JSON5.parse`. The actual impact will depend on how applications utilize the returned object and how they filter unwanted keys, but could include denial of service, cross-site scripting, elevation of privilege, and in extreme cases, remote code execution.
Suppose a developer wants to allow users and admins to perform some risky operation, but they want to restrict what non-admins can do. To accomplish this, they accept a JSON blob from the user, parse it using `JSON5.parse`, confirm that the provided data does not set some sensitive keys, and then performs the risky operation using the validated data:
```json
const JSON5 = require('json5');
const doSomethingDangerous = (props) => {
if (props.isAdmin) {
console.log('Doing dangerous thing as admin.');
} else {
console.log('Doing dangerous thing as user.');
}
};
const secCheckKeysSet = (obj, searchKeys) => {
let searchKeyFound = false;
Object.keys(obj).forEach((key) => {
if (searchKeys.indexOf(key) > -1) {
searchKeyFound = true;
}
});
return searchKeyFound;
};
const props = JSON5.parse('{"foo": "bar"}');
if (!secCheckKeysSet(props, ['isAdmin', 'isMod'])) {
doSomethingDangerous(props); // "Doing dangerous thing as user."
} else {
throw new Error('Forbidden...');
}
```
If an attacker attempts to set the `isAdmin` key, their request will be rejected:
```js
const props = JSON5.parse('{"foo": "bar", "isAdmin": true}');
if (!secCheckKeysSet(props, ['isAdmin', 'isMod'])) {
doSomethingDangerous(props);
} else {
throw new Error('Forbidden...'); // Error: Forbidden...
}
```
However, attackers can instead set the __proto__ key to {"isAdmin": true}. JSON5 will parse this key and will set the isAdmin key on the prototype of the returned object, allowing the attacker to bypass the security check and run their request as an admin:
```js
const props = JSON5.parse('{"foo": "bar", "__proto__": {"isAdmin": true}}');
if (!secCheckKeysSet(props, ['isAdmin', 'isMod'])) {
doSomethingDangerous(props); // "Doing dangerous thing as admin."
} else {
throw new Error('Forbidden...');
}
```
CVE-2022-46175
[CWE-1321](https://cwe.mitre.org/data/definitions/1321.html)
Pull Request resolved: https://github.com/facebook/react-native/pull/35759
Reviewed By: christophpurrer
Differential Revision: D42304806
Pulled By: rshest
fbshipit-source-id: 4ad338c878e8a235ea6b22d9f4d203c8f7779a63
Summary:
The variable `version` is previously used but in https://github.com/facebook/react-native/commit/234486068e7f547450829d17e8d5db111a1571bc#diff-adcf572f001c2b710d14f409c14763f1a50b08369b3034548f1602685d21f67f, its usage have been removed the but the variable is kept.
It also raises an error when using `bundle exec pod install --project-directory=ios` which works on `0.70.X` and below.
```txt
No such file or directory @ rb_sysopen - ../node_modules/react-native/package.json
/Users/davidangulo/Desktop/mobile/myapp/node_modules/react-native/scripts/react_native_pods.rb:212:in `read'
/Users/davidangulo/Desktop/mobile/myapp/node_modules/react-native/scripts/react_native_pods.rb:212:in `react_native_post_install'
```
## Changelog
[IOS] [FIXED] - pod install with --project-directory
Pull Request resolved: https://github.com/facebook/react-native/pull/35754
Test Plan: `bundle exec pod install --project-directory=ios` should not raise an error.
Reviewed By: christophpurrer
Differential Revision: D42298517
Pulled By: rshest
fbshipit-source-id: bef0b03312d2029188ae5437e3baf3ffce5cb73f
Summary:
When inheriting `RCTAppDelegate` in a module with swift code, the compiler will have a build error when it goes through module headers. because swift does not support cxx headers. we found this issue when we try to inherit the class at Expo's [`EXAppDelegateWrapper`](https://github.com/expo/expo/blob/main/packages/expo-modules-core/ios/AppDelegates/EXAppDelegateWrapper.h) with RCTAppDelegate in new architecture mode.
## Changelog
[IOS][FIXED] - Fix build errors when inheriting RCTAppDelegate in Swift modules
Pull Request resolved: https://github.com/facebook/react-native/pull/35661
Test Plan:
- ci passed
- tested with expo's setup: https://github.com/expo/expo/pull/20470
Reviewed By: rshest
Differential Revision: D42293851
Pulled By: cipolleschi
fbshipit-source-id: 8a173279db070cc0008c6f8214093951f504dcc1
Summary:
This is not a task from https://github.com/facebook/react-native/issues/34872 but it goes towards the same goal: removing language-specific logic from shared code and moving it to the FlowParser and TypeScriptParser.
I'm not sure about the documentation of the functions. It's been quite difficult for me to understand what the arguments are and what is returned by the functions because I find the naming quite confusing and nothing is typed.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[INTERNAL] [CHANGED] - [Codegen] Move language ternaries logic to FlowParser and TypeScriptParser
Pull Request resolved: https://github.com/facebook/react-native/pull/35742
Test Plan: I tested using Flow and Jest commands. I made sure that tests were broken when Flow and TypeScript implementations were reversed.
Reviewed By: NickGerleman
Differential Revision: D42280934
Pulled By: rshest
fbshipit-source-id: 580ebdf424a5c179c9928ac5f9441899fb04d0c7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35744
Changelog:
[Android][Fixed] - LoadingView of Android to use the Toast till the native implementation is functional
Reviewed By: lunaleaps
Differential Revision: D42284732
fbshipit-source-id: dc187e4602240f270b2fbfb40e47604e3a14415d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35743
Changelog:
[Android][Added] - For supporting Dev Loading View across multiple platforms, altering the javascript implementation of Loading view of android to also rely on native implementation as iOS instead of Toast, thereby unifying both platforms
Reviewed By: rshest
Differential Revision: D42258041
fbshipit-source-id: 1be56c1e5696b1024ba09a0aa11da96e0a08f210
Summary:
Changelog: [Internal]
This adds definition of `PerformanceEventTiming` interface, according to the W3C standard, so that [event timing](https://www.w3.org/TR/event-timing) data can be reported from native (the C++ part is in the next diff).
See here: https://www.w3.org/TR/event-timing/#performanceeventtiming
Reviewed By: christophpurrer
Differential Revision: D42279486
fbshipit-source-id: 0dfbcd6e5a08fc1b89651bd35b24fb4e731f8b05
Summary:
Changelog: [Internal]
While working on implementing [Event Timing API](https://www.w3.org/TR/event-timing/) I've noticed that there are multiple compiler warnings about unused lambda captures, which are coming from generated C++ code for EventEmitters.
This modifies the codegen so that the corresponding lambda doesn't capture event variable if it's not used in the event handler, thus getting rid of warnings.
Reviewed By: christophpurrer
Differential Revision: D42281899
fbshipit-source-id: 98442bb9f3ce374755188d818a9b2d6a8050bf15
Summary:
[Changelog][Internal]
This appears to be a regression from https://github.com/facebook/yoga/pull/1195
The `yoga/internal/experiments.cpp` was removed, but the corresponding Pod cache wasn't updated, which made the RNTester iOS to start fail.
Reviewed By: christophpurrer
Differential Revision: D42268322
fbshipit-source-id: 8db1118787ed41cde10babe6845f6d05a8f86bc2
Summary:
[Changelog][Internal]
Both iOS and Android platforms are at this point using the same native implementation of `performanceNow`, based on `std::chrono` (it used to be different some time ago).
This diff unifies the implementations, so it comes from one place in C++ code for all platforms.
The context is that I am developing event timing instrumentation and need a consistent way to get current timestamp from either JS or native (C++) side. The latter is now possible via calling `JSExecutor::performanceNow()`, which is guaranteed to be the same as called from JS.
Reviewed By: christophpurrer
Differential Revision: D42267898
fbshipit-source-id: dcb592f37d6567340ea59faddbf3b6d2b8507d50
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35731
[Changelog][Internal]
The initial intent was to try and use `unique_ptr` instead of `shared_ptr`, however turns out it complicates code more than it's worth it, so I ended up just factoring the repeated complex parts of the corresponding code to make it easier to reason about.
Reviewed By: christophpurrer
Differential Revision: D42265274
fbshipit-source-id: 105f57b449934c2e3227e592a76036ca7f61bc35
Summary:
This is not a task from https://github.com/facebook/react-native/issues/34872 but I noticed that we were passing `language` arguments that were never used for several errors so I removed them.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[INTERNAL] [CHANGED] - Remove unused language argument in Codegen errors
Pull Request resolved: https://github.com/facebook/react-native/pull/35732
Test Plan: I tested using Flow and Jest.
Reviewed By: christophpurrer
Differential Revision: D42266490
Pulled By: rshest
fbshipit-source-id: 7953a98586bf9e927a58222cc27cf88e9c1c1163
Summary:
changelog: [internal]
This is experimental implementation of `setNativeProps` in Fabric.
This diff brings `setNativeProps` to Fabric to make migration easier. I tried to stay as close as possible to Paper's behaviour, with all of its flaws (ready CAUTION section on https://reactnative.dev/docs/direct-manipulation)
State can't be stored in views because on iOS, eventually on Android, views are not the source of truth, shadow tree is. Fabric's implementation keeps state from setNativeProps in shadow node family in very inefficient data structure folly::dynamic. It is always reconciled with new prop updates. The performance cost is only paid in case node has used `setNativeProps` before.
Reviewed By: mdvacca
Differential Revision: D41875413
fbshipit-source-id: 453a5f7612a6f86a4cece269b13bd2ffd0c0e2d1
Summary:
This PR implements `inset` logical properties as requested on https://github.com/facebook/react-native/issues/34425. This implementation includes the addition of the following style properties
- `inset`, equivalent to `top`, `bottom`, `right` and `left`.
- `insetBlock`, equivalent to `top` and `bottom`.
- `insetBlockEnd`, equivalent to `bottom`.
- `insetBlockStart`, equivalent to `top`.
- `insetInline`, equivalent to `right` and `left`.
- `insetInlineEnd`, equivalent to `right` or `left`.
- `insetInlineStart`, equivalent to `right` or `left`.
## Changelog
[GENERAL] [ADDED] - Add Fabric implementation of inset logical properties
Pull Request resolved: https://github.com/facebook/react-native/pull/35692
Test Plan:
1. Open the RNTester app and navigate to the `View` page
2. Test the new style properties through the `Insets` section
<table>
<tr>
<td>Android</td>
<td>iOS</td>
</tr>
<tr>
<td><img src="https://user-images.githubusercontent.com/11707729/208821212-fbbac6ed-09a4-43f4-ba98-dfd2cbabf044.png" alt="1" width="360px" />
</td>
<td>
<img src="https://user-images.githubusercontent.com/11707729/208816997-ef044140-8824-4b1b-a77b-085f18ea9e0e.png" alt="2" width="360px" />
</td>
</tr>
</table>
Reviewed By: NickGerleman
Differential Revision: D42193661
Pulled By: ryancat
fbshipit-source-id: 3db8bcd2c4db0ef4886b9ec49a46424d57362620
Summary:
- Use ThemedReactContext explicitly to reduce confusion, "addLifecycleEventListener()" and "removeLifecycleEventListener" should be forced to call on ThemedReactContext
- Migrate "getNativeModule" and "handleException" calls from ThemedReactContext to ThemedReactContext.getReactApplicationContext
Changelog:
[Android][Changed] - Use ThemedReactContext explicitly to reduce confusion
Reviewed By: mdvacca
Differential Revision: D42101979
fbshipit-source-id: be34b7397ccf4f58477bab6cfa8c58eedd99e225
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35679
The Codegen cleanup step was not always working due to an issue with the codegen folder path. It was working for RNTester, but not for apps created from the Template.
## Changelog:
[iOS][Fixed] - Fix path issue to properly run the codegen cleanup step
Reviewed By: jacdebug
Differential Revision: D42137600
fbshipit-source-id: ba4cb03d4c6eb17fda70a4aff383908d2e468429
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35672
While working on some example, I discovered that the helper function `install_module_dependencies` was not adding the proper `-DRCT_NEW_ARCH_ENABLED=1` flag to the compiler flags.
## Changelog:
[iOS][Fixed] - Make sure to add the New Arch flag to libraries
Reviewed By: jacdebug
Differential Revision: D42131287
fbshipit-source-id: 68c492150ba4e4a2ec726b3e8b8a9c7842b543bc
Summary:
This diff is moving all relevant cxx component classes out of react-native-github, this is necessary to make it easy to iterate on their APIs
We will move them back again to OSS once we make the API stable
changelog: [internal] internal
Reviewed By: arhelmus
Differential Revision: D42018363
fbshipit-source-id: bacf0c667e2e8df57b4b57e257bf937586b8e6f7
Summary:
Extends the WebPerformance API with ability to report events, [according to the standard](https://www.w3.org/TR/event-timing/#sec-performance-event-timing).
This is an API-only change, the actual reporting comes in a separate diff, to simplify reviewing.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D42097695
fbshipit-source-id: d8b468ffed50c1c3d889151df5e8ca644d6e1a68
Summary:
Prevents scenarios when internal performance buffer may grow indefinitely (e.g. due to a broken logging), communicating back to `PerformanceObserver` the corresponding amount of dropped entries, `droppedEntriesCount`, [according to the standard](https://w3c.github.io/performance-timeline/#dom-performanceobservercallbackoptions-droppedentriescount).
NOTE: The backwards compatibility check is failing, which is an orthogonal issue. I am looking into it and won't land this one before it is sorted.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D42008409
fbshipit-source-id: 40d30e44d39e643bfb58a6254572823cb2b3b8df
Summary:
Now that D42097191 allows it, get rid of unused API in the related WebPerformance native modules (these were kept there only to pacify the backwards compatibility checks).
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D42037757
fbshipit-source-id: 5f5e7e76722cade9e730aba037f9e8ab51fc16d9
Summary:
This diff is fixing a NullPointerException occuring when using Placeholder in TextInput. In some particular scenarios Placeholder is being updated before the TextInput is even layed out.
In this diff I'm setting a defult LayoutParams to avoid NullPointerException to be thrown by android EditTextView. This change should not affect layout for TextInput components because layout will be overriden on the next Fabric commit.
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D42078080
fbshipit-source-id: 294376e7f78d6ed58fc9f893553356553accba6c
Summary:
This PR adds a safety check in case the Cocoapod build script is not able to clean the build folder.
We had evidences where this process failed, and in this way the user has a clear and actionable message to fix its situation.
## Changelog
[iOS][Added] - Add message with instructions about what to do if the cleanup of the build folder fails.
Pull Request resolved: https://github.com/facebook/react-native/pull/35642
Test Plan:
I was not able to reproduce the issue locally.
The fix is not destructive, let's see if the amount of issues decreases.
Reviewed By: dmytrorykun
Differential Revision: D42067939
Pulled By: cipolleschi
fbshipit-source-id: 433dbfaec42a1bf460dc9a48051aa51ec6e12d16
Summary:
This PR introduce an automatic way to detect whether the user sets its podfile to use frameworks.
In this way, users don't have to install pods with a specific environment flag but they can rely on the standard Cocoapods usage
## Changelog
[IOS][ADDED] - Automatically detect whether use_frameworks! is used
Pull Request resolved: https://github.com/facebook/react-native/pull/35636
Test Plan:
- CircleCI is Green
- Added unit tests
- Tested locally with an app
Reviewed By: dmytrorykun
Differential Revision: D42029355
Pulled By: cipolleschi
fbshipit-source-id: 76c92133deabbda59603b043a4d542737f10f044
Summary:
Upgrades `react-native` to `deprecated-react-native-prop-types@4.0.0`, which depends on `react-native/normalize-colors` instead of `react-native/normalize-color` and improves compatibility with React Native 0.72.
Changelog:
[General][Changed] Upgraded to `deprecated-react-native-prop-types@4.0.0` - https://github.com/facebook/react-native-deprecated-modules/blob/main/deprecated-react-native-prop-types/CHANGELOG.md
Reviewed By: cortinico
Differential Revision: D42088315
fbshipit-source-id: d1197e9a7d70654f601b421231b66bd760098ddf
Summary:
Many operations on references in JS can modify the referent by
executing additional JS, including operations that we currently mark as
const such as `getProperty`. Because of this, the current distinction
between const and non-const operations on references like `jsi::Object`
is somewhat arbitrary.
A more consistent approach is to mark all operations as const, so that
it is clear that the const-ness applies to the reference and not the
referent. This is analogous to how smart pointers work, since something
like `const shared_ptr<T>` only makes the pointer const, as opposed to
`shared_ptr<const T>`.
This also gives users better guarantees and more flexibility in where
these references may be used.
Changelog:
[General][Changed] - Mark methods on JSI references as const.
Reviewed By: fbmal7
Differential Revision: D41599116
fbshipit-source-id: 40b1537581b09c5a34d0928ee04e7db2b50d26ea
Summary:
This fixes some style errors found by dtslint, along with some test cases for StyleSheet.compose() where the recent change made it slightly too permissive when explicit return types are given. I also added runs of the TS tests to a script which runs in sandcastle so we can catch this at diff-submission time in the future.
Changelog:
[General][Fixed] - Fix Errors with TypeScript Tests
Reviewed By: lunaleaps
Differential Revision: D42085257
fbshipit-source-id: 7e6ca49d3c3aef822c61c97ecc07b55b0a949d51
Summary:
Adds some imperative VirtualizedList methods to the TS types which are documented on the website and are public enough. Also explicitly add `viewOffset` to `scrollToItem` since `scrollToItem` params are indefinite in flow and are passed to `scrollToIndex` (which supports the prop).
Changelog:
[General][Fixed] - Add missing VirtualizedList Imperative Types
Reviewed By: GijsWeterings
Differential Revision: D42047674
fbshipit-source-id: 60f7b35b049853d9fcb724918b3a0008a75ea573
Summary:
These are all documented on the website and seem to likely work in OSS to at least some extent. Add the missing types corresponding to functions exported from AppRegistry.
Changelog:
[General][Fixed] - Add missing types for AppRegistry
Reviewed By: GijsWeterings
Differential Revision: D42036018
fbshipit-source-id: 0728d6c5602a50e50f1eaf7f76c54ab47dcb0124
Summary:
This is exported from the RN entrypoint and documented on the RN website, so we should give types for it.
Changelog:
[General][Fixed] - Add type for RootTagContext
Reviewed By: christophpurrer
Differential Revision: D42040806
fbshipit-source-id: cb8cdf557098ddbe33c143b7ab5d80bda7f80a6e
Summary:
Adds some types referenced on the React Native webpage that aren't part of the typings.
Changelog:
[General][Fixed] - Add missing types to PushNotificationIOS
Reviewed By: christophpurrer
Differential Revision: D42040583
fbshipit-source-id: be7b86a02e30b99231f3ab35afc3222954f41cf0
Summary:
Accidentally added a reference to a flow type that doesn't exist in TS. This should fix the issue.
Changelog:
[General][Fixed] - Fix missing animation type
Reviewed By: christophpurrer
Differential Revision: D42043293
fbshipit-source-id: 03470aa25f503337e9e2b79cf74cff96c15a4ad8
Summary:
Makes sure that the global (standard) `performance` instance is initialized to still both provide `Performance.now()` as before, but also allows for the newly implemented functionality from the WebPerf API, such as marks/measures.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D42017812
fbshipit-source-id: ddbe79e91b45a84871de94018305f2a4536ada4b
Summary:
This was renamed in Flow but not in TS.
Changelog:
[General][Fixed] - Fix types for deprecated scrollTo fields
Reviewed By: christophpurrer
Differential Revision: D42040913
fbshipit-source-id: 5d9746be7b785bea8613f199d39940c4d5d7d138
Summary:
The flow type allows these parameters to be optional but not null. Make TS the same.
Changelog:
[General][Fixed] - Fix Vibration.vibrate() allowing null params
Reviewed By: christophpurrer
Differential Revision: D42046301
fbshipit-source-id: a030d4f141a526dfe2f0fb3a90e36e641fa6d789
Summary:
The flow type and inheriting TS types mark animated as optional, mark it here as well.
Changelog:
[General][Fixed] - Mark scrollToEnd animated as optional
Reviewed By: christophpurrer
Differential Revision: D42036647
fbshipit-source-id: 59d408adc639ee1e0ca040301511c64d7ba55bfe
Summary:
This was flagged when typechecking the existing examples. The current type enforces that both stylesheets overlap, meaning composed stylesheets with distinct props cause a typechecking error. This changes the signature so that each style can be different, and the intersection type of the two is returned.
Changelog:
[General][Fixed] - Fix type for `StyleSheet.compose()`
Reviewed By: christophpurrer
Differential Revision: D42008355
fbshipit-source-id: 238971a61b387c09be001d5df50fe3db70df566f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35646. Even though the RN code itself does not need `HERMES_ENABLE_DEBUGGER` anymore since the `ifdef`s are gone, the Hermes' headers it includes *do* still need that flag. This is because they were compiled with `HERMES_ENABLE_DEBUGGER` to set true, so that compile flag must match later on when importing the headers.
Changelog:
[Internal][Fixed] - We erroneously deleted usage of the HERMES_ENABLE_DEBUGGER flag, add it back.
Reviewed By: cortinico, mattbfb
Differential Revision: D42041827
fbshipit-source-id: db875f40a067c09aba37ab1b07422157f63b3700
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35644
The `repositories{}` block in the top level build.gradle is not needed anymore
The React Native Gradle Plugin is taking care of it.
Users can still specify if they need to provide custom repositories.
Changelog:
[Android] [Changed] - Remove unnecessary repositories{} block from top level build.gradle
Reviewed By: cipolleschi
Differential Revision: D42033953
fbshipit-source-id: 8ec1c12147fae68302ab47c60045869c72d1812c
Summary:
Add `uint32_t` as a valid type for communication between C++ and JS via bridging.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D42008412
fbshipit-source-id: 2c038e37745782b677d28bcbe4cc030683b74286
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35631Fixes#35592
I'm de-bumping AGP from 7.4 to 7.3 as per #35592. There is no stable release
of AGP that is working fine with the `addGeneratedSourceDirectory` API for resources.
Here I'm reverting to use the older APIs.
Changelog:
[Internal] [Changed] - De-bump AGP to 7.3.1 and do not use `addGeneratedSourceDirectory`
allow-large-files
Reviewed By: cipolleschi
Differential Revision: D42004813
fbshipit-source-id: f1a2b0f7c2233402749a3e4f3828be80111ad3a7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35633
Changelog: [Internal]
These changes add usage of `forEachPackage` as a replacement for `yarn --json workspaces info`.
This is because at some point in release cycle there is a script which removed `workspaces` block from react-native's `package.json`, so `yarn --info workspaces info` produces an error
Reviewed By: cortinico
Differential Revision: D41996732
fbshipit-source-id: 2c62c1a5eb41d711c563f9f7b0de3d67fc11823d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35621
Changelog: [Internal]
1. Added `for-each-package.js` script. This can be used to iterate through all of the packages inside `/packages` with the access to package manifest. This soon can be used as a replacement for `yarn workspaces --info`
2. Added `find-and-publish-all-bumped-packages.js` script. This script iterates through all the packages and detects if the version was changed via `git log -p` (same as `git diff`). If so, it tries to publish it to npm.
3. Added corresponding job and workflow to CircleCI config, which will use this script
Reviewed By: cortinico
Differential Revision: D41972733
fbshipit-source-id: c5d0ed5b852b744a699ecb88861ea3e82200e1f3
Summary:
While working on D42008409 I found out that codegen for pure C++ modules doesn't work with container types that are nested inside generated data structures, which happens because they don't have a specialization of `bridging::toJS` that wouldn't pass the `invoker` instance through.
It looks like an easiest option would be just to use `invoker` in codegen for `toJS` as well, which this diff does.
Note that I also experimented with removing `invoker` from being used in the `::toJS` specializations for containers altogether (see D42008410), as there doesn't seem to be a single use case when `invoker` would be ever needed in any `::toJS` specialization (and imagining such a scenario would be a stretch, tbh - why a conversion function would invoke anything running on JS side, given that invoker provides no return values anyway?..)
But since I am still not 100% about the invoker purpose there, I went with the codegen change.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D42008724
fbshipit-source-id: 6302d3ceacdfc8fed296ee1ef1a985f7273c2261
Summary:
changelog: [internal]
To make migration to the new architecture more straight forward, this change makes `UIManager.measure`, `UIManager.measureInWindow`, `UIManager.measureLayout` and `UIManager.measureLayoutRelativeToParent` functions backwards compatible. Users will not have to make any change to continue using the APIs.
This will make [Migrating .measure*()
](https://reactnative.dev/docs/new-architecture-library-intro#migrating-measure) in the migration guide optional.
Reviewed By: yungsters
Differential Revision: D41613050
fbshipit-source-id: 3c65ced231590243d118fbc120a87b08d5261da0
Summary:
I just noticed while working on 0.71 that the PR https://github.com/facebook/react-native/pull/35580 was incomplete. This PR takes care of re-aligning the leftovers. (in 0.71 I've taken care of the changes locally)
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[INTERNAL] [FIXED] - realign "leftover" metro packages from 0.73.3 to 0.73.5
Pull Request resolved: https://github.com/facebook/react-native/pull/35625
Test Plan: N/A
Reviewed By: cortinico, cipolleschi
Differential Revision: D41996338
Pulled By: dmytrorykun
fbshipit-source-id: bc1c95b0159f639e33835b922555d2f5b8c22c66
Summary:
This diff adds prepare command to hermes-engine.podspec. That command creates dummy `universal/hermes.xcframework` and `maocosx/hermes.framework`. This allow us to utilise CocoaPods auto-linking, and remove manual linking/cleanup code.
Also we now do not pollute user project with "Copy Hermes Framework" script phase. Which was quite bad on its own, and also caused annoying bugs on the CI.
allow-large-files
Changelog:
[iOS][Changed] - Prepare dummy hermes.xcframework before pod install.
Reviewed By: cipolleschi
Differential Revision: D41533994
fbshipit-source-id: d7d098ba5e882ac2d036335c23d7cda447d75b8d
Summary:
This is a backport of https://github.com/facebook/react-native/commit/0edcbc30c882e3bb111b555706a6d0a2249d4e70. It fixes inconsistencies in caching strategies of Hermes tarball and Hermes workspace on CircleCI.
## Changelog
[INTERNAL] [FIXED] - Update CircleCI config to use the RN version in Hermes workspace caching.
Pull Request resolved: https://github.com/facebook/react-native/pull/35617
Test Plan:
1. Create and push a new branch.
2. Change version in. react-native/package.json
3. Push those changes.
Before:
CircleCI restores cached Hermes workspace for the old version.
After:
CircleCI creates new workspace for the new version.
Reviewed By: cipolleschi
Differential Revision: D41970943
Pulled By: dmytrorykun
fbshipit-source-id: 7e343b7a8d4b1c5a63016ec53538abe4ad7808cc
Summary:
The current implementation think `{[key:T]:U}` and `{key:object}` are the same type, which is semantically wrong.
This pull request fixes the problem and return `{type:'GenericObjectTypeAnnotation'}`, so that `{[key:T]:U}` is `Object`. The current schema cannot represent dictionary type, `Object` is the closest one.
The previous incorrect implementation actually bring in code with logic that doesn't make sense (treating indexer as property), those and related unit test are all undone.
## Changelog
[General] [Changed] - Fix codegen output for object with indexer
Pull Request resolved: https://github.com/facebook/react-native/pull/35344
Test Plan: `yarn jest react-native-codegen` passed
Reviewed By: rshest
Differential Revision: D41304475
Pulled By: cipolleschi
fbshipit-source-id: caab8e458d83f9850c5c28b67cc561a764738372
Summary:
When using the `g` modifier on the regex, match and matchAll's behaviour is equivalent, and match has better backwards compatibility on older iOS versions.
Changelog: [General][Fixed] Fixed a backwards compatibility issue with AnimatedInterpolation
Reviewed By: yungsters
Differential Revision: D41879036
fbshipit-source-id: 240dda85ef0de8e27452846c77114ac46823f74f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35619
Reference https://github.com/reactwg/react-native-releases/discussions/41#discussioncomment-4353534
I'm exposing `ReactAndroid/src/main/jni/react/cxxcomponents` to be consumed via prefab.
It will be available to both: `react_nativemodule_core` and `reactnativejni`
Changelog:
[Internal] [Changed] - Expose ReactAndroid/src/main/jni/react/cxxcomponents via prefab
Reviewed By: cipolleschi
Differential Revision: D41965512
fbshipit-source-id: 3a5a7473267e2e161d9d7fb0e8dfa74593b47b6e
Summary:
This is a two step (1/2) fix to a race that could caused a `DELETE`...`CREATE` mutations being sent over to the fabric mounting layer. Such combination was assumed not possible from the differ, yet it happened at least in the existence of layout animation and when certain commits happen while animation is active.
This race condition could cause a view to get deleted at the end of one UI frame, yet the mount instructions generated from animation in the next frame still need to access the deleted view and caused crashes like T112157805. Note that even though such crash is recorded as `RetryableMountingLayerException` and is a soft crash (which only gets logged but not crash in production), the out-of-order mount instructions could lead to illegal view state and make the surface unusable, like what's shown here:
{F820669000}
The diff fixes this issue by removing the `DELETE` [conflict animation](https://fburl.com/code/5ctckvz3) keyframe, as well as the `CREATE` [immediate mutations](https://fburl.com/code/txyomytd) from the layout animation. The Fabric mounting layer assumes no combination of `DELETE...CREATE` in the same frame from differ + [layout animation overrides](https://fburl.com/code/zn17uqch).
Reviewed By: sammy-SC
Differential Revision: D41895427
fbshipit-source-id: d6df02663ba707af6db4a63a325ac776ca54d18e
Summary:
This diff adds support for String props on C++ Components
changelog: [internal] internal
Reviewed By: genkikondo
Differential Revision: D41784029
fbshipit-source-id: 3065186074e1feca3dd0dd724105f1596146ee1d
Summary:
Previous diff D41486648 is causing crashes and a sev S311353, which is due to usages of an old Android API that only work after level 24 (D36500518 (https://github.com/facebook/react-native/commit/0fc42fd35c577c71825f020b0fa09bee6d9ad105)). ~~This diff updates the implementation to use a compatible API, but with worse runtime complexity.~~
~~https://fburl.com/txd0r89e is a good explanation on the two algorithm to calculate a streaming median value. This diff uses the approach described in https://stackoverflow.com/a/4903642.~~
## Update
Following suggestion from sshic, I preserved the existing algorithm but with a custom comparator approach.
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D41505143
fbshipit-source-id: 494e07fa627b5cf8bad7971fa5de86d270a7412c
Summary:
Makes sure that we don't spam too often the JS performance entry reporting callback, which further dispatches entries to `PerformanceObserver` instances.
The logic is as following:
* ~~~If internal buffer of entries reaches the limit, we schedule the callback (with background priority)~~~
*~~~ Once the callback is processed, we schedule the next flush after a timeout of 500ms, this will also be scheduled from native with background priority~~~
* ~~~Whenever new performance type starts to be observed, we also schedule the callback, in order to prime the above~~~
* Schedule the flush with low priority, whenever there is the first entry coming into an empty buffer, and rely on the Scheduler to "do the right thing" when asked to flush it with background priority and not doo it exceedingly often (see the prolonged discussion)
Changelog: [internal]
Reviewed By: rubennorte
Differential Revision: D41875085
fbshipit-source-id: 368b525203215350ceabb43d5e9e8e3bd5242aca
Summary:
Delete references of CppComponentRegistry from the internals of React Native Android renderer, since it's not necessary anymore
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D41638890
fbshipit-source-id: c4b08853722874dbb21891817836862225469dd9
Summary:
This diff deletes the first implementation of C++ ViewManagers integrated into the internals of Fabric
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D41638894
fbshipit-source-id: 2e7aebff587e2e57b7f3fbf37a24b04943c74573
Summary:
There are other 3 packages which have unreleased changes on main:
```
babel-plugin-codegen/
eslint-plugin-specs/
eslint-config-react-native-community/
```
I'm bumping them in order to be able to publish them to NPM.
Changelog:
[Internal] [Changed] - Bump further patch packages to unblock nightly as they have unreleased changes on main
Reviewed By: hoxyq
Differential Revision: D41874749
fbshipit-source-id: 0b8cd69cab6fcb116f2635c964490927f4fb20be
Summary:
Changelog:
[Internal][Added] - Provided a way to override long press sensitivity,
Reviewed By: javache
Differential Revision: D41766246
fbshipit-source-id: befeafd93a73675ec609b0510dd8b5190b07dda0
Summary:
After adding `<uses-permission android:name="android.permission.POST_NOTIFICATIONS"/>` on my `AndroidManifest.xml`, I expected to use `PermissionsAndroid.PERMISSIONS.POST_NOTIFICATIONS` but `POST_NOTIFICATIONS` is `undefined` and is named `POST_NOTIFICATION` instead.
Every other Android permission is 1:1 in spelling except this one where it lacks `S`.
Not sure if this is a welcome change since this can be breaking. Or maybe we can include both with and without `S` to not be a breaking change. Or just keep it as is and close this PR.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Android] [Changed] - Rename `POST_NOTIFICATION` to `POST_NOTIFICATIONS`
Pull Request resolved: https://github.com/facebook/react-native/pull/35533
Test Plan: `PermissionsAndroid.PERMISSIONS.POST_NOTIFICATIONS` should not be `undefined`.
Reviewed By: cortinico
Differential Revision: D41705866
Pulled By: philIip
fbshipit-source-id: a0328b174f0196421565f0cd2b2f1eb509428553
Summary:
Our implementation of `PerformanceObserver.prototype.observe` diverges a little bit from the [spec](https://w3c.github.io/performance-timeline/#dom-performanceobserver-observe) regarding the behavior when calling it multiple times. E.g.:
1. We don't throw errors if both `type ` and `entryTypes` are passed.
2. We don't throw errors if neither `type ` nor `entryTypes` are passed.
3. We don't throw errors if we call observe with `type` and we call again later with `entryTypes`, and vice versa.
4. The logic to consolidate entry types in subsequent observe calls is incorrect.
This fixes those issues and also applies some minor naming improvements.
Changelog: [internal]
Reviewed By: rshest
Differential Revision: D41872269
fbshipit-source-id: 9a6b485f4ef2f479c8b6f0307012322f65a11879
Summary:
We're currently showing warnings when we call `performanceObserver.observe` and the native module for performance observers isn't available, but we don't do the same for `performance.mark`, `performance.measure`, etc.
This adds the warning in those cases.
Changelog: [internal]
Reviewed By: rshest
Differential Revision: D41872270
fbshipit-source-id: d720580b930550f27c827a58243579c42a4f6da9
Summary:
Re-apply #29278 that was recently closed by still valid.
Changelog:
[Internal] [Changed] - Update reference to statusBarTranslucent in Modal comment
Reviewed By: christophpurrer
Differential Revision: D41765526
fbshipit-source-id: 0397e86aa9adc5e5495cad8e2612cc5457840273
Summary:
Nightlies are currently broken on main. That's because nightlies rely on packages that got
re-scoped under `react-native`. We need to publish them to NPM.
In order to do so, I'm bumping versions for the one that have changes on main so that they
can be published to NPM to unblock nightlies.
Changelog:
[Internal] [Changed] - Bump all the react-native/ packages to publish on main
Reviewed By: hoxyq
Differential Revision: D41840985
fbshipit-source-id: 45b691611e33668df0922d4ff753738a773f162c
Summary:
Changelog:
[iOS][Changed] - Create a new compile time flag to enable remote sample profiling.
Reviewed By: cortinico
Differential Revision: D41554133
fbshipit-source-id: 00a7f9f6c9f09d72afee070c1cc6187aa3d0ddb1
Summary:
Changelog:
[Android][Changed] - Include the inspector in all build modes, and only turn it off/on at runtime.
Reviewed By: jpporto
Differential Revision: D40248901
fbshipit-source-id: f13c58f631e4617a6f157df8899e128959af450a
Summary:
Running pod install result in some warninigs on ruby v3:
```
script_phases.rb:51: warning: Passing safe_level with the 2nd argument of ERB.new is deprecated. Do not use it, and specify other arguments as keyword arguments.
script_phases.rb:51: warning: Passing trim_mode with the 3rd argument of ERB.new is deprecated. Use keyword argument like ERB.new(str, trim_mode: ...) instead.
```
## Changelog
[INTERNAL] [FIXED] - warnings while running `pod-install` inside script phase script
Pull Request resolved: https://github.com/facebook/react-native/pull/35594
Test Plan:
- Install ruby v3 (I haven't tested on ruby v2, most m1 users need to upgrade to v3)
- Run `pod install` in ios folder
Reviewed By: christophpurrer
Differential Revision: D41839668
Pulled By: cortinico
fbshipit-source-id: f3d328573179ddfd307011f0701f0befa0b111f8
Summary:
`AlertIOS` was deprecated and removed long ago (https://github.com/facebook/react-native/commit/e2bd7db732602b2c477fe040f2946bd8293df297) but there continues to be a test page with the name `AlertIOS` in RN-Tester. `AlertIOSExample.js` contains valid examples of how to use `Alert.prompt()` so it's worth keeping them around. Let's move those into `AlertExample.js` and remove `AlertIOSExample.js`. While we're here, let's do some extra fixes to the test page:
- Remove `showsIndividualExamples = true`. For whatever reason, I needed to remove this to show the examples properly...
- Convert all uses of `<TouchableHighlight>` with `<Pressable>`. The latter replaces the former, so I thought that made sense..
Some extra context:
In React Native macOS, we had forked `AlertIOS` into `AlertMacOS`, with a corresponding example page. This PR was made while working on removing those (https://github.com/microsoft/react-native-macos/pull/1548/).
## Changelog
[INTERNAL] [CHANGED] - Moved `Alert.prompt` examples into common rn-tester test page
Pull Request resolved: https://github.com/facebook/react-native/pull/35586
Test Plan:
Test page shows up fine on iOS .

Reviewed By: lunaleaps
Differential Revision: D41825889
Pulled By: NickGerleman
fbshipit-source-id: 82e4405b1f3a1ccb558b5a5038a90416e7a32c29
Summary:
Encountered this, causing typechecking to fail on an example in the current RN documentation.
`onFail` is an optional parameter (see https://github.com/facebook/react/blob/8e2bde6f2751aa6335f3cef488c05c3ea08e074a/packages/react-native-renderer/src/ReactNativeTypes.js#L106), which is not optional in current TS types. Update the TS typings to match.
Note that "?" here is positioned to be a Flow optional parameter, instead of a maybe type. Which means it accepts undefined, but not null, matching the TS usage of "?" which always means possibly undefined (but never null, like a flow maybe type allows).
Changelog:
[General][Fixed] - Fix TS Type for measureLayout optional parameter
Reviewed By: lunaleaps
Differential Revision: D41775900
fbshipit-source-id: 8f53428b8077ec9139c7c1bbc60ed20f5fa9f7ea
Summary:
In this diff I'm extending component to integrate layout and hierarchy of components
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D41621587
fbshipit-source-id: e31c87676ec3068036fb6e9444bce85934b18b7b
Summary:
changelog: [internal]
Fix Flow types for UIManager measure functions.
Host platform does not accept null value for reactTag parameter. It errors if null is passed. This moves error closer to developers as Flow can catch it.
Reviewed By: javache
Differential Revision: D41614452
fbshipit-source-id: 2216c195808b8a1aae58c7cb2fa15be8a073e222
Summary:
We have the expected module name available as part of the codegen schema, so we can remove the need for developers to implement the `getName` method as part of their module implementation.
Note that this method is not actually used when the TurboModules infra is used, as the moduleName from the turbo module manager is passed through to the TurboModule base class instead. Moving the method to codegen will make it easier to remove this method altogether once the old architecture is fully removed.
Changelog: [Android][Added] Support generating `getName` in react-native-codegen for Java TurboModules
Reviewed By: mdvacca
Differential Revision: D41615387
fbshipit-source-id: 6b117645fa39e5e9ab014b21198496a52f6f2ae2
Summary:
Small PR with bump to the new versions of CLI and Metro in preparation of the stable release for 0.71.
## Changelog
[General] [Changed] - Bump CLI to 10.0.0 and Metro to 0.73.5
Pull Request resolved: https://github.com/facebook/react-native/pull/35580
Test Plan: CI green
Reviewed By: cortinico
Differential Revision: D41800580
Pulled By: jacdebug
fbshipit-source-id: 7bf81308eb41490b004e685b1763574bfd3b27fb
Summary:
This diff adds type parameters to all uses of `new Array`.
Changelog: [internal]
Reviewed By: SamChou19815
Differential Revision: D41746116
fbshipit-source-id: 8aa2777dd13ef4cd9f8613adaa3509d3573d4446
Summary:
Changelog: [Internal]
This implements the C++ side logic of handling `Performance.measure` calls.
Since measures may refer to earlier logged marks by name, we need to keep track of the former. I also use a fixed size (circular) buffer to prevent the marks from piling forever.
Also adds implementation of clearing marks/measures, as per standard.
Reviewed By: mdvacca
Differential Revision: D41756928
fbshipit-source-id: 19dce28d6af4c5646274e6d5db20b41869282780
Summary:
Changelog: [Internal]
This adds JS side implementation (including the API) for the `Performance.measure` functionality, [as described in the corresponding standard](https://www.w3.org/TR/user-timing/#measure-method).
The JS part is separated from the C++ implementation (further down the stack) to help the review being more focused.
Reviewed By: mdvacca
Differential Revision: D41733190
fbshipit-source-id: 72b69f6bb332aed4b9477a186b0e818b62009220
Summary:
Followup to D41654962 (https://github.com/facebook/react-native/commit/59ee57352738f030b41589a450209e51e44bbb06), it looks like the default parser here is something different, so not all newer JS syntax is correctly recognixed. Set the parser for JSX to babel/eslint-parser explicitly.
Changelog:
[General][Fixed] - Explicitly set parser for jsx in ESLint config
Reviewed By: motiz88
Differential Revision: D41708672
fbshipit-source-id: 362716ab0aadb7c9cf5fc9f1175b69168372df88
Summary:
changelog: Introduce setNativeProps to Fabric
Add support for `setNativeProps` in Fabric for backwards compatibility. It is still recommended to move away from `setNativeProps` because the API will not work with future features.
We can make step [Migrating off setNativeProps](https://reactnative.dev/docs/new-architecture-library-intro#migrating-off-setnativeprops) in migration guide optional.
Reviewed By: yungsters, mdvacca
Differential Revision: D41521523
fbshipit-source-id: 4d9bbd6304b8c5ee24a36b33039ed33ae1fc21f8
Summary:
changelog: [internal]
Add findShadowNodeByTag_DEPRECATED` to Fabric's UIManager.
This API makes it possible to get ShadowNode reference for given native tag.
We will leverage this API to make UIManager.measure* calls backwards compatible in the new architecture.
Reviewed By: yungsters
Differential Revision: D41550734
fbshipit-source-id: a45b6a76634d034eac70603bad8ac60f9135ff24
Summary:
`findPackageJsonFile` always returns a path even though `package.json` does not exist. This causes issues in libraries whose repo setups look like:
```
react-native-webview
├── android
│ └── build.gradle
├── example <-- Note the lack of `package.json` here
│ └── App.tsx
├── ios
│ └── RNCWebView.xcodeproj
├── macos
│ └── RNCWebView.xcodeproj
├── package.json
└── src
```
When `newArchEnabled=true`, running `yarn android` will fail with the following:
```
FAILURE: Build failed with an exception.
* What went wrong:
Could not determine the dependencies of task ':app:generateCodegenArtifactsFromSchema'.
> Could not create task ':app:generateCodegenSchemaFromJavaScript'.
> /~/react-native-webview/example/package.json (No such file or directory)
```
## Changelog
[Android] [Fixed] - `findPackageJsonFile` should return `null` if `package.json` does not exist
Pull Request resolved: https://github.com/facebook/react-native/pull/35566
Test Plan:
```
git clone https://github.com/react-native-webview/react-native-webview.git
cd react-native-webview
git checkout new-arch-ios
yarn
cd example/android
./gradlew clean assembleDebug
```
Reviewed By: NickGerleman
Differential Revision: D41739176
Pulled By: cortinico
fbshipit-source-id: cab0f1f717db160df244c9bb2769e345d6e19917
Summary:
Changelog:
[General][Changed] - renamed react-native/polyfills -> react-native/js-polyfills and align with other packages versions (0.72.0) as a part of migration to monorepo
Reviewed By: motiz88
Differential Revision: D41553157
fbshipit-source-id: eef70c8e7639080acdeb6716d1a915760a85458a
Summary:
Missed while reviewing https://github.com/facebook/react-native/pull/34974 that flex gap props in Flow typings were added to ShadowStyle instead of LayoutStyle (directly above). The same issue is not present in the TS typings.
Changelog:
[General][Fixed] - Move flex gap props to the correct type
Reviewed By: yungsters
Differential Revision: D41736652
fbshipit-source-id: de0db1676464fbd962b2c7e7e9ef62b795332f1b
Summary:
Color support for AnimatedInterpolation was incomplete with native drivers, as only rgba type strings were supported. There was also an issue where color props instead a StyleAnimatedNode would never get applied. We were also potentially duplicating color parsing support, which is already centralized in normalizeColor / processColor.
Changelog: [iOS][Added] Enable AnimatedInterpolation to interpolate arbitrary color types.
Reviewed By: philIip
Differential Revision: D41649337
fbshipit-source-id: 505ba555b6a79113635fdfb35c6fe69c92d82234
Summary:
This PR prevents blob data from being prematurely de-allocated in native code when using slice to create views into an existing blob. Currently, whenever a new blob is created via createFromOptions, BlobManager.js creates a new blobCollector object since options.__collector is never provided.
https://github.com/facebook/react-native/blob/dc80b2dcb52fadec6a573a9dd1824393f8c29fdc/Libraries/Blob/BlobManager.js#L115-L123
When the reference to a blobCollector is garbage collected, the corresponding native memory for the blob data is de-allocated.
https://github.com/facebook/react-native/blob/27651720b40cab564a0cbd41be56a02584e0c73a/Libraries/Blob/RCTBlobCollector.mm#L19-L25
Since, `blob.slice()` is supposed to create a new view onto the same binary data as the original blob, we need to re-use the same collector object when slicing so that it is not GC'd until the last reference to the binary data is no longer reachable. Currently, since each blob slice gets a new blobCollector object, the memory is de-allocated when the first blob is GC'd.
Fixes https://github.com/facebook/react-native/issues/29970
Fixes https://github.com/facebook/react-native/issues/27857
## 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] - Blob data is no longer prematurely deallocated when using blob.slice
Pull Request resolved: https://github.com/facebook/react-native/pull/31392
Test Plan: I could use help coming up with a test plan here. I could add a referential equality check for the blob.data.__collector in `Blob-test` but it doesn't seem quite right to be testing the implementation detail there.
Reviewed By: javache
Differential Revision: D41730782
Pulled By: cortinico
fbshipit-source-id: 5671ae2c69908f4c9acb5d203ba198b41b421294
Summary:
D40660765 (https://github.com/facebook/react-native/commit/3982a2c6bd116a6dcc6ee6889e4a246b710b70a7) introduced extra logging for abnormal closes. The websocked 'close' event may not be called with the event argument.
Changelog: [Internal] - Fix for undefined websocket close
Reviewed By: jacdebug, cortinico
Differential Revision: D41731339
fbshipit-source-id: 92b28dcc0d55d0e9e32b4f4321f325fb3471edcd
Summary:
Newer versions of Buck (not released open source) support an `oncall` annotation to denote who owns a particular BUCK file. These annotations are useful to support so that if BUCK files are updated with such annotations they don't break.
## Changelog
[Internal] [Changed] - support oncall annotation in BUCK files
Pull Request resolved: https://github.com/facebook/react-native/pull/35562
Test Plan: The `test_buck` CI job validates that the file can be evaluated by open-source Buck. I ran this on a CircleCI fork, and it passed.
Reviewed By: motiz88
Differential Revision: D41731925
Pulled By: cortinico
fbshipit-source-id: 7d0ae164c3e6289d4aa76892658d46bbe4faf99c
Summary:
This note was added when upgrading from 0.69x to 0.70.x when `hermes_enabled` is explicitly set to `true`.
<img width="669" alt="Screenshot 2022-12-05 at 11 26 15" src="https://user-images.githubusercontent.com/36528176/205543104-b4a72c1c-57c0-422b-881e-8a0cb9d5c2a1.png">
But on 0.71, we are now using `get_default_flags` again which makes the note obsolete.
## Changelog
[Internal] [Removed] - removed hermes note
Pull Request resolved: https://github.com/facebook/react-native/pull/35555
Test Plan: N/A
Reviewed By: dmytrorykun
Differential Revision: D41731004
Pulled By: cortinico
fbshipit-source-id: d5f377062bf94fa73bc6e73d1f108e37ad68c715
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35539
This file is unused now that we rely on RNGP. We should be able to remove it
in the next stable release 0.72. In 0.71 we shipped it with a removal warning,
and users should not rely on it anymore.
Changelog:
[Android] [Removed] - Remove the react.gradle file as it's unused
Reviewed By: rshest
Differential Revision: D41655709
fbshipit-source-id: 20860da5e596d35738eea5748c791d3d923dc4fb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35540
We now don't need to generate .mk files anymore, therefore I'm removing
this logic from the codegen. In RN 0.72 users should be fully migrated
to CMake.
Changelog:
[Android] [Removed] - Remove .mk prebuilt file and .mk file generation from codegen
Reviewed By: rshest
Differential Revision: D41654122
fbshipit-source-id: 3a3c01fa8ab4d48460338e1a9ce2ecbd6df25f47
Summary:
A codemod landed which broke our public CI as it added
disable_infer_precompiled_header which is not known to Buck OSS. This ignores the argument like we do for other internal parameter types.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D41729615
fbshipit-source-id: 30601d793b15cca3164d0513882da94064b47996
Summary:
D41708199 (https://github.com/facebook/react-native/commit/3e91415696a77e5106cc9cd58077632fdf534b37) updated `deprecated-react-native-prop-types` so we should be able to re-enable this test, which I previously disabled as part of making RN tests fail on `console.error()`/`console.warn()` (i.e. any test unintentionally creating a redbox/yellowbox).
Changelog:
[Internal]
Reviewed By: yungsters
Differential Revision: D41724052
fbshipit-source-id: 4e91809940c4bf9bde416367326167598a4d1354
Summary:
This PR extracts the content of the codegen case `'Array'` and `'ReadOnlyArray'` into a single `emitArrayType` function inside the `parsers-primitives.js` file and uses it in both Flow and TypeScript parsers as requested on https://github.com/facebook/react-native/issues/34872. This also adds unit tests to the new `emitArrayType` function.
## Changelog
[Internal] [Changed] - Extract the content of the case 'Array' and 'ReadOnlyArray' into a single emitArrayType function
Pull Request resolved: https://github.com/facebook/react-native/pull/35546
Test Plan:
Run `yarn jest react-native-codegen` and ensure CI is green

Reviewed By: christophpurrer
Differential Revision: D41700084
Pulled By: rshest
fbshipit-source-id: 4bfd2d3ab3f1343bb401ba9c278dc0e0e1ea0989
Summary:
[Changelog][Internal]
The NativePerformance module functionality corresponds to the [timing extensions of the Performance API standard interface](https://www.w3.org/TR/user-timing/#extensions-performance-interface).
As this is logically separate from `PerformanceObserver` (which may exist without it), it makes sense to have it as a different native module, so there is no coupling between both.
Reviewed By: christophpurrer
Differential Revision: D41690145
fbshipit-source-id: 7443f4c51f54cc2fdddbdb2e89f9a1fa457ab280
Summary:
[Changelog][Internal]
Addresses the corresponding TODO in code, to make sure that PerformanceObserver.observe may be called multiple times with different entry types to observe.
Reviewed By: christophpurrer
Differential Revision: D41686237
fbshipit-source-id: 4287f63f7e71e5b1056d30ed616149841ba4f892
Summary:
[Changelog][Internal]
The name corresponds more precisely to what the method does.
Reviewed By: christophpurrer
Differential Revision: D41686205
fbshipit-source-id: 36c47b57fdeb757515cd14b890f38247f7fe8d02
Summary:
Changelog: [Internal]
Codemod-bot already hardcoded this to false a while back, so cleaning up the code related to it.
Reviewed By: RSNara
Differential Revision: D41615378
fbshipit-source-id: 7b62b20b8e25f0a06d207b2457d6caf9ad5c695e
Summary:
A flakey CDN is 404'ing the Java dep. Caching the Choco dependencies should stop this.
## Changelog
[Internal] [Fixed] - Cache Choco dependencies to stop erratic 404s on Java 8 install.
Pull Request resolved: https://github.com/facebook/react-native/pull/35399
Test Plan: Bump the PR to see if it's caching.
Reviewed By: huntie
Differential Revision: D41684462
Pulled By: blakef
fbshipit-source-id: f3eac9e8a00be33f7c3f0996f35abb63146cb3c4
Summary:
The `react-native-xcode` script assumes the that `node_modules` folder are in the same location as the react native project. This adds the ability to declare `CUSTOM_DIR` in `.xcode.env` file to let react-native-xcode know where the react native project is located - required for monorepos
## Issue
At the moment if a project is not using the default react native file structure then when trying to create a build or archive using Xcode it will fail, with the following error:
> File /Users/itxch/Library/Developer/Xcode/DerivedData/app-evgjukoxhuupzzdglopjnhcntvpw/Build/Intermediates.noindex/ArchiveIntermediates/jungul/BuildProductsPath/Release-iphoneos/app.app/main.jsbundle does not exist. This must be a bug with React Native, please report it here: https://github.com/facebook/react-native/issues
## Background
My project is a monorepo, using `npm` workspaces.
#### This is the relevant file structure

This file structure is incompatible with line 63 of `react-native-xcode.sh`
https://github.com/facebook/react-native/blob/c5a8425fada10b715f356731426db666975569c9/scripts/react-native-xcode.sh#L63
Note: `$REACT_NATIVE_DIR` is the `react-native` package directory inside node modules.
So by default this sets project root to be the parent folder of the `node_modules` folder. However in my case this is not correct, it should actually be:
```sh
PROJECT_ROOT=${PROJECT_ROOT:-"$REACT_NATIVE_DIR/../../app"}
```
## Solution
Seeing as hardcoding the value would not work, the simplest solution is to set the directory via a variable
```sh
PROJECT_ROOT=${PROJECT_ROOT:-"$REACT_NATIVE_DIR/../../$CUSTOM_DIR"}
```
`$CUSTOM_DIR` can easily be set via `.xcode.env` file.
## Changelog
[IOS] [Added] - allow for custom project dir in react-native-xcode script
Pull Request resolved: https://github.com/facebook/react-native/pull/35449
Test Plan:
After updating my `.xcode.env` file to include `export CUSTOM_DIR=app`, I can successfully create a build or an archive.
If the variable is not set it will be black, so it will not effect `$PROJECT_ROOT`
Reviewed By: GijsWeterings
Differential Revision: D41529396
Pulled By: cortinico
fbshipit-source-id: 890e9867e31f83a08561df8c2de1069e771726fc
Summary:
Revert the template `Podfile` to using `react-native-community/cli-platform-ios/native_modules`. The new internal script currently has a hard-coded path to `react-native-community/cli-platform-ios` which may not work in monorepos. The path in the `Podfile` is also hard-coded, but this is a file that the user has access to and can fix themselves if necessary.
## Changelog
[iOS] [Fixed] - Don't use the internal `native_modules.rb` script yet, as it hides a hard-coded path
Pull Request resolved: https://github.com/facebook/react-native/pull/35531
Test Plan: n/a
Reviewed By: rshest
Differential Revision: D41682119
Pulled By: cortinico
fbshipit-source-id: 1822fcd20a794dc9df6e8d6f36615e90b42c1a94
Summary:
- Untracking StackDump files through `.gitignore`
- Most of the programs like shell (bash) **_crashes_** it generates **_StackDump_**; `*.stackdump` file(s)
- Such files are only for low level debugging purpose and _shouldn't be tracked_
- PS: When using integrated terminals on IDEs it's common to have these files especially on Win m/c :)
## Changelog
[Internal] [Changed] - Untracking Stack Dumps; `*.stackdump` files
Pull Request resolved: https://github.com/facebook/react-native/pull/35530
Test Plan: - [NO-CODE] Diff
Reviewed By: rshest
Differential Revision: D41653070
Pulled By: cortinico
fbshipit-source-id: 0727feb66daa286d077743a451643970555e9c20
Summary:
Refactor unique -> shared pointer in Component. This will be necessary in the next diffs of the stack
changelog: [intenal] internal
Differential Revision: D41629759
fbshipit-source-id: 335161c350692e25ac3443bd19675a89f9df60c4
Summary:
`react-native/eslint-config` enables rules for TypeScript and `.js` files (as Flow), but seems to completely no-op if you have a `.jsx` file. Enabling it in an override leads to syntax errors because the config has not been enlightened on how to parse JSX.
This would normally happen if a config extended `plugin:react/recommended`, but we are already cutomizing the React plugin rules. So we instead just directly set `ecmaFeatures: {jsx: true}` as reccomended by https://github.com/jsx-eslint/eslint-plugin-react.
Changelog:
[General][Breaking] - Fix react-native/eslint-config linting of jsx files
Reviewed By: rickhanlonii
Differential Revision: D41654962
fbshipit-source-id: 778da0928fadb86caa6a33254379d3d7dd394892
Summary:
Consolidates creation of OkHttpClients used by RN panel apps into PanelAppOkHttpClientProvider. This diff adds no functional changes; however, a followup diff will leverage this to add an Interceptor for overriding the network tier.
Changelog:
[Internal] - Enable passing in custom OkHttpClient to NetworkingModule
Reviewed By: rshest
Differential Revision: D41621244
fbshipit-source-id: 8954f9adc6a0cfdf6312678e2dbd6be8ef9aa5ca
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35526
[Changelog][Internal]
This closes the full loop according to the [technical design](https://fb.quip.com/MdqgAk1Eb2dV) of the WebPerf API implementation, with the main components and the working central data flow in place.
The next step is to add some buffering/throttling, as in this diff we just spawn an idle-priority task after every performance entry coming (even though they still naturally do come in batches, because they manage to accumulate before the task is executed).
Reviewed By: christophpurrer
Differential Revision: D41496082
fbshipit-source-id: 5fd4cf22e75806f7bc98d1d1b6691596ccadf8b9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35525
[Changelog][Internal]
Adds ability to invoke an async JS callback from a C++ native module, as a task with priority.
This will allow native modules to schedule less important calls to JS thread with lower priority. One example use case is feeding collected perf metrics back to JS.
Reviewed By: javache
Differential Revision: D41492849
fbshipit-source-id: 12f738557972dc23398d9bb9a7a01125c79da070
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35529
ESLint configuration is derived from `react-native/eslint-config`, which has supported Flow, vanilla JS, and TypeScript.
https://github.com/react-native-community/react-native-template-typescript/pull/238 and a related PR ended up adding new rules to the TypeScript config, to fix bugs with TS linting. It required a followup change, to specify the parser/plugin, and explicity reference them as devDependencies. https://github.com/react-native-community/react-native-template-typescript/pull/240
`react-native/eslint-config` already includes setting the plugin/parser. But overriding rules requires declaring that again, and directly referencing a plugin means a need for the app to declare dependencies, since ESLint resolves modules from the current config.
The rules overridedn were later fixed in `react-native/eslint-config`, which is really the right place for the fix (e.g. https://github.com/facebook/react-native/pull/32644). I noticed this when deriving from the TS template in https://github.com/facebook/react-native/pull/32644 and removed the rule overrides, but didn't have the historical context to realize this means we can then:
1. Remove the explicit parser/plugins since `react-native/eslint-config` already sets them, and we are no longer overriding any rules.
2. Remove the devDependencies, to let the versions be managed entirely by `react-native/eslint-config`.
Changelog:
[General][Changed] - Simplify Template ESLint Configuration
Reviewed By: cortinico
Differential Revision: D41652699
fbshipit-source-id: 8e3313dbf27407c5866f3c2432cffc2ecec1b01d
Summary:
On main, We download and store `hermes.tar.gz` locally during builds.
If another commit on the Hermes repo lands, Gradle might not re-download the hermes.tar.gz
file.
This commit fixes it by using `useETag` that allows us to use ETag that Github exposes
to understand if the tarball has been updated or not.
Changelog:
[Internal] [Changed] - Ensure local hermes.tar.gz doesn't get stale between subsequent runs.
Reviewed By: javache
Differential Revision: D41652865
fbshipit-source-id: 9f6e02957989acb02f419286c94b05df701c8a04
Summary:
This makes it so that React Native unit tests will fail if code unexpectedly outputs a warning or error (which would show as a redbox error).
This logic split out from the normal `jest/setup.js` which is included by the jest-preset, to only effect our tests instead of existing RN Jest users.
Changelog:
[Internal][Changed] - Fail tests on `console.error()` or `console.warn()`
Reviewed By: huntie
Differential Revision: D41564032
fbshipit-source-id: 3cc7d3a8433fcb75f654669b9c350dea2da937a8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35521
Inside RC3 the jscexecutor target was prepared for prefab consumption
but not properly exposed.
This was not caught by the CI as we're not effectively using this target,
but some of our popular libraries do (i.e. Reanimated). I'm exposing it here.
Changelog:
[Internal] [Changed] - Properly expose `jscexecutor` as a prefab target
Reviewed By: javache
Differential Revision: D41648349
fbshipit-source-id: 1a04bc21aa50eece304828ce1d99ae795a51af48
Summary:
Yoga tries to use `std::bit_cast<>()` where it's available and falls back to
`std::memcpy()` everywhere else. Unfortunately, the feature-test macro
(`__cpp_lib_bit_cast`) is only defined if the feature is available *and you have
already included either `<version>` or `<bit>`* (or something else that includes
one of those). Since `CompactValue.h` checks `__cpp_lib_bit_cast` *first*, it's
not defined even if it *would be* defined, leading the header not to
`#include <bit>`, leaving `std::bit_cast<>()` undefined; later, other headers
from the STL are included, leading to `__cpp_lib_bit_cast` *becoming* defined
and causing later code to choose to use the undefind `std::bit_cast<>()`.
This diff fixes the problem by `#include`ing either `<version>` or `<ciso646>`
(depending on availability) before checking any feature-test macros.
Changelog: [Internal]
Reviewed By: smeenai
Differential Revision: D41641205
fbshipit-source-id: 7d7bc5791c902a45302d3707e6cbf21fc0493f0c
Summary:
This change adds a new action and workflow that will run whenever a commit is pushed that closes a PR via its message. When this happens, the corresponding PR will be labeled with "Merged" and a comment will be added with the name of the committer and the sha of the commit that resolved the PR.
This is not new functionality - it merely replaces a portion of the react-native-bot's functionality with a GitHub action.
## Changelog
[Internal] [Changed] - Moved close PR actions to a GitHub action
Pull Request resolved: https://github.com/facebook/react-native/pull/35500
Test Plan:
Tested the golden path here ("Merged" label and comment added): https://github.com/SlyCaptainFlint/react-native/pull/27
Tested the case where a PR already labeled with Merged was processed and no new comment was left on it (simulates the case where react-native-bot, which is still going to be running, got to the PR and processed it before the new GitHub action did): https://github.com/SlyCaptainFlint/react-native/pull/26
Reviewed By: cipolleschi
Differential Revision: D41567047
Pulled By: SlyCaptainFlint
fbshipit-source-id: 23745a17950b75c1a8f25f0b840c2172332c4cfa
Summary:
Update `babel/*` dependencies specifying `^7.x.y` where `x > 0` to the latest available semver minor, and corresponding superficial snapshot updates reflecting a small decrease in JS bundle size.
- `babel/core` to `^7.20.0`
- `babel/parser` to `^7.20.0`
- `babel/preset-env` to `^7.20.0`
- `babel/traverse` to `^7.20.0`
- `babel/cli` to `^7.19.0`
- `babel/eslint-parser` to `^7.19.0`
- `babel/preset-flow` to `^7.18.0`
- `babel/preset-syntax-flow` to `^7.18.0`
- Deduplicate / refresh others to take in patch updates
Changelog: [Internal] Bump Babel dependencies to latest 7.x
Reviewed By: JoeyMou
Differential Revision: D41449678
fbshipit-source-id: f04fe837a7961c4e2dde45fed59fcd138c2f8723
Summary: `dispatchPreallocationInBackground_` is removed and we don't need to use the lambda function anymore.
Reviewed By: javache
Differential Revision: D41574447
fbshipit-source-id: 9c2b8a067fb86b75320b338e3f8c7989315f9b8b
Summary:
Color support for AnimatedInterpolation was incomplete with native drivers, as only rgba type strings were supported. There was also an issue where color props instead a StyleAnimatedNode would never get applied. We were also potentially duplicating color parsing support, which is already centralized in normalizeColor / processColor.
Changelog: [iOS][Added] Enable AnimatedInterpolation to interpolate arbitrary color types.
Reviewed By: sammy-SC
Differential Revision: D40632443
fbshipit-source-id: 4dfb29edca4b919474408b43c3917ac9406a147a
Summary:
Color support for AnimatedInterpolation was incomplete with native drivers, as only rgba type strings were supported. There was also an issue where color props instead a StyleAnimatedNode would never get applied. We were also potentially duplicating color parsing support, which is already centralized in `normalizeColor` / `processColor`.
Changelog: [Android][Added] Enable AnimatedInterpolation to interpolate arbitrary color types.
Reviewed By: mdvacca
Differential Revision: D40571873
fbshipit-source-id: 41857ab0391279c5307bc31b855ea8fbcb4cccd8
Summary:
Restructured the JS implementation of AnimatedInterpolation to make it clearer how colors and other string-based interpolatables are supported. We're then able to use a very similar structure to implement this interpolation on the native driver as well, which simplifies implementation, and improves support for different color types.
Changelog: [General][Fixed] Improved support for AnimatedInterpolation of color props.
Reviewed By: mdvacca
Differential Revision: D40571890
fbshipit-source-id: 7c204a7b736722732dc5f9e0d158ef5af81b4bb1
Summary:
[Changelog][Internal]
Adds API definition for [Performance.mark](https://www.w3.org/TR/user-timing/#mark-method) support.
This is a bare bone implementation, that just logs events on the native side. The next step is the native logic for queuing, flushing etc.
Note that here I route both JS and native marks to native for now, for simplicity sake - ultimately this may not be what we want, as it may be more efficient to process marks, logged from JS, on the JS side.
Reviewed By: rubennorte
Differential Revision: D41472148
fbshipit-source-id: bdf2b182b8472a71a5500235849bca5af1c2f360
Summary:
This PR is a subtask of https://github.com/facebook/react-native/issues/34872
Moved `translateArrayTypeAnnotation` (Flow,TS) fns to `parsers-primitives.js`
- combined `Flow` and `TS` `translateArrayTypeAnnotation` fn 's into common fn
- moved it to `parsers-primitives.js`
- re-organized imports and exports :)
## Changelog
[Internal] [Changed] - Moved `translateArrayTypeAnnotation` (Flow,TS) fns to `parsers-primitives.js`
Pull Request resolved: https://github.com/facebook/react-native/pull/35479
Test Plan:
- ensure 👇 is `#00ff00`
`yarn lint && yarn flow && yarn test-ci`
Reviewed By: cipolleschi
Differential Revision: D41548046
Pulled By: GijsWeterings
fbshipit-source-id: 8fd7214f8b1e669ba42f326f814674eec179fed5
Summary:
Update `babel/generator` to the latest, which is a semver-minor update within the pre-existing range.
I'm separating this out for ease of review because it brings some noisy snapshot changes, including more granular source maps and fewer empty lines in generated output. The majority of this is a result of https://github.com/babel/babel/pull/14980 (`>=7.19.4`).
This and the previous diff clear the way for a general Babel update, which is currently blocking a perf-boosting Metro PR https://github.com/facebook/metro/pull/854.
Changelog: [Internal] Bump `babel/generator dependency` to `^7.20.0`
Reviewed By: motiz88
Differential Revision: D41438635
fbshipit-source-id: d56853169be22a2197ad53d6320ec6c1faf6b2a7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35508
It turns out that my previous diff hasn't really solved the Windows support.
The problem is that we're not escaping the URI of the Maven Local repository
properly on Windows.
To overcome this, I'll instead use the `toURI()` Api of File to properly
create a valid URI for a given folder.
Changelog:
[Internal] [Changed] - RNGP - Fix DependencyUtils for Windows support
Reviewed By: cipolleschi
Differential Revision: D41581849
fbshipit-source-id: 7905073c6daaf7c6a97405b3e6fb94b8f382234a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35506
In our build we had a mixture of `_` and `-` to separate targets.
Dashes don't play well with Gradle + as we expose them now via Prefab,
let's stick to use only underscores
Changelog:
[Internal] [Changed] - Rename target to don't use dashes
Reviewed By: cipolleschi
Differential Revision: D41578938
fbshipit-source-id: 8aa44aa2dc7bf4822b45e5044532837b989817d2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35497
In 0.71.0-RC.2, we had a regression in `use_frameworks!`.
This adds some CircleCI jobs to make sure we do not regress on those. It also updates the template to support these tests.
## Changelog
[iOS][Added] - CircleCI jobs to keep the use_framework! setup in check for the Old Arch
Reviewed By: cortinico
Differential Revision: D41551288
fbshipit-source-id: 531fabb1a7b6aceab2926bb83cf2887129df1776
Summary:
In 0.71.0-RC.2, we had a regression in `use_frameworks!`.
This brings back JSIDynamic and JSI together because the current setup is not compatible with iOS frameworks
## Changelog
[iOS][Added] - Bring back JSIDynamic and JSI
Reviewed By: cortinico
Differential Revision: D41557823
fbshipit-source-id: 95eb2fe7df69992861396e41d11cd5182193e1a3
Summary:
In 0.71.0-RC.2, we had a regression in `use_frameworks!`.
The `use_frameworks! :linkage => :static` use to work fine with the Old Architecture.
We modified how the `React-bridging` pod is configured and, now those are broken.
This change make sure to use the right imports for React-bridging.
## Changelog
[iOS][Changed] - Fix imports in React Bridging for Old Arch and frameworks
Reviewed By: christophpurrer, cortinico
Differential Revision: D41551103
fbshipit-source-id: 4416fde92fef11eb801daf2302a57fe52732e4ef
Summary:
This change excludes the `LongLivedObject.h` file from the pod in the ReactCommon library.
The file creates a problem when the `use_frameworks!` option is used in an app because there can't be two files with the same name, despite being in different paths,
within the same framework. Specifically, this `LongLivedObject` is just a redirect to the other one, so it should be safe to exclude this.
## Changelog
[iOS][Fixed] - Exclude redirector to `LongLivedObject.h` from ReactCommon podspec
Pull Request resolved: https://github.com/facebook/react-native/pull/35491
Test Plan: 1. Manually tested in an app from RC2
Reviewed By: cortinico
Differential Revision: D41548985
Pulled By: cipolleschi
fbshipit-source-id: acc57fccdedb344a3aa105f2968645a049392e07
Summary:
Animated.Color was never calling `flush`, and thus didn't trigger any animated views to update when the Animated.Color had (a native-only) color change when using the JS driver.
Changelog: [General][Fixed] Improved handling of native colors in Animated.Colors
Reviewed By: mdvacca
Differential Revision: D41519965
fbshipit-source-id: 52f78460cf67ab9260d3868b0d27692b64fc3c58
Summary:
Noticed that we weren't receiving pointer events for nested Text spans when the new pointer events implementation was enabled.
Changelog: [Internal]
Reviewed By: lunaleaps
Differential Revision: D41496672
fbshipit-source-id: 9d0ed83d1bb5f42211ec655328035651f25fa471
Summary:
These experiments have been removed already, but we still have references to them in C++.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D41549465
fbshipit-source-id: 1158fb391b4279ef4eb6ad7123cb8113d7ecccef
Summary:
`Promise<T>` is used very often in turbo module as function return types. So `T` is a critical thing for type safety. To enable future generator to produce more specific type for `Promise`, `T` is added to the schema.
## Changelog
[General] [Changed] - Fix codegen to add `T` of `Promise<T>` in CodegenSchema.js
Pull Request resolved: https://github.com/facebook/react-native/pull/35345
Test Plan: `yarn jest react-native-codegen` passed
Reviewed By: lunaleaps
Differential Revision: D41304647
Pulled By: cipolleschi
fbshipit-source-id: 6cdd2357b83d4d8007c881a7090cbb8969f3ae9d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35496
This commit includes a series of fixes needed for better integration with libraries for 0.71:
- I've added an `android/README.md` file as some libraries were failing the build if the folder was missing
- RNGP now applies dep substitution on app and all the libraries project
- RNGP now adds repositories on app and all the libraries project
- I've removed the maven local repo to the `/android` folder as now is empty
- I've fixed the path for the JSC repo for Windows users
- I've added a bit of backward compat by re-adding an empty `project.react.ext` block that libraries might read from.
- I've removed `codegenDir` from the `GenerateCodegenArtifactsTask` which was unused.
Changelog:
[Internal] [Changed] - RNGP - Various improvements needed for 3rd party libs
Reviewed By: cipolleschi
Differential Revision: D41549489
fbshipit-source-id: 2252da0180ac24fd3fe5a55300527da6781f0f8c
Summary: Changelog: [Internal] - Internal usage broke existing behavior, reverting to check if a flag is set.
Reviewed By: javache
Differential Revision: D41502122
fbshipit-source-id: 296bb1578cd63f935e4111bfec8d58f965149640
Summary:
this is a trivial change that allocates the NSMutableArray with the correct capacity before it is filled
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - RCTConvertVecToArray - allocate array with capacity
Pull Request resolved: https://github.com/facebook/react-native/pull/35490
Test Plan: tested locally: the code builds and runs as expected
Reviewed By: cipolleschi
Differential Revision: D41548050
Pulled By: GijsWeterings
fbshipit-source-id: a5b947331d6c5fffcfecc7c20c827f42442b1ab8
Summary:
Changelog: [Internal]
`NativeComponentRegistryUnstable.js` has Flow syntax but no `flow` directive. It seems to typecheck fine so I'm adding the directive here. (Plus `format` for good measure.)
Reviewed By: huntie
Differential Revision: D41547266
fbshipit-source-id: 1b6a03c705add91843633166a245d0447a21af6d
Summary:
This pull request migrates the appearance example to using React Hooks.
## Changelog
[General] [Changed] - RNTester: Migrate Appearence to hooks
Pull Request resolved: https://github.com/facebook/react-native/pull/35114
Test Plan: The animation works exactly as it did as when it was a class component
Reviewed By: cortinico
Differential Revision: D41531005
Pulled By: cipolleschi
fbshipit-source-id: a864766a3bb58a7f0c2b9c4ed8f731ee84713b26
Summary:
when I'm defining a turbomodule spec, I tried to extract a common parameter into an interface.
The error I get is this:
```
[Codegen] >>>>> Processing RNSimpleToastSpec
[Codegen] Done.
/Users/vojta/_dev/_own/simple-toast/example/node_modules/react-native-codegen/lib/parsers/typescript/utils.js:111
throw error;
^
TypeError: Cannot read properties of undefined (reading 'length')
at isModuleInterface (/Users/vojta/_dev/_own/simple-toast/example/node_modules/react-native-codegen/lib/parsers/typescript/modules/index.js:695:18)
at Array.filter (<anonymous>)
at buildModuleSchema (/Users/vojta/_dev/_own/simple-toast/example/node_modules/react-native-codegen/lib/parsers/typescript/modules/index.js:709:44)
at /Users/vojta/_dev/_own/simple-toast/example/node_modules/react-native-codegen/lib/parsers/typescript/index.js:158:9
at guard (/Users/vojta/_dev/_own/simple-toast/example/node_modules/react-native-codegen/lib/parsers/typescript/utils.js:108:14)
at buildSchema (/Users/vojta/_dev/_own/simple-toast/example/node_modules/react-native-codegen/lib/parsers/typescript/index.js:157:22)
at Object.parseFile (/Users/vojta/_dev/_own/simple-toast/example/node_modules/react-native-codegen/lib/parsers/typescript/index.js:185:10)
```
After the fix I get this:
```
[Codegen] >>>>> Processing RNSimpleToastSpec
[Codegen] Done.
/Users/vojta/_dev/_own/simple-toast/example/node_modules/react-native-codegen/lib/parsers/typescript/utils.js:111
throw error;
^
Invariant Violation: GenericTypeAnnotation 'Styles' must resolve to a TSTypeAliasDeclaration. Instead, it resolved to a 'TSInterfaceDeclaration'
```
Then I know that I should not be using an `interface` but a `type`
## Changelog
[Internal] [Fixed] - TS codegen crash when parsing interfaces
Pull Request resolved: https://github.com/facebook/react-native/pull/35492
Test Plan:
tested locally
let me know if you want an automated test
Reviewed By: cortinico
Differential Revision: D41548015
Pulled By: cipolleschi
fbshipit-source-id: 9acf02dffbb084831690f665357fb80225cbce0d
Summary:
This is the last library that we should expose via Prefab.
Thanks to cipolleschi 's work here moving the file to `/ReactCommon/jsc` folder
we can easily expose it to be consumed by third parties.
Changelog:
[Internal] [Changed] - Expose `jscruntime` to be consumed via Prefab
Reviewed By: cipolleschi
Differential Revision: D41534564
fbshipit-source-id: fb4b2d801def8caf71638dcb74eb87f8230984d4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35482
This change moves the JSCRuntime.h/cpp into a `jsc` folder.
This change is required for several reasons:
1. on iOS, the new `jsi`, `jsidynamic` and `jsc` setup is breaking the `use_frameworks!` with `:linkage => :static` option with the old architecture. So it is a regression.
2. JSCRuntime is required by some libraries and needs to be exposed as a prefab and the current setup makes it hard to achieve.
allow-large-files
## Changelog:
[General][Changed] - Move JSCRuntime into a separate pod/prefab
Reviewed By: cortinico
Differential Revision: D41533778
fbshipit-source-id: 642240c93a6c124280430d4f196049cb67cb130b
Summary:
Normally, when we work with RNTester, we have to install the pods with the `pod install` command. The `pod install` commands has some side effects on the Xcode.project: for example, it installs some build script phases.
In Sandcastle, we do not run that command to avoid network requests and to improve test reliability and reproducibility. This implies that, when we run the sandcastle jobs and/or we update the offline mirrors, we also have to upload the Xcode project associated with the specific JS engine.
This Diff operates in two steps:
1. when updating the offline mirrors, it creates a tarball with the Xcodeproj and stores it in the proper offline mirror folder.
2. when testing, it replaces the current project with the one stored in the offline mirrors before extracting the pods.
allow-large-files
## Changelog
[Internal] - Keep a copy of the Xcodeproj in the offline mirrors
Reviewed By: cortinico
Differential Revision: D41541712
fbshipit-source-id: e6d9633f9245631ab56c8b9689707b537c30075c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35436
Using std::optional as react-native has been using C++17 for quite some time
changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D41415031
fbshipit-source-id: d786647f64b4f90cf75409109830ae0885460c17
Summary:
The nightly version is bumped after the check is performed, therefore it fails.
With this diff, we become slightly more accepting with nightlies, allowing both `0.0.0` and `0.0.0-xxxx` as valid version for nightlies.
## Changelog
[JS][Fixed] - Accept 0.0.0 with and without prelrelease for nightlies' versions
Reviewed By: cortinico
Differential Revision: D41534995
fbshipit-source-id: 2d0417441ca7d3d3f7660c9317133ac3c6de2eb9
Summary:
When dry-run in stable branch, the tag already exists. We are bypassing the tag-existence check when in a dry-run to have the CI pass
## Changelog
[General] [Fixed] - Bypass tag version check when dry-run
Pull Request resolved: https://github.com/facebook/react-native/pull/35470
Test Plan:
CircleCI
It worked for RC1 and RC2
Reviewed By: cortinico
Differential Revision: D41529648
Pulled By: cipolleschi
fbshipit-source-id: d4d7f5534f86c2cf10b05e0d4cab950e4902d8df
Summary:
See the issue at https://github.com/facebook/react-native/issues/32432#issuecomment-1242234121
This fixes a bizarre issue when using the GNU coreutils tools. There are very minor differences in the standard command-line tools on macOS and the GNU coreutils. The `cp` command has slightly different semantics across these operating systems, so this commit normalizes those differences and allows GNU coreutils to be used or the system native version of `cp`.
Fixes#32432
## Changelog
[General] [Fixed] - Allow GNU coreutils to be used to build projects
Pull Request resolved: https://github.com/facebook/react-native/pull/35382
Test Plan: This change allows the use of the system or GNU coreutils verson of `cp`.
Reviewed By: cipolleschi
Differential Revision: D41532472
Pulled By: cortinico
fbshipit-source-id: f0fe5274d3828bf6099deceee797a82a6adfdcab
Summary:
This is a nit. Just moving this expo sample to a service account
which is co-owned by Meta and Expo.
Changelog:
[Internal] [Changed] - Move expo samples to a service account.
Reviewed By: cipolleschi
Differential Revision: D41533073
fbshipit-source-id: 4745bb35160c401ebb9ce03325bda64726f122dc
Summary:
We have two warnings on MapBuffer which I'd like to resolve as they show up on console every time.
1. We're using a deprecated method receiveCommand, which is actually legit but was missing a propagation of the warning. I'm adding it.
2. We had a null check that that was always not null. That is enforced by the Kotlin type system. I've checked the code and
we're actually always returning non-nulls there or raising exceptions instead.
Changelog:
[Internal] [Changed] - Fix compilation warnings for MapBuffer
Reviewed By: javache
Differential Revision: D41522129
fbshipit-source-id: c2dbb660f95a2ff7dac6e4fcdf476e4058cf730e
Summary:
The [monorepo RFC](https://github.com/react-native-community/discussions-and-proposals/pull/480) calls for renaming:
* `react-native-community/eslint-config` -> `react-native/eslint-config`
* `react-native-community/eslint-plugin` -> `react-native/eslint-plugin`
It also calls for the versions to be aligned with the rest of main -- currently `0.72.0`.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[General][Changed] - Renamed `react-native-community/eslint-config` to `react-native/eslint-config` v0.72.0 to align with other packages
[General][Changed] - Renamed `react-native-community/eslint-plugin` to `react-native/eslint-plugin` v0.72.0 to align with other packages
Pull Request resolved: https://github.com/facebook/react-native/pull/34581
Test Plan:
First test is to run `yarn lint`, and verify that output matches before and after this change.
Second test is to change the ESLint config to use the "old" packages (under `react-native-commnuity`) and run `yarn lint` to make sure that they work as expected. This is what customers will experience, until they manually move to the new ESLint packages.
Reviewed By: cortinico
Differential Revision: D41520500
Pulled By: hoxyq
fbshipit-source-id: a61e5ae15d5aaf11f0143a3b0257a60a03b1550b
Summary:
This PR updates the Cache strategy for the tarballs to include the React Native version we are building. In this way, when we publish a new Release/RC we are sure that we are going to rebuild a nmew
tarball. This should fix caching problems like:
- we have misconfigured the build script for the Hermes tarball, we then fix it, but we distribute the wrong cached artifacts
- the cached artifact has the wrong version
## Changelog
[Internal] - Fixed Hermes Tarball Cache Logic
Pull Request resolved: https://github.com/facebook/react-native/pull/35471
Test Plan:
1. CircleCI
The real way to check this is in the next RC cycle or in the next nightly.
Reviewed By: cortinico
Differential Revision: D41530651
Pulled By: cipolleschi
fbshipit-source-id: 45e8fd3b62c8e108d393d9463ff6762dfc6d3ec8
Summary:
This PR backports the changes in 0.71 to apply the same logic to decide when we have to build Hermes from source in both the `hermes-engine.podspec`
and in the `react_native_pods.rb` script.
## Changelog
[iOS] [Fixed] - Use the right logic to decide when we have to build from source
Pull Request resolved: https://github.com/facebook/react-native/pull/35469
Test Plan: Working on RC2
Reviewed By: cortinico
Differential Revision: D41529539
Pulled By: cipolleschi
fbshipit-source-id: 879522c2187df28f40f6bc699057e9ecfb7e25fb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35474
This cleans up our `on-issue-labeled` workflow and makes sure we use only github-scripts. So we don't need to checkout the code & run an external action.
Changelog:
[Internal] [Changed] - Move on-issue-labeled to use actions/github-script@v6
Reviewed By: cipolleschi
Differential Revision: D41522650
fbshipit-source-id: c93d10eddf5be2ca9f779389e8059633291c0138
Summary:
I'm getting `node_modules/react-native/Libraries/Events/EventPolyfill.js: Unexpected token, expected "{"` when building an app. Looking at the source code, it seems odd there'd be a return type defined for a constructor. Unless I'm missing something (I don't use flow), I think it should be removed?
## Changelog
[Internal] [Fixed] - Remove return type from constructor
Pull Request resolved: https://github.com/facebook/react-native/pull/35466
Test Plan: N/A
Reviewed By: jacdebug
Differential Revision: D41527010
Pulled By: yungsters
fbshipit-source-id: 9f4faf1305ebe1915f5bcf07fc86b7437aed0c97
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35459
Changelog:
[Internal] [Changed] - now bootstrapping Verdaccio before template app initialization, this is required because react-native migh depend on some package which version is not yet published to npm
Reviewed By: cipolleschi
Differential Revision: D41521496
fbshipit-source-id: 6183ab02c697d9d08e9dca5b323bd7a11a749c3a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35464
This extends the buildAll task to build both RNTester Debug and Release
We can finally do this now as debug and release are fully isolated
and don't clash on each other.
Changelog:
[Internal] [Changed] - Build RNTester Release inside buildAll
Reviewed By: cipolleschi
Differential Revision: D41521995
fbshipit-source-id: 37ec5e3b55080372f01f2736c1bb020b3776b193
Summary:
Build hermesc in Xcode run script phase, so it ends up inside `Pods/hermes-engine/buld_host_hermesc`. All the the housekeeping is now done by CocoaPods and Xcode, and we can get rid of all the setup/cleanup code.
Changelog:
[iOS][Changed] - Build hermesc in Xcode run script phase.
Reviewed By: cipolleschi
Differential Revision: D41521987
fbshipit-source-id: 336854fa23582255cba6d161acf2cc791cac9d00
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35463
This will allow us to easily retrieve debug/release APK for
both RN-Tester and the Template jobs for every run of the CI.
Changelog:
[Internal] [Changed] - Store RN Tester and Template APKs for Android on CI
Reviewed By: cipolleschi
Differential Revision: D41521977
fbshipit-source-id: e2ed60921fd005425d3915323b18dde2851e7fc2
Summary:
We don't really run AVD (Emulators on CI) so those steps
are entirely unnecessary and skipped every time. I'm removing them.
Changelog:
[Internal] [Changed] - Remove AVD code from Android CI
Reviewed By: cipolleschi
Differential Revision: D41521976
fbshipit-source-id: 2737ef0dfc84198ab9b837819c16ae46280ba43f
Summary:
Fixes https://github.com/facebook/react-native/issues/35429
This fix is fairly straightforward. Instead of hardcoding two separate paths for this repo or a simple user's project, we ask Node to resolve `react-native-codegen`.
Because `react-native-codegen` is moved [into the `/packages/*` folder](https://github.com/facebook/react-native/blob/main/package.json#L104), it's part of a workspace in this repository. That means that this fix works not only for monorepos in general but also resolves the right path within the react native repository.
You can test this out yourself when running this command in either the root, or any other workspace in this repository:
```bash
node --print "require('path').dirname(require.resolve('react-native-codegen/package.json'))"
```
I've tested this on Node 16 and 18, and seems to work nicely. Note that you _**have to specify `react-native-codegen/package.json`**_. That's because the `react-native-codegen` package itself is technically invalid; it's missing an entry point within the package (no `main`). When running `node --print "require.resolve('react-native-codegen')"` Node can't resolve the main entry point, and will fail during this process.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[iOS] [Fixed] - Fix incorrect codegen CLI paths in monorepo projects
Pull Request resolved: https://github.com/facebook/react-native/pull/35430
Test Plan: See PR https://github.com/facebook/react-native/issues/35429
Reviewed By: cortinico
Differential Revision: D41475878
Pulled By: cipolleschi
fbshipit-source-id: f0c362b64cf9c3543a3a031d7eaf302c1314e3f0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35456Fixes#35439
There is a bug in AGP 7.3.x which is causing assets to don't be copied properly inside the
final artifact: issuetracker.google.com/issues/237421684
As AGP 7.4.x is really close to release (is in Beta5, should be released stable in the next weeks)
we should be fine by bumping to beta5.
This also requires a bump of RNGP
Changelog:
[Android] [Changed] - Bump AGP to 7.4.x
allow-large-files
Reviewed By: cipolleschi
Differential Revision: D41519549
fbshipit-source-id: 60d568a3e49798a23f1d7bf4839ab58bd5549aba
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35461
This is another library which is adding prefab support as it's needed by
Expo libraries and Reanimated.
Changelog:
[Internal] [Changed] - Allow `reactnativejni` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D41520801
fbshipit-source-id: 91142a5b5051cfba478d93a2475a178eed6fbb29
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35460
Reanimated reported that `react_nativemodule_core` was missing some headers.
Specifically the one from ReactAndroid::react_debug, ReactAndroid::react_render_core, ReactAndroid::glog,
and ReactAndroid::react_render_debug.
I'm adding them here so they get included in the shipped headers for `react_nativemodule_core`
Changelog:
[Internal] [Changed] - Add missing headers to `react_nativemodule_core` prefab module
Reviewed By: cipolleschi
Differential Revision: D41520751
fbshipit-source-id: 4627a2d0f880d4bb3ff2f0e43cd735cf9a3f2f9a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35458
We're adding prefab support for those modules as they're needed by Reanimated
and we're exposing headers for them as well.
Changelog:
[Internal] [Changed] - Add prefab for _uimanager _scheduler and _mounting
Reviewed By: cipolleschi
Differential Revision: D41520606
fbshipit-source-id: 76f3c81705e99057b92cd9b86d0601a2b1410f95
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35457
This exposes `hermes-executor` to be consumed via prefab so that
libraries can depend on it and use its symbols if needed (Expo and Reanimated need it).
Changelog:
[Internal] [Changed] - Expose `hermes-executor` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D41520019
fbshipit-source-id: d590a043ea89fdd8ff41b0ed20900c9cf381a1e4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35454
Historically, we used to have hermes-executor debug and release as separate dynamic libraries.
This makes it impossible to prefab this library, so I have to reconcile it into a single library.
This will also help keep the setup consistent with the internal (BUCK) where we have a single target.
Changelog:
[Internal] [Changed] - Consolidate hermes-executor-debug and -release inside a single target
Reviewed By: cipolleschi
Differential Revision: D41519119
fbshipit-source-id: d9ddc30b72164daa29c735836ea433fd4d917fc8
Summary:
This script phase is added to the main target of the user project.
Adding it to the hermes-engine target is redundant and does nothing useful.
Changelog:
[iOS][Changed] - Do not add "Copy Hermes Framework" script phase to hermes-engine target.
Reviewed By: cipolleschi
Differential Revision: D41521276
fbshipit-source-id: a024fa33f7ec1605d1d6021f436d3d397871a50c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35445
As Flipper version is a bit old, let's bump it to the latest stable: 0.174.0.
This is a follow-up from D33583090 (https://github.com/facebook/react-native/commit/50057158ca32842d70160541e3cb5d4bd512f8f5).
At the time, it wasn't possible to update to the latest stable Flipper as crashes were observed due to NDK mismatch.
Changelog:
[Android] [Changed] - Bump Flipper to 0.174.0
Reviewed By: cortinico
Differential Revision: D41492705
fbshipit-source-id: 9ec205bb0b8e4ddcb56355a194cae0a64f3345d6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35455
This little change allows to support Gradle Configuration cache in user projects:
https://docs.gradle.org/current/userguide/configuration_cache.html
It allows to save several seconds on the build time.
We'll keep it disabled for now, but Gradle plans to enable it by default for everyone
in the future, so this changes makes us ready for it.
Changelog:
[Internal] [Changed] - RNGP - Correctly Support Gradle Configuration Cache
Reviewed By: cipolleschi
Differential Revision: D41519506
fbshipit-source-id: 6252546e811deb0777c0aab5332291368be7fa8f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35435
This raises the C++ language standard to C++17 which is needed to remove some folly:: dependencies
changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D41482821
fbshipit-source-id: 62af6e95e6e78378112a4ce4e9c3ab7df0587218
Summary:
This is a nit. We have this message "Please Report" which is really confusing in the
error message. Users are opening Github Issues but that's not really actionable for us.
We should clean it up.
Changelog:
[Internal] [Changed] - Do not suggest users to report on MessageQueue
Reviewed By: shwanton
Differential Revision: D41501707
fbshipit-source-id: fa57e50114a6e67b98f4b0b5d805031ae07d8776
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35444
Changelog:
[Internal][Changed] - now using Verdaccio to publish necessary packages for template app
- Adds script `/scripts/template/install-dependencies.js`, which incapsulates the logic of installing dependencies of template app
- The idea of the script is to run verdaccio and publish all necessary packages to node_modules, since these packages might not yet be present on npm
- This should also potentially resolve some template app test failures on CircleCI related to package-ifying Animated, VirtualizedList, FlatList modules
Reviewed By: cortinico
Differential Revision: D41498086
fbshipit-source-id: 48fbbb1c9334e7a9e7657e6275b7b04f9ce290b5
Summary:
i recently made a change to modularize some of our graphics dependencies
i think this codegen will be incorrect now after my diff, so i updated it so we would codegen the correct deps
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D41451842
fbshipit-source-id: 98b5576e9fbd2d693c8bcfeac39d8dfb1b1e0584
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35431
`[ -f "$source" ]` was wrong.
`man test` reads:
> -f file True if file exists and is a regular file.
-e file True if file exists (regardless of type).
hermes.framework is not a regular file but a directory. `-e` is beter here.
Also intermediate destiantion directories are now created if they didn't exist.
Changelog:
[iOS][Fixed] - Make copy-hermes-xcode.sh more reliable.
Reviewed By: robhogan
Differential Revision: D41472846
fbshipit-source-id: 87de0b48d178ca542299b8e5fa741fdc0570d4e2
Summary:
X-link: https://github.com/facebook/yoga/pull/1176
`Values` is a wrapper to story an array of YGValue's as CompactValues.
From https://github.com/facebook/yoga/issues/1174 we see a warning `Wdeprecated-copy` beacuse a user-defined copy constructor is not present, but a user-defined asignment operator is (the defaulted one). This adds an explicitly defaulted copy contructor which should silence the warning I think.
Changelog:
[Internal]
Reviewed By: christophpurrer
Differential Revision: D41447490
fbshipit-source-id: 8cc8f291cf12014d87cc71c4598bb84fdd6cd930
Summary:
In this diff I'm refactoring ViewGroupManager to implement IViewGroupManager
This will be used by ViewManagers that require to add views but don't depend on ViewGroupmanager
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D41386918
fbshipit-source-id: 427b9689eb3408c2477cf38494d42280b41fd7d8
Summary:
In this diff I'm introducing IViewGroupManager to extract methods required to add/remove views from a viewGroup
This will be used by ViewManagers that require to add views but don't depend on ViewGroupmanager
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D41386920
fbshipit-source-id: a7d893d92d0f12766dcc71dfd1b22539c3b9687d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35392
Changelog:
[General][Added] - For supporting Dev Loading View across platforms, adding the DevLoadingViewController without an activity/context.
Reviewed By: rshest
Differential Revision: D40947239
fbshipit-source-id: de124b0a7ee39dc7da3c1c45972a6703eff2f0ef
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35385
In OpenSource builds folly:: types are not always easy to consume.
With butter:: we actually allow consumers to opt-into other/non folly:: types (by providing a custom butter:: implementation).
This change adds a butter::function for that purpose.
It is especially useful for react-native-windows which prefers Mso::Functor over folly::Function.
You can use it by setting those compiler flags:
-DBUTTER_FUNCTION_OVERRIDE_INCLUDE=<functional/functor.h>
-DBUTTER_FUNCTION_OVERRIDE=Mso::Functor
std::function is no option as it is not move-only and we can't wait till 2025 > https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p0288r9.html
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D41388193
fbshipit-source-id: 56f58b9ddc602aa4b13000031d50de5228b4a16b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35296
This change adds some version checks and enforces that every version matches some specific format based on the build type we are trying to run.
## Changelog
[General][Changed] - Improve version checks
Reviewed By: cortinico
Differential Revision: D41161756
fbshipit-source-id: 4172195c5e031c1eaf7b33bb74f381c04e9adaf5
Summary:
changelog:
[General][Add] LogBox now makes URL links tappable.
Logbox messages may contain URLs with more information about the given error. Right now, they are not tappable or copyable. So engineers need to resort to manually retype the link to browser. This diff tries to address that.
Example of StrictMode error that has link in it.
{F798509909}
Reviewed By: yungsters
Differential Revision: D41305784
fbshipit-source-id: 456a9faf34f8b9e443759dd6903ba67d0b9de73c
Summary:
This PR makes sure that the `preapre_package_for_release` script fail fast if there is already a tag for the desired version
on github.
## Changelog
[General] [Added] - Make the `prepare_package_for_release` fail if there is already a git tag with that version
Pull Request resolved: https://github.com/facebook/react-native/pull/35305
Test Plan:
Tested manually. The script is currently only invoked during the release process.
<img width="1238" alt="Screenshot 2022-11-10 at 12 24 03" src="https://user-images.githubusercontent.com/11162307/201090947-274c1b1c-0b6a-4619-bc85-fa60e5eaeee1.png">
Reviewed By: cortinico
Differential Revision: D41403159
Pulled By: cipolleschi
fbshipit-source-id: fb87df345b14568c750482e5c68be53551a9acbb
Summary:
Original title: **[RN] Do not encode path to cmake in hermes-engine Pod, build hermesc in prepare_pods**
The result of `#{%x(command -v cmake | tr -d '\n')}` was being encoded into the `hermes-engine` Pod. This can lead to conflicts in the CocoaPods cache when `pod install` is run on different machines.
Instead of running the command during `pod install`, we defer to the actual build scripts so they can find `cmake` when `$CMAKE_BINARY` is not set.
More importantly, this fixes an issue that crept into the Sandcastle CocoaPods offline mirrors, but which would only manifest itself when people run `js1 oss prepare-pods`.
RNTester would not build due to RNTesterPods.xcworkspace being configured to use cmake from an arbitrary path instead of using the cmake from $PATH.
This does not affect Sandcastle due to `CMAKE_BINARY` getting overriden in Sandcastle.
---
**Update** by dmytrorykun:
It is impossible to address the problem described in the original title by simply adding `CMAKE_BINARY=${CMAKE_BINARY:-cmake}` to `build-hermes-xcode.sh`. This script is supposed to run from Xcode. Since Xcode doesn't have access to system `PATH` variable, it is unable to locate `cmake`, and build fails.
However this diff contains other useful changes:
1. Remove trailing newline in `cmake` path in `build-hermes-xcode.sh`.
2. Fix inverted logic in `copy-hermes-xcode.sh`.
3. Fix typo in `remove xcuserdata` step in Sandcastle.
4. Remove unused `HERMES_DISABLE_HERMESC_BUILD`.
Changelog:
[iOS] [Fixed] - Various fixes for Hermes build-from-source behaviour.
Reviewed By: cipolleschi
Differential Revision: D41139384
fbshipit-source-id: 4a4a44a7ac201d279718d84cd02d60b4eaf3956b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35397
This Diff removes the `HERMES_BUILD_FROM_SOURCE` that was not always propagated to the original script. This lead to some cases where hermesC was built during `pod install` and then removed by the `react_native_post_install`'s `else` branch.
Basically, when the Pods are installed the first time, everything run smoothly. Subsequent invocations of `pod install`, to install other dependencies, for example, will incur in this problem because:
1. Cocoapods will see that hermes-engine is already installed
2. the podspec is not executed, given that the pod has been fetched from the cache
3. The env var is not set (given that the podspec is not executed)
4. the main script sees the env var as not set, `ENV['HERMES_BUILD_FROM_SOURCE'] == "1"` return false
5. The `else` branch is executed, and it removes the `hermesc_build_dir` and the `copy Hermes framework` script phase.
## Changelog:
[iOS][Changed] - Remove `HERMES_BUILD_FROM_SOURCE` flag
Reviewed By: cortinico, dmytrorykun
Differential Revision: D41373439
fbshipit-source-id: ea4aafd187c0ca3ff5c0d79f8aeaaa46ad50f499
Summary:
The order of following calls is irrelevant.
```
__update_pods_and_offline_mirrors "$JS_ENGINE_JSC"
__update_pods_and_offline_mirrors "$JS_ENGINE_HERMES"
```
If execute `__update_pods_and_offline_mirrors "$JS_ENGINE_HERMES"` last, then `prepare_pods "$JS_ENGINE_HERMES"` is redundant.
allow-large-files
Changelog:
[Internal][Changed] - Cleanup offline pod mirrors updating behaviour.
Reviewed By: cipolleschi
Differential Revision: D41346899
fbshipit-source-id: 694713330fb94561d872883a18f97869cd30cd26
Summary:
Investigating [this comment](https://github.com/reactwg/react-native-releases/discussions/41#discussioncomment-4170008), I made some tests.
It seems like we can simply use `#import <RCTAppDelegate.h>` instead of the `#import <React-RCTAppDelegate/RCTAppDelegate.h>` in both setups:
- default setup
- `use_frameworks! :linkage => :static`
## Changelog
[iOS] [Fixed] - Support `use_framework! :linkage => :static` in template
Pull Request resolved: https://github.com/facebook/react-native/pull/35394
Test Plan:
1. Manually tested with a new app
2. CircleCI
3. Sandcastle
Reviewed By: cortinico
Differential Revision: D41402060
Pulled By: cipolleschi
fbshipit-source-id: e1ed8196ed860b3663a88f5283f2745e39b0e944
Summary:
Changelog:
[iOS][Changed] - Abort pod install if bad HERMES_ENGINE_TARBALL_PATH is set.
Reviewed By: cipolleschi
Differential Revision: D41341471
fbshipit-source-id: 34a3ac154b0a3f795d07dcd10f92361cb9bb4ad6
Summary:
The template has moved to typescript now, the self-reference needed an update
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[GENERAL] [FIXED] - reference App.tsx vs App.js in text of new typescript template
Pull Request resolved: https://github.com/facebook/react-native/pull/35377
Test Plan: It is just a text change - it either makes sense or it doesn't. I think it makes sense?
Reviewed By: cipolleschi
Differential Revision: D41386912
Pulled By: NickGerleman
fbshipit-source-id: 6e62c11567e8fbff70b123446a827b18af43e864
Summary:
The commit https://github.com/facebook/react-native/commit/3eddc9abb70eb54209c68aab7dbd69e363cc7b29 included on v0.69 introduced a wrong `if` statement inside the `componentDidUpdate` function of the `TouchableOpacity` component. As this `if` statement always evaluates to `true` (`(true || false) !== undefined`) we end up making unnecessary calls to the `_opacityInactive` method every time the component props changes, e.g. every time a `<Text>` inside the TouchableOpacity changes we call this function over and over, and this has been causing some performance issues on big lists.
This PR fixes this problem by adjusting the `componentDidUpdate` function to only call `_opacityInactive` when necessary.
Closes https://github.com/facebook/react-native/issues/34442
Closes https://github.com/facebook/react-native/issues/32476
## Changelog
[General] [Fixed] - Fix TouchableOpacity componentDidUpdate causing an excessive number of pending callbacks
Pull Request resolved: https://github.com/facebook/react-native/pull/35387
Test Plan:
1. Open the RNTester app and navigate to the `Touchable* and onPress` page
2. Test the `TouchableOpacity` component through the many sections
Reviewed By: cipolleschi
Differential Revision: D41397396
Pulled By: ryancat
fbshipit-source-id: 24863b5cbbdd2f3dd1f654b43d7031560937b888
Summary:
X-link: https://github.com/pytorch/pytorch/pull/89233
The `-weak_framework` flag is no longer necessary, Buck will weakly link frameworks depending on the `target_sdk_version` of the binary being linked.
Reviewed By: ebgraham, malfet
Differential Revision: D41348639
fbshipit-source-id: 47992282ba030294b2304c550d49df13e24e9c79
Summary:
- Untrack Test Reports generated by test libraries (reporters E.g. `jest-junit`)
- E.g. `/reports/junit/js-test-results.xml` report is generated; when we exec `yarn test-ci`, which is **_shouldn't_ be tracked**
### NOTE: Used `[skip ci]` to avoid wastage of compute resources �🌏
- Feel free to init tests manually if you find it necessary
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[GENERAL] [CHANGED] - Untrack Test Reports generated by test libraries (reporters E.g. `jest-junit`)
Pull Request resolved: https://github.com/facebook/react-native/pull/35187
Test Plan:
`yarn test-ci`

Reviewed By: cipolleschi
Differential Revision: D40993282
Pulled By: sshic
fbshipit-source-id: 3fe150d3e8bd45cec56b50f2dc071002412e475e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35379
This diff moves the publishing coordinates from:
```
com.facebook.react:react-native
com.facebook.react:hermes-engine
```
to
```
com.facebook.react:react-android
com.facebook.react:hermes-android
```
I've picked those they are the most layout friendly when building from source, but we can discuss if we want others.
I've updated the Gradle plugin to have a dependencySubstitution rule + update the template with those changes.
It should now be possible to still use `implementation("com.facebook.react:react-native:+")` inside libraries
on 0.71+ and RNGP will resolve dependencies correctly.
Changelog:
[Android] [Changed] - Void the Maven coordinates for react-native and hermes-engine
Reviewed By: cipolleschi
Differential Revision: D41380525
fbshipit-source-id: 91e059fa261acb89bee7ca0c79c30c3d856a2c80
Summary:
From exception logging, found crashes due to `Attempt to invoke virtual method 'int android.view.ViewGroup.getChildCount()' on a null object reference`. Tracing through the stack, it appears the constructor for `ViewGroup` conditionally calls `initializeScrollbarsInternal()`, which in turn calls `getChildCount()`. However `ReactModalHostView` overrides `getChildCount()`, so `getChildCount()` is called before `ReactModalHostView` constructor completes, resulting in null reference when accessing `mHostView` from `getChildCount()`.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Android] [Fixed] - Fix crash on initialize modal
Pull Request resolved: https://github.com/facebook/react-native/pull/35380
Test Plan: In the rn-tester project, display a modal.
Reviewed By: javache, cipolleschi
Differential Revision: D41392235
Pulled By: ryancat
fbshipit-source-id: ce78e4d458ad41769e78139ea0a8a038384e830d
Summary:
This allows folks with a monorepo setup for React Native to set a simple configuration on the "Bundle React Native code and images" phase. This is because the bundler was configured to look for node_modules in a specific place, but in a monorepo your node_modules may be at the root one layer lower than a default configuration.
This same pattern of overriding this variable exists in the [react-native-xcode](https://github.com/facebook/react-native/blob/main/scripts/react-native-xcode.sh#L63) file.
Fixes: https://github.com/facebook/react-native/issues/33636 - "Unable to resolve module index"
```
Error: Unable to resolve module ./index from /Volumes/Nexus/Projects/xxx/.:
None of these files exist:
* index(.native|.android.js|.native.js|.js|.android.jsx|.native.jsx|.jsx|.android.json|.native.json|.json|.android.ts|.native.ts|.ts|.android.tsx|.native.tsx|.tsx)
* index/index(.native|.android.js|.native.js|.js|.android.jsx|.native.jsx|.jsx|.android.json|.native.json|.json|.android.ts|.native.ts|.ts|.android.tsx|.native.tsx|.tsx)
```
## Changelog
[General] [Added] - Add support for overriding `PROJECT_ROOT` during bundle steps for monorepos.
Pull Request resolved: https://github.com/facebook/react-native/pull/35354
Test Plan: Working CI build via CircleCI.
Reviewed By: cipolleschi
Differential Revision: D41319439
Pulled By: ryancat
fbshipit-source-id: 8516e54436b0a9d4b9df1efeee8e62c95d4d35b2
Summary:
Changelog: [Internal]
I think this started to break when https://github.com/facebook/react/pull/25441 was synced to RN. Before, `closestInstance` would only be non-null under Fabric, after it could be non-null in both. And we were using `closestInstance` to determine which data to send to `selectNode` in devtools. This diff makes a change to call `selectNode` once for non-fabric and once for fabric, one of them would not send anything to devtools frontend, this would make sure it works for both platforms.
Reviewed By: mondaychen
Differential Revision: D41366466
fbshipit-source-id: fcf30d03e443f6fa067782cd31b7cfd2e0cd841e
Summary: Cleanup rn_defs. Most of the imports here were not related to RN, and for others we can use rn_apple_library instead.
Reviewed By: mdvacca
Differential Revision: D41302584
fbshipit-source-id: 0db79e202c0e18dd590ae0e6bf2821e6b49b606a
Summary:
UIRefreshControl has a tight integration with iOS in terms of UINavigationBar/UIScrollView. In this regard, whenever there's a UIScrollView with a UINavigationBar on top, the OS automatically adjusts the contentInset of the UIScrollView to reflect that (something that is exposed to React Native). In a similar manner, UIScrollView passes this along to the attached UIRefreshControl.
By setting the frame manually, the RCTRefreshControl component was preventing this behavior. Although having the option is desired, it should not be done by default. In the past it was possible to adjust for this by manually setting the correct value, calculating the statusBar's height/safeAreaInsets.top and appending 44pt (the UINavigationBar height). However, due to changes related to the Dynamic Island (see [here](https://useyourloaf.com/blog/iphone-14-screen-sizes)), the safe area and the status bar size no longer align, making this calculation more tricky.
In summary: this changes allows `progressViewOffset` to exist (in order to maintain feature parity with Android) but provides the opportunity for the OSs default behavior to kick in when applicable.
| Applying by default | Not applying by default (this change) |
:-------------------------:|:-------------------------:
 | 
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[iOS] [Fixed] - Fix application of _progressViewOffset in RCTRefreshControl to not occur by default (when value is unset)
Pull Request resolved: https://github.com/facebook/react-native/pull/35281
Test Plan: The GIFs attached display the behavior as expected/unexpected. I'm unaware of any tests written for RCTRefreshControl that could be improved to cover this change. Notes appreciated.
Reviewed By: sammy-SC
Differential Revision: D41302080
Pulled By: cipolleschi
fbshipit-source-id: a2a8e6ef1dcc2e73220c2a182b4516f3bbd94f60
Summary:
Jscodeshift has become maintained again in the past year, and has gotten rid of quite a good chunk of old dependencies that are no longer needed!
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - update jscodeshift
Pull Request resolved: https://github.com/facebook/react-native/pull/35356
Reviewed By: cipolleschi
Differential Revision: D41325527
Pulled By: rshest
fbshipit-source-id: 666b25c9bb3b1720479e9e098968b3b983adc2b4
Summary:
Fix linter warning when pulling in some code into AR
Changelog: [Internal]
Reviewed By: NickGerleman, mdvacca
Differential Revision: D41269423
fbshipit-source-id: 4305d6c362a51e62b19b4d3590fb0823073dff9a
Summary:
# What
* Pass the DevTools Settings Manager to connectToDevTools.
* This is an object that provides write and synchronized read access to on-device storage, that React DevTools will use during startup.
* This allows us to persist settings like whether to show component stacks on error, and on restart, behave correctly. In the future, this will be used to power the "restart and profile" flow.
Changelog
[General][Added] Pass DevTools Settings Manager to connectToDevTools
Reviewed By: lunaruan
Differential Revision: D40880260
fbshipit-source-id: 379a2c93b4cde0360e6fd380d837f426943bfa9e
Summary:
Fixes missing/incorrect devDependencies in a newly built app. The previous set did not pull in prettier, causing linting to fail. There was a peerDependency warning on yarn install. We also saw a separate lint warning at runtime specific to TS 4.9 being pulled in now, so we constrain in that version a bit.
Prettier and preset-env versions match the constraints and lockfiles of other RN packages.
## Changelog
[General] [Fixed] - Fixup template devDependencies
Pull Request resolved: https://github.com/facebook/react-native/pull/35372
Test Plan:
Created a new app targeting 0.71 via `react-native init`.
1. `yarn install --force` no longer shows warnings
2. `prettier` is installed, `yarn lint` no longer fails, and shows no warnings or errors
3. ~Tentatively a test step to add tests against linting in new app, but last time doing that in CircleCI led to timeouts with no output that I didn't have time to debug, so maybe that's fixed now? �♀️.~ (edit: still hangs)
Reviewed By: NickGerleman
Differential Revision: D41363021
Pulled By: lunaleaps
fbshipit-source-id: d6163b01e8934d75a231fa0fd849d7bde7b3500c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35353
Unfortunately we have 2 different definitions of SystraceSection.h
- xplat/js/react-native-github/ReactCommon/cxxreact/SystraceSection.h
- xplat/js/react-native-github/ReactCommon/react/renderer/debug/SystraceSection.h
The first one is the Old Arch one and the second one is the New Arch one.
As we first step, we unify the implementation
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D41307049
fbshipit-source-id: a9eb854dfcf49f87ad81fd9cc8dbe51648ecd209
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35342
This is a native implementation of the JS shimmed layout-specific properties in https://github.com/facebook/react-native/pull/35316.
There is an experiment splitting the prop splitting codepath in Fabric, so this change effectively has two implementations depending on whether `enablePropIteratorSetter` is enabled.
None of these changes make sense to propagate Yoga. `inlineEnd`, etc are already mapped to `YGEdgeStart` and `YGEdgeEnd`, but RN's mapping used a different name. Then `blockStart`, `blockEnd`, map directly to existing edges in all cases since we don't support a writing mode.
On web, the last value in the style which computes the given dimension is given precedence. E.g. if "left" comes after "start" it will be chosen. Yoga stylesheets are unordered, and precedence for edges is given based on specificity (left > start > horizontal > all).
We give precedence to new renamings (e.g. start to inlineStart), but to preserve consistent behavior, we give precedence to specific edges before overwriting them with flow relative ones (e.g. marginTop has precedence over marginBlockStar).
Changelog:
[General][Added] - Add Fabric implementation of flow-relative padding and margin
Reviewed By: javache
Differential Revision: D41267765
fbshipit-source-id: 896e2ed71fe8bf83aef00b0a9d70fd20b2ce47a7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35369
Somwhere between importing https://github.com/facebook/react-native/pull/35017 and running `js1 oss update-pods`, the entire Podfile lock was deleted without me noticing. This change runs `js1 oss prepare-pods` to restore it.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D41343786
fbshipit-source-id: 79abe41b18b8e13b9fba70906b8301b002d0e3db
Summary:
This change puts back D40716048 (https://github.com/facebook/react-native/commit/279cfec55fdf404fdb9198edbb37d3adfdfb3bf1) but in the right way, i.e. modifying the script that should generate those changes.
## Changelog
[iOS][Added] - Make the blobs proper TM
Reviewed By: dmytrorykun
Differential Revision: D41312160
fbshipit-source-id: 38850a63eb8d66ffd179743b4948a23340c8782e
Summary:
changelog: [internal]
Removing this to decrease clutter of warnings when devs navigate to Marketplace Home.
Reviewed By: cipolleschi
Differential Revision: D41306378
fbshipit-source-id: a1b7f8ebe1f4bb00e931d609eb97a3bbd5ef9052
Summary:
This PR is a task of https://github.com/facebook/react-native/issues/34872
- combined `Flow` and `TS` `buildPropertySchema` fn 's into common fn
- added callback param `resolveTypeAnnotation` to the same
- moved it to `parsers-commons.js`
- re-organized imports and exports
## Changelog
[INTERNAL] [CHANGED] - [Codegen]: Refactored `buildPropertySchema` fn of (Flow, TS) into common fn in `parsers-commons.js`
Pull Request resolved: https://github.com/facebook/react-native/pull/35288
Test Plan:
- ensure 👇 is `#00ff00`
```bash
yarn lint && yarn flow && yarn test-ci
```
Reviewed By: christophpurrer
Differential Revision: D41247738
Pulled By: cipolleschi
fbshipit-source-id: aecc0ed8d07efa1c2c39e8a8e64b4ee73b720b8f
Summary:
Cherry pick https://github.com/microsoft/react-native-macos/commit/e877ebfe083ffaa252738477098322504492f4be from React Native macOS into React Native Core. We've had this bug fix in our fork for a while now, so it's probably safe.
=== Original change notes ===
First, misc straightforward deprecated API updates.
Second, defensive changes to potentially address RCTDisplayLink crash.
Real-world data suggests crashes with this stack:
CVDisplayLink::start()
-[RCTDisplayLink updateJSDisplayLinkState] (RCTDisplayLink.m:157)
-[RCTDisplayLink registerModuleForFrameUpdates:withModuleData:]_block_invoke (RCTDisplayLink.m:67)
-[RCTTiming timerDidFire] (RCTTiming.mm:324)
-[_RCTTimingProxy timerDidFire] (RCTTiming.mm:93)
Some symbols are missing in this stack, presumably due to compiler optimizations.
-updateJSDisplayLinkState is calling CVDisplayLinkStart as a result of a
call to "_jsDisplayLink.paused = NO".
-registerModuleForFrameUpdates block is presumably getting called via pauseCallback,
likely via [RCTTiming startTimers], presumably owned by RCTCxxBridge.
The most likely immediate explanation for the crash is that we are calling
CVDisplayLinkStart with a zombie _displayLink pointer.
However there is a lot of indirection here as well as thread-hopping, and
unfortunately no clearly incorrect code that would explain such a zombie pointer.
Some defensive changes:
-explicitly remove the association to pauseCallback when underlying display link object is invalidated.
-remove a prior attempt at additional check in updateJSDisplayLinkState itself as it is not relevant.
-make sure we explicitly set _displayLink to NULL when we release it, such that there is one less failure point.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - RCTDisplayLink fix plus bonus deprecated API cleanup
Pull Request resolved: https://github.com/facebook/react-native/pull/35359
Test Plan: CI should pass.
Reviewed By: cipolleschi
Differential Revision: D41335438
Pulled By: christophpurrer
fbshipit-source-id: 5e97d28eab7dd8e5c81d0a5386df6631e16405a2
Summary:
Cherry pick https://github.com/microsoft/react-native-macos/commit/19a62d9f57a6fae7a046741e19978a801f69abee to React Native. These style props were being applied to a <Text> element, not a <View> element. They seemingly only worked because of a quirk of iOS.
=== Original change notes ===
The issue with the test is that the react native Text component has its own props for shadows - i.e. [textShadowColor, textShadowRadius, etc](https://reactnative.dev/docs/text-style-props) and the shadow props that View uses does not work on Text (i.e. shadowColor, shadowRadius, etc.). Not entirely sure how this test was passing without any errors before my change, it seems like something about the change is causing (expected) errors to actually show up.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Fixed] - Shadow consistency opacity fix with test updates
Pull Request resolved: https://github.com/facebook/react-native/pull/35360
Test Plan: Tested in our React Native macOS fork on iOS.
Reviewed By: cipolleschi
Differential Revision: D41335366
Pulled By: christophpurrer
fbshipit-source-id: f789b9565ed4e00fa558af8e418dd9e078064f98
Summary:
X-link: https://github.com/facebook/yoga/pull/1173
In https://github.com/facebook/react-native/issues/35351 we see incorrect child item height when the flex-wrap is enabled, the cross-axis is to be stretched, and main-axis overflow is caused by gap.
In YGDistributeFreeSpaceSecondPass, if we do not have overflow (determined by flexBasisOverflows), we have stretch cross-alignment, and we reason that nothing can add to main axis dimensions, we know we're a single line and want to take full cross dimensions. and can set YGMeasureModeExactly which uses parent dimensions. Guessing an optimization?
If we do have overflow, then we set YGMeasureModeAtMost to find minimum possible cross-axis dimensions instead.
`flexBasisOverflows` incorporates both computed flex basis, and margin, so it is more generally a flag for whether we will wrap. So we should incorporate gap spacing into it. E.g. it is also used for whether we should the match main axis parent dimension of the overall container. This change does just that, and renames the flag to `mainAxisOverflows`.
We will want to cherry-pick the fix for this into RN 0.71 since we have not yet introduced the community to the incorrect behavior, and we expect a lot of usage of flex-gap.
Changelog:
[General][Fixed] - Fix incorrect height when gap causes main axis to overflow and cross-axis is stretched
Reviewed By: yungsters
Differential Revision: D41311424
fbshipit-source-id: bd0c3b5aac478a56878703b6da84fc3993cc14da
Summary:
The goal of this diff is to introduce the scafolding of a BoxComponent. This class will be eventually shared by Android and iOS
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D41205801
fbshipit-source-id: e33e58062aa33e0c8e9a48fd112309a358f0a060
Summary:
The goal of this diff is to refactor the name of Component to ComponentDeprecatedAPI
Also, I'm introducing a new very simple Component API, this new Component will evolve in the next few diffs and days
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D41128461
fbshipit-source-id: b6aea08caa609153663cdd4165694cc57b4b76b6
Summary:
Rename this helper to make it explicit what it's used for. There's still more to do here to simplify these.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D41184338
fbshipit-source-id: a33d306978cb9026ebf10b00853042da4aaecd5a
Summary:
a lot of files were depending on Geometry even though they didn't use Vector, this will help with future modularity
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D41127194
fbshipit-source-id: 024519c638a1f0df3fdbfbdd937eac84b9adee6e
Summary:
at some point, the `Build.FINGERPRINT` of the emulator has changed and no longer includes `generic` as an option.
It apparently now, on all platforms, includes `google/sdk_gphone` at the beginning. Older emulators may still include `generic` in the `Build.FINGERPRINT` so we should maintain that check too.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Android] [Fixed] - Fix android emulator detection for packager host
Pull Request resolved: https://github.com/facebook/react-native/pull/35111
Test Plan: When running on a modern emulator, ensure that the packager attempts to load from `10.0.2.2`.
Reviewed By: cipolleschi
Differential Revision: D41266071
Pulled By: GijsWeterings
fbshipit-source-id: 43115dbde6a411fe2ebde23e720dff4812a4309f
Summary:
This PR should solve the `"Circular Dependencies"` problem/issue because of which some PRs are getting blocked as discussed here https://github.com/facebook/react-native/pull/35288#issuecomment-1314081952
- also moved below helpers to `parsers-commons.js`;
- `getTypeAnnotationParameters`
- `getFunctionNameFromParameter`
- `getParameterName`
- `getParameterTypeAnnotation`
- `getTypeAnnotationReturnType`
<3
## Changelog
[INTERNAL] [CHANGED] - Moved `translateFunctionTypeAnnotation` fn from `parsers-primitives.js` to `parsers-commons.js` also, moved it's helpers
Pull Request resolved: https://github.com/facebook/react-native/pull/35343
Test Plan:
- ensure 👇 is `#00ff00`
`yarn lint && yarn flow && yarn test-ci`
Reviewed By: christophpurrer
Differential Revision: D41273191
Pulled By: rshest
fbshipit-source-id: cc1839a91579e7914f05516a90b280a776510c9d
Summary:
Changelog:
[Internal][Changeded] - https://github.com/facebook/react-native/pull/31841 introduced customisations for DevSupportManager which made this create() redundant, hence deprecating and adding the annotation.
Reviewed By: cipolleschi
Differential Revision: D41292920
fbshipit-source-id: 9fc348a3f4f8f64ba6f7aee85f302e87e10e8cd5
Summary:
`aria-labelledby` Flow types were added to the Text props on https://github.com/facebook/react-native/commit/f353119113d6fc85491765ba1e90ac83cb00fd61 but the text component does not support `accessibilityLabelledBy`, which is the prop we were supposed to map `aria-labelledby` to. As the Text component does not really support `aria-labelledby` this PR updates the `TextProps` documentation to explain that this prop is necessary for cross-platform purposes and that other platforms need it.
## Changelog
[Android] [Changed] - Add notes to `aria-labelledby` from Text props
Pull Request resolved: https://github.com/facebook/react-native/pull/35327
Test Plan: Ensure CI is green
Reviewed By: necolas
Differential Revision: D41280877
Pulled By: lunaleaps
fbshipit-source-id: 81cf016bcf3117f15385ddd119c44d6f9fdd6b68
Summary:
Deletes `setAndForwardRefs` because it encourages a subtle pitfall with managing the referential equality of `ref` entities.
By the time this commit is landed, there will have been no more call sites to it in the `facebook/react-native` repository.
Changelog:
[Internal]
Reviewed By: sammy-SC
Differential Revision: D41209331
fbshipit-source-id: 3ef9c3543b581a716a1e41e524957867ee811675
Summary:
Normally when a `ref` prop supplied to a component is changed, the old `ref` receives `null` and the new `ref` receives the active component instance.
However, the current implementation of `ScrollView` has a bug where this does not happen (i.e. changing `ref` or `innerViewRef` does not cause either the old or new refs to be updated). This bug is due to a subtle issue with how `ScrollView` internally memoizes the `ref` (or `innerViewRef`) that is passed into the native component.
This commit fixes this behavior so that `ScrollView`'s `ref` and `innerViewRef` have the correct behavior.
Changelog:
[General][Fixed] When a ScrollView's `ref` or `innnerViewRef` changes, the old ref will now be invoked with `null` and the new ref with the active instance. (Previously, changing `ref` or `innerViewRef` on a `ScrollView` would be treated as though the ref had not changed at all.)
Reviewed By: sammy-SC
Differential Revision: D41208895
fbshipit-source-id: b465f666076edbef410cdf9661e040e1d8fa0404
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35285
While doing the release 0f 0.71.0-RC0, we noticed that having the RN version in the hermes tarball was causing more harm than good.
With the version in the name, we ended up with multiple tarballs for debug and release and we were not able to explicitly pick the right tarball given a build.
This change remove the version from the tarball name.
## Changelog
[General][Changed] - Remove React Native version from Hermes tarball name
Reviewed By: lunaleaps
Differential Revision: D41156353
fbshipit-source-id: 8899d5e1e1555bc728d923f3b78d1261e6ff09c7
Summary:
This is a backport of [this](https://github.com/facebook/react-native/commit/becb47ccb6a6ed77e81b5488561ef6d683933ffe) local fix we made on
0.71-stable.
All our podspecs delegates to the main React Native pods script to set up the dependencies properly. The React-Codegen.podspec, which is generated by
the script itself, was generated with hardcoded dependencies. This PR aligns the versioning with the other podspec.
On a side note, this could create issues in CI and when releaseing, because we are changing the versions to prepare the new release and it breaks some
steps.
## Changelog
[iOS] [Fixed] - Make sure that the React-Codegen.podspec does not enforce specific versions of its dependencies.
Pull Request resolved: https://github.com/facebook/react-native/pull/35274
Test Plan:
1. Ruby tests are passing
2. Manually tested that pods are correctly installed in the following configurations
- RNTester - Hermes - Old Architecture
- RNTester - Hermes - New Architecture
- RNTester - JSC - Old Architecture
- RNTester - JSC - New Architecture
Reviewed By: christophpurrer
Differential Revision: D41153859
Pulled By: cipolleschi
fbshipit-source-id: 043513866a66ecca3e326f8671bea3ec576422de
Summary:
Refering to "Support function signature along with function type properties in commands" in https://github.com/facebook/react-native/issues/34872
Many TypeScript programmers prefer `{ name(arg:string):void; }` to `{ readonly name:(arg:string)=>void; }`.
In this pull request, I updated test cases in both commands and modules to cover it, with missing implementation.
Command arguments are `NamedShape<T>` but the `optional` field is missing, it is also fixed.
## Changelog
[General] [Changed] - Add `TSMethodSignature` to react-native-codegen
Pull Request resolved: https://github.com/facebook/react-native/pull/35311
Test Plan: `yarn jest react-native-codegen` passed
Reviewed By: rshest
Differential Revision: D41217482
Pulled By: cipolleschi
fbshipit-source-id: 480af118d09b022bae919c5391547fd82c1a7cc9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35315
These headers are needed on react-native-macOS, but not explicitly imported all the time.
It seems that some UIKit header will implicitly import them.
We have other use case in react-native(-iOS) in which we also explicitly importing them - https://github.com/facebook/react-native/search?q=QuartzCore- , hence use following 'that' practice 'here'.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D41229835
fbshipit-source-id: b0182bf4f7905e8e157b341eb62cadec6ba354ca
Summary:
Inlines `setAndForwardRef` into `createAnimatedComponent.js`.
I am planning to delete `setAndForwardRef` because it encourages a subtle bad practice with management of the referential equality of `ref` entities. I am doing this instead of refactoring `createAnimatedComponent` because this legacy implementation is planned to be replaced very soon.
Changelog:
[Internal]
Reviewed By: sammy-SC
Differential Revision: D41205066
fbshipit-source-id: dc481e73a6c4d6acbae530d4da48b3a032575179
Summary:
Switches `TextInput` from `setAndForwardRefs` to `useMergeRefs` (and `useCallback`).
Instead of creating a new `_setNativeRef` function on every render, this will now only create a new ref function when either `mostRecentEventCount` changes, `viewCommands` (i.e. `props.multiline` on iOS) changes, or when `props.forwardedRef` changes.
When a text input is being edited, `mostRecentEventCount` will probably change. But when an unfocused `TextInput` is being updated because a parent is being updated, we will now no longer unnecessarily create a new `ref`. The observable behavior of this is that any `ref` supplied onto `TextInput` will now be invoked less frequently.
Changelog:
[General][Changed] Any `ref` set on `TextInput` will now be updated less frequently (when the underlying `ref` has not changed).
Reviewed By: sammy-SC
Differential Revision: D41191439
fbshipit-source-id: c69a061317c51ad6c6ca8acd116539e0f24a1d08
Summary:
While refactoring `TextInput`, I noticed that we are allocating each of the exported imperative instance methods on every invocation of the component. This is wasteful because if the `ref` does not change, this just creates more garbage.
Instead, we only need to allocate them when we are actually going to assign them onto a `ref`.
Changelog:
[Internal]
Reviewed By: sammy-SC
Differential Revision: D41191440
fbshipit-source-id: 0120d67a9e29a3e0c3f42c3fa436381d6bec7619
Summary:
Straightforward refactor of how `TextInput` augments the exported `ref` with instance methods.
This change is in preparation for additional refactors to eliminate `setAndForwadRefs`.
Changelog:
[Internal]
Reviewed By: christophpurrer
Differential Revision: D41191441
fbshipit-source-id: 30560ce489c48409003a9f92875e5096d3f1130e
Summary:
Hi, while adjusting [react-native-screens](https://github.com/software-mansion/react-native-screens) to `0.71.0-rc.0` I encountered the same problems as reported [here](https://github.com/reactwg/react-native-releases/discussions/41#discussioncomment-4085694) by WoLewicki.
Basically inside `CMake`'s `foreach` loop iterator variable is not being expanded to the actual value:
```cmake
foreach(autolinked_library ${AUTOLINKED_LIBRARIES})
target_link_libraries(autolinked_library common_flags) // <-- here we are literally linking to "autolinked_library".
endforeach()
```
## Changelog
[Android] [Fixed] - Fix Android autolinking failing because of not expanded variable
Pull Request resolved: https://github.com/facebook/react-native/pull/35306
Reviewed By: christophpurrer, cipolleschi
Differential Revision: D41220408
Pulled By: rshest
fbshipit-source-id: 12ce993f0c5227ca7d3c2cc272fe3739126930b3
Summary:
Cleans up `ScrollView-test.js` to be easier to read and to include a unit test for `ref`.
This prepares the Jest test suite to be extended with an additional test to validate a bug with `ref` invalidation.
Changelog:
[Internal]
Reviewed By: sammy-SC
Differential Revision: D41208894
fbshipit-source-id: 6d79adf131602292f7aa3180b1c230643e9baf16
Summary:
Add explicit annotations to React hook callbacks as required for Flow's Local Type Inference project. This codemod prepares the codebase to match Flow's new typechecking algorithm. The new algorithm will make Flow more reliable and predictable.
This diff adds `any` or `$FlowFixMe` in cases where more precise types could not be determined.
Details:
- Codemod script: `.facebook/flowd codemod annotate-react-hooks ../../xplat/js --default-any --write`
- Local Type Inference announcement: [post](https://fb.workplace.com/groups/flowlang/posts/788206301785035)
- Support group: [Flow Support](https://fb.workplace.com/groups/flow)
drop-conflicts
bypass-lint
Reviewed By: SamChou19815
Differential Revision: D41231214
fbshipit-source-id: d5f5ce8d61020baa1138292c9e9f1c69dffd324c
Summary:
Add explicit annotations to underconstrained implicit instantiations as required for Flow's Local Type Inference project. This codemod prepares the codebase to match Flow's new typechecking algorithm. The new algorithm will make Flow more reliable and predictable.
This diff adds `any` or `$FlowFixMe` in cases where more precise types could not be determined.
Details:
- Codemod script: `.facebook/flowd codemod annotate-implicit-instantiations ../../xplat/js --default-any --write`
- Local Type Inference announcement: [post](https://fb.workplace.com/groups/flowlang/posts/788206301785035)
- Support group: [Flow Support](https://fb.workplace.com/groups/flow)
drop-conflicts
bypass-lint
Reviewed By: SamChou19815
Differential Revision: D41226960
fbshipit-source-id: e5e3edbb1aed849f90cc683a4d416a9a2f8f3a19
Summary:
Changelog: [Internal]
The feature flag is a function not a boolean, flow didn't caught it..
Reviewed By: rbalicki2
Differential Revision: D41172775
fbshipit-source-id: b8a3365ab65049706b59e7e859f5f931ecab8360
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35256
Changelog:
[General][Added] - Making Dev Loading View cross platform by abstracting out the activity/context logic from the controller in a polymorph class.
Reviewed By: rshest
Differential Revision: D40908923
fbshipit-source-id: db8e94f8ded5ffe0deeb88335cd7f3d1bf87243a
Summary:
When a __rounded__ View on Android has a border, a small gap appears between the border and the center of the view (most noticeably when the background and border colors are the same)
Since the border is drawn on top of the other layers, the approach here is to make the center of the View slightly larger so that there is an overlap with the border, and closing the visible gap
There are 2 cases for a View with a border:
1. `borderWidth` is set for a consistent border width around all 4 edges
2. Uneven border widths are set (using `borderTopWidth`, `borderLeftWidth, ...)
**How is a rounded rectangle drawn?**
__Case 1__: `borderWidth` is set for a consistent border width around all 4 edges
- Before:
- first, `mInnerClipPathForBorderRadius` was used to draw the center of the View
- then the border is drawn along the path of `mCenterDraw` with a stroke width of the border width
- Now:
- `mBackgroundColorRenderPath` is used to draw the center of the View and is exactly a slightly enlarged version of `mInnerClipPathForBorderRadius`
__Case 2__: Uneven border widths are set (using borderTopWidth, borderLeftWidth, ...)
- Before:
- `mInnerClipPathForBorderRadius` was used to draw the center of the View
- for each edge, a quadrilateral is drawn
- `mOuterClipPathForBorderRadius` clips the outer edge of the border
- `mInnerClipPathForBorderRadius` (same is used to draw the center of the View) clips the inner edge of the border
- Now:
- `mBackgroundColorRenderPath` is used to draw the center of the View, allowing `mInnerClipPathForBorderRadius` to persist as the path that clips the inner edge of the border
When `mGapBetweenPaths` = 0, `mBackgroundColorRenderPath` == `mInnerClipPathForBorderRadius`, which is exactly the original implementation
Changelog:
[Internal][Fixed] - rounded Views with borders shows small gap
Reviewed By: mdvacca
Differential Revision: D39979567
fbshipit-source-id: 6db71d14ead6256e1b7becf73862e0a537c6a47b
Summary:
In D38850138 (https://github.com/facebook/react-native/commit/63a4539e4d36ac90137eea6cdde0154ca06878c0) I added a new example of the runtime permission `POST_NOTIFICATIONS` to RNTester, but forgot to add this permission to AndroidManifest.xml.
Changelog:
[Android][Added] - Add POST_NOTIFICATIONS permission to AndroidManifest of RNTester
Reviewed By: fkgozali
Differential Revision: D41204931
fbshipit-source-id: 80e5d526406715fd7570cc94cbf384858ff05aed
Summary:
Refer to "Support intersection of object types, `{...a, ...b, ...}` in Flow is equivalent to `a & b & {...}` in TypeScript, the order and the form is not important." in https://github.com/facebook/react-native/issues/34872
In this change I also extract the common part from `getTypeAnnotation` and `getTypeAnnotationForArray` into `getCommonTypeAnnotation`. Most of the differences are about `default` in the schema. After a schema is generated from `getCommonTypeAnnotation` successfully, `getTypeAnnotation` will fill `default` if necessary, while `getTypeAnnotationForArray` does nothing.
## Changelog
[General] [Changed] - Add intersection types in react-native-codegen for TypeScript
Pull Request resolved: https://github.com/facebook/react-native/pull/35247
Test Plan: `yarn jest react-native-codegen` passed
Reviewed By: cipolleschi
Differential Revision: D41105744
Pulled By: lunaleaps
fbshipit-source-id: cd250a9594a54596a20ae26e57a1c801e2047703
Summary:
Android 13 adds a new `POST_NOTIFICATION` runtime permission, which can only be requested if the `targetSdkVersion` of the app is set to 33. Since we upgrading Catalyst to SDK 33, let's add it as one of the permission examples.
Changelog:
[Android][Changed] - Add POST_NOTIFICATION runtime permission to RNTester
Reviewed By: fkgozali
Differential Revision: D38850138
fbshipit-source-id: 4cf7a5f60dd0891d7ada40aca37f0489d9d0d190
Summary:
changelog: [internal]
Call `AnimatedProps.setNativeView` any time `AnimatedProps` node changes to make sure it is always connected to underlaying host component.
Reviewed By: yungsters
Differential Revision: D41122065
fbshipit-source-id: 1d10fdd44933ff82d9bfc424cecb2640b7a66837
Summary:
Part of https://github.com/facebook/react-native/issues/34872:
> Update the [IncorrectlyParameterizedGenericParserError](https://github.com/facebook/react-native/blob/main/packages/react-native-codegen/src/parsers/errors.js#L134) error in the error.js file to accept a Parser instead of a ParserType parameter. Use the nameForGenericTypeAnnotation method of the parser to extract the genericName and delete the ternary operator.
Since the task was added to the issue we split the IncorrectlyParameterizedGenericParserError into 2 errors: MissingTypeParameterGenericParserError and MissingTypeParameterGenericParserError (https://github.com/facebook/react-native/pull/35134/), so I applied the change on both errors.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - Use parser instead of language in MissingTypeParameterGenericParserError and MoreThanOneTypeParameterGenericParserError
Pull Request resolved: https://github.com/facebook/react-native/pull/35294
Test Plan: I tested using Flow and Jest commands. More specifically, the tests that cover this change are the ones I renamed.
Reviewed By: christophpurrer
Differential Revision: D41181069
Pulled By: cipolleschi
fbshipit-source-id: 3412e29b1319a28b3ec6afb38b1eda448055fa6a
Summary:
This PR ports back into main the changes required to properly close the SonaType repository on Maven
## Changelog
[General] [Fixed] - Close the Maven repository properly
Pull Request resolved: https://github.com/facebook/react-native/pull/35272
Test Plan: We tested these changed in 0.71-stable branch when releasing 0.71.0-RC.0
Reviewed By: christophpurrer
Differential Revision: D41154965
Pulled By: cipolleschi
fbshipit-source-id: 74dd46e8fabf3baef544342282829c70d92f671f
Summary:
During the outage it become clear that we are not doing enough to communicate what the release support policy/window is. This is one of the tweaks I'm doing to help with that
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - small tweaks to issue templates + clear mention of support window
Pull Request resolved: https://github.com/facebook/react-native/pull/35304
Test Plan: N/A
Reviewed By: christophpurrer
Differential Revision: D41183435
Pulled By: cipolleschi
fbshipit-source-id: 32519c52616fb1903507fad291200eb959d451b4
Summary:
probably the smallest PR I ever submitted, but it was bothering me lol
There was a missing space in the method doc.
## Changelog
Add space to the method doc
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[iOS] [Fixed] - Add missing space in method documentation comment
Pull Request resolved: https://github.com/facebook/react-native/pull/35303
Reviewed By: jacdebug
Differential Revision: D41182765
Pulled By: cipolleschi
fbshipit-source-id: ebe5d56072137547e543a312c66cc3234142db13
Summary:
This was left over from an old codemod.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D41154548
fbshipit-source-id: 0b5fb3e78491b66ebaf13555f80e0265a25dc7d8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35138
Changelog:
[General][Added] - Add a C++ only TurboModule example (for Android/iOS/macOS/Windows)
react-native@0.69 introduced a new bridging layer to ease integration for pure C++ TurboModules using C++ std:: types directly instead of the lower level jsi:: types:
https://github.com/facebook/react-native/tree/v0.69.0/ReactCommon/react/bridging
This bridging layer can be used in JSI functions or more conveniently in C++ TurboModules.
Here is a example of an C++ only TurboModule which will work on Android and iOS and macOS/Windows (using microsoft/react-native-macos|windows) only using flow/TypeScript and standard C++ types.
C++ only TurboModules are very handy as they do not require to work with JSI APIs - instead std:: or custom C++ can by used.
Reviewed By: javache
Differential Revision: D39011736
fbshipit-source-id: 84c833d8540671fde8505f1aeb0265074b248730
Summary:
Changelog:
[Category][Internal] - Fix inspecting on non-fabric
the pointer events don't work on non-fabric components. In addition to check the pointer events feature flag, we need to check if fabric is on as well.
Reviewed By: rbalicki2
Differential Revision: D41053393
fbshipit-source-id: ab47bd845b578a0859f282ea8ff04ddbff17da02
Summary:
>Expandable and Collapsible are unique in the Android Accessibility API, in that they are not represented as properties on the View or AccessibilityNodeInfo, but are only represented as AccessibilityActions on the AccessibilityNodeInfo. This means that Talkback determines whether or not a node is "expandable" or "collapsible", or potentially even both, by looking at the list of AccessibilityActions attached to the AccessibilityNodeInfo.
>When setting the accessibilityState's expandable property, it should correlate to adding an action of either AccessibilityNodeInfoCompat.ACTION_EXPAND or AccessibilityNodeInfoCompat.ACTION_COLLAPSE on the AccessibilityNodeInfo. This work should be done in the ReactAccessibilityDelegate class's
>Currently, this feature is being "faked" by appending to the contentDescription in the BaseViewManager class. This should be removed when this feature is implemented properly.
fixes https://github.com/facebook/react-native/issues/30841
## Changelog
[Android] [Fixed] - using AccessibilityNodeInfo#addAction to announce Expandable/Collapsible State
Pull Request resolved: https://github.com/facebook/react-native/pull/34353
Test Plan:
- On some components, the state expanded/collapsed is properly announced on focus, on some it is not.
- On some components only the expanded/collapsed state is announced, and not other component text.
- Upon change, state change is not always announced.
- The accessibilityState's "expanded" field does not seem to work on all element types (for example, it has no effect on 's).
- using accessibilityActions it is possible to add an action for expand/collapse, but these are treated as custom actions and must have their own label defined, rather than using Androids built in expand/collapse actions, which Talkback has predefined labels for.
https://snack.expo.io/0YOQfXFBi
Tests 15th August 2022:
- Paper [Tests](https://github.com/facebook/react-native/pull/34353#issuecomment-1217425302)
- Fabric [Tests](https://github.com/facebook/react-native/pull/34353#issuecomment-1217781734)
Tests 6th September 2022:
- [Button which keeps control of extended/collapsed state in JavaScript with onAccessibilityAction, accessibilityActions and accessibiltyState (Paper)](https://github.com/facebook/react-native/pull/34353#issuecomment-1237601847)
- [TouchableWithoutFeedback keeps control of extended/collapsed state in Android Widget (Paper)](https://github.com/facebook/react-native/pull/34353#issuecomment-1237616304)
- [TouchableWithoutFeedback keeps control of extended/collapsed state in Android Widget (Fabric)](https://github.com/facebook/react-native/pull/34353#issuecomment-1237624755)
- [TouchableOpacity announces visible text and triggers expanded/collapsed with onPress and accessiblity menu (Fabric)](https://github.com/facebook/react-native/pull/34353#issuecomment-1237627857)
Announcing state with custom actions on Fabric (FAIL).
The issue is not a regression from this PR, as documented in https://github.com/facebook/react-native/pull/34353#issuecomment-1207744977. It will be fixed in a separate PR.
Reviewed By: NickGerleman
Differential Revision: D39893863
Pulled By: blavalla
fbshipit-source-id: f6af78b1839ba7d97eca052bd258faae00cbd27b
Summary:
* When I build the latest bishop (using buck), I get a failure and a suggestion:
```
Rule //fbobjc/Apps/Bishop:BishopPackage (//fbobjc/Apps/Bishop:BishopPlatform) FAILED because Command failed with exit code 1.
command: [/bin/bash, -e, /data/sandcastle/boxes/fbsource/buck-out/tmp/genrule-15268472800256890202.sh]
stderr: The target: fbsource//fbobjc/Apps/Bishop:BishopShareExtension is an App Extension, and must only use APIs available in App Extensions. However, it contains dependencies that do not set 'extension_api_only = True' in their BUCK files:
- //xplat/js/react-native-github:RCTSettingsApple
This command may be able automatically to fix this issue:
arc buildozer 'set extension_api_only True' //xplat/js/react-native-github:RCTSettingsApple
```
* This diff is the result of running that command
Reviewed By: christophpurrer
Differential Revision: D41121880
fbshipit-source-id: b1ecd077270d7f3909739364237af32dbc617f52
Summary:
This PR backport two fixes we did in 0.71 to unblock the release process:
* the change in `publish-npm` is needed because of the introduction of .strict() from https://github.com/facebook/react-native/commit/4f3ca8facfc41f27169c49ad8b3a28d3022d5f0a
* the removal of the other script (added originally here https://github.com/facebook/react-native/commit/e4b5d3eec9bae44c46795c4be097b31cb48593ae) is because:
1) that step is not needed anymore (we don't publish/upload hermes artifacts to the GH release)
2) by the time this job gets run the release crew has already setup the GH release
3) the logic for the versioning was broken and even on the 0.71-rc pipeline it was tagging stuff as 1000.0.0
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Fixed] - Fix release scripts for "release" pipeline scenario
Pull Request resolved: https://github.com/facebook/react-native/pull/35258
Test Plan: The fact that 0.71-rc0 was released is the ✅ for this.
Reviewed By: jacdebug
Differential Revision: D41120888
Pulled By: cipolleschi
fbshipit-source-id: 06d108f0659ad1db53c6324fe1d735f52c34a3c5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35226
Changelog: [Internal]
This adds scaffolding for the C++ side of NativePerformanceObserver module.
Thanks to christophpurrer for helping set this up, as this is the first one of this kind inside core/OSS.
Reviewed By: rubennorte
Differential Revision: D41028555
fbshipit-source-id: 4acf0e71a254a42044cbbe5f94f40938342c6aa2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35106
This Diff remove the assert on the initializer in the EventEmitter in place of a more idiomatic check when the method is invoked.
It aims to solve an internal error and promotes best practices for the iOS platform.
## Changelog:
[iOS][Changed] Refactor RCTEventEmitter initialization
Reviewed By: sammy-SC
Differential Revision: D40762253
fbshipit-source-id: 83d26616ce147914948e536e9e4b1010758fb690
Summary:
This PR updates he cache strategy for the `checkout_with_cache command`.
The previous strategy was using three keys in descending priority order to restore from the cache:
* `<< parameters.checkout_base_cache_key >>-{{ arch }}-{{ .Branch }}-{{ .Revision }}`
* `<< parameters.checkout_base_cache_key >>-{{ arch }}-{{ .Branch }}`
*`<< parameters.checkout_base_cache_key >>-{{ arch }}`
When it saves, it always saves using the first key.
The restore works as it follows:
1. It tries to restore the cache using the first key
2. If it fails, it checks whether there is a cache hit for a key that matches the second key as a pattern
3. If it fails, it checks whether there is a cache hit for a key that matches the third pattern
4. Otherwise, it is a cache miss.
This does not work well. Imagine that you submit some code in commit `xxxx` for branch `abc`.
The CI run the first time, it misses all the three keys and checks out the code normally.
Then, it stores the checked out code in the `checkout_key-abc-xxxx` key.
Then, you submit a commit `yyyy` in the same branch.
The CI starts, it tries with the key `checkout_key-abc-yyyy` but it misses
It tries with the key `checkout_key-abc` and it finds the cache for `checkout_key-abc-xxxx` and it restores it, forgetting about your changes.
While doing the release, we created a tag in a commit X. Then we manually had to remove it, but the CI had a cached version of .git with the tag for
the `0.71-stable` branch. And the release failed because the tag was already existing.
### Why this should work
With this solution, we are going to cache using the commit. If there is no cache for a specific commit, it will be a miss. It won't try to be smart and
retrieve the code from previous caches.
This should prevent stale caches and if we manually remove a tag, and then we do a new commit, it should work.
This is a good trade-off that allows to pay the checkout cost only for the first batch of jobs of the pipeline.
**NOTE:** This still won't work if we don't do a new commit.
## Changelog
[General] [Fixed] - Change Cache strategy to avoid cache bumps in Release
Pull Request resolved: https://github.com/facebook/react-native/pull/35259
Test Plan: 1. CircleCI must be green
Reviewed By: jacdebug
Differential Revision: D41120895
Pulled By: cipolleschi
fbshipit-source-id: 2b45da01803197dbe4a25a313a9dfc53a976d096
Summary:
Changelog:
[Internal][Changed] - In order to make Dev Loading View cross platform, refactoring the accessary show methods.
Reviewed By: cortinico
Differential Revision: D41029102
fbshipit-source-id: 475949548fe98217e61d6cf64accbbdc0fb0f1c5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35163
# What
This diff contains all the changes from D40333083 (https://github.com/facebook/react-native/commit/0fac9817df403e31d8256befe52409c948614706) (aka https://github.com/facebook/react-native/pull/34964), **except** the change to `setUpReactDevTools.js`, which actually uses the new files.
# Why
* We want to ship the Buck, C++, etc. changes before the JavaScript changes that depend on those files.
* Otherwise, apps can fail at startup with the message:
```
`TurboModuleRegistry.getEnforcing(...): '${name}' could not be found. ` +
'Verify that a module by this name is registered in the native binary.',
```
* Note that this only occurs if you are using a previously-built version of the C++, Obj C, etc. files in RN, but a more recent version of the JavaScript files. If you are building from matching sources, this does not occur.
* After a few days, we can land the JS files.
## Changelog
Changelog
[General][Added] Add, but don't use, DevTools Settings Manager.
Reviewed By: NickGerleman
Differential Revision: D40873390
fbshipit-source-id: c7bac6ae65f85666b8616443db278ebb175b691b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35212
A previous change - https://github.com/facebook/react-native/pull/34011 - already fixed basic usage of <react/bridging/.../ imports.
However that change was only tailored towards the usage of: <react/bridging/CallbackWrapper.h>
Any other header besides <react/bridging/CallbackWrapper.h> from <react/bridging/... can't be imported at this time in Xcode ... ... which is bad.
For C++ TurboModules we need to be able to access *any* <react/bridging/...> header via the React-Codegen CocoaPod.
Hence adding bridging now as a sub-spec to the ReactCommon CocoaPod
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D41057878
fbshipit-source-id: 83c117bc5252d84dd419cdb72f145f65547d23b2
Summary:
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Android] [Fixed] - fixed typo in template build.gradle
Pull Request resolved: https://github.com/facebook/react-native/pull/35209
Reviewed By: cipolleschi
Differential Revision: D41080347
Pulled By: cortinico
fbshipit-source-id: d2e36f232f798a636f98843edbc5651730125fc4
Summary:
Noticed these types could be improved based on the tests added in D40979066 (https://github.com/facebook/react-native/commit/e81c98c842380d8b72c1dc8d4a6e64f760e2a58c).
Changelog: [Android][Fixed] Corrected Nullable annotations for parameters and return values in TurboModules codegen
Reviewed By: mdvacca, cipolleschi
Differential Revision: D40979940
fbshipit-source-id: cfc352a9e7eb9f59e2cce3d7da110a9a8d32db4b
Summary:
This is the 2nd iteration of D39468561 (https://github.com/facebook/react-native/commit/4d1a56813c7975c848631de331e424587054fd57). We first check if the `BridgeDevSupportManager` can be used before we return the `PerfTestDevSupportManager`. This is to avoid a breakage of Quantum that happened on the previous diff.
Add a `DevSupportManager` that can be used for performance testing. This `DevSupportManager` allows the inspector connection to be established, but leaves everything else disabled.
Previously, if Developer Support was enabled on a release build, the application would present an error as it unsuccessfully attempted to use the bridge dev support manager.
This is now conceptually the new flow for deciding what DevSupportManager to choose.
```
if (developerSupportEnabled) {
if (full support available) {
use full support (i.e. bridge)
} else {
use profiling-only support (i.e. perftest)
}
} else {
disable dev support
}
```
The first attempt at this diff erroneously used this logic:
```
if (developerSupportEnabled) {
if (debug build) {
use full support (i.e. bridge)
} else {
use profiling-only support (i.e. perftest)
}
} else {
disable dev support
}
```
So now we are always checking to see if the `BridgeDevSupportManager` is available, and if it is, we use it.
(`enableOnCrease` indicates the development mode setting: https://www.internalfb.com/code/fbsource/[6b8a941fdf2a0fd58d9db36f5a59fa5fb53ad2df]/xplat/js/react-native-github/ReactAndroid/src/main/java/com/facebook/react/ReactInstanceManager.java?lines=259)
Changelog: [internal]
Reviewed By: makovkastar
Differential Revision: D40948243
fbshipit-source-id: 50c6b6b905f5b9c5b5ecc090b36edbd6090ea774
Summary:
[Changelog][Internal]
This adds module specs for the native part of PerformanceObserver, as well as the interaction logic vs the NativePerformanceObserver API.
See https://fb.quip.com/MdqgAk1Eb2dV for more detail.
Reviewed By: rubennorte
Differential Revision: D40897006
fbshipit-source-id: 77475f21dad9ee9dbe15df5a989eb08d314e6db2
Summary:
The method that would restore these files was removed in https://github.com/facebook/react-native/pull/34846. The action performed by `saveFilesToRestore` is no longer necessary (thanks kelset for pointing this out).
Changelog: [internal]
Reviewed By: cortinico
Differential Revision: D41003911
fbshipit-source-id: bbc057ac450e7f134c4664173291ca56c18f1b17
Summary:
The project.android block is unnecessary and contains a wrong path. Let's use the default path which is `./android`.
## Changelog
[Internal] - Remove project.android block from rn-tester's CLI config
Pull Request resolved: https://github.com/facebook/react-native/pull/35197
Test Plan: Tested locally + will wait for a CI run
Reviewed By: robhogan
Differential Revision: D41013193
Pulled By: cortinico
fbshipit-source-id: 5c76c9b571b23ad71a23a8f3f05a9acb4d6e20b9
Summary:
We accidentally added `-DCMAKE_BUILD_TYPE=Debug` for Hermes which is causing
a really slow engine execution. This fixes it and keep the -DCMAKE_BUILD_TYPE
aligned with the one used on Android.
Changelog:
[iOS] [Fixed] - Correctly set -DCMAKE_BUILD_TYPE for Hermes on iOS
Reviewed By: hramos, cipolleschi
Differential Revision: D40980934
fbshipit-source-id: 30f0455990a911b51eb109bebca8272507302650
Summary:
[Changelog][Internal]
This is to prevent an accidental use of PerformanceObserver while it's still a work in progress.
PerformanceObserver is also moved into a dedicated folder, `Libraries/WebPerformance`.
Reviewed By: rubennorte
Differential Revision: D40978749
fbshipit-source-id: 09645a95bed72902870ebc00c1b4a3d81ab4c829
Summary:
## Changelog:
[Android] [Fixed] - Fix a bug that returns a random number from callback argument `timeRemaining` of `idleCallbacks` registered by `requestIdleCallbacks`.
`global.performance.now()` returns a time from an unknown origin, while `frameTime` is epoch time. Thus, `global.performance.now() - frameTime` is just a random number rather than an elapsed time from the frame start time.
As a simple solution, I would suggest to use `Date.now()`.
Its resolution is lower than `frameTime` due to the security issue in JavaScript VM. So, it loses some precision, but, at least, it is not wrong.
Reviewed By: javache
Differential Revision: D40941461
fbshipit-source-id: b0094e181b97a844d133a9268fe48cd8c8fadfda
Summary:
Support various annotations types in QuickPerformanceLogger markEvent for Android.
Changelog:
[Internal][Changed] - Added support for various markEvent annotation types
Reviewed By: dmitry-voronkevich
Differential Revision: D40852658
fbshipit-source-id: fc4053555f65958653be30a58742c83040a19df1
Summary:
This change moves the default new application template in OSS from Flow to TypeScript. This better aligns with the communities usage, and aligns to the great work that has been happening for TS codegen and built-in types. This used [`react-native-community/react-native-template-typescript`](https://github.com/react-native-community/react-native-template-typescript) as a main reference, maintained by radko93. A few things are different:
1. Updated `types/*` devDependencies to match bumped libraries (e.g. Jest 26 to 20).
2. Removed `types/react-native`
3. Removed explicit `moduleFileExtensions` to Jest config in package.json (TS and TSX and added by default in current versions)
4. Removed overrides to eslint config to disable `no-shadow` and `no-undef`, since this was fixed in the underlying eslint config with https://github.com/facebook/react-native/pull/32644 and https://github.com/facebook/react-native/pull/32655
5. Re-translated `App.js` to be a direct translation (e.g. still a raw function instead of React.FC which is sometimes discouraged)
6. Aligns completely to `tsconfig/react-native` maintained configuration (We no longer have the opinionated override of `skipLibCheck`). The important settings are that `strict` is enabled for, but `allowJS` is also enabled to let users import JS modules without anything unexpected. `esModuleInterop` is enabled, which is needed for consistency with Babel import transformations used by Metro. Consistent with our [current documentation](https://reactnative.dev/docs/typescript) built against the community template, `tsc` will typecheck your code without emitting(building) anything.
[Documentation](https://reactnative.dev/docs/typescript) will need to be updated as a followup.
Changelog:
[General][Changed] - Use TypeScript by default for new applications
Pull Request resolved: https://github.com/facebook/react-native/pull/35165
Test Plan: Added usage of `tsc` and `jest` when validating a newly built app. Passes in CircleCI `test_js` job. This also meant removing some cases of copying packages into the users app to pull in the root Metro config (we seem to be able to use the template Metro config consistent with what real apps would get).
Reviewed By: cortinico
Differential Revision: D40911951
Pulled By: NickGerleman
fbshipit-source-id: 15994534235695e91cf994ad06ba2183dfc89a50
Summary:
In the top js errors there are 2 mids related to segment fetching:
- requireForFacebook.js:unknownModuleError (https://www.internalfb.com/logview/details/facebook_android_javascripterrors/ba11461526aff8a6842401b35b02f5a4), 11.64 K vs. 524
- asyncRequire.js:verifySegment (https://www.internalfb.com/logview/details/facebook_android_javascripterrors/5452ba893b8d9ba8e97e070cf6976b65) 5.39 K vs. 180
Both errors will result in surface not loading.
A lot of traces have logs similar with the following:
```11-01 19:57:51.166 27735 7626 W fb4a.BridgelessReact: registerSegment(segmentId = "1090", path = "/data/data/com.facebook.katana/app_overtheair/resources/412137089/414433453/hbc-seg-1090__DELIM__main.jsbundle")
11-01 19:57:51.167 27735 7445 I ReactNativeJS: Module 39122 in segment 0 doesn not exist moduleDefiner
11-01 19:57:51.171 27735 7445 E ReactNativeJS: Error: Requiring unknown module "39122"., js build: 414433453
11-01 19:57:51.175 27735 7445 E ReactNativeJS: Error: Segment meta module is not setup properly. Details: segmentId = 1090, metaModule === undefined
11-01 19:57:51.175 27735 7445 E ReactNativeJS:
11-01 19:57:51.175 27735 7445 E ReactNativeJS: This error is located at:
```
RegisterSegment lives through 3 threads while in bridge there are only 2 threads involved (native & JS):
- Native thread, log printed (fb4a.BridgelessReact: registerSegment...)
- Background thread: no log, added in this diff (Finish registerSegment...)
- JS thread: logs not printed, should print logs here:
https://www.internalfb.com/code/fbsource/[60521987354ed1ef9a0d10bafc60db3c25302ab4]/xplat/ReactNative/venice/ReactInstance.cpp?lines=308-330
Since the JS thread logs aren't printed and there are segment errors right after calling registerSegemnt, I think registerSegment is not done. It could be caused by:
- ReactInstance being null, I added logs in background thread to verify (Finish registerSegment...) since dispatching to background thread relies on non-nullable ReactInstance.
- Work on JS thread hasn't been executed when trying to use/verify the segment. I added atomic method ```registerSegmentAtomic``` to make sure JS thread is blocked until segment is fully registered.
```registerSegmentAtomic``` will be tested behind gating added in D40917444.
Changelog:
[Android][Changed] - Add feature flag enableAtomicRegisterSegment
Reviewed By: RSNara
Differential Revision: D40921759
fbshipit-source-id: 84221aa81f0c549f931a4847b154187299639ef4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35166
The Hermes source code is not included in the RN npm package. This piece of code is a remnant from an early experimentation into integrating Hermes more tightly with React Native. We ended up using a combination of the scripts in `scripts/hermes` to fetch the source code from GitHub and relying on prebuilts for stable releases.
Added `strict()` flag to ensure the script fails immediately if an unrecognized flag is passed.
Avoid logging temp publishing folder value to console when `--help` is used.
Changelog: [internal]
Reviewed By: cortinico
Differential Revision: D40918939
fbshipit-source-id: 2e62ab16467c4c67f03efdf5211a156cb70e0b11
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35123
**Context**
On RN Desktop, images can be copy/pasted into text inputs.
When copy/pasting local files w/ semi-colons in the filename (`/downloads/devices:pre-call-IMG_346C38284B2B-1.jpeg`), RN would throw this error.
{F785684529}
The error was due to no having the correct asset loader due to the local file path being parsed incorrectly.
To parse the url, we convert the string URI to a `NSURL` using a custom convertor fn.
The conversion was matching any `:` and assuming it was a network url scheme:
https://www.internalfb.com/code/archon_react_native_macos/[fde4113acd89fb13ee11636c48b59eac49c21bae]/React/Base/RCTConvert.m?lines=97-111
When an image path with `:` in the name was passed to this, it was assuming it was a valid network url and not file path.
Because this is a local filepath, the image path needs to be a filesystem url. Since this was parsed as network url, it did not have the `file://` prefix and would not pass this check, causing the loader to throw.l
https://www.internalfb.com/code/fbsource/%5B60d9d5e67383%5D/xplat/js/react-native-github/Libraries/Image/RCTImageLoader.mm?lines=220-230
## Changelog
[iOS] [Added] - Add support for parsing files w/ `:` in filename
Reviewed By: christophpurrer, philIip
Differential Revision: D40729963
fbshipit-source-id: 2f3adcabc8f0f1f22cbfca69c3484e72b1d93d25
Summary:
Just bumping RNGP to make the new sources avialable to the template.
Changelog:
[Internal] [Changed] - Bump RNGP to 0.71.8
Reviewed By: robhogan
Differential Revision: D40948246
fbshipit-source-id: c6a193fcdc0675be9ef7f1320d63e884b8b65daa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35181
As the title says, this unblocks `test_buck` by removign the lambdas used inside test.
Changelog:
[Internal] [Changed] - Fix test_buck by not using lambdas inside ReactImagePropertyTest
Reviewed By: cipolleschi
Differential Revision: D40958412
fbshipit-source-id: 60b8609a25985230dfd6c4dcdf983dc2a8cfaf64
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35169
This reorganizes typing structure a bit.
`Utilities.d.ts` was originally added for utilitiy types but I ended up leaving it a grab bag of types that didn't belong to any individual bit of code. Out of what is in it right now, `Insets` was actually public, and seems to have been imported.
We also run into files around the renderer which are [currently overwritten](https://github.com/facebook/react-native/commits/e286da25fc83324363486eb668806aca179f74b3/Libraries/Renderer/implementations/ReactNativeRenderer.d.ts) by the React sync script.
Finally, all of the top-level imports of `Utilities` were auto-generated by VS Code, but fail in real apps. I think this is because our tsconfig sets a `baseUrl` to allow resolution from the types folder, so the tooling in the RN repo will use that, but it breaks in real apps that don't have that mapping.
This splits all these up into a couple separate directories that are hopefully easier to reason about, and removes `Omit` which has been a builtin type for quite some time (we were actually already using built-in `Omit`).
Changelog:
[General][Fixed] - Fixup TS Organization
Reviewed By: cipolleschi
Differential Revision: D40932319
fbshipit-source-id: 0b6e3e3eda603885b4dc01dcb9f5233aa546d128
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35178
I forgot to add the logic to fetch the -SNAPSHOT version when on nightlies.
This code takes care of it.
Changelog:
[Internal] [Changed] - Make sure nightly versions are using the -SNAPSHOT artifacts
Reviewed By: cipolleschi
Differential Revision: D40939367
fbshipit-source-id: 29d60cf281d30b3dbd05d7ea1c766541a8fab90a
Summary:
Saw in the logs an ever increasing number of warnings coming from WebSocketModule about requesting an instance that has already gone away.
On module invalidation we should close all outstanding websockets, as they will no longer be able to send events to JS.
Changelog: [Android][Fixed] On instance destroy, websockets are correctly closed
Reviewed By: mdvacca
Differential Revision: D40897255
fbshipit-source-id: 1578de8baa342479d14ee1070c3314d45c7fbd8d
Summary:
This PR is a follow up of https://github.com/facebook/react-native/pull/35075 and https://github.com/facebook/react-native/commit/1546666a6d713ef756b2f11de9581e3b2bbe08dc to ensure that even in the local e2e testing scenario the new maven approach is followed - without this, RNTestProject on Android won't work, like so:
<img width="1905" alt="Screenshot 2022-10-27 at 12 15 38" src="https://user-images.githubusercontent.com/16104054/198334105-30fb2037-4e7c-4814-8c3f-2412ba0bd49f.png">
And iOS will always build everything from source every time.
This PR addresses both by generating the artifacts locally, and passing them to RNTestProject as if they were coming from a url (mimicking as closely as possible the behaviour for the final user)
In doing so, there's been some refactoring to prep the ground for follow up work.
* refactor CI to rely less on scripts directly in the CircleCI config, but invoke .js ones
* we should be able to trigger more the "manual" artifacts generation so that it will only happen once between RNTester and RNTestProject, and we can pass existing artifacts to the other flows.
* once all of this in place, a very good improvement would be to be able to download the maven artifacts kind of like nightlies and stables do. This will only be viable by checking that there's no local changes, after which there needs to be logic to pull down from CircleCI the artifacts based on git commit <-> circleCI job references.
---
While at it, I've also fixed the hermes-engine podspec logic for detecting if it's on CI: basically the local e2e script needs to align with the changes done here: https://github.com/facebook/react-native/commit/4b512077354eb4702ce144e9958d7513c1607275
but as you can see there, the condition was actually inconsistent across the various files, so realigned to `CI === 'true'`. We probably didn't catch that so far 'cause the other condition in the hermes podspect (existence of `hermestag_file`) is only true on release branches and this new logic has not been in any release branches yet.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Fixed] - add logic to local e2e script to handle maven local for iOS and Android accordingly
Pull Request resolved: https://github.com/facebook/react-native/pull/35104
Test Plan:
Run ` yarn test-e2e-local -t RNTestProject -p Android` successfully.
Run ` yarn test-e2e-local -t RNTestProject -p iOS` successfully. On the pod install stage, you will see `[Hermes] Using pre-built Hermes binaries from local path.`
Reviewed By: dmytrorykun
Differential Revision: D40893239
Pulled By: cipolleschi
fbshipit-source-id: a31217ec4f177383c62292d00fabc4cbe4391cfd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35176
This commit extends the ReactNative-application.cmake logic so
that if the app is using codegen at the app level, the generate library
is properly built and linked.
It helps us simplify the RN Tester setup and makes it easier for app users
to use the codegen at the app level.
Changelog:
[Internal] [Changed] - [Android] Link against the app codegen if available
Reviewed By: cipolleschi
Differential Revision: D40936941
fbshipit-source-id: 26fa4d764fb369c987e94e0c3bce61841b982b27
Summary:
The documentation for `useColorScheme()` suggested that the user's preferred color scheme will be 'Dark Mode'. Instead suggesting 'Dark Mode' as an example of what the user's preferred color scheme could be is more correct.
## Changelog
[INTERNAL] [FIXED] - Edited documentation for `useColorScheme()` hook
Edited
```javascript
/**
* A new useColorScheme hook is provided as the preferred way of accessing
* the user's preferred color scheme (aka Dark Mode).
*/
export function useColorScheme(): ColorSchemeName;
```
to
```javascript
/**
* A new useColorScheme hook is provided as the preferred way of accessing
* the user's preferred color scheme (e.g. Dark Mode).
*/
export function useColorScheme(): ColorSchemeName;
```
Pull Request resolved: https://github.com/facebook/react-native/pull/35141
Test Plan: Documentation only - no testing required.
Reviewed By: cipolleschi
Differential Revision: D40934781
Pulled By: rshest
fbshipit-source-id: acac8947c3f99016839be27f505066e8992a20fa
Summary:
Improving test coverage in anticipation of some changes being made to `hermes-utils.js`.
Moved test scripts to `hermes/__tests__` and grouped related tests.
We have been delegating some of the work to local binaries via `execSync`, which can be hard to mock or test. We now use a proxy `delegateSync` method that uses `spawnSync` internally to break down the invocation into `command`, `arguments`, `options`. Instead of simply mocking based on the command being executed, we can now conditionally mock based on the arguments being passed.
Added a `createTarballFromDirectory` method. This can be used later when creating different tarballs.
Added `populateMockFilesystemWithHermesBuildArtifacts()` to mock the filesystem state after Hermes has been built.
Changelog: [internal]
Reviewed By: cipolleschi
Differential Revision: D40871802
fbshipit-source-id: 4348d3c38926ec7eb13d794040a9040010879f58
Summary:
Include dSYMs when building the universal XCFramework for Hermes iOS.
CocoaPods should pick up dSYMs automatically when using `vendored_framework` if:
- `hermes.framework` has a `hermes.framework.dSYM` in the same base directory
- `hermes.xcframework` has a `dSYMs` folder with a `hermes.framework.dSYM` in it, for each slice
The dSYMs for the macOS hermes.framework are already being created.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D40790250
fbshipit-source-id: 50fcb3492434637b00458c1aa443ac6ec5472fac
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35162
The dSYMs for Apple will not be distributed as part of the prebuilts tarball. They can still be included in the tarball by passing a `-d` flag to the create-tarball script.
Changelog: [internal]
Reviewed By: cipolleschi
Differential Revision: D40813679
fbshipit-source-id: 26dee8251684c5ecad649ccd27ce688cfe88ec8f
Summary:
Changelog: [Internal]
Override logic for determining whether a dispatched `Event` triggers a native `EventAnimationDriver`.
Natively driven AnimatedEvents on bubbling events is not supported. `PointerEvents` requires this and this diff adds custom matching logic such that if a parent specifies an `AnimatedEvent` on `onPointerMove` and a child view dispatches it, the `AnimatedEvent` will still fire.
Reviewed By: javache
Differential Revision: D38722563
fbshipit-source-id: 7cde57eaff9584b33c6ab15f1fe85c0a9bac132e
Summary:
Changelog: [Internal] - Refactor match logic on determining whether to run an EventAnimationDriver (drivers for natively animated events) for an Event dispatched.
Previously, drivers were stored by key on the NativeAnimatedNodesManager (based on event handler and viewTag) and has been refactored to be stored in a list for easier matching.
This diff changes it so the match logic for running an EventAnimationDriver happens on the Event instance. This change is motivated by PointerEvents needing custom match logic (done on a following change).
Reviewed By: javache
Differential Revision: D40691002
fbshipit-source-id: e4f6742a2af3b751214aefa1fc069f65e8e71d77
Summary:
As part of unifying JS QPL interface, I'm bringing markerAnnotate to the parity with Web version.
At the moment it supports only string annotations, but I'm adding support for ints, arrays of ints, arrays of strings, etc.
## Changelog:
[Internal] [Changed] - Refactored markerAnnotateWithMap -> markerAnnotate
Reviewed By: eddyerburgh
Differential Revision: D40796535
fbshipit-source-id: 9831e353036835b97bb7b2f60085016034c04269
Summary:
## Changelog:
[Internal] [Added] - Adding new markerAnnotateWithMap to the QPL.
This is part of bigger effort to unify JS QPL interfaces across platforms.
Reviewed By: eddyerburgh
Differential Revision: D40796537
fbshipit-source-id: a75b97c20ca411653552228f7dc2fcbedd8ddca9
Summary:
This is a follow up action item from S295231 and T136039462 where we want to make sure null uri in image source is handled properly. This diff adds an unit test to make sure we are using transparent image when uri is null.
Changelog:
[Android][Internal] - Add unit test to ImageView for null uri in source
Reviewed By: javache
Differential Revision: D40732791
fbshipit-source-id: fd468bfe7c33a4f3f8913ead3e84a1770d7c907f
Summary:
## Context
If React Native is built from *main* of any non-stable commit, then Hermes is built from source. The build is performed by `build-ios-framework.sh` and `build-mac-framework.sh` scripts in `hermes-engine.podspec` `prepare_command` stage. Since those scripts have no access build target information, they build all possible architectures and platforms just in case. That takes ages.
## Solution
The idea is to integrate build script into Xcode *run script* phase, and use build target information to build Hermes for active architecture only.
## Implementation
- Existing behaviour remains unchanged for local tarball and remote prebuild cases.
- `build-hermesc-xcode.sh` builds Hermesc as `hermes-engine.podspec` `prepare_command`. Default build location is `react-native/sdks/hermes-engine/build_host_hermesc`.
- `build-hermes-xcode.sh` builds Hermes in 'Build Hermes' Xcode script phase. It uses `$PLATFORM_NAME`, `$CONFIGURATION`, `$ARCHS`, `$IPHONEOS_DEPLOYMENT_TARGET` and `$MACOSX_DEPLOYMENT_TARGET` environment variables to configure cmake project so it builds only active architecture. The script also gets RN version, *cmake* path and *hermesc* path from the podspec.
- `copy-hermes-xcode.sh` copies Hermes.framework inside the app bundle. This script phase is added to the user app target in a `post_install` hook, after pods are integrated in a user project.
- `OTHER_LDFLAGS -framework "hermes"` added to the user project to enable linking against Hermes.framework.
- If `HERMES_OVERRIDE_HERMESC_PATH` is set, then Hermesc building is skipped, and `HERMES_OVERRIDE_HERMESC_PATH` is used for `build-hermes-xcode.sh`.
- `HERMES_CLI_PATH` is injected into user project config to enable Hermes source maps in `react-native-xcode.sh`.
## Things that didn't work
- *Running build-hermesc-xcode.sh in Xcode run script phase*. This doesn't work because Hermesc is supposed to be built for macos, and if build target is ios, then Xcode configures environment in such a way that Hermesc build fails.
- *Installing Hermesc into CocoaPods download folder*. So it then ends up in `Pods/hermes-engine/build_host_hermesc`, and all the housekeeping is handled by CocoaPods. This doesn't work because cmake uses absolute paths in a configured project. If configured project is moved to a different location, nothing builds.
- *Installing Hermesc directly into Pods/hermes-engine*. This doesn't work because CocoaPods runs prepare_command before Pods folder clean up, and everything gets wiped.
## Known issue
- If `Pods/hermes-engine` is manually removed, then `sdks/hermes-engine/build_host_hermesc` must also be removed before running `pod install`. Otherwise cmake will complain about stale cache:
```
CMake Error: The source "<CocoaPodsCache>/hermes-engine/<hash2>/CMakeLists.txt" does not match the source
"<CocoaPodsCache>/hermes-engine/<has1>/CMakeLists.txt" used to generate cache. Re-run cmake with a different source directory.
```
## Benchmark
MacBook M1 2021 32 GB.
```
export REACT_NATIVE_PATH=~/fbsource/xplat/js/react-native-github
cd $REACT_NATIVE_PATH/packages/rn-tester
pod install
rm -rf $REACT_NATIVE_PATH/sdks/hermes-engine/build_host_hermesc
cd $REACT_NATIVE_PATH/packages/rn-tester/Pods/hermes-engine
echo 't1=$(date +%s); $@; t2=$(date +%s); diff=$(echo "$t2 - $t1" | bc); echo Operation took $diff seconds.' > /tmp/benchmark.sh
```
```
# Before
export BUILD_TYPE=Debug
export JSI_PATH=$REACT_NATIVE_PATH/ReactCommon/jsi
export RELEASE_VERSION=1000.0
export IOS_DEPLOYMENT_TARGET=iphonesimulator
export MAC_DEPLOYMENT_TARGET=12.6
cd $REACT_NATIVE_PATH/packages/rn-tester/Pods/hermes-engine
. /tmp/benchmark.sh $REACT_NATIVE_PATH/sdks/hermes-engine/utils/build-ios-framework.sh
# Operation took 252 seconds
. /tmp/benchmark.sh $REACT_NATIVE_PATH/sdks/hermes-engine/utils/build-mac-framework.sh
# Operation took 179 seconds
```
```
# After
. /tmp/benchmark.sh source $REACT_NATIVE_PATH/sdks/hermes-engine/utils/build-hermesc-xcode.sh $REACT_NATIVE_PATH/sdks/hermes-engine/build_host_hermesc
# Operation took 59 seconds.
. /tmp/benchmark.sh xcodebuild -workspace $REACT_NATIVE_PATH/packages/rn-tester/RNTesterPods.xcworkspace -scheme hermes-engine
# Operation took 106 seconds.
```
|Before|||After|||
|--|
|iOS framework (s)|Mac framework (s)|Total (s)|Hermesc (s)|Target-specific framework (s)|Total (s)|
|252|179|431|59|106|**165 (-266) (-61%)**|
The performance win is fixed, and does not depend on the project size and structure.
As an example, this is how these changes affect build time of RNTester.
|Before||||After|||
|--|
||Pod install (s)|Xcode build (s)|Total (s)|Pod install (s)|Xcode build (s)|Total (s)|
|Clean build|1219|132|1352|734 (-485)|249(+117)|**983 (-369)**|
|Incremental build|82|30|112|105 (+23)|**34 (+4)**|139 (+27)|
The most important values here are the total clean build time and the incremental Xcode build time. The first one went down by 369 seconds, the second one went up by 4 seconds. I consider it a reasonable tradeoff.
The extra 4 seconds in the incremental Xcode build time can potentially be mitigated by setting up output file lists for the new script phases.
allow-large-files
Changelog:
[iOS][Changed] - Hermes is integrated into Xcode build.
Reviewed By: hramos
Differential Revision: D40063686
fbshipit-source-id: e6993d62225789377db769244bc07786cc978a27
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35160
With the simplified migration to the new arch, we are offering a function in cocoapods that takes care of configuring all the dependencies for libraries.
That function was not setting the proper version of C++ for the library. This could lead to build problems.
This Diff make sure that the libraries that are created with this function call have the proper C++ version.
NOTE: we already have a post install hook that was setting the the proper C++ version, but that was only working for the project. Plus, we can't read that version from the React-Core podspec because at the podspec definition time, cocoapods has not read that yet. Therefore, I just hardcoded the C++ version on top of the file, so it will be easier to update if we decide to change it.
## Changelog
[iOS][Fixed] - Make sure that libraries created with `install_modules_dependencies` has the right C++ version.
Reviewed By: dmytrorykun
Differential Revision: D40894561
fbshipit-source-id: a5187be2d85888a335d4c033f16fdacaf2c945f9
Summary:
This pull request migrates the dimensions example to using React Hooks.
## Changelog
[General] [Changed] - RNTester: Migrate Dimensions to hooks
Pull Request resolved: https://github.com/facebook/react-native/pull/35084
Test Plan: The animation works exactly as it did as when it was a class component
Reviewed By: yungsters
Differential Revision: D40779014
Pulled By: NickGerleman
fbshipit-source-id: e740684d3022a945da5abc33b2e8834c6cfabb97
Summary:
`exact_empty_objects` is on by default in 0.191, delete usage
Changelog: [Internal]
Reviewed By: SamChou19815
Differential Revision: D40822684
fbshipit-source-id: 8e84f0542e6b66049cac34e429f0b724f85a9557
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35156
There are two tarballs: the source code for Hermes that is downloaded from GitHub, and the hermes-runtime-darwin-{}-v{}.tar.gz tarball with prebuilt artifacts that is built in CI.
Renamed some methods to make it clearer which tarball they work with.
Changelog: [internal]
Reviewed By: cipolleschi, dmytrorykun
Differential Revision: D40812290
fbshipit-source-id: a2c865e1d1461829fe8d468f52deeb55f3565cb0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35028
**This Diff require a bump in the react-native-codegen (including this [commit](https://github.com/facebook/react-native/commit/7680bdeb4f96a8092393372a59c77a9d7b729cae)) to work**
This diff sets up iOS and Android to pass their platform to the codegen so that we can have platform-specific specs.
## Changelog
[General][Added] - Enable platform-specific Codegen Specs
Reviewed By: cortinico
Differential Revision: D40516395
fbshipit-source-id: 0624f0bfb93c90f78131a605a4847e780783bbaf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35154
This diff bumps the codegen to v0.71.1, preparing it for the branch cut.
## Changelog
[General][Changed] - Bump codegen version
Reviewed By: dmytrorykun
Differential Revision: D40852498
fbshipit-source-id: ba1dc87f3726bc27cbd176f160c62a0bdc291433
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35146
This class is used by Fabric - but does not compile on macOS yet.
Changelog:
[iOS][Fixed] Make ManagedObjectWrapper compile on macOS
Reviewed By: javache
Differential Revision: D40839241
fbshipit-source-id: 73b93a9963db89af19529fbfd60a64f4e5aaf036
Summary:
D38121921 (https://github.com/facebook/react-native/commit/5ddb9977e662a1b41dd7203605ca8480432fc06a) added a grid accessibilityRole to Flow typings and RNTester example shared with iOS. It it forwarded on Android, but doesn't have an equivalent UIAccessibilityTrait mapping.`RNTesterSnapshotTests/testScrollViewExample` reports an error:
```
Failure: RedBox errors: (
"Error setting property 'accessibilityRole' of RCTScrollView with tag #125: Invalid UIAccessibilityTraits 'grid'. should be one of: (
adjustable,
====================== 38 lines skipped ======================
) (NSInternalInconsistencyException)
Path: <unknown>
Line: 0
```
This adds the grid mapping, which I think should fix this error.
Changelog:
[ios][Fixed] - Map `accessibilityRole: grid` to `UIAccessibilityTraitNone`
Reviewed By: christophpurrer
Differential Revision: D40848904
fbshipit-source-id: 80f72bcd4e4826cc0d535693117a6c1e5fbd1d7d
Summary:
Fix typo
## Changelog
[General][Fixed] - Fixed typo syncronization -> synchronization
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[CATEGORY] [TYPE] - Message
Pull Request resolved: https://github.com/facebook/react-native/pull/35132
Reviewed By: christophpurrer
Differential Revision: D40832387
Pulled By: rshest
fbshipit-source-id: 834ece525e4469c942e678e2a3d4ecf30be4f550
Summary:
## Summary
This PR extracts the content of the codegen case `'Float'` into a single `emitFloat` function inside the `parsers-primitives.js` file and uses it in both Flow and TypeScript parsers as requested on https://github.com/facebook/react-native/issues/34872. This also adds unit tests to the new `emitFloat` function.
## Changelog
[Internal] [Changed] - Extract the content of the case 'Float' into a single emitFloat function
Pull Request resolved: https://github.com/facebook/react-native/pull/35124
Test Plan:
Run `yarn jest react-native-codegen` and ensure CI is green

Reviewed By: rshest
Differential Revision: D40828746
Pulled By: cipolleschi
fbshipit-source-id: 9c7cecf7268f16aaef29065c1983ad9a4dd18dbe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35094
Currently the build on console is firing this warning:
```
> Task :app:processDebugMainManifest
package="com.androidtemplateproject" found in source AndroidManifest.xml: /tmp/AndroidTemplateProject/android/app/src/main/AndroidManifest.xml.
Setting the namespace via a source AndroidManifest.xml's package attribute is deprecated.
Please instead set the namespace (or testNamespace) in the module's build.gradle file, as described here: https://developer.android.com/studio/build/configure-app-module#set-namespace
This migration can be done automatically using the AGP Upgrade Assistant, please refer to https://developer.android.com/studio/build/agp-upgrade-assistant for more information.
```
This diff fixes it so users won't see it anymore on 0.71
Changelog:
[Android] [Fixed] - Sets the namespace via Gradle and not via AndroidManifest
Reviewed By: cipolleschi
Differential Revision: D40724654
fbshipit-source-id: 9b01748a22e9993b60e17bf25acbc68ba8e4eb77
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35117
This mimics some behavior we have in Android that allow uesers to turn on selectively TM and Fabric.
Notice that if fabric is enabled, TM must be enabled as well, otherwise the app won't work
## Changelog
[iOS][Added] - Added the possibility to selectively enable TM and Fabric with the new Architecture
Reviewed By: cortinico
Differential Revision: D40794328
fbshipit-source-id: b7fc7bb819d05566dcd335832cab224f80b23346
Summary:
Quick update (requested by cortinico) ahead of release 0.71. Note that there was not a new release of `react-native-communiity/cli-platform-ios` in https://github.com/react-native-community/cli/commit/f6f23cca4b4c93030bb05e1fff68bd22ce13baba.
Changelog:
[General][Changed] - Bump CLI to 10.0.0-alpha.2
Reviewed By: robhogan, cortinico
Differential Revision: D40806560
fbshipit-source-id: 5c852a204c3c2d272d0502a34221f24ce7613cb0
Summary:
This PR is a task from https://github.com/facebook/react-native/issues/34872:
> Extract the UnsupportedFunctionParamTypeAnnotationParserError in its own throwing function (if it does not exists already) and reuse that function passing a proper type. Then, refactor the code using a dictionary and avoiding the three different ifs in both parsers.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - Extract the UnsupportedFunctionParamTypeAnnotationParserError in its own throwing function in error-utils
Pull Request resolved: https://github.com/facebook/react-native/pull/35057
Reviewed By: lunaleaps
Differential Revision: D40721099
Pulled By: cipolleschi
fbshipit-source-id: af5e4cd275d0049047d35660559b94a27e660e40
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35116
This diff let release versions of React Native to consume the Hermes tarball from Maven.
It is already setup to download proper debug/release version
## Changelog
[iOS][Added] - Download Hermes from Maven while for -stables
Reviewed By: cortinico
Differential Revision: D40794707
fbshipit-source-id: b6fa44a272ca044e1c4057a08accecb2009ad312
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35115
When looking at the new entry point I've realized we have the dynamicLibraryName as first parameter.
As this API is not released yet, let's move it as last.
So users on Java can easily call DefaultNewArchitectureEntryPoint.load(true, true, true)
while now they will have to call DefaultNewArchitectureEntryPoint.load("...", true, true, true)
Users in Kotlin won't be affected by this.
Changelog:
[Internal] [Changed] - Sort parameters in DefaultNewArchitectureEntryPoint
Reviewed By: cipolleschi
Differential Revision: D40793370
fbshipit-source-id: 9dc1569d76a1479a738f8e0f41a4183d7c04538f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35109
This is just a safety check to make sure we don't accidentally
publish a 1.x or a 1000.x version on Maven Central by mistake.
Changelog:
[Internal] [Changed] - Gate the Maven Central publishing to 0.x version.
Reviewed By: mdvacca
Differential Revision: D40767782
fbshipit-source-id: 58f2906c3b01bfd0fd388a300ba303b289633d4e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35108
I've rewritten the comment in the android/app/build.gradle.
They were really old, contained wrong links and most of the people ignored it.
I've also moved the enabling of Hermes to the `gradle.properties` file.
RNGP still supports the old method, but we must be sure that we notify
library authors if they were reading project.ext.react.enableHermes in the past
(also the website needs to be updated).
I've also cleaned up the CircleCI setup as now we can specify Hermes enabled/disabled
via the CLI (this will also make easier to do e2e testing).
Changelog:
[Android] [Changed] - Cleanup the template documentation after RNGP & hermesEnabled to gradle.properties
Reviewed By: cipolleschi
Differential Revision: D40762872
fbshipit-source-id: 2c09245e0a923faac53cc6c8a89e99788ae47f8a
Summary:
Small PR with bump to the new versions of CLI and Metro in preparation of the branch cut for 0.71.
While at it, did a cheeky `npx yarn-deduplicate` to clean up a bit the deps.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[General] [Changed] - Bump CLI to 10.0.0-alpha.1 and Metro to 0.73.3
Pull Request resolved: https://github.com/facebook/react-native/pull/35107
Test Plan: CI is green
Reviewed By: motiz88
Differential Revision: D40762683
Pulled By: huntie
fbshipit-source-id: e523a49c78588ca80351f44cb02bcd4c0137475e
Summary:
Just bumping RNGP to make the new sources avialable to the template.
Changelog:
[Internal] [Changed] - Bump RNGP to 0.71.7
Reviewed By: cipolleschi
Differential Revision: D40760927
fbshipit-source-id: 909c88377a231ea6678c6af14c5594fdc4830b79
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35095
This change will make sure that we load the correct JS engine at runtime,
by using the BuildConfig flag that RNGP sets for us.
This will solve a lot of noise in adb logcat for users seeing
stacktraces mentioning failing to load `jscexecutor` library.
This is also a breaking change, but as the API was not widely used nor
advertised in the template, we should be fine by just mentioning this in the release notes.
Changelog:
[Android] [Changed] - Update the template to load the correct JS engine at runtime
Reviewed By: cipolleschi
Differential Revision: D40710597
fbshipit-source-id: d59a7a52b22a9bf273ea89094c6620c3ecf6eb00
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35101
Those CMake variables are effectively unused now. They're raising a warning on CMake builds
of templates + let's not expose them as we haven't released RNGP yet, before libraries
or other tools start relying on them.
Changelog:
[Internal] [Changed] - RNGP - Do not set GENERATED_SRC_DIR and REACT_ANDROID_BUILD_DIR
Reviewed By: cipolleschi
Differential Revision: D40751998
fbshipit-source-id: 13f54a6247e4734c21c263f8b1e6b4b9e8ba406c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35100
That's just a minor bump of AGP before the branch cut.
Changelog:
[Android] [Changed] - Bump AGP to 7.3.1
allow-large-files
Reviewed By: cipolleschi
Differential Revision: D40752006
fbshipit-source-id: 4856bc7ca275cf46d3afcc7c24928c5f1d5e6e33
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35099
I'm removing the ReactFlipperPlugin from the new app template.
That plugin is effectively empty and is a stub + is deprecated
so is generating a warning for all the users.
Changelog:
[Android] [Changed] - Do not import/use the deprecated ReactFlipperPlugin
Reviewed By: cipolleschi
Differential Revision: D40751984
fbshipit-source-id: 1f1fdf9c7dfccb9e7bbd4c8c2292df71e00c644f
Summary:
In 2017, React published v15.5 which extracted the built-in `prop types` to a separate package to reflect the fact that not everybody uses them. In 2018, React Native started to remove `PropTypes` from React Native for the same reason. In 0.68 React Native introduced a deprecation warning which notified users that the change was coming, and in 0.69 we removed the PropTypes entirely.
The feedback we've received from the community is that there has not been enough time to migrate libraries off of PropTypes. This has resulted in users needing to patch the React Native package `index.js` file directly to add back the PropTypes, instead of migrating off of them. We can empathize with this fix short term (it unblocks the upgrade) but long term this patch will cause users to miss important changes to `index.js`, and add a maintenance cost for users.
Part of the reason there was not enough time is that we didn't do a good job surfacing libraries that were using PropTypes. This means, when you got a deprecation warning, it wasn't clear where the source of the usage was (either in your code or in a library). So even if you wanted to migrate, it was difficult to know where to actually make the change.
In the next release, we've made it easier to find call sites using deprecated types by [fixing the code frame in errors](https://github.com/react-native-community/cli/pull/1699) reporting in LogBox, and ensuring that [the app doesn't crash without a warning](https://github.com/facebook/react-native/pull/34650). This should make it easier to identify exactly where the deprecated usage is, so you can migrate it.
To help users get off of the patch, and allow more time to migrate, we're walking back the removal of PropTypes, and keeping it as a deprecation for a couple more versions. We ask that you either migrate off PropTypes to a type system like TypeScript, or migrate to the `deprecated-react-native-prop-types` package.
Once we feel more confident that the community has migrated and will not need to patch React Native in order to fix this issue, we'll remove the PropTypes again. **If you have any trouble finding the source of the PropType usage, please file an issue so we can help track it down with you.**
Changelog:
[General][Changed] - Add back deprecated PropTypes
Reviewed By: yungsters
Differential Revision: D40725705
fbshipit-source-id: 8ce61be30343827efd6dc89a012eeef0b6676deb
Summary:
## Overview
When I implemented `ignoreLogs` it was originally just to move `console.ignoreYellowBox` over to LogBox. When I did that, I also added filtering for console messages too. My thought process was: Developers probably don't want to configure hiding logs twice, so the LogBox method can handle both.
This was a mistake. We should never hide console errors and warnings, because it completely silences important feedback to the users such as deprecation warnings. These issues should be fixed, not silenced, and since adding the silencing behavior it's clear that this feature is being abused to ignore legitimate warnings that need address.
Issue #33557 is a great reason why - the correct fix for this is not to ignore the errors, it's to address the deprecation / removal of the API. Allowing an easy `ignoreLog` method to hide the problem made this migration much more painful.
Thus, we're reverting back to the pre-logbox behavior of always showing console logs, even if they're ignored by LogBox in the app UI. Hopefully, this results in more of these issue being addressed instead of ignored.
Changelog:
[General] [Changed] - Do not filter errors/warnings from console
Reviewed By: yungsters
Differential Revision: D40724661
fbshipit-source-id: de3d2db1b0c32dee96acf92c9b1ca07ba0f4e218
Summary:
We are running into a group seeing frequent disconnects from Metro in a specific office. These are surfaced (at least on iOS) as websocket closures, without a prior websocket error. WebSocket closure can be for a variety of reasons, and the spec for a CloseEvent is to include fields `wasClean`, `code`, and `reason`, with `code` having the most well-defined meaning.
This change makes it so that we emit extra context when the websocket is closed. That should help inform developers the reason behind any close that may be abnormal.
Changelog:
[General][Added] - Log Abnormal Closes to Metro Websocket
Reviewed By: motiz88
Differential Revision: D40660765
fbshipit-source-id: ef606d8d809af1c697a78eb00cc5666c29a8bca3
Summary:
Currently, RCTBlobManager (the native module for Blob support) cannot be loaded on iOS when the new architecture is enabled.
## Changelog
[General] [Added] - `BlobModule` to `RCTCoreModulesClassProvider`
Pull Request resolved: https://github.com/facebook/react-native/pull/35047
Test Plan:
The snippet below can be used to test Blob support with the new architecture enabled.
```
// App.tsx
import { useEffect } from 'react';
import { View } from 'react-native';
function uriToBlob(uri: any) {
return new Promise((resolve, reject) => {
const xhr = new XMLHttpRequest();
xhr.responseType = 'blob';
xhr.onload = () => {
const blob = xhr.response;
resolve(blob);
};
xhr.onerror = err => {
reject(err);
};
xhr.open('GET', uri);
xhr.send();
});
}
export default function App() {
useEffect(() => {
uriToBlob('https://www.google.com/images/branding/googlelogo/1x/googlelogo_color_272x92dp.png');
});
return <View />;
}
```
Related issue: https://github.com/facebook/react-native/issues/35042
Reviewed By: NickGerleman
Differential Revision: D40716048
Pulled By: cipolleschi
fbshipit-source-id: 17643d230fa7ea83baee363d137d51f87818baa8
Summary:
This remove a flag to effectively go publishing to Sonatype.
The idea was to protect us against accidentally publishing a nightly as a stable release.
We need to remove this before RC0
Changelog:
[Internal] [Changed] - Remove the --dry-run gate from publishing to Sonatype
Reviewed By: cipolleschi
Differential Revision: D40687038
fbshipit-source-id: e6821905f41899430813f9575f17a5068b05a9bb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35092
As we're close to the cut of the 0.71 branch, I'll take the opportunity to polish
our Gradle public API.
We're exposing a mixture of Path (String) and File (java.io.File or RegularFileProperty).
Here I've moved everything to use File as it's more configurable for the users,
specifically if they're using monorepos or other setup.
This also allows us to remove the resolution logic for the cliPath.
Changelog:
[Internal] [Changed] - RNGP - Use the File Api to specify cliPath and remove ComposeSourceMap path
Reviewed By: cipolleschi
Differential Revision: D40710595
fbshipit-source-id: a17095eebae5123b70fd2b8e3d512656817006ca
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35091
This diff refines the DefaultNewArchitectureEntryPoint to make it easier for user to
either turn on Fabric, TurboModules or both.
Changelog:
[Internal] [Changed] - Make it easier for user to toggle only Fabric or TurboModules in New Architecture
Reviewed By: cipolleschi
Differential Revision: D40710596
fbshipit-source-id: 236060b2ebccb1bf25e7f5c0fc15f54c5ce5f608
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35093
It turns out that using the Artifacts API to manipulate the APK to remove
.so has unintended side effects and is causing the `installDebug` and `installRelease`
commands to fail.
I've resorted to register a packaging option for each variant to make sure we include only
the correct artifacts we want.
This should fix the current startup crash that is experienced on main.
Changelog:
[Android] [Fixed] - RNGP - Do the .so cleanup using pickFirst and exclude
Reviewed By: cipolleschi
Differential Revision: D40722285
fbshipit-source-id: 982e1e9c474522fc4419c969ede5ee14e5404f3a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35083
We don't need to `enableCodegenInApps` keys but we can instead rely on the
existence of the `codegenConfig` key inside the `package.json` to decide if
Codegen should run in App modules or not.
Changelog:
[Internal] [Changed] - RNGP - Remove enableCodegenInApps and infer it from package.json
Reviewed By: cipolleschi
Differential Revision: D40687079
fbshipit-source-id: cd4a6c67caa19c1d199ae75388a0551339f876a0
Summary:
This PR is part of https://github.com/facebook/react-native/issues/34872.
This PR contains two changes, extracting the visitor object and then factoring out the `getConfigType()` function to the `parsers/utils.js` file. Then we can reuse the same function in both flow and typescript by passing the extracted visitor object.
## Changelog
[Internal] [Changed] - Extract visitor object in the same file and factor out `getConfigType()` to `parsers/utils.js`.
Pull Request resolved: https://github.com/facebook/react-native/pull/35035
Test Plan: Output of `yarn jest react-native-codegen` ensures all passed test cases
Reviewed By: cortinico
Differential Revision: D40548855
Pulled By: cipolleschi
fbshipit-source-id: 310b8565322a4e4800a3fffc67479a9dfa45d620
Summary:
changelog:
[general][Added] - Concurrent rendering safe implementation of ScrollViewStickyHeader
This is a re-land of ScrollViewStickyHeader from Kacie Bawiec.
Reviewed By: yungsters
Differential Revision: D40380217
fbshipit-source-id: 60dc86086a4d9d97eef71c4ed2e26536f7e72889
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35089
Changelog:
[General][Fixed] - Back out "Add enum example to Android/iOS rn-tester TurboModule"
This broke the rn-tester adding due to an invalid flow-enum setup. Needs further investigation
Reviewed By: cipolleschi
Differential Revision: D40714320
fbshipit-source-id: 9831276762f90df0ffaca3304382fe5925009343
Summary:
This pull request migrates the activity indicator example to using React Hooks.
## Changelog
[General] [Changed] - RNTester: Migrate ActivityIndicator to hooks
Pull Request resolved: https://github.com/facebook/react-native/pull/35071
Test Plan: The animation works exactly as it did as when it was a class component
Reviewed By: jacdebug
Differential Revision: D40698379
Pulled By: NickGerleman
fbshipit-source-id: 08b275fcc4e3a10b5872e0031fa2ecce5360a7b9
Summary:
fd91748146 added a condition not to pump an extra message when we didn't see symbolication warnings (which do not seem to show up in a stock internal build), but I missed that the test specific to RCTLogLevelError checked for string containment instead of equality, and the last assertion we process on log level is incorrect in OSS as a result.
Changelog:
[Internal][Fixed] - Fix RCTLoggingTests in OSS
Pull Request resolved: https://github.com/facebook/react-native/pull/35085
Test Plan:
`test_ios-Hermes` passes again in OSS: https://github.com/facebook/react-native/pull/35085 (JSC and Android failures look unrelated)
RCTLoggingTests still pass running `buck test //xplat/js/react-native-github/packages/rn-tester:RNTesterIntegrationTests`
Reviewed By: rshest
Differential Revision: D40699773
Pulled By: NickGerleman
fbshipit-source-id: 5acc8ec2b26a1f9acac2f070b85f1d65ee15a011
Summary:
* Add a DevToolsSettingsManager, which has android and iOS variants, which uses a new TM (Android) or takes advantage of the Settings TM (iOS) to get/set console patch settings
* This is backed by either the existing Settings module (iOS) or a new Java TM, which uses the SharedPreferences AP
## Testing
Manual testing
## Changelog
[General] [Added] - Add DevToolsSettingsManager
Pull Request resolved: https://github.com/facebook/react-native/pull/34964
Test Plan: * Extensive manual testing
Reviewed By: NickGerleman
Differential Revision: D40333083
Pulled By: rbalicki2
fbshipit-source-id: f3816e3bd7dea3086f6f2269c3a099af14aebb3b
Summary:
Without this, the CocoaPods output would display multiple "Building RNTester..." logs. With these changes, we make it clear that these are separate targets that are being configured.
Changelog: [internal]
Reviewed By: mdvacca, cipolleschi
Differential Revision: D40656813
fbshipit-source-id: a317112e804d08b9e64e2d62e8b27e4045b317b0
Summary:
Some portions of continuous test runs RNTesterIntegrationTests will hang for an hour when running in Sandcastle without outputting anything. Locally debugging, I see a deadlock waiting on a semaphore, where the test assumed an extraneous symbolication warning would be fired.
This change makes it so that we only look for the extraneous messages if we haven't already seen the target message, since they do not seem to show up in local testing. I also added assertions per semaphore that the log statement is propagated within a still very gracious 10 seconds. This means we still can see what tests are running/failing if this test has issues, instead of a deadlocked test runner with no output.
Changelog:
[Internal][Fixed] - Fix deadlock in RCTLoggingTests
Reviewed By: cipolleschi
Differential Revision: D40667275
fbshipit-source-id: ab78f3c2ef47e2fd740b1dad2a65912e9542301d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35079
This bumps the Docker image for React Native Android to 6.0
shipping the NDK 23 with it, finalizing all the work needed
to support NDK 23.
Changelog:
[Internal] [Changed] - Bump the Android Docker image to 6.0 (for NDK 23)
Reviewed By: cipolleschi
Differential Revision: D40675449
fbshipit-source-id: 5fb53080ce796263cd592dbc489743e6295060ba
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35075
This diff updates the New App template for Android to use the React Native Gradle Plugin.
With this we can:
1. Get rid of all the C++ code.
2. Remove a lot of New Architecture logic in the build.gradle
3. Reuse the prebuilts of React Native/Hermes via prefab
Changelog:
[Android] [Changed] - Update the template to use RNGP
Reviewed By: cipolleschi
Differential Revision: D40673732
fbshipit-source-id: 70935248993d1e24904c982e75f12ad580faa9d8
Summary:
There are use cases in which we want to pass a set of unique elements from C++ to JS and back. We can do this simple by re-using a plain JS array for these purposes.
Changelog:
[Internal][Added] react-native bridging > Add support for std::set
Reviewed By: cipolleschi
Differential Revision: D40668244
fbshipit-source-id: d06603440569e5f760c2859a54cf6e4232c7d97a
Summary:
With RNGP we can now deprecate react.gradle
I'll create a page on the website to describe what is the migration strategy here,
but users should be fine by just replacing `apply from react.gradle` with
`apply plugin: com.facebook.react`.
Changelog:
[Android] [Removed] - Deprecate react.gradle
Reviewed By: cipolleschi
Differential Revision: D40675546
fbshipit-source-id: a50348791d669df1ed9e0470a6664e291c1a4584
Summary:
The `typeof X` type annotation now respects the initialization state of `X`: if `X` hasn't been declared it will be an error to get its type.
Changelog: [Internal]
Reviewed By: jbrown215
Differential Revision: D40638870
fbshipit-source-id: 57459dec30ec5b87397365a709f2d846c87e378a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35036
This diff is the base to create a polimorphic behavior for TypeScript and Flow parser. This type will allow to share a lot of code between the parsers and also to keep their differences a part.
It will be the base diff/PR for further tasks in the Codegen umbrella Issue
## Changelog:
[General][Added] - Parser interface to divide parser logic.
Reviewed By: cortinico
Differential Revision: D40548707
fbshipit-source-id: e632ba52b00b43e50306e3a792a841e72e8c07f4
Summary:
Bumping RNGP to make sure all the changes are available for 0.71
I've also removed the caret from react-native's package.json as
I don't want .5 to be used by template tests yet.
The Android template needs to be updated in order to use
that version of the Gradle plugin.
Changelog:
[Internal] [Changed] - Bump react-native-gradle-plugin to 0.71.5
Reviewed By: cipolleschi
Differential Revision: D40642114
fbshipit-source-id: 70359efc3d2300e9c04c1b361c45061fd1c2931b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35066
This just bumps the NDK version used inside the template to be 23.
We can't merge this as it is but we have to wait for a bump of the Docker image for Android.
Changelog:
[Android] [Changed] - Bump NDK to 23
allow-large-files
Reviewed By: cipolleschi
Differential Revision: D40637103
fbshipit-source-id: e637140cbe6052e94a6efedf12f4b5b81b90a7eb
Summary:
Throws a JS error instead of crashing Hermes with an invariant when trying to convert a JS symbol or BigInt to a folly::dynamic value.
Changelog:
[General][Fixed] - Fixed crash when converting JS symbol to folly::dynamic
Reviewed By: javache
Differential Revision: D40444164
fbshipit-source-id: 37df8059b2eb425563f30cf1e9c0436e8d665b34
Summary:
I tried to build the source locally to test changes with `rn-tester`. However, the gradle build failed due to "./ReactAndroid/gradle.properties (No such file or directory)". I believe this error was introduced by https://github.com/facebook/react-native/commit/3d05bac5872b42a5f412ec9042ce5be0b5d5b8d3.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Fixed] - Fix ReactAndroid not found in rn-tester build
Pull Request resolved: https://github.com/facebook/react-native/pull/35058
Test Plan:
- Clone the react-native repo.
- Run `cd packages/rn-tester`.
- Run `yarn install-android-jsc` and encounter the error.
- Apply the fix.
- Run `yarn install-android-jsc` and build succeeds.
Reviewed By: cipolleschi
Differential Revision: D40639856
Pulled By: cortinico
fbshipit-source-id: 58b51bcad0af7a21cac032c98484c5942a203e4c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35067
I accidentally broke test_android by landing a diff without waiting for
the full CI output.
Changelog:
[Internal] [Fixed] - Unbreak test_android by passing the correct file to hermesc
Reviewed By: cipolleschi
Differential Revision: D40638239
fbshipit-source-id: 1d03106f3b144f537265910df095a6023b181d85
Summary:
As pointed out by necolas on https://github.com/facebook/react-native/issues/34424#issuecomment-1261482517 we forgot we add the `role` prop mapping to the `Text` component. This PR adds a new `role` prop to `Text`, mapping the web `role` values to the already existing `accessibilityRole` prop and moves the `roleToAccessibilityRoleMapping` to a common file that can be imported by both the `Text` and `View` components as requested on https://github.com/facebook/react-native/issues/34424. This PR also updates the RNTester AcessebilityExample to include a test using this new prop.
## Changelog
[General] [Added] - Add role prop to Text component
Pull Request resolved: https://github.com/facebook/react-native/pull/34976
Test Plan:
1. Open the RNTester app and navigate to the Accessibility Example page
2. Test the `role` prop through the `Text with role = heading` section
Reviewed By: yungsters
Differential Revision: D40596039
Pulled By: jacdebug
fbshipit-source-id: f72f02e8bd32169423ea517ad18b598b52257b17
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35063
This is part of a series of tasks to make the React Native Gradle Plugin (RNGP) variant-aware.
Here I'm add Variant support to RNGP via the Variant API from AGP 7.x
A short summary of changes:
- I've pushed a number of breaking changes to ReactExtension (we should document them in the release notes). Specifically I've removed properties which I believe were unnecessary and confusing
- I've removed all the extra logic to do the .so cleanups and use the new tasks that use the Artifacts API
- I've introduced only a `debuggableVariants` to make all the decisions for the bundling and minification which should be sufficient for users
- I've removed all the funcional interfaces are replaced them with lists as they're easy to handle and understand for users.
Changelog:
[Android] [Changed] - Added Flavor Support to React Native Gradle Plugin (RNGP)
Reviewed By: cipolleschi
Differential Revision: D40335028
fbshipit-source-id: d9ac1437de8a27db2e93df15b13772b221e036b2
Summary:
This is part of a series of tasks to make the React Native Gradle Plugin (RNGP) variant-aware.
I'm extending RNGP to do autoconfiguration of dependencies for React Native and Hermes Engine using the Utils classes which were introduced before.
Changelog:
[Internal] [Changed] - RNGP - Automatically Configure Dependencies for ReactNative & Hermes
Reviewed By: cipolleschi
Differential Revision: D40633487
fbshipit-source-id: d4240987a9400fff2ec2aff2d13afc5b24778598
Summary:
This is part of a series of tasks to make the React Native Gradle Plugin (RNGP) variant-aware.
Historically we used to enable the codegen only for library modules. This is not working well for apps like RN Tester which don't have library modules but are running the codegen.
Therefore I'm introducing the `enableCodegenInApps` that is allowing apps to turn off the codegen if needed.
Changelog:
[Internal] [Changed] - RNGP - Introduce enableCodegenInApps
Reviewed By: cipolleschi
Differential Revision: D40633106
fbshipit-source-id: dc2ae9bbfe5b7940f9e9fe505ab2198a42c8a3f6
Summary:
This is part of a series of tasks to make the React Native Gradle Plugin (RNGP) variant-aware.
Here I'm renaming the top level property to enable hermes from `enableHermes` to `hermesEnabled`. We have a bunch of other properties which are called *Enabled. This one was following a different convention.
I'm retaining the backward compatibility for users using `project.ext.react.enableHermes` so this is not going to be a breakign change.
Changelog:
[Internal] [Changed] - RNGP - Top level property enableHermes -> hermesEnabled
Reviewed By: cipolleschi
Differential Revision: D40633109
fbshipit-source-id: 9d7efad6cb3bb382d1beb56966795a3f42bdaae6
Summary:
This is part of a series of tasks to make the React Native Gradle Plugin (RNGP) variant-aware.
Here I'm creating a new task BundleAndHermesCTask that is variant-aware.
Historically we had problems with the Bundle and the Hermes task being separated and overriding their own output. Consolidating those two steps in a single one will make it easier to support seaprate variants.
I'm going to use this task in a subsequent diff.
Changelog:
[Internal] [Changed] - RNGP - Introduce the BundleAndHermesCTask
Reviewed By: cipolleschi
Differential Revision: D40633108
fbshipit-source-id: 89f6d32ef219626ed5d4c5a0b8ac804c6704b2d6
Summary:
This PR adds React native binding for https://github.com/facebook/yoga/pull/1116
## Changelog
[General] [Added] - Flex gap yoga bindings
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/34974
Test Plan:
Run rn tester app and go to view example. You'll find a flex gap example. Example location - `packages/rn-tester/js/examples/View/ViewExample.js`
### Tested on
- [x] iOS Fabric
- [x] iOS non-fabric
- [x] Android Fabric
- [x] Android non-fabric
To test on non-fabric Android, I just switched these booleans. Let me know if there's anything else I might have missed.
<img width="674" alt="Screenshot 2022-10-14 at 3 30 48 AM" src="https://user-images.githubusercontent.com/23293248/195718971-7aee4e7e-dbf0-4452-9d47-7925919c61dc.png">
Reviewed By: mdvacca
Differential Revision: D40527474
Pulled By: NickGerleman
fbshipit-source-id: 81c2c97c76f58fad3bb40fb378aaf8b6ebd30d63
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35038
React-jsi provides JSI to allow React Native to interface with JavaScriptCore.
The hermes-engine Pod provides a second copy of JSI, as Hermes is built and linked statically with JSI.
This second copy of JSI would lead to an [ODR Violation](https://en.cppreference.com/w/cpp/language/definition).
To resolve this, when Hermes is enabled:
- React-hermes and hermes-engine are installed.
- React-jsc is not installed.
- React-jsi continues to be installed.
- React-jsi will not build JSI.
- React-jsi will declare a dependency on hermes-engine.
The result is that the JSI dependency for React Native is satisfied by hermes-engine, and there is no duplicate JSI library in the project.
When Hermes is disabled:
- React-jsi and React-jsc are installed.
- React-hermes and hermes-engine are not installed.
- React-jsi will build JSI.
Changelog:
[iOS][Changed] Resolve JSI ODR violation, make hermes-engine the JSI provider when Hermes is enabled
Reviewed By: cipolleschi
Differential Revision: D40334913
fbshipit-source-id: 409407a193a35cbd21b0e8778537b3627e4c54a2
Summary:
Move JSC and Hermes CocoaPods configuration to scripts/cocoapods/jsengine.rb.
This file provides a setup_jsc! function and a setup_hermes! function that will configure the necessary pod dependencies for each of the supported JavaScript engines.
Currently, the JSI and JSC pods are installed in both cases. This will likely change in upcoming changes to how Hermes and JSC are configured.
Changelog: [internal]
Reviewed By: dmytrorykun
Differential Revision: D40459234
fbshipit-source-id: d6c89c7f650b1efcce5622594db7fd726eafc2bc
Summary:
The React-Hermes and hermes-engine headers are only needed when Hermes is enabled.
Changelog: [internal]
Reviewed By: cipolleschi
Differential Revision: D40451162
fbshipit-source-id: d38830f8abe57a91798e216d7930bb7add483899
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35031
The React-jsi Pod was serving two purposes: building JSI, and configuring JavaScriptCore as the JS engine.
By splitting the React-jsi Pod into React-jsi and React-jsi, we can start working towards de-coupling the JSI dependency from any particular JS engine.
Pods that depended on React-jsi, now depend on React-jsi and React-jsc.
One exception to this is React-hermes, which is only installed when Hermes is enabled, and thus does not require JavaScriptCore.
Upcoming commits should take care of removing the React-jsc dependency when Hermes is enabled, but it is out of scope for this commit.
Changelog:
[iOS][Changed] - The JSC Runtime is now provided by the React-jsc Pod instead of React-jsi. Libraries that declared a dependency on React-jsi in order to specifically create a JSC runtime (`makeJSCRuntime()`) will need to add React-jsc to their dependencies.
Reviewed By: dmytrorykun
Differential Revision: D40442603
fbshipit-source-id: b9b21146b9deb401f80cfef76a87c9867754a953
Summary:
This is part of a series of diffs to make the React Native Gradle Plugin (RNGP) variant-aware.
Here I'm removing two deprecated properties `useJavaGenerator` and `reactRoot`.
They were both not widely used, we had a deprecation warning and now they're just making the whole setup harder.
Changelog:
[Internal] [Changed] - RNGP - RNGP - Setup tasks to cleanup the Apk/Aab from unused .so
Reviewed By: cipolleschi
Differential Revision: D40547688
fbshipit-source-id: c4b8c1cef3a2abae1060e8ce2540e45d0313a4be
Summary:
Changelog: [Internal]
This occurs sometimes on AR, because `measure` doesn't exist on `Suspense`.
Reviewed By: lunaruan
Differential Revision: D40531850
fbshipit-source-id: 4013d660e5e47a28b27d5b6df57bcb7ce88a4ea8
Summary:
This is part of a series of tasks to make the React Native Gradle Plugin (RNGP) variant-aware.
Here I'm removing the `applyAppPlugin` property which was never used. The new logic will apply the App Plugin if the `com.android.application` plugin is found.
I've also removed the corresponding tests. New one will follow afterwards
Changelog:
[Internal] [Changed] - RNGP - Remove unused applyAppPlugin
Reviewed By: cipolleschi
Differential Revision: D40547689
fbshipit-source-id: ce1089498a586a43cb5e07950767c2c4b51b4597
Summary:
Refer to `In component, props and events pick properties from the component interface by themselves independently, I would like to reverse the direction, to have a function dispatching properties to props and events, to reduce duplicated code.
` in https://github.com/facebook/react-native/issues/34872
## Changelog
[General] [Changed] - Refactor codegen: Dispatch props and events from a central place.
Pull Request resolved: https://github.com/facebook/react-native/pull/34975
Test Plan: `yarn jest react-native-codegen` passed
Reviewed By: cortinico
Differential Revision: D40507917
Pulled By: cipolleschi
fbshipit-source-id: 71988877008ae11a01affd31b34bb3a3b88f96be
Summary:
Changelog: [RNTester][Internal] - Add pointer event test ensuring that pointerover events are fired when an element appears under the cursor
This diff adds a port of an existing web platform test that checks if pointerover & pointerenter events are fired for elements that are mounted underneath the cursor.
Reviewed By: lunaleaps
Differential Revision: D40449499
fbshipit-source-id: 393f4325f7a9d9025fe9d0aab38642b1e3ab2612
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35034
Currently, when creating an app using the command:
`npx react-native init MyApp --version nightly`
iOS fails to install the dependencies because it does not find a proper tarball to run Hermes.
This diff solve the problem by fetching the Hermes tarball that is created by the CI while building the nightly.
## Changelog:
[iOS][Fixed] - Make the nightly work with the proper Hermes tarball
Reviewed By: cortinico
Differential Revision: D40512418
fbshipit-source-id: f510f84be9f19807236091687df5e13961103318
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35015
React Native releases are cut every few months. Without testing, the workflow is prone to breakage.
Dry-run the release workflow on every commit in order to surface any issues as they are introduced instead of at release time.
Fixed issues that surfaced during testing of this workflow:
- Upload both Hermes tarballs
Changelog: [internal]
Reviewed By: mdvacca
Differential Revision: D40483764
fbshipit-source-id: 5ca6bd4dcdfd64c24882ffb202edbfd701efd462
Summary:
I forgot to update the path of the default CMakeLists file for the template.
I'm doing it here.
Changelog:
[Internal] [Changed] - Let the user use the default CMakeList inside the template
Reviewed By: mdvacca, cipolleschi
Differential Revision: D40517207
fbshipit-source-id: 7c02ff5893064dbf54ad573c2984884b1017dacf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35027
This is part of a series of tasks to make the React Native Gradle Plugin (RNGP) variant-aware.
Here I'm extending preparing classes to handle the Dependency versions and pre-configure the repositories as we wish.
Changelog:
[Internal] [Changed] - RNGP - Create DependencyUtil to support with dep version configuration
Reviewed By: cipolleschi
Differential Revision: D40512101
fbshipit-source-id: 05867a4c3fd341373669ea72d950ec4ee78a158d
Summary:
This is part of a series of tasks to make the React Native Gradle Plugin (RNGP) variant-aware.
Here I'm creating some tasks that will take care of doing the .so cleanup of the Apk/AppBundle.
Historically we used to use a error prone mechanism which was relying on assumptions on file paths and was breaking the variant-aware assumptions.
I'm going to use those tasks in a subsequent diff.
Changelog:
[Internal] [Changed] - RNGP - RNGP - Setup tasks to cleanup the Apk/Aab from unused .so
Reviewed By: cipolleschi
Differential Revision: D40512100
fbshipit-source-id: 649999dc8d126e7c939b61a5cec608d39cd7f688
Summary:
This is part of a series of tasks to make the React Native Gradle Plugin (RNGP) variant-aware.
Here I'm extending the GenerateCodegenSchemaTask to make sure we exclude the generated build/ASSETS and build/RES folders from execution avoidance.
Changelog:
[Internal] [Changed] - RNGP - Make sure GenerateCodegenSchemaTask is not considering generated assets/res for execution avoidance
Reviewed By: cipolleschi
Differential Revision: D40512103
fbshipit-source-id: 193f4fd241a0fd973863beb6ff0dd1128dcee1d7
Summary:
This diff adds explicit type arguments to polymorphic function calls that do not constrain their types. This codemod will reduce the error burden that will come in a future version of flow.
This specific diff was generated by running:
```
flow codemod annotate-implicit-instantiations --write .
flow --json --pretty | jq '.errors | .[] | .message | .[] | .loc |.source' | sort | uniq | sed -e 's/"//g' | xargs hg revert
hg st -n | xargs grep "generated" | sed -e 's/:.*//g' | xargs hg revert
arc f
```
So these are the codemod results that introduced no new errors and no generated files.
Changelog: [Internal]
drop-conflicts
Reviewed By: SamChou19815
Differential Revision: D40413074
fbshipit-source-id: 42b52719978f1098169662b503dbcfd8cefdad53
Summary:
The `template/android/app/build_defs.bzl` file can be removed as it's unused in the Template.
## Changelog
[Internal] - Remove build_defs.bzl from Android Template
Pull Request resolved: https://github.com/facebook/react-native/pull/35020
Test Plan: n/a
Reviewed By: cipolleschi
Differential Revision: D40506250
Pulled By: cortinico
fbshipit-source-id: 14d8522a995a4b19b5b6610fcb2c5b1dda3374c8
Summary:
I've just realized we have a typo in the `OsRule`. This is actually causing those tests to fail if run locally on M1 (but not on CI as it runs on a `amd64` architecture).
## Changelog
[Internal] - Fix typo in OsRule
Pull Request resolved: https://github.com/facebook/react-native/pull/35024
Test Plan: Not much to test other than it's green locally, previously it was red. CI should be green regardless
Reviewed By: cipolleschi
Differential Revision: D40507320
Pulled By: cortinico
fbshipit-source-id: 75600014a515b2cb76debbd6e1d79ecd78ea5092
Summary:
This configuration was stale and has no effect on the Gradle Plugin, I'm removing it then 👍
## Changelog
[Internal] - Remove useJavaGenerator key from ReactAndroid/build.gradle file
Pull Request resolved: https://github.com/facebook/react-native/pull/35021
Test Plan: n/a
Reviewed By: cipolleschi
Differential Revision: D40506375
Pulled By: cortinico
fbshipit-source-id: 2bcdc67686b1ac9fc77091d9324f5ad585df8818
Summary:
A super small PR to bump CLI to latest available of the 9.x stream, to make available in main the asset image fix (https://github.com/react-native-community/cli/pull/1290) and to be able to cherry pick it back in 0.70 branch.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[General] [Changed] - bump CLI to 9.2.1
Pull Request resolved: https://github.com/facebook/react-native/pull/35022
Test Plan: CI is green
Reviewed By: dmytrorykun
Differential Revision: D40507344
Pulled By: huntie
fbshipit-source-id: 7c3753e9df154eb5835f021cdfe1b476499afb9a
Summary:
This PR is part of https://github.com/facebook/react-native/issues/34872
This PR extracts `UnsupportedFunctionReturnTypeAnnotationParserError` exception to a separate function inside an `error-utils.js` file
## Changelog
[Internal] [Changed] - Extract `UnsupportedFunctionReturnTypeAnnotationParserError` to a seperate function inside `error-utils.js`
Pull Request resolved: https://github.com/facebook/react-native/pull/34965
Test Plan:
```sh
yarn jest react-native-codegen
```
Added unit case in `error-utils-test.js` file
<img width="939" alt="Screenshot 2022-10-13 at 11 46 54 AM" src="https://user-images.githubusercontent.com/86605635/195517350-dcb7a26d-434c-4e45-a174-ce82931073e5.png">
Reviewed By: dmytrorykun
Differential Revision: D40338048
Pulled By: cipolleschi
fbshipit-source-id: baa41e0e96c9e17a35f316433c8d80c9bf88d334
Summary:
This PR extracts the content of the codegen case 'String' into a single `emitString` function inside the parsers-primitives.js file and uses it in both Flow and TypeScript parsers as requested on https://github.com/facebook/react-native/issues/34872. This also adds unit tests to the new `emitString` function.
ref: https://github.com/facebook/react-native/pull/34936
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - Extract the content of the case 'StringTypeAnnotation' into a single emitString function
Pull Request resolved: https://github.com/facebook/react-native/pull/34981
Test Plan: Run `yarn jest react-native-codegen` and ensure CI is green
Reviewed By: cortinico
Differential Revision: D40376836
Pulled By: cipolleschi
fbshipit-source-id: feb1b07ec7fc2c333f5054f8cd8d18457d985257
Summary:
https://github.com/facebook/react-native/pull/34933 has been merged just after I pushed a new commit to the branch to improve tests of `assertGenericTypeAnnotationHasExactlyOneTypeParameter` function, but the last commit was not imported to the internal repository.
The `assertGenericTypeAnnotationHasExactlyOneTypeParameter` can throw different types of Error, and I believe that `.toThrow(Error)` is not specific enough. So I replaced it with `toThrowErrorMatchingInlineSnapshot()`.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - Improve assertGenericTypeAnnotationHasExactlyOneTypeParameter tests in parsers-commons
Pull Request resolved: https://github.com/facebook/react-native/pull/34942
Test Plan: Some test cases were ok because the assertGenericTypeAnnotationHasExactlyOneTypeParameter function threw an Error, but for the wrong reason. I've made sure that the error displayed in the inline snapshot is the one we expect.
Reviewed By: cortinico
Differential Revision: D40384993
Pulled By: cipolleschi
fbshipit-source-id: aaa943be1e808af2c5131f7d06baf24bc3bffa31
Summary:
This PR is a part of https://github.com/facebook/react-native/issues/34872.
Extracted the UnsupportedObjectPropertyValueTypeAnnotationParserError in its own throwing function and reuse that function passing a proper type.
## Changelog
[Internal] [Changed] - Extract the UnsupportedObjectPropertyValueTypeAnnotationParserError in its own throwing function and reuse that function passing a proper type.
Pull Request resolved: https://github.com/facebook/react-native/pull/34917
Test Plan:
Output of yarn jest react-native-codegen.
<img width="451" alt="Screenshot 2022-10-10 at 12 55 39 PM" src="https://user-images.githubusercontent.com/32268377/194816863-5220dbaa-3b63-42bf-8e62-9d7b915f7cbd.png">
Reviewed By: cortinico
Differential Revision: D40424885
Pulled By: cipolleschi
fbshipit-source-id: 08d4d13ee3959391261fe13c190a4bb893970757
Summary:
[`Share`](https://reactnative.dev/docs/share) currently does not support the `anchor` option in iOS, so share sheets will always be displayed in the middle of the screen on iPads and on the top left corner of the window on Mac Catalyst.
This PR utilizes the `anchor` functionality already implemented in [`ActionSheetIOS`](https://reactnative.dev/docs/actionsheetios) to bring this support to `Share` on iOS.
## Changelog
[iOS] [Changed] - type definition for the `options` parameter of `Share.share` (added optional `anchor` property)
[iOS] [Added] - `anchor` option support for `Share`
Pull Request resolved: https://github.com/facebook/react-native/pull/35008
Test Plan:
Tested with modified `rn-tester` that utilizes the `anchor` option on iPad simulator. Marked all 3 changes in code.

```js
const SharedAction = () => {
const [shared, setShared] = React.useState();
const ref = React.useRef(); /* create ref (1/3) */
const sharedAction = async () => {
try {
const result = await Share.share(
{
title: 'Create native apps',
message:
('React Native combines the best parts of native development with React, a best-in-class JavaScript library for building user interfaces.': string),
url: 'https://reactnative.dev/',
},
{
subject: 'MUST READ: Create native apps with React Native',
dialogTitle: 'Share React Native Home Page',
tintColor: 'blue',
anchor: ref.current?._nativeTag, /* add anchor in options (2/3) */
},
);
if (result.action === Share.sharedAction) {
setShared(result.action);
} else if (result.action === Share.dismissedAction) {
//iOS only, if dialog was dismissed
setShared(null);
}
} catch (e) {
console.error(e);
}
};
return (
<View style={styles.container}>
<Text>action: {shared ? shared : 'null'}</Text>
<Text style={styles.title}>Create native apps</Text>
<Text>
React Native combines the best parts of native development with React, a
best-in-class JavaScript library for building user interfaces.
</Text>
{/* supply ref to Node (3/3) */}
<Text ref={ref} style={styles.button} onPress={sharedAction}>
SHARE
</Text>
</View>
);
};
```
Reviewed By: cipolleschi
Differential Revision: D40459336
Pulled By: skinsshark
fbshipit-source-id: 72fbb3905ea0b982bb7f4b99967d121cd482181a
Summary:
circleci analyze_code errors: https://app.circleci.com/pipelines/github/facebook/react-native/16638/workflows/76804803-ceb5-4fb3-bd24-26bbb9826827/jobs/321696
- __Image.flow and Image.ios:__ requires needed to be sorted alphabetically
- __error-utils-test.js:__ duplicate describe block title is used, i believe this was a typo
Changelog:
[Internal][Fixed] - fix circleci:analyze_code errors
Reviewed By: lunaleaps
Differential Revision: D40491001
fbshipit-source-id: a1df6ded77374f92e297d0a8866a2c4096e1196a
Summary:
Add full functionality for `Symbol`s and `BigInt`s in the debugger. Note- using the [protocol monitor](https://umaar.com/dev-tips/166-protocol-monitor/) was the most reliable way of figuring out which fields exactly need to be set for these types to play nicely in DevTools. I brought up the monitor and then used the regular, standard chrome console with the functionality I wanted:
- Evaluating `Symbol` and `BigInt` literals, like `Symbol.for("a")` and `1n`
- Right-click save the resulting expressions
From there, I inspected the CDP messages being sent. Then I was able to fill in the correct fields from there, and be confident that those were correct, given that I was copying the exact behavior of Chrome itself.
Changelog:
[General][Fixed] Support properly sending BigInts and Symbols over the Chrome DevTools Protocol.
Reviewed By: neildhar, jpporto
Differential Revision: D40442228
fbshipit-source-id: 98a514edbeb35fcbd427a25475f435e22956f2db
Summary:
Changelog:
[Internal][ErrorHandling] 3/n Add a gate for parsing unhandled JS errors in C++
Gate this just in case it causes issues. Enabling this is definitely a better behavior than before, because we want the JS stack when there is a JS error, not the native stack.
Reviewed By: sammy-SC
Differential Revision: D40397393
fbshipit-source-id: 586b4d7bcf710edb048b5c643646ba2f3c4c302a
Summary:
checking for background == null to fix this error:
```java.lang.NullPointerException: Attempt to invoke virtual method 'android.graphics.drawable.Drawable$ConstantState android.graphics.drawable.Drawable.getConstantState()' on a null object reference
at com.facebook.react.views.textinput.ReactTextInputManager.setUnderlineColor(:4)
```
Changelog:
[Internal][Fixed] - check for null background in Android TextInput setUnderlineColor
Reviewed By: beatthat
Differential Revision: D40451369
fbshipit-source-id: 8618d5ff73f517f714c26a0b17af078493822244
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35013
Previously, release builds were only built for stable RN releases. This creates a discrepancy between CI jobs that run on commits versus CI jobs that run on releases. We are working on reducing these differences in order to limit the number of issues we may face when cutting a React Native release.
Now, build_hermes_macos will be run as a matrix of Debug/Release builds in every workflow.
Updated build_hermes_macos to take 'flavor' as a Enum, not a string.
Store hermesc in separate directories as Circle CI does not allow two different jobs (e.g. build_hermes_macosDebug and build_hermes_macosRelease) to write to the same path when storing artifacts.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D40308952
fbshipit-source-id: b96b9a6c7cf8d0becafcf2fdcb761540816ae336
Summary:
In this diff I'm shipping and deleting mapBufferSerialization for Text measurement
changelog: [internal] internal
Reviewed By: NickGerleman
Differential Revision: D40348982
fbshipit-source-id: 7336cbe055a55d7d8d4f0a723049842bae1defb5
Summary:
This diff refactors the initialization of MapBuffer so
changelog: [internal] internal
Reviewed By: NickGerleman
Differential Revision: D40348981
fbshipit-source-id: 88bbf4f2370373c20f805c3b23d0ecbe8a26bb86
Summary:
Recently this PR got merged https://github.com/facebook/react-native/pull/34919 that aligned the info.plist to the current default. Problem: the variable `MARKETING_VERSION` was not set in the template, so generating a new project and testing on iOS would fail accordingly:
<img width="1400" alt="Screenshot 2022-10-18 at 15 27 27" src="https://user-images.githubusercontent.com/16104054/196461640-470079f5-0f64-471f-8221-0d17f2b0114f.png">
This PR takes care of setting the variable so that the app can build successfully.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[iOS] [Fixed] - add MARKETING_VERSION to template project
Pull Request resolved: https://github.com/facebook/react-native/pull/35012
Test Plan: Run `yarn test-e2e-local -t RNTestProject`, apps builds correctly and runs on simulator.
Reviewed By: cipolleschi
Differential Revision: D40472420
Pulled By: cortinico
fbshipit-source-id: 18ddd57ce54186a101321583a7a8391e97ca9511
Summary:
This is the second diffs that backs out the Custom Native State from the Codegen. The reason why we are backing it out are:
1. It forces users to create new types in JS that are not ctually used there. For example, the NativeState you define, and eventually exports, in JS is not used anywhere in your JS code.
2. You need to put in the JS native state some types that does not exists in JS, only to have them generated by the Codegen. ImageRequest, for example, does not exists in JS, but you need it in your (iOS) state to load images
3. There are a lot of edge cases due to how C++ handles variables. Some variables needs to be created as pointers. Some others as `const &`. It does not scale to hard code all of them and there is the risk to have the same type that needs to be a pointer in some case and something else in others.
4. It is better to instruct the users on how to properly create a component with Custom State, Shadow Node and Descriptor.
## Changelog:
[General][Removed] - Back out parsing and generation of Custom Native State from Codegen
Reviewed By: cortinico
Differential Revision: D40426134
fbshipit-source-id: c368e122cc31ee8df056fe1bf6cecaab482140a4
Summary:
This is the first diffs that backs out the Custom Native State from the Codegen. The reason why we are backing it out are:
1. It forces users to create new types in JS that are not ctually used there. For example, the NativeState you define, and eventually exports, in JS is not used anywhere in your JS code.
2. You need to put in the JS native state some types that does not exists in JS, only to have them generated by the Codegen. ImageRequest, for example, does not exists in JS, but you need it in your (iOS) state to load images
3. There are a lot of edge cases due to how C++ handles variables. Some variables needs to be created as pointers. Some others as `const &`. It does not scale to hard code all of them and there is the risk to have the same type that needs to be a pointer in some case and something else in others.
4. It is better to instruct the users on how to properly create a component with Custom State, Shadow Node and Descriptor.
## Changelog
[General][Removed] - Back out components with native state in RNTester
Reviewed By: cortinico
Differential Revision: D40419254
fbshipit-source-id: 1895c7050f01f76a8901a97e9700f74cae707b79
Summary:
Changelog:
[General][Added] - Introduce `useAnimatedValue` hook to make it easier working with `Animated.Value`s in function components.
Reviewed By: javache
Differential Revision: D40434219
fbshipit-source-id: 3caf6ad98d11a534b8cc6816820bc1d125150380
Summary:
This change starts adding more coverage to GitHub Actions. Existing workflows are split up to be per-platform, and stale scripts, etc are removed.
We are currently limited a bit by issues with the build itself, but this still adds a good bit of coverage that readily works, and adds places to inject more.
Another option would have been to move these to CircleCI where we have more credits, or used docker images instead of manual setup steps. etc, The Yoga build and number of changes is very light though, so we don't really need the complexity yet.
Some TODOs:
1. Fix the Apple Builds (pod lint and pod install return errors seen by the community)
2. Add working Android UTs
3. Add C++ UTs
4. Add Apple Publish
5. Add version stamping
Changelog:
[Internal][Added] - Start Adding Yoga GitHub Actions
X-link: https://github.com/facebook/yoga/pull/1165
Reviewed By: cortinico
Differential Revision: D40386426
Pulled By: NickGerleman
fbshipit-source-id: c540dd25bfec6ac8c05e461c1236ef7fe6cb8598
Summary:
We found this feature crashing the app during hot reload, and as there is no user code dependent on it so far, we decided to disable it until we find the root cause.
changelog: [internal] internal
Reviewed By: mdvacca
Differential Revision: D40445312
fbshipit-source-id: fe28b58c5dca6c91389ad38675ca37669a4965a0
Summary:
Changelog: [RNTester][Internal] - Add PointerOver/PointerOut handling test
This diff adds another platform test based on WPT testcase for mouseover/mouseout events but instead applied to pointerover/pointerout events recently implemented for RN.
Reviewed By: lunaleaps
Differential Revision: D40359286
fbshipit-source-id: 672f413f56faca55b9d838150fb66de66d78d6f2
Summary:
iOS did not support the implementation of Korean word-wrap(line-break) before iOS14.
If the attribute applied, the word-wrap of Korean will works.
## 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] [Added] - Line break strategy for Text and TextInput components
Pull Request resolved: https://github.com/facebook/react-native/pull/31272
Test Plan:
1. Test build and run on above iOS 14.
2. Test it does not affect existing text components when set default(none) strategy.
3. Test whether word-wrap works with Korean when set hangul-word strategy.
<img src="https://user-images.githubusercontent.com/26326015/112963967-d7f70c00-9182-11eb-9a34-8c758b80c219.png" width="300" height="" style="max-width:100%;">
Reviewed By: javache
Differential Revision: D39824809
Pulled By: lunaleaps
fbshipit-source-id: 42cb0385221a38c84e80d3494d1bfc1934ecf32b
Summary:
This PR is the follow up to the conversation started here by SimenB: https://github.com/react-native-community/discussions-and-proposals/issues/509
Basically, we want to move RN to use its own custom environment so that we can tweak it going forward - this PR in fact only sets up the groundwork for that; robhogan mentioned that with this in place, Meta engineers can
> iterate on it (with jest-environment-node as a starting point) against our internal product tests
This is also connected to Rob's work to bring Jest 29 into the codebase https://github.com/facebook/react-native/pull/34724 and my "mirror" PR to bring template in main up to the same version (https://github.com/facebook/react-native/pull/34972)
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[General] [Changed] - move Jest config to use a custom react-native Jest env
Pull Request resolved: https://github.com/facebook/react-native/pull/34971
Test Plan: Tested that `yarn test` in main works fine after the changes; CI and Meta's internal CI will also serve the purpose of verifying that it works (but there's no reason not to since it's still pretty much just relying on `node`).
Reviewed By: huntie
Differential Revision: D40379760
Pulled By: robhogan
fbshipit-source-id: 2c6d0bc86d337fda9befce0799bda2f56cc4466c
Summary:
Breaks the runtime dependency cycle introduced in D40259791 (https://github.com/facebook/react-native/commit/971599317b7bdf1152157206f9503a23ac8c4162) by converting a value import to a type import. (Unlike runtime dependency cycles, type-level cycles are OK as long as they are reasonably small.)
Changelog:
[General][Fixed] - Fix require cycle warning in VirtualizedList
Reviewed By: javache
Differential Revision: D40412019
fbshipit-source-id: 33bf3af12be64a1932549a0d11f2ce8b3c483218
Summary:
changelog: [internal]
Removing listener on detached node leads to a red box, if the said node is `DiffClampAnimatedNode`. This is because calling `AnimatedNode.__getNativeTag()` makes native module call and creates node in native. This node is not completely initialised and red boxes because `[RCTAnimatedNode parentNodes]` is nil when it shouldn't be.
The fix is make sure all listeners are removed before node is destroyed. It is logically correct thing to do. The fix is global, for all components using `DiffClampAnimatedNode`.
Reviewed By: yungsters
Differential Revision: D40381895
fbshipit-source-id: 4f558faf8101b70552f30e6360998e902aacbc83
Summary:
Changelog:
[Internal][Added] - Add support for passing objects with `AnimatedNode` values and arrays of `AnimatedNode` elements in the `transform` styling prop.
Reviewed By: javache
Differential Revision: D40379943
fbshipit-source-id: 826b9cd0c0cfe02b55d86d1c735f8faf31196e64
Summary:
It seems like CircleCI is not handling well env variables with \n in it.
I'm moving it over to a base64 encoded string and I'm extending the publish
scripts to base64 decode the key.
Changelog:
[Internal] [Changed] - Unbreak Nightly job by providing a GPG key as base64 encoded.
Reviewed By: cipolleschi
Differential Revision: D40426438
fbshipit-source-id: a60a7e7ad71580e81e675c84008d2712712e42a6
Summary:
This PR is a task from https://github.com/facebook/react-native/issues/34872:
> Extract the visit function in a shared function in the parsers/utils.js folder. Use the new function in the Flow and TypeScript parsers.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - Extract the visit function in a shared function in the parsers/utils.js
Pull Request resolved: https://github.com/facebook/react-native/pull/34946
Test Plan: I tested using jest, flow and eslint commands.
Reviewed By: NickGerleman
Differential Revision: D40276462
Pulled By: cipolleschi
fbshipit-source-id: 299cc2a3aa65a9757b217192a13838d037c497a1
Summary: Changelog: [Internal] Add more properties to PointerEvent, ensure all web platform tests are passing
Reviewed By: mdvacca
Differential Revision: D40314330
fbshipit-source-id: 071683f26f5a1e17d7ea49ac022c0ca23b6f9947
Summary: Changelog: [Internal] - Add an option to only see failed tests for PointerEvents web platform tests
Reviewed By: mdvacca
Differential Revision: D40281369
fbshipit-source-id: 638879b39ca66c11e722e6140c631dacfc98ee34
Summary:
Changelog: [Internal] Reorder and prefix things with wpt for convenience
Open to other suggestions
Reviewed By: mdvacca
Differential Revision: D40247488
fbshipit-source-id: 4046040d5904b324a9a84dc47f4de858456e7bbc
Summary:
Changelog:
[General][Added] - Highlight elements on hover while mouse down for React DevTools element inspection.
Since there is probably no mouse hover events for RN, this diff implements something that works similar like hover for RN: user keeps the mouse down and moves the cursor around, and the elements under the mouse is highlighted just like Web.
Reviewed By: lunaruan
Differential Revision: D40369733
fbshipit-source-id: ef223ee0f31f4e0372674fc39dd13bad8c15aa92
Summary:
This diff adds defaults to Jest.fn's type params.
An upcoming change to flow will be more restrictive about how we implicitly instantiation type arguments. Since the argument to jest.fn is often omitted, this signature is the single biggest offender of our new rules. To reduce the error diff, I'm adding reasonable defaults so that the mocked function can still behave like a function without adding extra flow errors where there were none before.
Changelog: [Internal]
Reviewed By: SamChou19815
Differential Revision: D40394215
fbshipit-source-id: 2df596b6ba8b54680694e08c432a1e7c94dc2df0
Summary:
The jsi library itself is `jsi/jsi.{h,cpp}`. JSIDynamic provides support for converting between folly::dynamic and jsi::value, independent of the jsi library.
Changelog:
[iOS][Changed] Moved JSIDynamic out of React-jsi and into React-jsidynamic
Reviewed By: cipolleschi, dmytrorykun
Differential Revision: D40334023
fbshipit-source-id: d2c69e7afb7f43f93080301b88c81e1fa46279d7
Summary:
There's no need for the 3 type arguments here. Flow will infer a union already if multiple properties are provided. Worse, by not providing these properties these tvars end up with no bounds, which can cause downstream constraints to stall. All of the suppresisons added here are for legitimate errors that were uncovered by consolidating to one type argument.
Changelog: [internal]
Reviewed By: SamChou19815
Differential Revision: D40355811
fbshipit-source-id: 088fd087017a6082c793ef00c8810a81b39fb9fb
Summary:
Changelog: [Internal] Code clarity: Use enum to clarify the values parsed by JsErrorHandler
Create a enum `JSErrorHandlerKey` to define the keys for the values that goes into each stack frame.
Next up -- using this in the Bridge!
Reviewed By: sammy-SC
Differential Revision: D40326127
fbshipit-source-id: e416814fbcaa922afa92d9baf79eaa898ff979f0
Summary: changelog: Fix vertical text alignment in new architecture when line height is not 0.
Reviewed By: javache
Differential Revision: D40346225
fbshipit-source-id: f6282cb8df80e9a543e5602fddcca1a1a82377e3
Summary:
changelog: [internal]
`parentNodes` may be nil in case `DiffClampAnimatedNode` was not setup correctly. In this case, let's just noop and warn rather than throw redbox. This is not necessary but makes the code safer in world where native animated is invoked by new and old architecture at the same time (pre-bridgeless).
Reviewed By: yungsters
Differential Revision: D40381724
fbshipit-source-id: 6252f05951079649b810902559bfec9dd4f957d9
Summary:
There's no need for the 3 type arguments here. Flow will infer a union already if multiple properties are provided. Worse, by not providing these properties these tvars end up with no bounds, which can cause downstream constraints to stall. All of the suppresisons added here are for legitimate errors that were uncovered by consolidating to one type argument.
Changelog: [internal]
Reviewed By: SamChou19815
Differential Revision: D40355813
fbshipit-source-id: f02a101e5e32f3a2f660a34349e6416b9fde4124
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34983
This sets up our CircleCI logic to publish artifacts to Maven Central.
I will check if tomorrow's nightly successfully landed on Maven Central
Snapshot repository.
I've added a --dry-run to the the close and release step of the publishing
to avoid accidentally publishing to Maven Central. We'll remove this if
we decide to go with the Maven Central publishing.
Changelog:
[Internal] [Changed] - Configure CircleCI to publish artifacts to Maven Central
Reviewed By: jacdebug, huntie
Differential Revision: D40377691
fbshipit-source-id: 36a74074ea95097bb7268352e40f4d2670f3cd65
Summary:
Changelog:
[General][Changed] - Add Metro health check files to the template's `.gitignore`
We're adding an opt-in watcher health check to Metro, which can occasionally leave files named `.metro-health-check*` in the project. To ensure this doesn't clutter people's repos accidentally if enabled, we preemptively add this as a pattern to `.gitignore` in the new project template. We also add it to the React Native repo's `.gitignore` file just in case.
Reviewed By: arushikesarwani94
Differential Revision: D40352040
fbshipit-source-id: 261803b684d79292c014205084e61d5e4f7aeb3d
Summary:
This PR is part of https://github.com/facebook/react-native/issues/34872.
As a part of this PR, `UntypedModuleRegistryCallParserError` is separated into its own throwing function in `error-utils.js` file and is used in both Flow and TypeScript parsers
## Changelog
[Internal] [Changed] - Extract `UntypedModuleRegistryCallParserError` to a separate function inside `error-utils.js` file.
Pull Request resolved: https://github.com/facebook/react-native/pull/34953
Test Plan:
Added unit case in error-utils-test.js file to test the new function.
Output of `yarn jest react-native-codegen` ensures all passed test cases.
<img width="450" alt="Screenshot 2022-10-12 at 12 44 36 PM" src="https://user-images.githubusercontent.com/32268377/195277708-97340db3-f3d8-48a3-9a59-95d2747c67b0.png">
Reviewed By: christophpurrer
Differential Revision: D40297017
Pulled By: cipolleschi
fbshipit-source-id: b02dcf0e110ab903a0d1831783194ae4a543075b
Summary:
This PR is part of https://github.com/facebook/react-native/issues/34872.
This PR extracts `IncorrectModuleRegistryCallTypeParameterParserError` exception to a separate function inside an `error-utils.js` file
## Changelog
[Internal] [Changed] - Extract `IncorrectModuleRegistryCallTypeParameterParserError` to a seperate function inside `error-utils.js`
Pull Request resolved: https://github.com/facebook/react-native/pull/34941
Test Plan:
```sh
yarn jest react-native-codegen
```
Added unit case in `error-utils-test.js` file
<img width="940" alt="Screenshot 2022-10-11 at 4 42 03 PM" src="https://user-images.githubusercontent.com/86605635/195076564-3b023c17-661c-4330-805c-0216c4391d59.png">
Reviewed By: dmytrorykun
Differential Revision: D40296642
Pulled By: cipolleschi
fbshipit-source-id: 7c7bba6a4f68e9b8fa4729a7651f22cce6d7ca6e
Summary:
This PR is part of https://github.com/facebook/react-native/issues/34872
This PR extracts `IncorrectModuleRegistryCallArityParserError` exception to `throwIfIncorrectModuleRegistryCallArityParserError` inside an `error-utils.js` file.
## Changelog
[Internal] [Changed] - Extracted IncorrectModuleRegistryCallArityParserError exception to throwIfIncorrectModuleRegistryCallArityParserError function
Pull Request resolved: https://github.com/facebook/react-native/pull/34940
Test Plan:
Added unit case in error-utils-test.js file
yarn jest react-native-codegen
<img width="1144" alt="Screenshot 2022-10-11 at 4 04 55 PM" src="https://user-images.githubusercontent.com/22423684/195070498-627d1bb8-53b1-43d3-b410-462e4f0da23a.png">
Reviewed By: dmytrorykun
Differential Revision: D40296626
Pulled By: cipolleschi
fbshipit-source-id: 33a299b1adf6334753c2390a81a54832c9096ec5
Summary:
This PR extracts the codegen `ModuleInterfaceNotFoundParserError` exception into a separate function inside `error-utils.js` so that it can be used by both Flow and Typescript parsers as requested on https://github.com/facebook/react-native/issues/34872. This also adds unit tests to the new `throwIfModuleInterfaceNotFound` function.
## Changelog
[Internal] [Changed] - Extract codegen `ModuleInterfaceNotFoundParserError` in a separate function that can de used by Flow and TypeScript parsers
Pull Request resolved: https://github.com/facebook/react-native/pull/34922
Test Plan:
Run `yarn jest react-native-codegen` and ensure CI is green

Reviewed By: dmytrorykun
Differential Revision: D40296533
Pulled By: cipolleschi
fbshipit-source-id: 205469b15337f6c3847936a6ef5427b5a9e08665
Summary: Changelog: [Internal] - Add a display example for offset of many pointers
Reviewed By: mdvacca
Differential Revision: D39736111
fbshipit-source-id: 1fb3f1037d7e743ae1a383a4f4ee876e32da4a6a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34962
For jobs that take a string parameter, where that string parameter is expected to be one of a set of accepted values, use an enum instead.
If an unexpected value is passed to a enum parameter, then `circleci config validate` will flag the issue.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D40310118
fbshipit-source-id: b8416c415705ff6eba80cc5f0d9bfe670569f732
Summary:
Changelog: [Internal] - Add more state to PointerEventState per pointer such that `offset` coordinates and `hitPath` accurately reflect each pointer.
This change eagerly calculates the hitPath of every pointer under a MotionEvent.
Reviewed By: mdvacca
Differential Revision: D39736109
fbshipit-source-id: ef76dc19a86eaf9b26f35c6a55781ece6e43eecc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34970
I'm setting up `gradle-nexus` on our build to simplify the closing and releasing of staging repositories.
As of now, you'll have to go to Sonatype UI and manually click the release button.
With this plugin, we can instruct CircleCI to do the publishing automatically for us as
part of the nightly/stable release process.
Changelog:
[Internal] [Changed] - Setup gradle-nexus to automate closing and releasing staging repositories
Reviewed By: cipolleschi
Differential Revision: D40342759
fbshipit-source-id: 72e80f4bcc80058d5a6ea562ae136a91b2aeedbb
Summary:
This extracts the core changes from https://github.com/facebook/yoga/pull/1116, to support gap/row-gap/column-gap, mostly identical, apart from the rename of gaps -> gutters.
The core functionality in this PR looks to be well tested from the fixtures added. I am not an expert in the internals of Yoga, but I am seeing everything that I would expect to. The space for the gap is accounted for in line-breaking, and the accumulated gaps limit the available line-length, before sizing flexible children, so items are sized correctly as to accommodate the gap. Then the gap is used for spacing during main axis and cross-axis justification.
Changelog:
[Genral][Added] - Implement gap/row-gap/column-gap (within the yoga C ABI)
Reviewed By: javache
Differential Revision: D39922410
fbshipit-source-id: 5850f22032169028bd8383b49dd240b335c11d3d
Summary:
`VirtualizedList_EXPERIMENTAL` is a fork of VirtualizedList. It was originally created for the purpose of keyboard/a11y fixes, which required the list to allow rendering discontiguous regions of cells. So, the large part of the refactor is in the data structure used to represent state (now a sparse bitmask), and building out the render function to operate off the bitmask.
This structure allows pre-rendering areas where we know focus must be able to be synchronously be moved to. This is exercised on platforms like Windows and macOS which fire view level focus events. The new implementation otherwise aims to preserve near-exact list behavior as previously.
Apart from the structure change, the refactor has made the code (subjectively) a lot easier to reason about, and there are now stronger internal invariants than before. The bitmask structure also enables new approaches for nested list stability, and implementing OffScreen.
**Why ship it now?**
Having two implementations has multiple times prevented other changes to VirtualizedList, so it is incurring a constant engineer cost.
At this point, we have a lot of reason to be confident in the maturity of the new list implementation (see the test plan below). So, reconciling the implementations not only unlocks the enhancements of the new list, but unblocks future changes to VirtualizedList.
## Test Plan
1. **Unit tests:** A few dozen unit tests were added to VirtualizedList, validating the regions it renders in response to injected input, across its API surface. Both VirtualizedList implementations must pass the same tests, around expected behavior.
2. **RNTester:** Scenarios in RNTester were manually validated, and all worked as before
3. **New invariants:** I added a lot of internal logic checks and bounds checks as invariant violations, to try to produce signal if any part of the refactor went unexpected in the wild.
4. **MSFT Rollout:** I rolled out the changes as a fork of VirtualizedList at MSFT to a couple of high-usage surfaces using Android, iOS, and Windows on Paper. Some invariant violations were surfaced and fixed, but telemetry showed solid system and scenario health with the change.
5. **Meta import:** Fixed all land-blocking test failures when using the new list. These were confined to updating snapshots, and adding additional checks for invalid input.
6. **Panel apps:** Manually validated top-level surfaces of panel apps in debug/release modes. Fixed a couple of invariant violations and novel usages. Profiled new JS structures against an expensive list with Hermes profiler.
7. **Facebook App Rollout:** After some manual validation of top-level surfaces, the change was rolled out to Facebook for Android and iOS as an experiment. New invariant violations were fixed, and the change has sat in production for several weeks at this point, while measuring impact to metrics like error rate, responsiveness, and impressions.
This is the first introduction to all of OSS, and some Meta internal apps. This means there may still be novel usages of VirtualizedList that were not picked up during testing, but I think there has been enough diligence to roll out what has been tested, and forward fix anything unexpected that might still come up.
Changelog:
[General][Changed] - Ship VirtualizedList_EXPERIMENTAL
Reviewed By: javache
Differential Revision: D40259791
fbshipit-source-id: 63eee9381d197a1e38ae663b2158436ff135c0e1
Summary:
Change version of rn apps following xcode settings.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[iOS][Fixed] - Automatically following version on xcode.
Pull Request resolved: https://github.com/facebook/react-native/pull/34919
Reviewed By: cipolleschi
Differential Revision: D40340271
Pulled By: motiz88
fbshipit-source-id: a2263a8c7a70847fe6fcedcd82c5109100aafde6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34967
This diff is a preparatory work for publishing artifacts on Maven Central.
What it does is:
1. It sets up all the 3 modules (react-native, hermes-engine, external-artifacts) for publishg
2. Adds coordinates to publish on the Snapshot repository
3. Adds support for appendign -SNAPSHOT version if invoked with `-PisNightly=true`
4. Configures GPG signing of artifacts.
I haven't touched the CircleCI and JS code yet. I'll do it in another diff.
Changelog:
[General] [Changed] - Setup publishing for Snapshot and Stable on Maven
Reviewed By: mdvacca, cipolleschi
Differential Revision: D40146212
fbshipit-source-id: 9321e16f6c18b35bc3ae785749d613085c56e7bc
Summary:
D31464478 enabled clang-format by default across projects, but opted out directories with a lot of formatting errors. This removes the opt-out, so clang-format is run in that directory as well.
Changelog:
[Internal][Changed] - Remove clang-format opt-out for Libraries
Reviewed By: lunaleaps
Differential Revision: D40310275
fbshipit-source-id: abe154ab466798fbfa010364a3627f40ca18b179
Summary:
Remove old `__offline_mirrors__` from `.gitignore`.
This directory is not synced to GitHub.
Changelog: [Internal]
Reviewed By: fbmal7
Differential Revision: D40245262
fbshipit-source-id: ccc93ea4cb5729432f590f78e463b14ba6e78b22
Summary:
Update RNTester Podfile.lock after running `pod install` with Hermes enabled, which is the default in open source.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D40197412
fbshipit-source-id: ce57d204b704fda85cae7f2966e479e80db25e1b
Summary:
This adds the `destructuredArrayIgnorePattern` rule [recently introduced in `typescript-eslint`](https://github.com/typescript-eslint/typescript-eslint/issues/4691), making underscored identifiers in array destructurings no longer an error, e.g.
```js
const [state, _dispatch] = useContext(MyContext);
```
would be acceptable if `state` is used.
## Changelog
[General] [Added] - Add destructuredArrayIgnorePattern to eslint config
Pull Request resolved: https://github.com/facebook/react-native/pull/33552
Test Plan: Install the `react-native-community/eslint-config` package and test the example.
Reviewed By: lunaleaps, cipolleschi
Differential Revision: D40166101
Pulled By: ryancat
fbshipit-source-id: 1e30297bf40d65e09682c4f9f3b3dd432ba5310e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34886
## Reduced cache size
The `build_hermes_macos` job can spend over 20 minutes restoring cached build artifacts (over 5 GB), when only `build_macosx` and `destroot` are required to be cached: `build_macosx` as it may contain a pre-built `hermesc` from previous builds, and `destroot` which contains the artifacts for previous iOS/macOS builds.
This is the `build_hermes_macos` Restore Cache step, before the changes in this diff:
```
Found a cache from build 308044 at v1-hermes-build_hermes_macos-debug-PEiMHp9XQ13KtYFQMKoT27DmHkkoxOi_PJUyW7PacZE=
Size: 5.2 GiB
Cached paths:
* /Users/distiller/react-native/sdks/hermes/build_host_hermesc
* /Users/distiller/react-native/sdks/hermes/build_iphoneos
* /Users/distiller/react-native/sdks/hermes/build_catalyst
* /Users/distiller/react-native/sdks/hermes/build_iphonesimulator
* /Users/distiller/react-native/sdks/hermes/build_macosx
* /Users/distiller/react-native/sdks/hermes/destroot
Downloading cache archive...
Unarchiving cache...
```
Size: 5.2 GiB
Time to restore cache: 183s
This is the `build_hermes_macos` Restore Cache step, after the changes in this diff:
```
Found a cache from build 310128 at v2-hermes-build_hermes_macos-debug-e7WmoA0+mfveXq1zsMYpgR6BYqVuuDjmVeLLyjqPJWk=
Size: 1.3 GiB
Cached paths:
* /Users/distiller/react-native/sdks/hermes/build_macosx
* /Users/distiller/react-native/sdks/hermes/destroot
Downloading cache archive...
Unarchiving cache...
```
Size: 1.3 GiB
Time to restore cache: 42s
**This is a size reduction of 75%, and execution time reduction of 77%.**
This savings will apply to every workflow that runs afterwards until the Hermes cache is invalidated due to a new commit landing in `facebook/hermes`.
## Added `export_hermesc`
As part of the work mentioned above, a reusable `export_hermesc` command was added, which will export hermesc for use in downstream steps. Either of the macOS or iOS build scripts will generate this binary. As we now only cache the macOS build dir, that version is loaded from cache by default if available:
- If the cache contains hermesc, both the macOS and iOS builds will use it.
- If the cache does not contain hermesc, then the iOS job will use the hermesc that was built by the macOS job previously.
- The `export_hermesc` command will work regardless of the order of the Hermes build scripts
## Refactoring of magic strings into reusable yaml references
Some additional changes to the Circle CI config were done in order to reduce repetition of artifacts/cache paths that are re-used across workflows.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D40153737
fbshipit-source-id: b9f07302ccc9bac1ce72a09b944d3210e6db2ec1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34944
In react-native-windows, the ability to detect a press event on a virtual span is dependent on setting a native only `isPressable` prop.
This modifies the Text component to include `onPressIn` and `onPressOut`. As a side-effect, this will also lazily initialize the pressability config when `onPressIn` or `onPressOut` only is set.
Changelog:
[General][Fixed] - Pressability for text with only `onPressIn` / `onPressOut` props
Reviewed By: yungsters
Differential Revision: D40264432
fbshipit-source-id: 583b210127d8f020ad98030d4a5381c302e88d2a
Summary:
Adds changelog for new patch.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - add changelog entry for 0.70.3
Pull Request resolved: https://github.com/facebook/react-native/pull/34958
Test Plan: N/A
Reviewed By: lunaleaps
Differential Revision: D40302608
Pulled By: dmytrorykun
fbshipit-source-id: eebc98e0fccd61260fac6ff5ea9a83b0d81abfbf
Summary:
This moves configureDevPorts inside AgpConfiguratorUtils, and makes it use
finalizeDsl. This removes a deprecated API `BaseVariant` which is causing a
build warning for all the users + it's a step towards making RNGP fully variant aware.
Changelog:
[Internal] [Changed] - Move configureDevPorts inside AgpConfiguratorUtils and use finalizeDsl
Reviewed By: cipolleschi
Differential Revision: D40139558
fbshipit-source-id: 1e5b8661b8d223a603f8ab5d160edd2133304d92
Summary:
I'm suppressing this deprecation on `reactRoot` as it's unnecessary.
It creates noise and the usage is actually legit.
Changelog:
[Internal] [Changed] - Suppress deprecation on reactRoot passed as deprecatedReactRoot
Reviewed By: cipolleschi
Differential Revision: D40139555
fbshipit-source-id: f3755f020ab1dceb17d0fdd18c6c8e374c87c60c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34943
The RCTAppDelegate class is the new way we have to encapsulate logic we don't want to leak to the average user.
However, some advanced users, like Expo users, may need more options to customize their setup.
This Diff provides more methods to extend the AppDelegate.
## Changelog
[iOS][Added] - Add more extension points for RCTAppDelegate
Reviewed By: cortinico
Differential Revision: D40262513
fbshipit-source-id: 9365a51d938a586b1508233bfa63693cf9aebf7a
Summary:
Changelog
[General][Internal] - Make react-native-codegen work on Windows within BUCK
This makes react-native code-gen work on Windows - by basically filling in some necessary windows commands for the existing bash/shell ones
Reviewed By: cortinico, cipolleschi
Differential Revision: D40268750
fbshipit-source-id: 0db7597999ec8108babf56abed436f6dc7789cce
Summary:
I'm cleaning up the Buck setup in the New App template. It hasn't been touched since 2018 and is currently not working, but will end up being propagated in user space.
This is also affecting the Gradle setup as there is a need to have an extra task just for Buck.
I doubt anyone is using this at this stage. We can get back to it or have a dedicated guide for users that are willing to use it.
## Changelog
[Android] [Remove] - Cleanup Buck usages from New App Template
Pull Request resolved: https://github.com/facebook/react-native/pull/34881
Test Plan: Testing was missing on this API so there is nothing to test here
Reviewed By: cipolleschi
Differential Revision: D40142064
Pulled By: cortinico
fbshipit-source-id: 6c65e1030bf3fe1603bfb7d486f8f3fd7d254126
Summary:
This PR extracts the content of the codegen case `'Stringish'` into a single `emitStringish` function inside the `parsers-primitives.js` file and uses it in both Flow and TypeScript parsers as requested on https://github.com/facebook/react-native/issues/34872. This also adds unit tests to the new `emitStringish` function.
## Changelog
[Internal] [Changed] - Extract the content of the case 'Stringish' into a single emitStringish function
Pull Request resolved: https://github.com/facebook/react-native/pull/34936
Test Plan:
Run `yarn jest react-native-codegen` and ensure CI is green

Reviewed By: cipolleschi
Differential Revision: D40255921
Pulled By: rshest
fbshipit-source-id: 9c08f81f12c93995bb6ba032fabcd6451b8dc7c1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34949
Changelog: [Internal]
Currently, link groups depend on supermodules to generate. To continue supporting link groups while allowing us to migrate off supermodules, we'll add a talkios_link_group label on all talkios targets to persist the current hierarchical information.
Reviewed By: jkeljo
Differential Revision: D40268275
fbshipit-source-id: a82e969e7cb8ec167489be73dc9bc71cf8ec37e1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34884
Xcode 14 is now stable. Updating CI to use latest Xcode command line tools.
The Circle CI 14.0.1 container ships with Ruby 2.7.6 and CocoaPods 1.11.3, see full manifest here: https://circle-macos-docs.s3.amazonaws.com/image-manifest/v8824/index.html
Changelog: [iOS][Changed] Bump to Ruby 2.7.6 and CocoaPods 1.11.3
Reviewed By: mdvacca
Differential Revision: D40148796
fbshipit-source-id: b1eab68e159ec3237ff2ef596163b73fc1e511e4
Summary: Currently, link groups depend on supermodules to generate. To continue supporting link groups while allowing us to migrate off supermodules, we'll add a talkios_link_group label on all talkios targets to persist the current hierarchical information.
Reviewed By: jkeljo
Differential Revision: D40268252
fbshipit-source-id: 9211add120448e95f892d36a85583c700b2ec9a0
Summary:
As identified in https://github.com/facebook/react-native/issues/34350, modals do not honor the system's status bar colors because they may not be set by the deprecated `systemUiVisibility` flags. Unless `android:windowLightStatusBar` is set to true, the default flag is a zero-integer (a.k.a. "dark mode", where the icons show as white). Since the `StatusBar` component is using the new `setSystemBarsAppearance` API, the ModalHost should also infer its status bar settings from the same API.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Android] [Fixed] - Fixed an issue on Android API 31+ where modals would turn status bar icons white by default
Pull Request resolved: https://github.com/facebook/react-native/pull/34899
Test Plan:
- On a screen with the `StatusBar` bar style set to `dark-content`, the modal also uses white icons
- On a screen with the `StatusBar` bar style set to `light-content`, the modal also uses black icons
### Preview
Here, I change the `barStyle` from `light-content` to `dark-content` and demonstrate that the proper attributes are retained. The "Before" is a recording from `main` and the "After" is this branch. Notice how in "Before", the status bar is always turning the icons white when the modal opens.
|Before|After|
|-|-|
|||
## Other considerations
There's some argument towards removing this check entirely--the status bar appearance should be derived from the theming and/or the parent activity's settings, thereby removing the need to apply separate styling
Reviewed By: lunaleaps
Differential Revision: D40243122
Pulled By: lunaleaps
fbshipit-source-id: ffa56c7d6a1906f89658f95a12f6bf1cefd5be8e
Summary:
Add a `DevSupportManager` that can be used for performance testing. This `DevSupportManager` allows the inspector connection to be established, but leaves everything else disabled.
Previously, if Developer Support was enabled on a release build, the application would present an error as it unsuccessfully attempted to use the bridge dev support manager.
With this change, if a developer opts into developer support in a release build (i.e. `enableOnCreate == true && ReactBuildConfig.DEBUG == false` in the `DevSupportManagerFactory`), the `PerfTestDevSupportManager` will be used, allowing use of things like heap size reporting and the sampling profiler.
(`enableOnCrease` indicates the development mode setting: https://www.internalfb.com/code/fbsource/[6b8a941fdf2a0fd58d9db36f5a59fa5fb53ad2df]/xplat/js/react-native-github/ReactAndroid/src/main/java/com/facebook/react/ReactInstanceManager.java?lines=259)
Changelog: [internal]
Reviewed By: rubennorte
Differential Revision: D39468561
fbshipit-source-id: cb3c82e7a8ee74316b23f57dc8d0cc6e5cdb18a7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34927
The changes made in D36902220 (https://github.com/facebook/react-native/commit/a04195167bbd8f27c6141c0239a61a345cac5a88) and D36958882 (https://github.com/facebook/react-native/commit/d8c25ca1b62df2b93f70bbb1f7b379643ab9ccd4) attempted to reduce flickering and consistency issues when using Animated.
In the old renderer, we explicitly reset all animated props, and wait for the subsequent React commit to set the props to the right state, but if `initialProps` are used, the React reconciliation may not be able to identify the prop-update is required and will leave out the value. This behaviour is different in the new renderer, where we do not explicitly `restoreDefaultValues` on detaching the animated node, and instead rely on the latest state being correct(?).
Changelog:
[General][Fixed] Stop styles from being reset when detaching Animated.Values in old renderer
Fixes#34665
Reviewed By: rshest
Differential Revision: D40194072
fbshipit-source-id: 1b3fb1d1f4a39036a501a8a21e57002035dd5659
Summary: Changelog: [Internal] Adjust styling so test works on mobile screen and verified Android is passing
Reviewed By: mdvacca
Differential Revision: D40247320
fbshipit-source-id: c39bff510900393af7696e92e1f846999eb0ced3
Summary:
Add TurboModule code-gen support for macOS and Windows
Changelog
[General][Internal] - Add TurboModule code-gen support for macOS and Windows
Reviewed By: javache
Differential Revision: D40140890
fbshipit-source-id: 60d235f16af590c07abddba3d289efa7d1d973c0
Summary:
Adds changelog for new patch.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - add changelog entry for 0.68.4
Pull Request resolved: https://github.com/facebook/react-native/pull/34924
Test Plan: N/A
Reviewed By: rshest
Differential Revision: D40226689
Pulled By: rshest
fbshipit-source-id: 2c60533fb9ed40a7b40dc8385482d98cd77fd309
Summary:
This PR reduces code duplication by extracting all the errors in the module/errors into a single parsers/errors.js file. All the errors must drop the corresponding Flow or Typescript token in the name and take an extra language parameter in the constructor. Also, rename the hasteModuleName parameter to nativeModuleName.
Part of https://github.com/facebook/react-native/issues/34872
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - Extract all the parsers errors in the module/errors into a single parsers/errors.js file
Pull Request resolved: https://github.com/facebook/react-native/pull/34896
Test Plan:
run ```yarn jest react-native-codegen``` and check all test case passes.
<img width="793" alt="image" src="https://user-images.githubusercontent.com/34857453/194545577-cf2d980b-b6b7-4f93-b13e-2e45d92dceab.png">
Reviewed By: rshest
Differential Revision: D40176486
Pulled By: rshest
fbshipit-source-id: b33ae49b2bcceeffd307370ee5e3b24a9e1bb340
Summary:
A moderate vulnerability was found in all versions of `ws` below 7.4.6 June last year. React native current uses v6.1.4 which is susceptible to it, fortunately this security fix has been backported to v6.X.X and we don't need to upgrade any major versions/worry about breaking changes. This PR bumps `ws` to 6.2.2 ([CHANGELOG](https://github.com/websockets/ws/releases/tag/6.2.2)) due to this ReDoS vulnerability
More information about this vulnerability can be found here -> https://github.com/advisories/GHSA-6fc8-4gx4-v693
Closes https://github.com/facebook/react-native/issues/31646
## Changelog
[Internal] [Security] - Bump ws to 6.2.2 due to ReDoS vulnerability
Pull Request resolved: https://github.com/facebook/react-native/pull/34759
Test Plan:
Ensure WebSocket tests are working as expected
Tested HMR working on Twilight
| iOS | Android |
| https://pxl.cl/2g70M | https://pxl.cl/2g70V |
Reviewed By: hramos, cortinico
Differential Revision: D39722905
fbshipit-source-id: 12088ab5ea26d904675de484e2014949d6696465
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34911
This diff adds the Same component with state added in the previous diff for iOS
## Changelog
[Android][Added] - ComponentWithState
Reviewed By: cortinico
Differential Revision: D40108233
fbshipit-source-id: b5bd1d1bdd7053920f737772c85034e4c5aed26a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34909
This Diff introduces a Sample component in RNTester which uses the NativeState to load some images.
It is an example on how to use CustomNativeState
In this first diff, I focused on the iOS side of things. The next diff will make this work with Android.
## Changelog
[iOS][Added] - Introduce sample component which work with the native state.
Reviewed By: cortinico
Differential Revision: D39884926
fbshipit-source-id: 9323d751fd06a1bb8ff93af836d97010c2095833
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34910
This Diff adds supports on the CustomState generation for ImageSource and ImageRequests, to enable NativeComponents to use the ImageSource loading provided by React Native.
To achieve this, I also had to fox some errors in the imports and to introduce some functions to decorate parameters.
This diff also introduces the tests for thise additional types in both generators and parsers.
## Changelog
[General][Added] - add support for ImageSource and ImageRequest in the State.
Reviewed By: cortinico
Differential Revision: D39884889
fbshipit-source-id: ae3d2d51dfe6a4fe688dc78fec83f428beb8d443
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34796
This diff introduces the generation of custom native states using basic types as we do with the Props.
To make it work, the custom types are already writte in the Props.h file, therefore the State.h file must import that other file to have access to the required types.
This diff adds and updates the tests for the State.
## Changelog
[General][Added] - Generate custom Native State
Reviewed By: cortinico
Differential Revision: D39816763
fbshipit-source-id: 42d1aa9a6df23145f4a46ae8ccfb43d81fa651fb
Summary:
ios debug archiving build will generate ip.txt that will leak metro server address for other people testing.
moreover, it will slow down launch time for metro server availability to wrong address.
this pr introduce `SKIP_BUNDLING_METRO_IP` to prevent ip.txt generation.
## 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] [Changed] - introduce SKIP_BUNDLING_METRO_IP to skip ip.txt generation
Pull Request resolved: https://github.com/facebook/react-native/pull/31829
Test Plan:
### Classic build will generate ip.txt
```sh
xcodebuild -workspace RNTesterPods.xcworkspace -scheme RNTester -configuration Debug -sdk iphoneos -destination 'generic/platform=iOS'
find $HOME/Library/Developer/Xcode/DerivedData/RNTesterPods-* -name 'ip.txt'
```
this will find the ip.txt
### Specify `SKIP_BUNDLING_METRO_IP=1` will not generate ip.txt
```sh
SKIP_BUNDLING_METRO_IP=1 xcodebuild -workspace RNTesterPods.xcworkspace -scheme RNTester -configuration Debug -sdk iphoneos -destination 'generic/platform=iOS'
find $HOME/Library/Developer/Xcode/DerivedData/RNTesterPods-* -name 'ip.txt'
```
this will NOT find the ip.txt
Reviewed By: hramos
Differential Revision: D40095785
Pulled By: hramos
fbshipit-source-id: 0c913f078e683879e07e9ce3306e899d631206b2
Summary:
This PR is a task from https://github.com/facebook/react-native/issues/34872
_Extract the modules/utils.js from the flow and typescript folders in a shared parsers-commons.js file. Then, have the two parsers use the same wrapModuleSchema function for modules._
(`wrapModuleSchema` is a copy-paste mistake, in this case it is `wrapNullable` and `unwrapNullable`)
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - Extracts Codegen's modules/utils.js files from the flow and typescript folders in parsers-commons
Pull Request resolved: https://github.com/facebook/react-native/pull/34898
Test Plan:
I ran `yarn jest react-native-codegen`:
<img width="775" alt="Capture d’écran 2022-10-07 à 21 29 48" src="https://user-images.githubusercontent.com/17070498/194639515-a446c2cf-daf3-43a1-9833-cd546ca5865e.png">
Reviewed By: cipolleschi
Differential Revision: D40193740
Pulled By: cipolleschi
fbshipit-source-id: 02cbacc215fe5dd9bdd0839d8796587ab2821906
Summary:
[Changelog]: Internal
integrate the offscreen component when we render an application that is configured to do so
Reviewed By: rubennorte
Differential Revision: D39458472
fbshipit-source-id: 9bd492ca258723cb9cf0b7e4f6c9b0005554e91e
Summary:
Changelog: [RNTester][Internal] - Add "PointerMove Between" platform test
This diff adds another port of a web platform test which verifies the event order when a hoverable pointer moves between elements.
Reviewed By: lunaleaps
Differential Revision: D40164303
fbshipit-source-id: 12f39dfcf7a1a4acabfd762185bc2227451b1057
Summary:
Changelog: [iOS][Internal] - Get the "move across" pointer event test passing on iOS
After implementing the "MoveAcross" pointer event test it indicated that the implementation, at least on iOS, was firing the events in an incorrect order. Extrapolating from the test's expectations all the events related to entering/leaving/ect. should fire before the down/move/up instead of placing those down/move/up/ect. between the leave and enter events.
Reviewed By: lunaleaps
Differential Revision: D39221372
fbshipit-source-id: 31b7292e524a9ec9d998e658b7d0ef3ebc825d68
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34875
Create common script for generating a Hermes tarball after Hermes is built from source.
Use after building Hermes from source to create a tarball of the resulting build artifacts. The path to the tarball can be passed to CocoaPods via a `HERMES_ENGINE_TARBALL_PATH` envvar in order to use these pre-built Hermes artifacts when installing the `hermes-engine` pod with `pod install`.
Use in Circle CI when creating a Hermes tarball for caching and for use in stable React Native releases.
Usage:
```
pod install
# When Hermes is built from source via CocoaPods, the build artifacts will be located in the Pods directory for hermes-engine
node ./scripts/hermes/create-tarball.js \
--inputDir ./sdks/hermes \
--buildType Debug \
--releaseVersion 1000.0.0 \
--outputDir .
```
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D40124378
fbshipit-source-id: f9712e87526ccc737afac4599b0ab0a7bb3f3956
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34885
We use workflows extensively in Circle CI, so caching a git checkout should help speed up tests when downstream jobs need to checkout the repository. In the current configuration, the Windows job is most likely to run and write to the .git cache first, which results in permission issues when the .git cache is loaded onto macOS or linux hosts.
By splitting the cache by architecture, we may lose on some reusability across jobs with distinct architectures, but it ensures we avoid cross-platform permission issues.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D40150781
fbshipit-source-id: 4a4b2a4da5e20f754b72db0c9852c7c1616b610c
Summary:
A few fixings to make `yarn jest react-native-doegen` works on Windows:
- ~~Add a `.gitignore` file to tell git not to track generated/temporary files.~~
- There is no `rm` on Windows, change it to `rimraf`.
I have been using it in the last 3 months and it works perfectly on Windows, otherwise I could not even build the code in my laptop.
## Changelog
[General] [Changed] - Make `yarn` and `yarn jest react-native-codegen` works on Windows with git
Pull Request resolved: https://github.com/facebook/react-native/pull/34854
Test Plan: `yarn jest react-native-codegen` passed
Reviewed By: cortinico
Differential Revision: D40059524
Pulled By: cortinico
fbshipit-source-id: e3cde2506c7d18c2b580099257637b90f4cb328c
Summary:
On some platforms, when two inputs are in a scrollview, trying to switch focus to another textinput doesn't work and requires two taps. This is because from `_handleTouchEnd` we blur the currently focused input, even if that input had only just become focused from the same touch event. Instead, only blur when the event did not target the current textinput.
Changelog: [Android][Fixed] TextInputs may not get focused when switching inputs in a ScrollView
Reviewed By: jehartzog
Differential Revision: D40159333
fbshipit-source-id: 388f85dff5ac8f24d7e2590e887635391c52d72f
Summary:
Replaced import cycle with Flow type cycle, which will remove the warnings from Metro.
Changelog: [internal]
Reviewed By: motiz88
Differential Revision: D40177136
fbshipit-source-id: e63986d8918e48e8c4cd8014d306d68fcbd2cf10
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34897
This [commit](https://github.com/facebook/react-native/commit/7680bdeb4f96a8092393372a59c77a9d7b729cae) added the possibility to create Codegen specs that are platform specific.
However, it also modifies how the codegen is invoked and we need to publish a new version of the `react-native-codegen` package on NPM before we can use that feature.
## Changelog:
[General][Fixed] - Remove usage of the codegen spec filtering until we publish a new version of the codegen.
Reviewed By: robhogan
Differential Revision: D40176447
fbshipit-source-id: 20be630dec3dcd7efb9fd510c6cf9f2c161f906a
Summary:
Noticed that we were using a different tag for each pointer event observed (and that weren't clearing these properly when recyling views).
Each of these tags is a hashmap entry and a boxed boolean, so we can do much better by just using a single (boxed) integer.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D40077519
fbshipit-source-id: 130e78c3641eaedfa8787644b98763fd4367bc27
Summary:
This diff helps the library maintainer to keep their spec file platform specific if some specs make no sense in one platform or in the other.
We are filtering the spec files when we need to create the Schema.
The diff modifies also the call sites in the `scripts` (for iOS) and in the `gradle-plugin` (for Android).
It also adds tests for the new functions in the CLI.
The change is completely additive and it should not change any pre-existing behaviour.
## Changelog
[General][Added] - Add support for platform-specific specs
Reviewed By: cortinico
Differential Revision: D40008581
fbshipit-source-id: b7fcf6d38f85fe10e4e00002d3c6f2910abdbe35
Summary:
`TSParenthesizedType`, `TSUnionType`, `TSNullKeyword`, `TSUndefinedKeyword`, `TSVoidKeyword` etc are repeatly processed in so many places. In this change I put them in a new file `parseTopLevelType.js`, and everyone call that file, all repeat implementation are deleted.
The `parseTopLevelType` function will look into a type consisted by the above types in any possible combination (but still very easy to do), and tell you if a type is nullable, or if there is a default value, and what is the real type with all noises removed.
Array types and union types are processed in component twice, for property of array, and property of nested arrays (`componentsUtils.js`). They are extracted into single functions.
## Changelog
[General] [Changed] - Refactor in turbo module TypeScript codegen: process `(T)`, `T|U`, `T|undefined` and related stuff in a central place
Pull Request resolved: https://github.com/facebook/react-native/pull/34814
Test Plan: `yarn jest react-native-codegen` passed
Reviewed By: yungsters, sammy-SC
Differential Revision: D40094373
fbshipit-source-id: f28e145bc4e7734be9036815ea425d820eadb8f0
Summary:
This change will expose the rrc_image module to be consumed via Prefab by user projects. This is needed as part of a change of the codegen to support custom states.
Changelog:
[Internal] [Changed] - Expose rrc_image to consuming build
Reviewed By: cipolleschi
Differential Revision: D40098541
fbshipit-source-id: 2e07d8b19f53ba93920009603c95a43b01f131eb
Summary:
This change will expose the `react_render_imagemanager` module to be consumed via Prefab by user projects. This is needed as part of a change of the codegen to support custom states.
Changelog:
[Internal] [Changed] - Expose react_render_imagemanager to consuming build
Reviewed By: cipolleschi
Differential Revision: D40022929
fbshipit-source-id: ece47503b11a641067ae6db82f1d69b244c9c5be
Summary:
react-native-windows builds treat a lot of c++ compiler warnings as errors. Including ones that cause value truncation when assigning `size_t` values to an `int`.
This fixes the compiler warning, by using `size_t` as the type for `i`, which matches `size`. I then modified the loop to avoid the value underflow that occurs when decrementing an unsigned zero value.
## Changelog
[Internal] [Changed] - Fix compiler warnings around mixing int and size_t usage in unsafe ways
Pull Request resolved: https://github.com/facebook/react-native/pull/34889
Test Plan: This code change was made in react-native-windows when integrating latest react-native changes. -- our fabric implementation was able to run through this code without any issues.
Reviewed By: mdvacca
Differential Revision: D40158306
Pulled By: rozele
fbshipit-source-id: b6858cb953635b37fd63a88ed1a372eb3dc394f7
Summary:
Create documentation to write C++ ViewManagers in React AR apps
changelog: [internal] internal
Differential Revision: D40119174
fbshipit-source-id: edce0e6b226a30007c39f924b5896fa2267e98b7
Summary:
This diff further simplifies the New App Template by removing the
buildConfigFields for both Hermes and New Architecture with the React Native Gradle Plugin.
Changelog:
[Android] [Changed] - Let RNGP set buildConfigFields for New Architecture and Hermes
Reviewed By: cipolleschi
Differential Revision: D40139559
fbshipit-source-id: 202b6ac9c4c036a026a2ff3e8279087ffd363eaa
Summary:
I fixed the TypeScript definitions for Systrace in https://github.com/facebook/react-native/commit/a0f56adb07dd21ee69ad1942e9d485586f1c3ec0, but I forgot to update the TypeScript tests that were outdated. This diff fixes those tests and CI in OSS.
Changelog: [internal]
Reviewed By: cipolleschi
Differential Revision: D40141920
fbshipit-source-id: f73501450af0be6b0b6f836b9a774abb1fa4f620
Summary:
This change encapsulates all the NDK configuration logic inside the React Native
Gradle Plugin. The changes are additive so that the user can still specify a
custom configuration if they wish.
So far I've applied the changes to RN Tester. Changes to the template require a
bump of the Gradle Plugin NPM package.
Changelog:
[Android] [Changed] - Hide the C++/Cmake configuration from user space inside the framework
Reviewed By: cipolleschi
Differential Revision: D40139557
fbshipit-source-id: 013220695791e3d0d458e118de16953e0545c3de
Summary:
We're currently using `global.__RCTProfileIsProfiling` to determine if the app is currently profiling to forward calls to Systrace to native.
We're defining `global.__RCTProfileIsProfiling` when the React Native runtime is initialized (which, in most cases, is on startup or shortly after startup), which means that enabling profiling in the middle of the session doesn't set this value to `true`.
This diff adds a new method (in the global scope for now, as the rest of bindings for Systrace) to check if we're profiling in real time. This call should be very cheap as it's implemented as a JSI function that calls into a C++ API directly.
Changelog: [internal]
Reviewed By: rshest
Differential Revision: D40095840
fbshipit-source-id: e7030d6370ecb43d56478b03cb63806ffa0cd0cf
Summary:
It doesn't make sense to have checks for whether we're profiling or not in `__DEV__` blocks, where we shouldn't be profiling in the first case.
We're going to remove the `global.__RCTProfileIsProfiling` flag in favor of a function that checks if we're profiling in real time (as opposed to checking if we're profiling only on startup, which is what that value does). This is just to make that migration easier without having to migrate callsites that are bad practices anyway.
Changelog: [internal]
Reviewed By: rshest
Differential Revision: D40095841
fbshipit-source-id: ba6cdf4bef8a4c169c50a974671c21144ccee92b
Summary:
This refactors the systrace module to:
1) Migrate it to ESM
2) Fix the typing of certain parameters (e.g.: `eventName` and `cookie` shouldn't be optional)
2) Fix TypeScript definitions
3) Add inline documentation for methods
4) Add args (metadata) to all methods where it's supported in fbsystrace (`endEvent` and `endAsyncEvent`).
5) Make `setEnabled` a no-op. The only place where this method is called is from native, when starting a profile session. The problem is that implementation for Systrace in OSS (https://github.com/facebook/react-native/blob/main/ReactAndroid/src/main/java/com/facebook/systrace/Systrace.java#L40-L42) doesn't support listeners, so this wouldn't work correctly there. It also doesn't get called with Venice, so instead of fixing it for Venice with the same Meta-internal behavior, I decided to fix it for everyone with the synchronous method.
I'm not considering this a change in the public API of systrace because this module has been broken in OSS for ages and I'm assuming no one's using it at this point.
Changelog: [internal]
Reviewed By: rshest
Differential Revision: D40095842
fbshipit-source-id: fee41b2b7ae23aefe059e390c55d139db75247c5
Summary:
This moves the prefab/pickFirst configuration from the user's
build.gradle to the React Native Gradle Plugin.
As this configuration is entirely under our control, is safe
to assume users won't need to tweak it (e.g. we control which
libraries are built, etc.).
Changelog:
[Android] [Changed] - Encapsulate the prefab configuration for consumers
Reviewed By: cipolleschi
Differential Revision: D40094691
fbshipit-source-id: d1510a0a382d26e94e3d01f30661af39f7bedf52
Summary:
I'm adding a series of excludes to the `GenerateCodegenSchemaTaskTest`.
The reason is that RN Tester is setting `packages/rn-tester` as the root of the
specs as they're not isolated.
This is causing the Gradle task to crawl inside the `android/app/build` folder
where we store sourcemaps and other files that have .js files. As those files
gets updated when you build, the codegen task gets invalidated over and over
and Gradle is firing warning about it.
Changelog:
[Internal] [Changed] - Exclude generated folders from the GenerateCodegenSchemaTask
Reviewed By: cipolleschi
Differential Revision: D40098418
fbshipit-source-id: fcffbc73e8258c4e9eefda062e1fad77be650002
Summary:
changelog: [internal]
RuntimeScheduler's callbacks previously did not pass down argument `didUserCallbackTimeout`. This was intentionally left out because React team intended to remove it. But, as it turns out, it was not removed and it is needed for Offscreen to not enter infinite render loop. In React, it is used here: https://github.com/facebook/react/blob/main/packages/react-reconciler/src/ReactFiberWorkLoop.new.js#L1022-L1028
Reviewed By: ryancat
Differential Revision: D40060377
fbshipit-source-id: c45719fbbd0275ab2bcf9a2bbf0191aaa96010cc
Summary:
Fixes Xcode release builds when Hermes is enabled.
The Hermes debugger is loaded by the Hermes executor only if HERMES_ENABLE_DEBUGGER is defined. The hermes-engine Pod would set `HERMES_ENABLE_DEBUGGER=0` in release builds, but of course this would satisfy the HERMES_ENABLE_DEBUGGER ifdef check, leading to build time issues due to missing `hermes::debugger` symbols.
Now, both the `hermes-engine` and `React-hermes` pods only set `HERMES_ENABLE_DEBUGGER=1` in debug builds. No gcc preprocessor definition is added by these pods in release builds.
Changelog:
[iOS] [Changed] - Do not load Hermes inspector in release builds
Reviewed By: cipolleschi
Differential Revision: D40077503
fbshipit-source-id: dd9ce148e8521fc4e43e47e90f29ba8f7c9b7e4a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34869
Changelog: [Internal]
This merges all instances of `enablePropIteratorSetter` into a single one.
Both `AccesibilityProps` and `BaseTextProps` had their own instances if it, which is now redundant.
Reviewed By: cipolleschi
Differential Revision: D40062555
fbshipit-source-id: b6ccf5a9538612dd731a6f9c4eaceeebcb6d95be
Summary:
Automation tests were hitting issues with view recycling enabled because we use the main tag field to lookup views, and not properly resetting it when recycling.
Changelog: [Internal]
Reviewed By: jehartzog
Differential Revision: D40076594
fbshipit-source-id: 5f518b979a23562f7e7fc8271488678e78f50e91
Summary:
This PR renames ` hermes-inspector-msggen` to `react-native/hermes-inspector-msggen`, moves it to `packages/hermes-inspector-msggen` and makes the package private as part of RFC480.
Related to https://github.com/facebook/react-native/issues/34692
## Changelog
[General] [Changed] - Move and rename `hermes-inspector-msggen` to `react-native/hermes-inspector-msggen`
Pull Request resolved: https://github.com/facebook/react-native/pull/34850
Test Plan: run `sh ReactCommon/hermes/inspector/tools/run_msggen`
Reviewed By: mattbfb
Differential Revision: D40060406
Pulled By: cortinico
fbshipit-source-id: e018fd88e8374a69fbd8737fbb9abe7565d4a003
Summary:
Adds changelog for new patch.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - add changelog entry for 0.70.2
Pull Request resolved: https://github.com/facebook/react-native/pull/34859
Test Plan: N/A
Reviewed By: NickGerleman
Differential Revision: D40056094
Pulled By: NickGerleman
fbshipit-source-id: 1e833b63080351c66dafc4e43f3681220a9738eb
Summary:
Add explicit annotations to useCallback as required for Flow's Local Type Inference project. This codemod prepares the codebase to match Flow's new typechecking algorithm. The new algorithm will make Flow more reliable and predictable.
Codemod command: `flow codemod annotate-use-callback`
drop-conflicts
bypass-lint
Changelog: [Internal]
Reviewed By: evanyeung
Differential Revision: D40079418
fbshipit-source-id: 59750a5d07b2ac1f440927794a7523682f048a5e
Summary:
Added a new job to testing RNTester app on both architectures
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Added] - Support both architectures to test RNTester iOS app
Pull Request resolved: https://github.com/facebook/react-native/pull/34864
Test Plan: CircleCI jobs
Reviewed By: cortinico, cipolleschi
Differential Revision: D40062371
fbshipit-source-id: 1a28890edc57b64232d647d85694b34d50a9cd64
Summary:
While working on https://github.com/facebook/react-native/pull/34513 I noticed that on main branch the versioning is not really consistent everywhere. So this PR is an attempt at realigning so that on the main branch, RN is 1000.0.0 everywhere - in a way, it's cleaning up the room for the monorepo work to go flawlessly).
It's just a pass of `node scripts/set-rn-version.js --to-version 1000.0.0`.
There's the small chance that some versions where kept to 0.0.0 on purpose (build tools are weird), so we might just have to close this off. No big deal :)
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - re-align version to be 1000.0.0 on main everywhere
Pull Request resolved: https://github.com/facebook/react-native/pull/34817
Test Plan: CI is green and when imported, nothing breaks.
Reviewed By: cortinico
Differential Revision: D39926953
Pulled By: cortinico
fbshipit-source-id: ff66530382f891e17c00b35edf97c03591b6a9a8
Summary:
This is a long time coming effort to improve the situation around the local e2e script that in the release crew: the current bash-based script is quirky at best, and what you end up generating as a sample project is not really a true sample project. This is where this PR comes in: it migrates the flow from `./scripts/test-manual-e2e.sh` to `yarn test-e2e-local <options>`.
Here's the current shape of the options:
```sh
Options:
--help Show help [boolean]
--version Show version number [boolean]
-t, --target [choices: "RNTester", "RNTestProject"] [default: "RNTester"]
-p, --platform [choices: "iOS", "Android"] [default: "iOS"]
-h, --hermes [boolean] [default: true]
```
The idea is to change it so that you can just run the script, and it will do that one specific thing "well", without the tester needing to do anything aside from actually testing the app once it's open.
Some of the key changes:
* tries to stick to the patterns of the other established *.js based scripts, in terms of tooling and approach (and even refactor parts that can be shared with other scripts) - like the android artifacts generation
* no need to start the android emulator on the side
* no need to start Metro on the side
* RNTester iOS will open up on the simulator (no Xcode open that then you need to press)
Things that still need work:
* see the #fixme and #todo in comments
* because we rely on exec, the output sent back is not formatted/shaped correctly so it's a bit more noisy/chaotic - but can't handle it right now because the package we use doesn't allow it - see https://github.com/shelljs/shelljs/issues/86
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - Migrate bash E2E local testing script to new JS based command
Pull Request resolved: https://github.com/facebook/react-native/pull/34513
Test Plan:
To test the script, you can run it passing the options showed above; this is the current situation:
* RNTester iOS Hermes ✅
* RNTester Android Hermes ✅
* RNTester iOS JSC ✅
* RNTester Android JSC ✅
* RNTestProject Android Hermes ✅
* RNTestProject iOS Hermes ✅
* RNTestProject Android JSC ✅
* RNTestProject iOS JSC ✅
Reviewed By: cortinico
Differential Revision: D39814692
Pulled By: cortinico
fbshipit-source-id: d4791798aaad764c6a3757269b7636f847ccf2ca
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34858
Changelog:
[iOS][Fixed] - Fix race condition in RCTLoggingTests integration tests
RCTLoggingTests work in the following way:
* Put a custom hook on logging (logging function) to intercept log messages
* Send several log messages via JS and see whether they hit the hook as expected
The problem with this approach was that there may be unexpected log messages, which squeeze inbetween the points of time when the hook was set and when the first message was sent.
There was a (now 6 years old!!!) fix to mitigate this problem, which was adding a lead pause of 2s to "make sure" that all the other possible log messages had been sent: https://github.com/facebook/react-native/pull/10568
That didn't actually guarantee fixing the problem in general, just partially mitigating it, as the race condition conceptually still remained there.
Here I take a different approach, which should guarantee that we skip all the rogue JS messages before we start sending and reading them on our own:
* Install the hook
* Log a "marker" message
* Pump the log until the marker appears - at this point we know that the hook has been definitely installed
Reviewed By: cipolleschi
Differential Revision: D40043442
fbshipit-source-id: b4aa617d27c2dcff26682dd72e47ec19cb0d11ca
Summary:
I'm handling this TODO i left to unbreak the CI.
We need to make sure all the autolinked libraries are getting the folly flags and other common flags propagated correctly.
## Changelog
[Internal] [Change] - Propagate common flag to autolinked libraries
Pull Request resolved: https://github.com/facebook/react-native/pull/34853
Test Plan: Will rely on a green CI
Reviewed By: cipolleschi
Differential Revision: D40055134
Pulled By: cortinico
fbshipit-source-id: fb9afab954ab402f6a3ab417aba934035580f936
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34843
We can now remove a lot of unnecessary code to copy .so
files around as they're consumed via prefab from :ReactAndroid
Changelog:
[Android] [Changed] - Cleanup the Android template after prefab support
Reviewed By: cipolleschi
Differential Revision: D40014642
fbshipit-source-id: 00e69ea62bdb4882b40b8b6f19cdf80235c847b5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34831
Historically we had to download an unzip the fbjni Android Archive to use it.
Here I'm updating the way how we consume to use prefab so we can remove a lot
of unnecessary configuration, also from the app template.
Changelog:
[Internal] [Changed] - Consume fbjni via Prefab
Reviewed By: cipolleschi
Differential Revision: D39964574
fbshipit-source-id: 1b18682c2b36aabb1fc1a3819ca09e575182eae4
Summary:
When building and using C # libraries,
EntryPointNotFoundException thrown from YGInteropSetLogger.
so, I added YOGA_EXPORT on YGInteropSetLogger.
X-link: https://github.com/facebook/yoga/pull/960
Reviewed By: yungsters
Differential Revision: D40027238
Pulled By: yungsters
fbshipit-source-id: 6af584a16e66a31c91374a1bb64434888762e3c8
Summary:
When I use libyogacore.so in other programming languages, it crash with message as
> Could not obtain symbol from the library: dlsym(0x20b84d220, YGConfigIsExperimentalFeatureEnabled): symbol not found
This function is defined as `WIN_EXPORT bool YGConfigIsExperimentalFeatureEnabled` in yoga.h, but is not defined using `YOGA_EXPORT` in yoga.cpp.
X-link: https://github.com/facebook/yoga/pull/1127
Reviewed By: yungsters
Differential Revision: D40024450
Pulled By: yungsters
fbshipit-source-id: f6f01eadccb13d593c68300059e96f4b0bbc9fb6
Summary:
Currently the `Content-type` is not defined and defaults to `text/plain`. This makes it more accurate.
## 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] - add `headers.Content-type` to `openFileInEditor` call
Pull Request resolved: https://github.com/facebook/react-native/pull/33517
Test Plan: - [x] in development trigger `openFileInEditor`, e.g. by pressing on a line in a stack trace -> code editor opens
Reviewed By: cipolleschi
Differential Revision: D40022413
Pulled By: cortinico
fbshipit-source-id: 00ad3cdcdd1f82436c04aed3643c9f0b55778592
Summary:
Currently, it is not clear how to run codegen tests in the OSS.
## Changelog
[General][Added] - Add instructions about how to add tests in the OSS
Reviewed By: cortinico
Differential Revision: D40020907
fbshipit-source-id: 073ec8bf08d2a9e8b26287763dd881371ecf561d
Summary:
There are two issues from nightly builds.
#### 1. `VERSION_NAME=1000.0.0-main` in _ReactAndroid/gradle.properties_
the solution is to remove unused _ReactAndroid/gradle.properties_ git revert when publishing package.
#### 2. `pod install` error from downloading hermes, e.g. the url is unavailable. `https://github.com/facebook/react-native/releases/download/v0.0.0-20221002-2027-2319f75c8/hermes-runtime-darwin-debug-v0.0.0-20221002-2027-2319f75c8.tar.gz`
fix _hermes-engine.podspec_ to support nightly build and build hermes from main branch.
## Changelog
[General] [Fixed] - Fix nightly build issues
Pull Request resolved: https://github.com/facebook/react-native/pull/34846
Test Plan:
1. i cannot fully test publish-npm.js workflow and it stops at `npm publish`. i can just check at this moment, the _ReactAndroid/gradle.properties_ is right.
2. create a `npx react-native init` project and `yarn add react-native@nightly`. patch `node_modules/react-native/sdks/hermes-engine/hermes-engine.podspec` and try `pod install`
Reviewed By: cipolleschi
Differential Revision: D40021649
Pulled By: cortinico
fbshipit-source-id: c9e2701e524f4b16eab6f2c72b5cfa34883082c3
Summary:
Currently the autorebase feature doesn't work because it fails the `if` validation due to how we distribute permissions.
For now I'm making this action less restricted. We can tweak it if we notice abuse.
Config now is the same as https://github.com/cirrus-actions/rebase
## Changelog
[Internal] - Make autorebase less restrictive
Pull Request resolved: https://github.com/facebook/react-native/pull/34848
Test Plan: Nothing to test
Reviewed By: cipolleschi
Differential Revision: D40022304
Pulled By: cortinico
fbshipit-source-id: 74270b47c61267484c073706fa900f22b3569a94
Summary:
Sync the changes in `types/react-native` https://github.com/DefinitelyTyped/DefinitelyTyped/pull/62394 to here as required by lunaleaps
## Changelog
[Internal] [Added] - Sync new changes in `types/react-native`
Pull Request resolved: https://github.com/facebook/react-native/pull/34794
Test Plan: Tested in `types/__typetests__/index.tsx`
Reviewed By: cortinico
Differential Revision: D39846101
Pulled By: cortinico
fbshipit-source-id: cebe62aa97f764d9a10c8371936870c515fb9be3
Summary:
This adds support for the `verticalAlign` style attribute, mapping the already existing `textAlignVertical` attribute as requested on https://github.com/facebook/react-native/issues/34425. This PR also updates the TextExample.android on the RNTester in order to facilitate the manual QA of this.
## Changelog
[Android] [Added] - Add support for verticalAlign style
Pull Request resolved: https://github.com/facebook/react-native/pull/34567
Test Plan:
1. On Android open the RNTester app and navigate to the Text page
2. Check the text alignment through the `Text alignment` section
https://user-images.githubusercontent.com/11707729/188051914-bf15f7eb-e53f-4de5-8033-d1b572352935.mov
Reviewed By: jacdebug
Differential Revision: D39771237
Pulled By: cipolleschi
fbshipit-source-id: d2a81bec1edd8d49a0fcd36a42fea53734909739
Summary:
A follow up to D38708718 (https://github.com/facebook/react-native/commit/403fea25f65a38f4b4d8e0edcf89741b29e62059) review, this factors feature flags for Fabric core code into a separate file, `CoreFeatures`.
Keeping them together is arguably better for maintenance and makes code easier to reason about.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D40007784
fbshipit-source-id: 1885d5d6200575c6015f063d8b05813b18b47ffb
Summary:
CMake on Windows uses "Visual Studio **" generators are [multi-configuration](https://cgold.readthedocs.io/en/latest/glossary/multi-config.html),
which requires the hermes cli and hermes runtime build flavors to be compatible. Using the "MakeFile" generator will avoid the requirement and keeps the gradle script simpler. Please note that the "Makefile" generator is the default when only "Visual Studio Community edition" with default packages is available.
Use NMake generator for Hermes build on Windows
## Changelog
CMake on Windows uses "Visual Studio **" generators are [multi-configuration](https://cgold.readthedocs.io/en/latest/glossary/multi-config.html),
which requires the hermes cli and hermes runtime build flavors to be compatible. Using the "MakeFile" generator will avoid the requirement and keeps the gradle script simpler. Please note that the "Makefile" generator is the default when only "Visual Studio Community edition" with default packages is available.
[Android] [Fixed] - Use NMake generator for Hermes build on Windows
Pull Request resolved: https://github.com/facebook/react-native/pull/34790
Test Plan: Verified that RN build on Windows with multiple SKUs of Visual studio.d
Reviewed By: cortinico
Differential Revision: D39889332
Pulled By: cortinico
fbshipit-source-id: f2d39d981e7c58c8cb93a4322155c844cb6bded3
Summary:
Ensuring the file paths uses forward slashes as separator to avoid the characters from being interpreted as ASCII escape characters.
## Changelog
Fixing build failure building RN codegen CLI on Windows. Ensuring the file paths uses forward slashes as separator to avoid the characters from being interpreted as ASCII escape characters.
[Android] [Fixed] - Fixing failure building RN codegen CLI on Windows
Pull Request resolved: https://github.com/facebook/react-native/pull/34791
Test Plan: Ensured RN main branch builds on Windows with new architecture turned on.
Reviewed By: cipolleschi
Differential Revision: D39889468
Pulled By: cipolleschi
fbshipit-source-id: 7d79eac9f433908cc86dd7ca2eec841739ef6365
Summary:
`react.gradle`'s `detectCliPath` was not working correctly for the `cliJsFromNode` check, this fixes it.
## Changelog
[Android] [Fixed] - Fix react.gradle's detectCliPath's for finding the path from Node
Pull Request resolved: https://github.com/facebook/react-native/pull/34808
Test Plan:
Tested manually from a monorepo setup, this incorrect check was preventing the CLI from being found correctly:
```
❯ pwd
/Users/liam.jones/code/monorepo/packages/apps/app1/android
❯ node --print "require.resolve('react-native/cli').bin" # old code
undefined
❯ node --print "require.resolve('react-native/cli')" # new code
/Users/liam.jones/code/monorepo/node_modules/react-native/cli.js
Reviewed By: cortinico
Differential Revision: D39883661
Pulled By: cortinico
fbshipit-source-id: 2120df3443e38631e0fbd9b844aa93a87449186f
Summary:
When using flow syntax like this, the parser would throw an error.
```
const foo = new ClassInstance();
export type {foo};
```
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D39850098
fbshipit-source-id: 28a7748892559c2c4a0fb8afa8612cbeb5568058
Summary:
Works around a crash identified by Sapienz in D39852058 (https://github.com/facebook/react-native/commit/30411ae1a42e46d0e5a2da494a39ed2767ba8808)
These logs will still be logged to the console, as they were before
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D39968830
fbshipit-source-id: 5d7a5d935e85a7d67e7780d95b2253e50888ad90
Summary:
Previously, ViewPropsMapBuffer conversions were hardcoded deep in Android infrastructrue. I've generalized this into a different mechanism to allow any Props struct to support MapBuffer props.
There are still some things that need to be cleaned up and this should be treated as experimental. One thing we likely want to do is remove the hardcoded IDs (fine for codegen'd code; less so for handwritten) and use compile-time-hashed IDs instead with human-readable string names.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D38708719
fbshipit-source-id: 64603dee7f21828be31346c555d99862dab304ea
Summary:
Instead of having a special flag just for View MapBuffer props, we now use one flag to indicate that MapBuffer should be used for all props; each XShadowNode must set a special trait indicating if that ShadowNode supports MapBuffer props.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D38708718
fbshipit-source-id: b398ec62a0db9c0ff23c0007c5503cf2838c4173
Summary:
Creates a new `valid-flow-typed-signature` ESLint rule that validates the `flow-typed` signatures at the top of each file.
This lint rule will discourage contributors from locally forking the `flow-typed` definitions. Instead, any changes should be submitted as patches to the upstream definition in: https://github.com/flow-typed/flow-typed
Changelog:
[Internal]
Reviewed By: rickhanlonii
Differential Revision: D39868721
fbshipit-source-id: e5e3ffe7568dbe52c9b598b53110b0fcbcad3e38
Summary:
Introduces a portable bundle that implements the `sort-imports` ESLint rule that we use internally at Meta, to the React Native repository.
As a consequence of the rapid changes that occur to this rule internally (and the desire to minimize red tape for Meta engineers), the portable bundle is built with Rollup with a lot of context omitted.
Changelog:
[Internal]
Reviewed By: skinsshark
Differential Revision: D39907799
fbshipit-source-id: 58fb6dc08030f20ac02c0e3fd1b175e22e4d74c0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34829
I realized there is a race condition in how prefab headers are prepared and bundled. If the download of boost is not 'fast enough' the headers will be missing during prefab preparation.
This fixes it.
Changelog:
[Internal] [Changed] - Fix broken template tests due to missing boost headers
Reviewed By: cipolleschi
Differential Revision: D39968622
fbshipit-source-id: 4680f84c15f4443a16def45d41a10a1083f4f196
Summary:
This PR bumps the dep version of Metro and the RN CLI to latest, and realigns them to avoid the issue we currently have in 0.70: https://github.com/facebook/react-native/issues/34714 (this commit will be cherry-picked there)
Also, it pins it all down to precise version. See comments for reasoning.
While at it, I gave a cleanup pass to the yarn.lock with [`yarn deduplicate`](https://github.com/scinos/yarn-deduplicate#readme).
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[General] [Changed] - bump CLI to 9.1.3 and Metro to 0.72.3
Pull Request resolved: https://github.com/facebook/react-native/pull/34803
Test Plan: CI is green
Reviewed By: dmytrorykun
Differential Revision: D39967392
Pulled By: dmytrorykun
fbshipit-source-id: 799dd745834c9ba349362f70afb4bdbd1a48260e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34800
The TypeScript parser was not handling negative default values properly. The reason why is because the AST for those values is structurally different and wraps them in a `UnaryExpression` with the `-` operator.
This Diff adds the support for those default values and it also add some tests in both Flow and TS.
## Changelog
[General][Fixed] - Properly parse negative values
Reviewed By: cortinico
Differential Revision: D39847784
fbshipit-source-id: 95fc5768987477c540a54a7c4e4ff785d7a1e5d7
Summary:
I accidentally broke `main` as I added a PRIVATE link for external libraries.
I need to get back to this, but for the meantime I'm disabling this linking
to make the CI green.
Changelog:
[Internal] [Fixed] - Unblock template jobs on main due to accidental PRIVATE linking
Reviewed By: cipolleschi
Differential Revision: D39932205
fbshipit-source-id: 5acbf567e0c194224a01141273665a293ead8e32
Summary:
This adds the YGGutter enum, used to choose between row/column gap variants (row-gap, column-gap, gap).
This used later in changes from https://github.com/facebook/yoga/pull/1116, in the APIs which deal with setting gap on style on yoga node.
Note the original PR called this `YGGap`, but this ending up leading to a couple public method signatures that could appear ambiguous:
1. `SetGap(YGGap gap, float gapLength)`: Enums like `YGAlign` are the vaues for an `align` prop. `YGGap` controls the variant of the gap (like `YGEdge` does for left/right/top/bottom variants). So the enum reads as if it is the `gapValue`, and it looks like we have two of the same parameter.
2. `SetGap(YGGap gapDirection, float gap)`: This is misleading, because the direction gaps flow is the cross-axis of flex-direction.
3. `GetGap(YGGap gap)`: `gap` is the variant, but looks like an out param.
The [CSS Box Alignment](https://www.w3.org/TR/css-align-3/#column-row-gap) spec refers to these gaps as "Gutters", which removes the ambiguity.
Changelog:
[General][Added] - Add YGGutter Enum
Reviewed By: yungsters
Differential Revision: D39922412
fbshipit-source-id: 4b0baf800fecb3d03560a4267c7fb4c4330fd39e
Summary:
https://github.com/facebook/yoga/pull/1116 adds a new enum. The enum generator is out of date with copyright header, and some codemods, but it also looks like there were manual changes, types added, etc since generation. I fixed up the script to incorporate generating the changes folks made manually, and also added an enum that was previously only added manually to the C ABI.
Changelog:
[General][Fixed] - Fixup Yoga Enum Generator
Reviewed By: yungsters
Differential Revision: D39922252
fbshipit-source-id: b678fa9a43a896873d8c434745bdaf3f16fd991f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34819
This is crashing on A12 because of using the regular Context instead of the application context. That said, this probably makes more sense as a log warning.
Reviewed By: javache
Differential Revision: D39852058
fbshipit-source-id: 1ac93f8cc9ecdb14f60baca175c8ecff2ff42ac0
Summary:
Deletes `eslint-config-react-native-community/yarn.lock` because the package source directory is part of the `react-native` Yarn workspace (and therefore does not need its own `yarn.lock`).
Changelog:
[Internal]
Reviewed By: cipolleschi
Differential Revision: D39934080
fbshipit-source-id: dc00b3934965285208fc2fb066ec8b64e8111e9e
Summary:
This removes the old way of consuming `libreact_nativemodule_core.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
This is the last mode that we'll have to handle the prefab for.
I'll do the cleanup just after this change landed.
Changelog:
[Internal] [Changed] - Move `react_nativemodule_core` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39929261
fbshipit-source-id: 61669da2cfd0545160a2a4c596c8e4adb22303ec
Summary:
This removes the old way of consuming `libfolly_runtime.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Moreover, I've exposed a `folly-flags.cmake` file which can be used by libraries
to know which lists of flags they need to use for Folly.
Changelog:
[Internal] [Changed] - Move `folly_runtime` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39928571
fbshipit-source-id: 4864c37813ec681a6a464c97de6dfc078f5553f1
Summary:
This removes the old way of consuming `libyoga.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `yoga` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39927496
fbshipit-source-id: f7ab2a3aab3cb42effa648dfeff6711d183260e4
Summary:
This removes the old way of consuming `libreact_renderer_mapbuffer.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `react_renderer_mapbuffer` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39927266
fbshipit-source-id: e82c2bda02c85a2a6747b92a3f20f2a5118bda65
Summary:
This removes the old way of consuming `libfabricjni.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `fabricjni` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39927210
fbshipit-source-id: dbd8814a6cad38d09484561120df911ab24b5f8a
Summary:
This removes the old way of consuming `libglog.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `glog` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39927147
fbshipit-source-id: 99f0241da1dece0efc8d928c3d25f30f3fa48a09
Summary:
This removes the old way of consuming `libjsi.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `jsi` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39924434
fbshipit-source-id: cb92d3a4ed6cb87e75462082506f310feb7bec9f
Summary:
This removes the old way of consuming `librrc_view.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `rrc_view` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39924231
fbshipit-source-id: 231809631f807ea2ea40d2581759f391adfba94d
Summary:
This removes the old way of consuming `libreact_render_graphics.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `react_render_graphics` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39923620
fbshipit-source-id: 9edb6557b4d195e1703b1ae532ca14126930a43a
Summary:
This removes the old way of consuming `libreact_render_core.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `react_render_core` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39923551
fbshipit-source-id: b800d4369f0de8edbc68b11d9efecf2cb5ea68c1
Summary:
This removes the old way of consuming `react_newarchdefaults.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `react_newarchdefaults` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39857115
fbshipit-source-id: 194a75b530b21e593b0390565a3b91155e07f17e
Summary:
This removes the old way of consuming `libreact_render_componentregistry.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `react_render_componentregistry` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39856487
fbshipit-source-id: 98006054481a5635ee3241e3281455cd934eca08
Summary:
This removes the old way of consuming `react_debug.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `react_debug` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39889945
fbshipit-source-id: e31f3c3027718a54c0a7228db00d145c1f3f7873
Summary:
Moves the `retry3` utility function into its own file so that it can be reused in other steps that are not related to Android.
Changelog:
[Internal]
Reviewed By: rickhanlonii, cipolleschi
Differential Revision: D39889996
fbshipit-source-id: bf79cc19ad6178af0a0d8117a81116e0c32f4333
Summary:
Found and removed duplicates of the word "the" in comments.
## Changelog
[Internal] [Removed] – Removed duplicates of the word "the" in comments.
Pull Request resolved: https://github.com/facebook/react-native/pull/34807
Test Plan: Not applicable.
Reviewed By: yungsters, cipolleschi
Differential Revision: D39880587
fbshipit-source-id: b7277aa70604902929903c31ab69d4c532f2667a
Summary:
This removes the old way of consuming `react_codegen_rncore` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `react_codegen_rncore` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39855726
fbshipit-source-id: a8ee00ea31422a20832909b9d7e5a8123cf88c84
Summary:
This removes the old way of consuming `runtimeexecutor` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `runtimeexecutor` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39852978
fbshipit-source-id: 87795118f1bcf496a3c50791f920d8b230932555
Summary:
This removes the old way of consuming `turbomodulejsijni.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `turbomodulejsijni` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39851647
fbshipit-source-id: 6201546ad47a53b366a54b022457fce7b744f064
Summary:
This lint rule (and the associated Jest test) fails because `path` on Windows outputs backslashes. This diff fixes the rule.
Changelog:
[Internal]
Reviewed By: cortinico, cipolleschi
Differential Revision: D39887464
fbshipit-source-id: b75480ccf4dcc384e2f7b91d8dcaf3af5f341434
Summary:
Removes the `error-subclass-name` ESLint rule from `react-native/eslint-plugin`, and implements a new `require-extends-error` ESLint rule inside the React Native repository. This rule was only intended to be used for internal development of React Native.
This will change `react-native/eslint-plugin` to no longer provide the `error-subclass-name` rule.
NOTE: One behavior difference here is that I also implemented the desired behavior of checking classes that extend `Library.SomeError`.
Changelog:
[General][Removed] - `react-native/eslint-plugin` no longer provides the `error-subclass-name` rule.
Reviewed By: lunaleaps
Differential Revision: D39858882
fbshipit-source-id: 27b53216d77a15b3425bd9669dbc9d954c1c61da
Summary:
Moves the `no-haste-imports` ESLint rule into the React Native repository because it was only intended to be used for internal development of React Native.
This will change `react-native/eslint-plugin` to no longer provide the `no-haste-imports` rule.
Changelog:
[General][Removed] - `react-native/eslint-plugin` no longer provides the `no-haste-imports` rule.
Reviewed By: lunaleaps
Differential Revision: D39858883
fbshipit-source-id: b8d91ce5996b615341cf60c6f839afac1e26dac9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34802
This removes the old way of consuming `libreact_render_debug.so` from
`Android-prebuilt.cmake` to using Prefab which is natively supported
by the Android pipeline.
Changelog:
[Internal] [Changed] - Move `react_render_debug` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D39849622
fbshipit-source-id: 45451dfe92ecce94d1b466094baae05a75ed803f
Summary:
Creates an ESLint rule that prohibits (and autofixes) imports from `react-native` or `react-native/path/to/file`, within the React Native repository.
The ESLint rule is configured using the `eslint-plugin-lint` package instead of `react-native/eslint-plugin` because the rule is only applicable to the React Native repository. The rule does not (and should not) be publicly facing, and changes to the rule should not require publishing new versions of `react-native/eslint-plugin`. (As a follow-up, the `no-haste-imports` rule should be migrated over from `react-native/eslint-plugin`.)
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D39831222
fbshipit-source-id: 566330e6df77fdff5ce755324b9f592b9365019e
Summary: We have decided not to go forward yet with using flexlayout in react-native. This change removes it for now.
Reviewed By: JTYim
Differential Revision: D39822037
fbshipit-source-id: 726e8657b62e6b4e55e5f72be3ca5539d317348e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34801
D39796598 (https://github.com/facebook/react-native/commit/8cdc9e7f04e2dd3026d15dcd5765952bfb2c5c08) broke this CircleCI job, causing failures for `dtslint` and `prettier`. This fixes both issues, by upating formatting, and removing types from `legacy-properties.d.ts` that we no longer export.
These were not flagged by sandcastle. It looks like this is because:
1. We run eslint, but not dtslint internally
2. Arcanist will ignore anything under a "vendor" directory, while we do not exlude anything from the prettier check in OSS.
I also updated the eslint config to lint any TypeScript that appears outside the types directory, since typings are now spread out.
Changelog:
[Internal][Fixed] - Fix `analyze_code` CircleCI Job
Reviewed By: cipolleschi
Differential Revision: D39848604
fbshipit-source-id: 844dfe26e4b618059542b29df163402079c39322
Summary:
Interface was supported in component, but it only allows interfaces in limited cases.
In this change, I extended interface support to all places where object literal type is supported.
I also refactor the code so that properties and events are able to share the same implementation.
In order not to mess up the diff, I noticed that implementations are repeated in processing array properties and non-array properties. But I leave it without refactoring. I will do it in future PRs.
I also commented potential problems I found in the code.
## Changelog
[General] [Changed] - Fix interface support in turbo module TypeScript codegen (component only)
Pull Request resolved: https://github.com/facebook/react-native/pull/34778
Test Plan: `yarn jest react-native-codegen` passed
Reviewed By: cortinico
Differential Revision: D39809230
Pulled By: cipolleschi
fbshipit-source-id: cfb51ce915249b5abceafee1c08b7e5762d03519
Summary:
Adds changelog for new patch.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - add changelog entry for 0.69.6
Pull Request resolved: https://github.com/facebook/react-native/pull/34798
Test Plan: N/A
Reviewed By: cortinico
Differential Revision: D39848387
Pulled By: dmytrorykun
fbshipit-source-id: a8448f5bb1d3c65337038b9ac270416d34d88cfc
Summary:
Release versions are currently broken on `main`. This happened once we bumped the AGP version to 7.3. It seems like that the path we used to use for assets has changed.
The app build successfully but it fails to start as it can't load the bundle.
This is also causing the hermes e2e test to fail: https://github.com/facebook/hermes/pull/821
## Changelog
[Android] [Fixed] - Fix crash on release versions after AGP 7.3 bump
Pull Request resolved: https://github.com/facebook/react-native/pull/34797
Test Plan:
Tested this locally and it works fine with RN Tester (can run a release version of it).
Plus, inspecting the zip:
### Before
```
$ unzip -l packages/rn-tester/android/app/build/outputs/apk/hermes/release/app-hermes-arm64-v8a-release.apk | grep android.bundle
1248608 01-01-1981 01:01 assets/mergeHermesReleaseAssets/RNTesterApp.android.bundle
```
### After
```
$ unzip -l packages/rn-tester/android/app/build/outputs/apk/hermes/release/app-hermes-arm64-v8a-release.apk | grep android.bundle
1248608 01-01-1981 01:01 assets/RNTesterApp.android.bundle
```
Reviewed By: cipolleschi
Differential Revision: D39847369
Pulled By: cortinico
fbshipit-source-id: 0e21c0b6e58b49ac097c59223649b74b2879b5e5
Summary:
This adds the `alt` prop to the `Image` component as requested on https://github.com/facebook/react-native/issues/34424. Using this new `alt` prop enables the `accessibility` prop and passes down the alt text to `accessibilityLabel`. This PR also updates RNTester ImageExample in order to facilitate the manual QA.
#### Open questions
- ~~On web `alt` text is displayed on the page if the image can't be loaded for some reason, should we implement this same behavior if the `Image` component fails to load `source`?~~ Not for now
## Changelog
[General] [Added] - Add alt prop to Image component
Pull Request resolved: https://github.com/facebook/react-native/pull/34550
Test Plan:
1. Open the RNTester app and navigate to the Image page
2. Test the `alt` prop through the `Accessibility Label via alt prop` section, this can be tested either by enabling Voice Over if you're using a real device or through the Accessibility Inspector if you're using a simulator
https://user-images.githubusercontent.com/11707729/187790249-0d851363-c30e-41b6-8c24-73e72467f4ba.mov
Reviewed By: lunaleaps
Differential Revision: D39618453
Pulled By: cipolleschi
fbshipit-source-id: 0e26b2574514e76ce7e98ddb578f587a9cc30ee9
Summary:
Currently, height is sometimes the only valid option for pushing `TextInput` up in the layout on Android. The problem is when switching keyboards. For instance, switching from ABC to emojis. This will trigger keyboard show events and recalculate the height for the `KeyboardAvoidingView`. Since the keyboard is still showing, the view has the height that was previously calculated and thus `frame` represents that. This means the `frame.height` has adjustments for the keyboard calculated in it, but it is used the same way as if the keyboard was not showing. This results in wrong calculation and the input showing at the incorrect place in the layout (mostly hidden under the keyboard)
This fix simply uses the previous calculation to offset `frame.height`, resulting in the correct height and smooth switching between keyboards. It's also scoped only to height mode since that's where the problem shows.
_Note: I mention android here, but it fixes it for both platforms. It's just that iOS usually works best with different behaviour so it's rarely used there._
## Changelog
[General] [Added] - Include `this.state.bottom` when calculating new keyboard height to fix android keyboard switching
Pull Request resolved: https://github.com/facebook/react-native/pull/34749
Test Plan:
With simple code:
```jsx
import { StatusBar } from "expo-status-bar";
import React from "react";
import {
KeyboardAvoidingView,
StyleSheet,
Text,
TextInput,
View,
} from "react-native";
export default function App() {
return (
<KeyboardAvoidingView style={styles.container} behavior="height">
<Text>Open up App.js to start working on your app!</Text>
<StatusBar style="auto" />
<TextInput style={{ backgroundColor: "red", width: "100%" }} />
</KeyboardAvoidingView>
);
}
const styles = StyleSheet.create({
container: {
padding: 32,
flex: 1,
backgroundColor: "#fff",
alignItems: "center",
justifyContent: "space-between",
},
});
```
Notice the consistency of the TextInput after the changes, while before it would just move around more you switch the keyboards.
| Before | After |
|---|---|
|  |  |
Reviewed By: cipolleschi
Differential Revision: D39718812
Pulled By: NickGerleman
fbshipit-source-id: 2550182e846f3f8e719d727fa8e6d87165faebf6
Summary:
We need to bump & publish a new version of the Gradle Plugin.
This is needed otherwise the template will break as I start to remove
entries from the `Android-prebuilt.cmake` file
Changelog:
[Internal] [Changed] - Bump react-native-gradle-plugin to 0.71.2
Reviewed By: lunaleaps, mdvacca
Differential Revision: D39815785
fbshipit-source-id: b140187971e2f963ef459e9c83ce9a76e67c89bd
Summary:
React Native's TS definitions are currently mostly stored in one monolithic file. This change splits the definitions up to correspond to the source files they came from, and are placed next to the source files. I think this should help inform, and make it easy to update the TS declarations when touching the Flow file.
I noticed as part of the change that the typings have not yet removed many APIs that were removed from RN. This is bad, since it means using the removed/non-functional API doesn't cause typechecker errors. Locating typings next to source should prevent that from being able to happen.
The organization here means individual TS declarations can declare what will be in the RN entrypoint, which is a little confusing. Seems like a good potential next refactor, beyond the literal translation I did.
Changelog:
[General][Changed] - Place TS Declarations Alongside Source Files
Reviewed By: lunaleaps, rshest
Differential Revision: D39796598
fbshipit-source-id: b36366466fd1976bdd2d4c8f7a4104a33c457a07
Summary:
There was a bug on Android when an Animated.ScrollView had a RefreshControl while an Animated style was applied, ie `transform`:
```
<Animated.ScrollView
refreshControl={<RefreshControl />}
style={{
transform: [{
translateY: new Animated.Value(200, {useNativeDriver: true})
}]
}}
/>
```
The transform value was being incorrectly applied twice. Since the styles were applied once on RefreshControl and once on NativeScrollView, the transform style is effectively applied twice:
**1. ScrollView.js**
- RefreshControl gets the transform through Fabric commit
- [The RefreshControl gets wrapped around ScrollView](https://fburl.com/code/k60krxbj) while on iOS there is no change in the parent/child relationship. [Outer/inner styles are split and applied to RefreshControl/ScrollView](https://fburl.com/code/b2to75er), and transform styles are applied on the parent (RefreshControl)
**2. createAnimatedComponent.js**
- NativeScrollView gets the transform through Animated
- [ScrollView forwards its ref to NativeScrollView](https://fburl.com/code/w1whtl5f), which means AnimatedComponent is setting the transform styles on NativeScrollView and not RefreshControl as ScrollView.js did
This diff fixes this bug by using the `useAnimatedProps` hook which makes both RefreshControl and ScrollView components into animated components. Otherwise, the components don't know what to do with Animated values.
---
Changelog:
[Internal][Fixed] - Animated transform style properties were being applied twice when used on an Animated.ScrollView with RefreshControl on Android
Reviewed By: javache
Differential Revision: D38815633
fbshipit-source-id: 2b76639d2237176b6aae4fb1e22cf1a1ec70a69a
Summary:
Currently, it is possible in one of the "minimum press duration" unit tests for certain instructions to take longer than expected, skewing the return value of `Date.now()` by at least 10ms.
This changes the unit test to mock `Date.now()` more accurately so that the test is no longer flakey.
Changelog: [Internal]
Reviewed By: jacdebug
Differential Revision: D39804152
fbshipit-source-id: ab62fd1921bd015d969da9595bd3267c38c6e59c
Summary:
I've just realized that CMake is ignoring `ccache`, even if you have it
installed. This is the necessary change needed to verify if the user
has `ccache` installed and eventually use it.
While not a necessary change for Prefab supprot, this is a nice to have
that I've discovered while working on it.
Changelog:
[Internal] [Changed] - Make sure ccache is considered as part of the CMake build
Reviewed By: cipolleschi
Differential Revision: D39815089
fbshipit-source-id: be62e5fe98954593fd907ec21c41950a967cff04
Summary:
This is part of the preparatory work for Prefab support for React Native.
I've added a task that will help us copy, filter and prepare the headers to
be consumed by Prefab.
It's not used at the moment. I will use it in the next commit.
Changelog:
[Internal] [Changed] - Add the PreparePrefabHeadersTask.kt inside the Gradle Plugin
Reviewed By: cipolleschi
Differential Revision: D39815101
fbshipit-source-id: 73e48666efa372a1647d08a7586083434d9ebbbb
Summary:
Cleans up the dependencies in `ReactCommon/hermes/inspector/tools/msggen` by
- Analyzing and removing any dependencies that are never referenced.
- Upgrading all dependencies to their latest versions (by deleting `yarn.lock` and re-running `yarn`).
- I only upgraded Babel dependencies to the same version used by the rest of `react-native`.
Notably, this resolves 13 vulnerabilities reported by Dependabot.
## Changelog
[Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/34782
Test Plan:
Ran the following successfully:
```
$ cd ReactCommon/hermes/inspector/tools/msggen
$ yarn
$ yarn test
$ yarn build
```
Reviewed By: cortinico, cipolleschi
Differential Revision: D39804478
fbshipit-source-id: c673e80b64fcf49c3f903c5d7f0a68c77d63a4bd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34786
This diff is the TS equivalent of D39686251.
It introduces the possibility to parse a custom Native State in Typescript.
The parsing follows the exact same rules as props, as initial heuristic. This should allow enough customization for the developers who needs a custom state.
Currently, we only support using `interface` for the state and the interface must contain the `NativeState` string in its name.
This diff introduces also tests for the TypeScript parser and it aligns the tests between Flow and TS.
## Changelog
[General][Added] - Implement custom Native State parsing in TypeScript
Reviewed By: cortinico
Differential Revision: D39811476
fbshipit-source-id: 1e1b86b50b9632c13157ff6c8115f5ebcbada643
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34753
This Diff introduce a the capability to parse custom NativeStates in Flow. To achieve this I also had to define the CodegenSchema.
The parsing follows the exact same rules as props, as initial heuristic. This should allow enough customization for the developers who needs a custom state.
There is only a case I was not able to make it work that is STATE_ALIASED_LOCALLY, from the fixtures. I don't know how diffuse it is and I think we can live with some workarounds for the time being.
This diff also adds tests for the custom Native State Flow Parser.
## Changelog
[General][Added] - Implement custom Native State parsing in Flow
Reviewed By: cortinico
Differential Revision: D39686251
fbshipit-source-id: 446997a39b33b7e9351d5ba12cecaeff33df4d16
Summary:
Brings in line with rest of code base and avoids running into this error
```
‘sharedApplication’ is unavailable: not available on iOS (App Extension) — Use view controller based solutions where appropriate instead.
```
when `Requires Only App-Extension-Safe-API` is set to Yes.
## Changelog
[iOS] [Fixed] - Update usage of UIApplication.sharedApplication in RCTKeyCommands
Pull Request resolved: https://github.com/facebook/react-native/pull/34787
Test Plan: Setting `Requires Only App-Extension-Safe-API` to Yes before this change means the app will not compile, after the change it does.
Reviewed By: dmytrorykun
Differential Revision: D39812410
Pulled By: cipolleschi
fbshipit-source-id: 78d185ba20301b10609e4a387f000f0cfda55663
Summary:
Within the `hermes-engine.podspec` contained in the RN repo (at `react-native/main/sdks/hermes-engine/`), there's a bit of logic that triggers `./utils/build-ios-framework.sh` and `./utils/build-mac-framework.sh` .
The issue is that we all thought that that `./utils/build-ios-framework.sh` would invoke the React native version of the scripts (since the podspec file lives right next to the `utils` folder) but, in reality, it doesn't. It just so happens that the Hermes repo has a root level `utils` folder which is (you guessed it) where the Hermes variation of those build scripts live.
So, when running the pod install command in a react-native project (build from source), it will go and download the hermes source code (since the `source[:git]` gets set) but then it will use the **hermes** variation of the `build-*.sh` scripts.
[Read more here](https://github.com/facebook/react-native/pull/34513#issuecomment-1248286691).
This PR is taking kudo's proposed [patch here](https://github.com/reactwg/react-native-new-architecture/discussions/68#discussioncomment-3654191) - props for the fix go to him.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[iOS] [Fixed] - Change hermes logic in build scripts for Apple to use the correct files
Pull Request resolved: https://github.com/facebook/react-native/pull/34710
Test Plan: Tested by kudo in his work, and in my PR locally - [see here](https://github.com/facebook/react-native/pull/34513#issuecomment-1249431302).
Reviewed By: cortinico
Differential Revision: D39647057
Pulled By: cipolleschi
fbshipit-source-id: 6520e248801a307ca2f8886a3853dd1ff4af193d
Summary:
Changelog: [Internal][Bridgeless][iOS]
# Before diff
Be in Venice > run Metro > run FBiOS > navigate to any RN surface.
`UIManagerBinding createAndInstallIfNeeded` happens After `ReactInstance loadScript -> evaluateJavaScript`: install Fabric UIManager before main bundle execution
Reviewed By: RSNara
Differential Revision: D39760231
fbshipit-source-id: f17bf02e9b1fb0f9b0ff24c86aa6dc9349c42192
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34776
CocoaPods is not used when Hermes is built in Circle CI, so we cannot rely on the React Native CocoaPods scripts to be loaded.
The get_hermes_build_type function is removed from the RN CocoaPods scripts and in its place, the ENV['PRODUCTION'] envvar is accessed directly.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D39778190
fbshipit-source-id: 12083b7b4533b4ad7bb7a08612883983a0583616
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34761
Separate debug and release tarballs are built in CI. Use the appropriate Hermes artifacts tarball when building hermes-engine.
Add hermes.rb tests.
Changelog:
[iOS] [Changed] - Remove debugger from Hermes when building for release
Reviewed By: cipolleschi
Differential Revision: D39698499
fbshipit-source-id: e6b10d34c7f94c2f86fc47d8b97466011aaa75cc
Summary:
Fix remaining NDK comment for new architecture
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[General] [Fixed] - Fix remaining NDK comment for new architecture
Pull Request resolved: https://github.com/facebook/react-native/pull/34769
Reviewed By: cipolleschi
Differential Revision: D39762860
Pulled By: cortinico
fbshipit-source-id: 35a3c9fed58d32bd6dc16c0d6bb217a3c2849612
Summary:
We want to fix the order of execution of layout, layout effects and passive effects in React Native, but the use of the Fabric background executor for layout complicates this (and other things).
This brings back a flag to disable this background thread to do layout synchronously in JavaScript, before the execution of layout effects and passive effects.
This is expected to regress performance on some screens, so we need to address the antipatterns in those screens before shipping this.
Changelog: [internal]
Reviewed By: javache
Differential Revision: D39727131
fbshipit-source-id: 4323b089234d3304ca3bfe5697668fb44ac64c12
Summary:
Currently, fbios link groups depend on supermodules to generate. To continue supporting
link groups while allowing us to migrate off supermodules, we'll add a `fbios_link_group` label on all fbios targets to persist the current hierarchical information.
Reviewed By: jkeljo
Differential Revision: D39543862
fbshipit-source-id: 2abe5b3ee883e77336076d88436a1c84139b5a97
Summary:
Aside from the log output, these changes do not change the behavior of the hermes-engine Pod.
Removed unused git branch checks.
Use react_native_path var to build filepaths.
Edit Hermes build from source log message to be consistent with other logs.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D39699165
fbshipit-source-id: 7e389eb5315fc5a2510b84eddac2f499a3e65157
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34704
Create separate hermes-engine tarballs for release and debug builds, and only include the debugger in debug builds.
Changes the hermes-engine podspec to use a debug Hermes build by default in order to preserve the inclusion of the debugger.
Upcoming changes should split the hermes-engine Pod to allow Xcode to use release and debug builds as needed.
Changelog:
[iOS][Changed] - Use debug Hermes builds by default
Reviewed By: cipolleschi
Differential Revision: D39326467
fbshipit-source-id: 94c5fe7db80194d22fced6717c5efc7accd36d48
Summary:
In `buildEventSchema` and `buildPropSchema`, they check into property types to see if the given property could be converted into an event schema or a property schema. The original implementation only handles limited cases, I refactor them and make them easier to maintain.
In `getPropertyType` in `events.js`, it handles `(T)` at a wrong place, fixed.
In `getPropertyType` in `props.js`, it doesn't handle `(T)`, fixed.
And I also fixed some other issues to make the codegen reports error better.
There are many duplicated test cases that cover every piece of the code, I changed some of them so that it tests both original cases and new cases.
## Changelog
[General] [Changed] - Handle (T) and undefined properly in turbo module component codegen
Pull Request resolved: https://github.com/facebook/react-native/pull/34693
Test Plan: `yarn jest` passed in `packages/react-native-codegen`
Reviewed By: NickGerleman
Differential Revision: D39647075
Pulled By: cipolleschi
fbshipit-source-id: 8e1df2b54aab37b7151d0bf74260e2eba0602777
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34746
The changes made in
https://github.com/facebook/react-native/pull/34694
introduced the need to have the env variable TMP_PUBLISH_DIR for the publishing and set-rn-version scripts to work.
This break any usage of set-rn-version when the env variable is not set upfront.
With this change, we are creating a temp folder in the scope that requires it (e.g. set-rn-version.js) and then passing the path to the save/revert functions.
## Changelog
[Internal] [Added] - Do not depend on an ENV variable when publishing and setting the RN version.
Reviewed By: cipolleschi
Differential Revision: D39683565
fbshipit-source-id: 21d85d1c16c4cb7324636ceb5eba626ff8cbb775
Summary:
This updates the `transform` property to support string values as requested on https://github.com/facebook/react-native/issues/34425. This also updates the existing unit tests of the `processTransform` function ensuring the style processing works as expected and updates the TransformExample on RNTester in order to facilitate the manual QA of this.
## Changelog
[General] [Added] - Add string support to the transform property
Pull Request resolved: https://github.com/facebook/react-native/pull/34660
Test Plan:
1. Open the RNTester app and navigate to the Transforms page
2. Check the transform style through the `Transform using a string` section
https://user-images.githubusercontent.com/11707729/189550548-ee3c14dd-11c6-4fd1-bd74-f6b52ecb9eae.mov
Reviewed By: lunaleaps
Differential Revision: D39423409
Pulled By: cipolleschi
fbshipit-source-id: 0d7b79178eb33f34ae55a070ce094360b544361f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34754
This Diff is the second step of enabling the CodeGen to parse and generate a NativeState for the components.
The feature has been largely requested by the OSS community but it could be also helpful for people in Meta.
## Changelog
[General][Added] - Always generate an empty NativeState for Fabric Components
Reviewed By: cortinico
Differential Revision: D39696435
fbshipit-source-id: e24768af78f59696c0b4db009e8065bb5c89316b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34750
This Diff is the first step of enabling the CodeGen to parse and generate a NativeState for the components.
The feature has been largely requested by the OSS community but it could be also helpful for people in Meta.
To allow the generation of custom `NativeState`, we first have to always generate a `ViewEventEmitter`: that's because the `ConcreteShadowNode` template lists the Generics with this order: `Name`, `Props`, `EventEmitter`, Others...
If we skip the `EventEmitters` and we put the `State`, React Native would think that the State is actually an `EventEmitter` and the build step will fail.
## Changelog
[General][Added] - Always generate a ViewEventEmitter for Fabric Components
Reviewed By: cortinico
Differential Revision: D39509869
fbshipit-source-id: 390cc146ef013baf1ed09d55a0182a5aeb5b9d9e
Summary:
This PR adds [verdaccio](https://github.com/verdaccio/verdaccio) to release packages in the `packages` directory during the E2E test on CI.
The rationale behind this is the following:
- Firstly, we wanted to push the [monorepo RFC](https://github.com/react-native-community/discussions-and-proposals/pull/480). We hit an issue when renaming the packages to follow the same convention caused by the e2e test using the template to fail. This is because the template installs packages from the live version of npm – and if you just rename a package in a given PR without releasing it, the package understandably can't be installed since it's not published, yet – as you can see [here](https://app.circleci.com/pipelines/github/facebook/react-native/15286/workflows/149df51f-f59b-4eb3-b92c-20c513111f04/jobs/282135?invite=true#step-108-283).
- Secondly, the current e2e test on `main` does not actually test the latest code of the packages in the `packages` directory as it simply downloads the latest versions from npm. This creates a divide between what's tested and what users should expect when using nightlies or when a new minor is released.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - Use verdaccio for template e2e test
Pull Request resolved: https://github.com/facebook/react-native/pull/34577
Test Plan: `test_js` CI check should pass. Additionally, I have temporarily updated the [PR](https://github.com/facebook/react-native/pull/34572) renaming `assets` to `assets-registry` to include the verdaccio changes – the `test_js` passes there, additionally proving merging this PR will unblock us with the rename PRs.
Reviewed By: cipolleschi
Differential Revision: D39723048
Pulled By: cortinico
fbshipit-source-id: aeff3811967360740df3b3dbf1df50e506fb72d8
Summary:
when specifying dev server without port, e.g. http://www.example.com/, there are some issues.
1. redbox error
<img src="https://user-images.githubusercontent.com/46429/190540390-8ee420f2-7642-427b-9f2e-e0c6d31015f8.png" width="30%">
2. showing -1 in loading view
<img src="https://user-images.githubusercontent.com/46429/190540727-158f35ad-359f-443a-a4b0-768dd2f7e400.png" width="50%">
the root cause is coming from [`java.net.URL.getPort()` will return -1 when the url doesn't have a port](https://developer.android.com/reference/java/net/URL#getPort()). this pr replaces the parser to [`okhttp3.HttpUrl`](https://square.github.io/okhttp/4.x/okhttp/okhttp3/-http-url/#port) that it will have default port 80 for http or port 443 for https. the two call paths should only serve http/https address, not file:// address. it should be safe to change from java.net.URL to okhttp3.HttpUrl.
not fully related, in the case above, android will connect to `ws://www.example.com/:8097` for react-devtools
we should strip the trailing slash in *setUpReactDevTools.js*
## Changelog
[Android] [Fixed] - Fix port as -1 if dev server without specifying port on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/34705
Test Plan:
test on rn-tester with the following steps
1. `yarn start`
2. open another terminal and run `ngrok http 8081` and it will return a tunnel url, e.g. `71a1-114-36-194-97.jp.ngrok.io`
3. open dev setting in app and change the dev server to `71a1-114-36-194-97.jp.ngrok.io`
5. reload the app
Reviewed By: cipolleschi
Differential Revision: D39573988
Pulled By: cortinico
fbshipit-source-id: 397df90ab30533207bd87a3f069132d97c22c7fd
Summary:
## Summary
In the past, NativeAnimatedModule could animate **both** Paper **and** Fabric components.
For Fabric nodes, we needed to manually flush NativeAnimatedModule's operations queue. So, we started tracking which nodes were Fabric owned in NativeAnimatedModule.
## Changes
With bridgeless mode, all components must be Fabric-owned. So, should be able to remove this fabric ownership tracking logic and **always flush.**
## Is this safe?
In the worst case, we over-flush. This doesn't seem bad. cc sammy-SC.
## Do we still need flushing?
Arguably, all this manual flushing should be unnecessary, because we already migrated AnimatedModule's Paper integration to RCTSurfacePresenterObserver, here: D14336760 (https://github.com/facebook/react-native/commit/544d9fb10b5a73bd499feb18dab1a7dc11738748). So, do we still need this flushing?
Yes. Here's what happens when you disable all the manual flushing in bridgeless mode: https://pxl.cl/2dqPf.
Long-term, we need to re-think this operations queuing in NativeAnimatedTurboModule. I left my thoughts in T130668424 (Investigation - Day 5).
Changelog: [Internal]
Reviewed By: p-sun
Differential Revision: D39592477
fbshipit-source-id: e971edc0d99661a37b5f430bce46c78acaa121c0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34747
Just a minor cleanup after the AGP bump.
Changelog:
[Internal] [Changed] - Cleanup of ReactAndroid/build.gradle after AGP 7.3.x bump
Reviewed By: cipolleschi
Differential Revision: D39687286
fbshipit-source-id: 441e449b51b25e4152cf1e7e7e22c7c9f1432d05
Summary:
This behaviour diverges from the original SafeAreaView implementation and causes issues when you try to use SafeAreaView in non-root placements (not recommended)
Changelog: [iOS][Internal]
Reviewed By: sammy-SC
Differential Revision: D39497303
fbshipit-source-id: 03bc288557f611bd4a8c16b3a6df8887e89ee9ec
Summary:
When `GenerateRCTThirdPartyFabricComponentsProviderCpp.js` generates `RCTThirdPartyFabricComponentsProvider.mm` an edge case happens in the following situation:
- The same library exports multiple modules with one component each (i.e. one component per file);
- The **first component** is excluded for iOS via the `excludedPlatforms` property in *codegenNativeComponent*.
A "loose" comma appears in the generated template, breaking the code.
```c++
Class<RCTComponentViewProtocol> RCTThirdPartyFabricComponentsProvider(const char *name) {
static std::unordered_map<std::string, Class (*)(void)> sFabricComponentsClassMap = {
, // <-- the offending comma
{"NativeComponent2", NativeComponent2Cls}, // rnmylibrary
};
}
```
At some point, `GenerateRCTThirdPartyFabricComponentsProviderCpp.js` does not properly filter out empty arrays resulting from excluded components. This does not seem to be a problem when the excluded component is not the first being processed, as the comma gets added at the end of the previous line, after the comment with the name of the library.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[iOS] [Fixed] - Fix error in the Codegen template for ThirdPartyFabricComponentsProvider
Pull Request resolved: https://github.com/facebook/react-native/pull/34738
Test Plan:
<!-- Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes the user interface. -->
This is the schema that leads to the bug. Notice that the first component was excluded for iOS.
```json
{
"modules": {
"ComponentFile1": {
"type": "Component",
"components": {
"NativeComponent1": {
"excludedPlatforms": ["iOS"]
"extendsProps": [
{
"type": "ReactNativeBuiltInType",
"knownTypeName": "ReactNativeCoreViewProps"
}
],
"events": [],
"props": [],
"commands": []
}
}
},
"ComponentFile2": {
"type": "Component",
"components": {
"NativeComponent2": {
"extendsProps": [
{
"type": "ReactNativeBuiltInType",
"knownTypeName": "ReactNativeCoreViewProps"
}
],
"events": [],
"props": [],
"commands": []
}
}
}
}
```
`GenerateRCTThirdPartyFabricComponentsProviderCpp.js` should generate a template without the comma in the wrong position (before NativeComponent2).
I also added an additional test case to cover this problem. All the other tests passed.
Reviewed By: sammy-SC
Differential Revision: D39686573
Pulled By: cipolleschi
fbshipit-source-id: 6054464d024218eb0b2e02974aa5cc7c8aebbbc9
Summary:
Checking if Hermes is enabled is failing because there is no `podfile.lock` file in the directory where this script is executed and `USE_HERMES` will be set to `false` which will prevent building Hermes binary jsbundle.
## Changelog
[iOS] [Fixed] - `HERMES_ENABLED` check fixed in react-native-xcode.sh
Pull Request resolved: https://github.com/facebook/react-native/pull/34675
Test Plan:
1. Enable Hermes
2. Make a release build
3. Verify the `main.jsbundle` file is Hermes binary bundle
Reviewed By: cortinico
Differential Revision: D39686608
Pulled By: cipolleschi
fbshipit-source-id: 237c77ced484d4ab77e576c7a2bb7b6826228017
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34739
AGP 7.3.0 just got released which is glorious!
This allows us to remove a lot of unnecessary boilerplate to handle correct task ordering
inside the template
This requires "react-native-gradle-plugin" version 0.71.1 to be published on NPM.
Changelog:
[Android] [Changed] - Bump AGP to 7.3.0 inside the template
Reviewed By: mdvacca, dmytrorykun
Differential Revision: D39653419
fbshipit-source-id: 517363c952cbad2be0f2766c0a2b7daf3e75048b
Summary:
As we're shipping the AGP 7.3.x bump which requires
changes of the Gradle Plugin, I'm bumping a version so I can use it
already in the new template.
Changelog:
[Internal] [Changed] - Bump react-native-gradle-plugin to 0.71.1
Reviewed By: mdvacca, dmytrorykun
Differential Revision: D39653418
fbshipit-source-id: 9e898530345f1a3461c44c04b4cc5e7736a0f6a5
Summary:
`verifyVirtualizedList` chokes on missing displayName in DEV, due to a mistake in D39648806 (https://github.com/facebook/react-native/commit/a0d1585cdb5ae86e5d4e5bc51fdfa9ae7e049b4b). Not sure why this isn't triggered in Jest tests (maybe it is able to fill displayName via transform?), but this fixes the issue in dev mode.
Changelog:
[Internal][Fixed] - Fix crash in DEV when VirtualizedList_EXPERIMENTAL is loaded
Reviewed By: mdvacca
Differential Revision: D39670991
fbshipit-source-id: b1a784aa3fffdc5f2f025eb1f689307132aad9b6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34724
Following on from the recent upgrade from Jest 26->27, this brings us up to present day Jest 29 for tests of React Native itself, Metro, and Meta-internal code. An update to the template for RN apps will follow.
Changelog:
[Internal][Fixed] Update to Jest 29
Reviewed By: huntie
Differential Revision: D39543504
fbshipit-source-id: b47fdb678212b475881ec19085f6cd45a4530333
Summary: Changelog: [Internal] - A refactor to pass the object PointerEventState containing relevant state / and also properties for pointerEvent objects
Reviewed By: vincentriemer
Differential Revision: D39626285
fbshipit-source-id: e2ff5313ef03d7d2d36c35ca459950ec07650df2
Summary:
Changelog: [Internal]
Stop using `TouchEventCoalescingKeyHelper` for tracking and stop making the distinction between traditional touch events (down, up, move) vs hover only events. The only events that currently coalesce are `onpointermove` events. This change uses just one counter now that we increment whenever some non-move event is fired.
Let me know if there's a simpler way to ensure counter doesn't overflow.
This change also ensures we're overriding `getCoalescingKey` which isn't used by Fabric but for old event emitter it might be (which we use for native animations). Part of that requires the `coalescingKey` to be a short so updated to that.
There was also a bug where I forgot to pass `mLastButtonState` to one of the dispatch calls. Will be wrokign on refactor so its less argument soup.
Reviewed By: javache
Differential Revision: D39530927
fbshipit-source-id: 689fa98580b206a480cc08121971cdf96bdbbfaa
Summary:
The prop is removed as part of D39589089 (https://github.com/facebook/react-native/commit/bc5cb7cd7933da707c02ff0dd993c607ba7d40b3) (no longer does anything). Remove from the TS declarations.
Changelog:
[General][Removed] - Remove listKey from TS typings
Reviewed By: lunaleaps
Differential Revision: D39650827
fbshipit-source-id: dd9b5eccba1b9f6964a6d60ea5bae9913e8396e3
Summary: Changelog: [Internal] - Update the base accessibility props to include the added aria props. See https://github.com/facebook/react-native/compare/0.70-stable...main for changes.
Reviewed By: cipolleschi
Differential Revision: D39633224
fbshipit-source-id: 6c08ab8540b8b6e2b57f066a35754376c5ae3d68
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34707
AGP 7.3.0 just got released which is glorious!
This allows us to remove a lot of unnecessary boilerplate to handle correct task ordering
on both React Android & the template
Changelog:
[Android] [Changed] - Bump AGP to 7.3.0
Reviewed By: mdvacca
Differential Revision: D39553534
fbshipit-source-id: 9680893e9f48cac867206aeb7eb468dbf91c1643
Summary:
This PR refactors the Animated directory to use ESModule imports/exports instead of using a mixture of the 2 module formats, as requested on https://github.com/facebook/react-native/issues/34425.
## Changelog
[Internal] [Changed] - Convert all files in the Animated directory to use ESModule imports/exports
Pull Request resolved: https://github.com/facebook/react-native/pull/34539
Test Plan: This doesn't really add or modify any existing features so checking if CI passes should be enough
Reviewed By: yungsters
Differential Revision: D39235720
Pulled By: yungsters
fbshipit-source-id: 84b4c0a71dc9fca1ab7053263f1cf7c336df58c1
Summary:
VirtualizedList uses a combination of ES6 and CommonJS imports/exports. This moves fully to ES6 imports and exports, in the experimental version (which should soon replace the original).
Changelog:
[Internal][Changed] - Move VirtualizedList_EXPERIMENTAL to ES6 import/export
Reviewed By: rshest
Differential Revision: D39648806
fbshipit-source-id: a5da40f62a6010cd5b9894b02a91af86d3a8b995
Summary:
VirtualizedList is large and complicated, getting larger and more complicated. This splits out a subcomponent, the cell renderer into its own file, since it is relatively isolated already. This uses the copy from VirtualizedList_EXPERIMENTAL, whose only real difference is exposing focus capture events to the containing VirtualizedList.
Changelog:
[Internal][Changed] - Extract VirtualizedListCellRenderer
Reviewed By: rshest
Differential Revision: D39648087
fbshipit-source-id: bb7c2eff0c658713c256650596f86e8788019baf
Summary:
Now that the prop noops, remove the usages of the property. This is the point of no return for the prop.
Replaced listKey usage with a combination of `flow check`, regex replace, manual inspection.
Changelog:
[General][Removed] - Remove usages of listKey
Reviewed By: fred2028
Differential Revision: D39589089
fbshipit-source-id: 722ebb7dce038a2709656394b7d736e72f488bb7
Summary:
The previous approach to set a heading in Android required us to trick the accessibility service into thinking that this element was the heading inside of a list, which used to be the only place you could use headings on Android.
This worked for the most part, but could cause problems in specific circumstances, such as if that element actually *was* part of a list. Since we were overriding its CollectionItemInfo, and presenting it as the first item in a single column list, the parent list could have confusing announcements such as announcing this item as "Item 1" even if it was not the first item in the actual list.
Since API 28, there has been an API to set any view as a heading (https://developer.android.com/reference/android/view/View#setAccessibilityHeading(boolean)).
This switches our implementation to use this new API via the AccessibilityNodeInfoCompat class for backwards compatibility to older API versions.
Changelog:
[Android][Changed] - Simplify Accessibility Heading role implementation.
Differential Revision: D39076827
fbshipit-source-id: 583dc1e9d2779a4efa5f98cabef506df2770d892
Summary:
Following up on the previous diff to remove the only usage of `listKey` for persistent association, we can remove the need for a manual `listKey`, and instead rely on per-instance association via refs.
A followup change will remove the existing usages.
Changelog:
[General][Removed] - Remove VirtualizedList `listKey` prop
Reviewed By: p-sun
Differential Revision: D39466677
fbshipit-source-id: 6b49f45c987fff9836918ba833fbb16f24414ff8
Summary: Changelog: [Internal] - Update changes to Keyboard, Alert from differences in those files from https://github.com/facebook/react-native/compare/0.70-stable...main
Reviewed By: NickGerleman
Differential Revision: D39629997
fbshipit-source-id: 85bb91d00a165e708dbf4e32d7f37ce8a6c02a72
Summary:
Keeping the lowercase values but keeping the conversion values the same.
D39478951 (https://github.com/facebook/react-native/commit/ea1ec29ba67c837c82c74357e313bd4505b81eb8) reverted some changes that moved it back to uppercase but needed to add new values to `____FontWeight_Internal`. This diff removes the need for the uppercase values
Changelog: [Internal]
Differential Revision: D39506944
fbshipit-source-id: 079f73c1adcf2db28b961523b05562e21fcf3630
Summary:
## Changelog
[General] [Added] - Add `types` folder to house TypeScript types.
Release TypesScript types with react-native and eventually deprecate [types/react-native](https://www.npmjs.com/package/types/react-native).
The current plan is to release types/react-native for 0.70 and 0.71 while also maintaining types here. This will result in some double maintenance until 0.72 but will give community time to move off of types/react-native.
After this lands, there have been changes on `main` of types that we need to update. Then, when we release 0.71 from DefinitelyTyped, we can simply copy over the `types` folder from this repo.
Pull Request resolved: https://github.com/facebook/react-native/pull/34614
Test Plan:
`yarn run test-typescript` for linting types
* Created a new project using the TS template and my local clone of `react-native` on this branch.
`npx react-native init MyTSApp --version <path-to-my-local-rn-repo> --template react-native-template-typescript`
* Updated the `package.json` to remove `types/react-native`
* Deleted my node_modules and re-ran yarn
* Opened MyTSApp in VSCode and verified the type suggestions appeared and cmd+click to defnitions took me to the node_module dependency `react-native/types`
## Danger is failing on this PR and it's expected
as it runs off the changes on `main`. [This is expected](https://docs.github.com/en/github-ae@latest/actions/using-workflows/events-that-trigger-workflows?fbclid=IwAR2_AE0Jwndt8Gu-iTQnxGxLJq7nakbi7sz8jwZ6U62JWLSdcZuvjcQ6WvE#pull_request_target). However testing it locally passes. Once merged, and these changes are on `main`, danger will pass again.
```
$ react-native/packages/react-native-bots
❯ yarn danger pr https://github.com/facebook/react-native/pull/34614
yarn run v1.22.19
$ ..react-native/node_modules/.bin/danger pr https://github.com/facebook/react-native/pull/34614
Starting Danger PR on facebook/react-native#34614
Danger: ✓ found only warnings, not failing the build
## Warnings
🔒 package.json - <i>Changes were made to package.json. This will require a manual import by a Facebook employee.</i>
✨ Done in 13.24s.
```
Reviewed By: mdvacca
Differential Revision: D39479137
Pulled By: lunaleaps
fbshipit-source-id: 1d506f812d566b783b6e79104cd6339b077a42a7
Summary:
This diff updates the documentation for enableCppRenderSystem feature flag
This is a follow up of D38725771 (https://github.com/facebook/react-native/commit/399907fe4ad843ac6aa0aa2f553ba3aee3c83006)
changelog: [internal] internal
Reviewed By: cortinico, makovkastar
Differential Revision: D39558834
fbshipit-source-id: e079ee688a912dfa2670c66e5adf347a902a45e1
Summary:
This diff moves Component and ComponentManager classes -> react/cxxcomponents. The purpose is to be able to use these classes from any platform, not only Android
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D39531533
fbshipit-source-id: 4732aa7bf59d82dae11441212975f0e225c6d458
Summary: Changelog: [Internal] Add flow declaration for Alert. Couldn't figure out how to do type statics on interfaces in Flow.
Reviewed By: yungsters
Differential Revision: D39186533
fbshipit-source-id: 928ee76080490a133c9773d2330473a688e0612d
Summary:
Upgrades all of our JavaScript tooling to use `yargs@^17.5.1`.
Of all [release notes](https://github.com/yargs/yargs/releases), these are the major version notes:
- [v17.0.0](https://github.com/yargs/yargs/releases/tag/v17.0.0)
- [v16.0.0](https://github.com/yargs/yargs/releases/tag/v16.0.0)
A cursory inspection suggests that these breaking changes are unlikely to seriously impact our use cases (or can be fixed forward).
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D39550338
fbshipit-source-id: 5b2c5265f8c7a95ab0cc9bab62873f9e4355f32f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34694
TL;DR Relax the assumption of having git to build the RN NPM package.
We do have two CI Systems: CircleCI for OpenSource and Sandcastle for Internal. It's crucial that the two CIs are aligned.
We currently don't have a way to test the new app template on Sandcastle for Android & iOS.
This results in scenarios where internal Diffs gets landed and break the public CI externally.
This is preparation work to then be able to build the RN NPM package in Sandcastle (which will be done in a follow-up diff).
With this we also introduce the restoring of all the changed files after the publishing script is done.
## Changelog
[Internal] [Added] - Made it possible to create publishing NPM packages in Sandcastle.
Reviewed By: cortinico, cipolleschi
Differential Revision: D39467471
fbshipit-source-id: b0de88a768b8a2fb798dd684fa8f97f4d0acb751
Summary:
Adds changelog for new patch.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - add changelog entry for 0.70.1
Pull Request resolved: https://github.com/facebook/react-native/pull/34702
Test Plan: N/A
Reviewed By: lunaleaps
Differential Revision: D39550336
Pulled By: dmytrorykun
fbshipit-source-id: 4e6ff93fb419bf08b4c5b1f88312591d79bd3e29
Summary:
This diff creates a new Feature Flag to Enable/Disable C++ Render System in JS
Changelog: [Internal] Internal
Reviewed By: sammy-SC
Differential Revision: D38725771
fbshipit-source-id: 3a238781bec427274dbd8f7c045d360135d1803e
Summary:
This diff integrates the registration of C++ component into React Native Android
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D38725769
fbshipit-source-id: 33eb9ebb93983c4038529748758eac3e43eec3e5
Summary:
CppViewMutationWrapper is a class that will be used to execute operations to mutate C++ Components in React Native Android
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D38725765
fbshipit-source-id: 3dfe11deb873750a78f6dbbaee82b62134908de4
Summary:
This diff introduces the APIs that will be used to register C++ components in React Native Renderer for Android
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D38725768
fbshipit-source-id: a7116b787f83544282230666d9d5acbfb1df4047
Summary:
Customize gradle/buck to be able to build fabric C++ components files
changelog: [internal] internal
Reviewed By: cortinico, sammy-SC
Differential Revision: D39448416
fbshipit-source-id: 3beddf27082728e2316e483c2541c7405e4c57f7
Summary:
Update our internal tests to use Jest 27. If this sticks, we should follow up with updating the RN template.
Changelog:
[Internal][Fixed] Update Jest setup to v27.5.1
Reviewed By: motiz88
Differential Revision: D39383717
fbshipit-source-id: 0fbb5a7b1ab70ccbfaed22b2de92f445f756afe0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34690
While working on another part of the codebase I realized that
our Unit Tests are not compiling due to references to missing classes.
I'm cleaning them up + hooking the compileTest task inside the
`buildAll` task so at least they will be compiled on both CIs.
Changelog:
[Internal] [Changed] - Make the Android unitTests compile
Reviewed By: cipolleschi
Differential Revision: D39501945
fbshipit-source-id: 03d3e4872d6c738b8b85d1fef9302ac230e857d2
Summary:
Adding support for application to hook into further tracing methods
## Changelog
[General][Added] - Add additional Systrace support
Reviewed By: NickGerleman
Differential Revision: D38673212
fbshipit-source-id: 55a90a0cd57809bca5f01da7acddcf253e5852ba
Summary:
Changelog: [Internal] Remove unused RuntimeExecutor from UIManagerBinding constructor
Since [UIManager is the class that has a reference to RuntimeExecutor](https://github.com/facebook/react-native/blob/ce50c43986bae05ad62552be46f4d5bb4a46f097/ReactCommon/react/renderer/uimanager/UIManager.h#L35-L36), there's no reason for `UIManagerBinding` to own a reference to RuntimeExecutor too.
The purpose of `UIManagerBinding` is to bind the Fabric `std::shared_ptr<UIManager>` in C++ to `global.nativeFabricUIManager` in JS.
Doing this cleanup to make the next diff easier.
Reviewed By: sammy-SC
Differential Revision: D39490927
fbshipit-source-id: 4c393dccc6985bef44e3b0afc32b9f79bea25f80
Summary:
We already support attaching-on-reload when a debugger was a previously connected, and this connection logic seems to slow down app startup by 2 seconds in debug mode when running on device.
Changelog:
[Internal][Removed]
Reviewed By: jpporto
Differential Revision: D39272704
fbshipit-source-id: deb8651798cb9a13b81e1703920d3f9bd58869d2
Summary:
This task has been created T131775291 that blames D39268920 (https://github.com/facebook/react-native/commit/f1c1f8116ba1cfa9d10c5b8c30b98b796047b9c2). I reverted part of the changes and added the support of capital letters for the font weight. It should make the test pass.
However, I am a bit puzzled: I tried to change the title of the `GemstoneTitleBar` and the test was not showing the changed value. I think I'm missing something.
Changelog: [Internal]
Reviewed By: GijsWeterings
Differential Revision: D39478951
fbshipit-source-id: d3e28336fe52c5c58b49872c3f5b6e63e1e37ca5
Summary:
When `getItemLayout` is not supplied, VirtualizedList doesn't know the measurements for its child items ahead of time. It caches most recent cell measurements so that an item which is virtualized away is associated with its correct height. VirtualizedList will not consume space for an item it has not yet rendered/knows measurements for.
This also means an initially created list will only take up the height of its `initialNumToRender()`. This can cause scroll jumping for the scenario of nested VirtualizedLists of the same orientation, since a virtualized away child list will shrink (compared to the spacer), then re-expand, once returned to.
There is logic in the VirtualizedList constructor to load cached frame metrics based on supplied listKey, to enable reloading most recent state. Though locally it seems to be reading the context too early in the lifecycle (compared to other successful checks during componentDidMount, render). It was moved from `componentDidMount` to `constructor` as part of the initial change (https://www.internalfb.com/diff/D6330846 (https://github.com/facebook/react-native/commit/2668dc8e1be7bf93e65ca2e11c87cbeef3310c3e)?dst_version_fbid=131968984136932&transaction_fbid=1578362385612542), and I think has likely been unreliable or dead since.
Restoring state was the only usage of a durable key for nested lists beyond their lifetime. So removing the dead code lets us remove the need for a `listKey`, which has been error-prone. This still leaves the problem present since inception, but there may be alternate solutions like scroll anchoring.
Changelog:
[Internal][Removed] - Remove dead code for restoring state to nested VirtualizedList
Reviewed By: ryancat
Differential Revision: D39466678
fbshipit-source-id: fc2f39802e5cdf9b920974333be64c74211b99a9
Summary:
This updates `fontVariant` to support space-separated string values, i.e., `'small-caps common-ligatures'`, thus aligning it with the [CSS Fonts Module Level 4](https://drafts.csswg.org/css-fonts/#font-variant-prop) specification as requested on https://github.com/facebook/react-native/issues/34425. This also adds unit tests to the `processFontVariant` function ensuring the style processing works as expected.
## Changelog
[General] [Added] - Add space-separated string support for fontVariant
Pull Request resolved: https://github.com/facebook/react-native/pull/34641
Test Plan:
This can be tested either through `processFontVariant-tests` or by using the following code:
```js
<Text
style={{
fontVariant: 'small-caps common-ligatures',
}} />
```
Reviewed By: javache
Differential Revision: D39423317
Pulled By: cipolleschi
fbshipit-source-id: ad971addb423ed338e178528a11fe9d456c03e6e
Summary:
This Diff adds a couple of APIs to the `react_native_pods.rb` file to simplify further the migration to the New Architecture for the iOS app.
Specifically, it aims to simplify [this](https://reactnative.dev/docs/next/new-architecture-app-intro#ios---build-the-project) steps by offering a RN-managed min version and creating the .xcode.env file for the user if it is missing.
## Changelog
[iOS][Added] - Add new API to simplify app migration
Reviewed By: cortinico
Differential Revision: D39469599
fbshipit-source-id: f0323e86c83c2731671fcd5bb4288071304bb43b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34670
Users can enable the New Architecture on iOS in two way: using the `RCT_NEW_ACRH_ENABLED` env variable or setting the `new_arch_enabled` flag when invoking the `use_react_native` function.
We need to set the `RCT_NEW_ACRH_ENABLED` even when the other method is used because we need to inject that flag into the codebase.
## Changelog
[iOS][Fixed] Make sure to turn on the `RCT_NEW_ACRH_ENABLED` flag
Reviewed By: cortinico
Differential Revision: D39430904
fbshipit-source-id: abb55642b4c72d7dec8b045fb4a43c1763f0ee0f
Summary:
This adds an example FlatList with nested children of both orientations. Debug text is shown for what is detected to be visible, and what is currently being rendered.
Changelog:
[Internal][Added] - Add Nested FlatList RNTester Example
Reviewed By: rshest
Differential Revision: D39466679
fbshipit-source-id: 5d6ce4adb9a862ca96b1a7b268b70101207d2980
Summary:
Small follow up to my template update. Using the namespace in the OnLoad.cpp
should prevent name clashing and make it easier to read.
Changelog:
[Android] [Changed] - Update the OnLoad.cpp to use the facebook::react namespace
Reviewed By: cipolleschi
Differential Revision: D39475773
fbshipit-source-id: 9c0748d37858196d4e8ea6674d9cfd6ef4eff1cd
Summary:
This diff removes the feature flag ReactFeatureFlags.enableSpannableCache and it's already disabled MC
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D39449840
fbshipit-source-id: 69a514b611c1179f2160a1bfd4c4199538738448
Summary:
Remove feature flag: ReactFeatureFlags.enableScrollEventThrottle
This feature has been disabled for a while
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D39449184
fbshipit-source-id: c5ad0d43462422d284e14302fb9d7b39aa37da70
Summary:
A previous change made the RuntimeAdapter contain a HermesRuntime (as opposed to an arbitrary JSI Runtime).
Now that it's known to be a HermesRuntime, expose that type information to the Inspector, so a runtime type check can be skipped (which is failing in some builds, despite the concrete type being what's expected).
Changelog: [internal]
Reviewed By: neildhar
Differential Revision: D39429109
fbshipit-source-id: ad5ae0604ac208da2002fd37e38d24319b45aebd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34671
I'm simplifying the template further by:
- Do not expose a configurable dynamic library name. Let's use `appmodules`
and still allow the users to configure it, if needed.
- Move all the initialization logic inside the `JNI_OnLoad` method
- Cleanup the `DefaultReactNativeHost` to don't require a dynamic library
name but just a boolean.
Changelog:
[Android] [Changed] - Further simplify the New App Template by don't requiring the dynamic library name
Reviewed By: cipolleschi
Differential Revision: D39462948
fbshipit-source-id: 737733fc263162a0baf3b7a451e48b8616679d3b
Summary:
This aligns the logic of setting style (width / height) and source of Android with iOS.
iOS handles nullish uris with set width and heigth by passing them through. Android did not.
## Changelog
[Android] [Fixed] - Align android image style / source logic with ios
Pull Request resolved: https://github.com/facebook/react-native/pull/34655
Test Plan:
```
<Image source={{width: 100, height: 100}} />
```
Before this Patch:
* iOS: Renders a blank image with 100x100
* Android: Renders a blank image with 0x0
After this Patch:
* iOS: Renders a blank image with 100x100
* Android: Renders a blank image with 100x100
Reviewed By: sammy-SC
Differential Revision: D39423391
Pulled By: cipolleschi
fbshipit-source-id: 997c06dea42e9b69fda12b678a1b82ad8319537f
Summary:
Fix invalid range "t-5" in string transliteration [iOS] for M1 pod install issue.
This should fix pod install error for M1 machines.
## Changelog
[iOS] [Fixed] - Fix ios pod install error
Pull Request resolved: https://github.com/facebook/react-native/pull/34636
Test Plan: Run pod install on M1 machine.
Reviewed By: sammy-SC
Differential Revision: D39423276
Pulled By: cipolleschi
fbshipit-source-id: 4ec95af7103395792facba0f93fd8de05a3fe78d
Summary:
The folder `/packages/react-native-codegen/android` is not existing anymore, I'm removing it.
## Changelog
[Internal] - Remove :packages:react-native-codegen:android from top level settings
Pull Request resolved: https://github.com/facebook/react-native/pull/34579
Test Plan: Will rely on a green CI
Reviewed By: cipolleschi
Differential Revision: D39440292
Pulled By: cortinico
fbshipit-source-id: 492722b1b697e0bf03cf2803b25fb9604cf0778a
Summary:
allow-large-files
When working on https://github.com/facebook/react-native/pull/34614, danger is failing because it doesn't share `node_modules` with the root directory where `typescript` is installed as we added it as a parser in our eslint config.
By setting `bots` as a yarn workspace, dependencies are all installed under the root `node_modules` folder and in local testing (detailed in test section) we no longer have the `typescript module not found` error. However, danger will continue to fail on https://github.com/facebook/react-native/pull/34614 as the `danger_pr` Github action runs from what's defined on `main`.
Once these changes land, I can rebase https://github.com/facebook/react-native/pull/34614 on it and danger's eslint should pass.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal][Fixed] - Add `bots` directory as a yarn workspace and update `danger_pr` Github action
Pull Request resolved: https://github.com/facebook/react-native/pull/34652
Test Plan:
To verify this fix I had to run:
```
react-native $ yarn && cd bots
react-native/bots$ yarn run danger pr https://github.com/facebook/react-native/pull/34614
```
which resulted in
```
❯ yarn run danger pr https://github.com/facebook/react-native/pull/34614
yarn run v1.22.19
$ lunaleaps/react-native/node_modules/.bin/danger pr https://github.com/facebook/react-native/pull/34614
Starting Danger PR on facebook/react-native#34614
Danger: ✓ found only warnings, not failing the build
## Warnings
🔒 package.json - <i>Changes were made to package.json. This will require a manual import by a Facebook employee.</i>
✨ Done in 12.78s.
```
Verified this also on another PR:
```
yarn run danger pr https://github.com/facebook/react-native/pull/34650
```
Reviewed By: NickGerleman
Differential Revision: D39435286
Pulled By: lunaleaps
fbshipit-source-id: 8c82f49facf162f4fc0918e3abd95eb7e4ad1e37
Summary:
Changelog:
[General][Fixed] In RN devtools, call that method, and then set component state to not inspecting.
Reviewed By: lunaruan
Differential Revision: D38852009
fbshipit-source-id: d14bd4cc4461f0f7ec4ae9cd6098a58eef3e6ab9
Summary:
Changelog:
[General][Fixed] - Currently selectNode doesn't work for Fabric. Passing the instance instead of a tag to `selectNode` works.
Reviewed By: lunaruan
Differential Revision: D38851141
fbshipit-source-id: 7640d0f31fb099346a4d8205981e262da6be4990
Summary:
PlatformColor should work on all *color style attributes on all platform.
Partially fixes https://github.com/facebook/react-native/issues/32942
## Changelog
[Android] [Fixed] - Support PlatformColor in borderColor
Pull Request resolved: https://github.com/facebook/react-native/pull/33544
Test Plan: Open rn tester (USE_FABRIC=false) platform color api examples. Without the changes to ViewProps.java, it will error out.
Reviewed By: lunaleaps
Differential Revision: D39413519
Pulled By: NickGerleman
fbshipit-source-id: 58962ba2956aa3df45144108eec194aedf23886b
Summary:
Changelog: [RNTester][Internal] - Add "move across" test for pointer events
This diff adds a new platform test ported from the wpt's [mousemove-across test](https://github.com/web-platform-tests/wpt/blob/master/uievents/order-of-events/mouse-events/mousemove-across.html) along with a rough port of the wpt's event recorder class which is made to work in a react component environment.
Reviewed By: lunaleaps
Differential Revision: D39221252
fbshipit-source-id: 16b2e03dbc71a2e83cc43af1e950803feaf6657b
Summary:
`getSize` should resolve with an array of `[width, height]` but this mock resolves with `{ width, height }`.
It should be `ReadOnlyArray<number>` instead of `{width: number, height: number}`
The native image loader call is [here](https://github.com/facebook/react-native/blob/main/Libraries/Image/NativeImageLoaderIOS.js#L18):
```js
+getSize: (uri: string) => Promise<$ReadOnlyArray<number>>;
```
but in the [jest setup file](https://github.com/facebook/react-native/blob/main/jest/setup.js):
```js
getSize: jest.fn(url => Promise.resolve({width: 320, height: 240})),
```
My tests were failing on `Image.getSize()` - `TypeError: Invalid attempt to destructure non-iterable instance.`
I managed to trace this down to this object being returned by the Jest mock - looks like it's returning a size object instead of a dimensions array.
## Workaround
If you are hitting this issue, you can work around this mock by using:
```js
ReactNative.NativeModules.ImageLoader.getSize = jest.fn((_) => Promise.resolve([320, 240]));
```
## Changelog
[JavaScript] [Changed]: Changed the mocked return value of `ImageLoader.getSize` to be `[320, 240]` instead of `{ width: 320, height: 240 }`
Pull Request resolved: https://github.com/facebook/react-native/pull/34653
Test Plan: TBD? I think a test with `Image.getSize(path)` will cover it. That's where I hit the error with the ios-specific imageLoader's getSize method.
Reviewed By: robhogan
Differential Revision: D39413522
Pulled By: NickGerleman
fbshipit-source-id: 7f18d7acde0cf94da0b4aec8fe2d0cad3fb0cc55
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34666
This diff updates the new app template and reduces the amount of C++ code in user space.
From now on users will have to only:
1. Create a CMakeLists.txt file
2. Create an OnLoad.cpp file with the Modules/Components they want to provide.
Changelog:
[Android] [Changed] - Update the template to Reduce the amount of C++ code in user space for New Architecture
Reviewed By: cipolleschi
Differential Revision: D39381762
fbshipit-source-id: 7309b6c61ba9ddd8856cb4aaa6d923ddd816741c
Summary:
This diff reduces the amount of C++ code in user space by:
- Moving all the C++ implementation of the .defaults package inside a `react_newarchdefaults` shared library
- Exposing only the entrypoint logic inside the RN-Tester's `OnLoad.cpp` file.
Changelog:
[Android] [Changed] - Reduce the amount of C++ code in user space for New Architecture
Reviewed By: cipolleschi
Differential Revision: D39381820
fbshipit-source-id: 9c4b5596b67b5a7ee58824319c80e325348ed06c
Summary:
https://www.internalfb.com/T131530362
We are testing the New App template in CircleCI.
For Android we test the combination of Debug/Release and Old/New Architecture, and always use the Hermes engine.
We don't test the JSC engines (in iOS this is already happening).
We're not automatically testing that we can create a new project with JSC, forcing release managers to do it manually.
## Changelog
[Android] [Added] - Automatic testing of the new project template with the JSC engine.
Pull Request resolved: https://github.com/facebook/react-native/pull/34664
Test Plan:
- Open the circle-ci dashboard
- Verify there are now 8 jobs adeed to the pipeline:
```
test_android_template-Debug-Hermes-false
test_android_template-Debug-Hermes-true
test_android_template-Debug-JSC-false
test_android_template-Debug-JSC-true
test_android_template-Release-Hermes-false
test_android_template-Release-Hermes-true
test_android_template-Release-JSC-false
test_android_template-Release-JSC-true
```
- Verify they are all passing.
Reviewed By: cortinico
Differential Revision: D39426388
Pulled By: vincenzovitale
fbshipit-source-id: e5d606b1cc3ace53f8dab0f7d6d7d06ab11a2b46
Summary:
Changelog: [Internal] - Stop dispatching pointer events when a child view has indicated it wants to handle a native gesture.
In discussion and alignment with web standards, we've decided to not dispatch any pointer events during a native gesture.
Currently, on ACTION_HOVER_MOVE, we remove child views of the native gesture handling view and continue dispatching onPointerMove for ancestor views. This change removes this logic and won't dispatch a onPointerMove event at all.
For all other MotionEvent actions, this is already the case.
Also adding an example in RNTester that involves a scrollView (which handles gestures during scrolling)
Reviewed By: javache
Differential Revision: D39377157
fbshipit-source-id: cb0a719f67136e31b68d6f6e794fee10b256bf21
Summary:
Jest 27 [flips defaults](https://jestjs.io/blog/2021/05/25/jest-27#flipping-defaults), making "modern" fake timers (ie, `sinonjs/fake-timers`) the default, over "legacy", which we currently use.
We're not quite ready for modern timers yet, partly due to Promise polyfills (https://github.com/facebook/react-native/pull/34659), and also some internal issues with specific tests.
This makes our use of legacy timers explicit in preparation for an update to Jest. A switch to modern timers may follow later.
Changelog:
[Internal][Changed] - Prepare for Jest 27+ by making legacy fake timer use explicit
Reviewed By: jacdebug
Differential Revision: D39383719
fbshipit-source-id: 6a3dc6f8547cc76f7702a5a39c9b30a184303f17
Summary:
When I moved the C++ file around I only updated the Android-prebuilt.cmake
I haven't update the Android.mk equivalent. I'm doing it here.
Changelog:
[Internal] [Changed] - Update Android-prebuilt.mk to use the correct paths for turbomodule & fabricjni
Reviewed By: cipolleschi
Differential Revision: D39397567
fbshipit-source-id: f9f412ef4a9402f9528414af24eac06a0657f6f5
Summary:
This test currently uses `jest.runAllTicks()` to execute cached, immediately-resolving promises, under Jest "legacy" timers (the RN default) - this works only because [we polyfill Promise](https://github.com/facebook/react-native/blob/main/jest/setup.js#L24) using a userland JavaScript implementation that internally uses mocked-out timer functions.
Here we change to a more universal approach by adding a new microtask/promise to the end of the queue and awaiting it.
This allows us to remove our Promise polyfill from Jest setup (to follow).
Changelog:
[Internal][Fixed] - Prepare `LogBoxLog-test.js` for native promises
Reviewed By: huntie
Differential Revision: D39418413
fbshipit-source-id: 1384ef385b1e10261754513369af8997d296ffea
Summary:
This test was causing uncaught promise rejections, because the mocked `symbolicateStackTrace` in this test returns a different type from the real one, causing `LogBoxSymbolication`'s unawaited, cached promises to reject.
This wasn't picked up as a test failure because our `promise` polyfill silently swallows uncaught rejections, but it does cause a failure if we use native promises in tests.
Changelog:
[Internal][Fixed] - Fix LogBoxSymbolication-test.js
Reviewed By: huntie
Differential Revision: D39418412
fbshipit-source-id: 0be8f1551c4a58dc47faf1597caf47271af40af2
Summary:
This PR adds support for number values for `fontWeight` as requested in https://github.com/facebook/react-native/issues/34425.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[General] [Added] - Added support for number values in fontWeight.
Pull Request resolved: https://github.com/facebook/react-native/pull/34598
Test Plan:
```js
<Text style={{ fontWeight: 900, color: 'red' }}>
Hello World
</Text>
```
Reviewed By: jacdebug
Differential Revision: D39268920
Pulled By: cipolleschi
fbshipit-source-id: 9bb711677bf173f9904b74f382659042856efd83
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34514
Changelog: [Internal][iOS] Modularlize RCTBridgeModule.h 3/n - Move RCTTurboModuleRegistry.h to its own file in ReactInternal target
# Why clean up RCTBridgeModule.h?
Clean up one unnecessary import of RCTBridgeModule.h.
RCTBridgeModule includes a lot of header files, and this header is imported everywhere. The ultimate goal is that files (especially React Native infra files) should only import only what they need and not import the entirety of RCTBridgeModule.h whenever possible.
This way, certain headers that are Bridge-only can be compiled out of the new architecture with a flag.
Reviewed By: RSNara
Differential Revision: D38971168
fbshipit-source-id: 3b1b23d422f965a5a14bc4178d32b844906f2c8b
Summary:
This adds the `id` prop to `Text`, `TouchableWithoutFeedback` and `View` components as requested on https://github.com/facebook/react-native/issues/34424 mapping the existing `nativeID` prop to `id`. As this components are inherited by others this also adds the `id` prop support to `Image`, `TouchableBounce`, `TouchableHighlight`, `TouchableOpacity` and `TextInput`.
This PR also adds android tests ensuring that the `id` property is passed to the native view via the `nativeID` prop, these tests were based on the existing `nativeID` tests ([NativeIdTestCase.java](https://github.com/facebook/react-native/blob/main/ReactAndroid/src/androidTest/java/com/facebook/react/tests/NativeIdTestCase.java)).
## Changelog
[General] [Added] - Add id prop to Text, TouchableWithoutFeedback and View components
Pull Request resolved: https://github.com/facebook/react-native/pull/34522
Test Plan: Ensure that the new `id` prop android tests pass on CircleCI
Reviewed By: lunaleaps
Differential Revision: D39089639
Pulled By: cipolleschi
fbshipit-source-id: 884fb2461720835ca5048004fa79096dac89c51c
Summary:
Changelog: [internal]
This brings back a fix for ScrollView on iOS that we removed because we thought it was no longer necessary, but it actually is.
Reviewed By: jacdebug
Differential Revision: D39382967
fbshipit-source-id: f052b4fb899f4e60e8c530990caf07344a907c43
Summary:
1. In some situation (I don't know exactly how it is triggered but I found that during porting it to `react-native-windows`), `ExportNamedDeclaration.exportKind` is missing. Just skip the checking to `exportKind` because the rest of the checking is sufficient without reading this field.
2. Add `TSParenthesizedType` to module codegen in TypeScript, so that type `(T)` is treated like `T`.
## Changelog
[General] [Changed] - codegen: support TypeScript type `(T)` for turbo module codegen (module only)
Pull Request resolved: https://github.com/facebook/react-native/pull/34621
Test Plan: `yarn jest` passed in `packages/react-native-codegen`
Reviewed By: RSNara
Differential Revision: D39322001
Pulled By: cipolleschi
fbshipit-source-id: 1855711da7062a065c05a10f275e26baa88cf75f
Summary:
changelog: [internal]
preemtive view allocation has been disabled on iOS for over a year. We kept the code in but didn't do anything with it. This diff removes the code and related mobile config.
Post where we decided to turn preemtive view allocation off: https://fb.workplace.com/groups/215742978987717/permalink/832644567297552/
jest_e2e[run_all_tests]
Reviewed By: mdvacca
Differential Revision: D37922589
fbshipit-source-id: 1af8949cbbd9d48a2d80ca238b280178cbe2ead5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34619
When it comes to migrate existing libraries, users needs to update their .podspec files with a bunch [of changes](https://reactnative.dev/docs/0.69/new-architecture-library-ios#add-folly-and-other-dependencies).
This diff groups those changes in a single function, so that contributors can just invoke that function to prepare their dependencies.
## Changelog
[iOS][Changed] - Add function to simplify podspecs
Reviewed By: cortinico
Differential Revision: D39312203
fbshipit-source-id: ed631839e07d472a1fdcba33310f9b1d94fe2fd7
Summary:
For some reason the turbomodule example inside RN Tester was not enabled by default. I'm enabling it.
Changelog:
[Internal] - Always enable TurboModuleExample for RN Tester
Reviewed By: cipolleschi
Differential Revision: D39381821
fbshipit-source-id: 711c20a51a2f3b274f1b9396d00898b0f60a6f86
Summary:
Pull request https://github.com/facebook/react-native/issues/34251 only partially worked because I didn't notice that there is ` 1` after the snapshot name. In this change I fixed the issue and find out there is one case that Flow and TypeScript parser generate different result.
It is expected since the test inputs are different. TypeScript removes one member because there is no `{...X, ...}` type in TypeScript. We could make the codegen support intersection type and rewrite it to `X & {...}`, but this will not be included here anyway.
## Changelog
[General] [Changed] - codegen: ensure equivalent Flow and TypeScript TM definition generates the same output
Pull Request resolved: https://github.com/facebook/react-native/pull/34620
Test Plan: `yarn jest` passed in `packages/react-native-codegen`
Reviewed By: NickGerleman
Differential Revision: D39321965
Pulled By: cipolleschi
fbshipit-source-id: aec60f5c9c18323cbd833bf5705af544d7db2e73
Summary:
With the IDE autocompletion now working \o/ I was able to apply some suggestions
to the Kotlin code I wrote inside the .defaults package (like remove redudant qualifiers and similar).
Changelog:
[Internal] [Changed] - Cleanup the Kotlin code in the .defaults package
Reviewed By: cipolleschi
Differential Revision: D39348983
fbshipit-source-id: b443a6be179c85d2a4f4293051c4f26af93eb5f1
Summary:
This adds a a couple of tests to run existing behavior where VirtualizedList avoids batched renders until it has seen scroll metrics when the list is not initialized to the zero position.
Changelog:
[Internal][Added] - Add VirtualizedList tests for handling non-zero initialScrollIndex before scroll metrics
Reviewed By: yungsters
Differential Revision: D39247250
fbshipit-source-id: 530f58f9c7421949c388048c376fc5b0ab7835d9
Summary:
Changelog: [Internal] Move Bridge-only constants into a separate file
- Move Bridge only constants from RCTBridge.h into RCTBridgeConstants.h.
- Move shared constants from RCTBridge.h into RCTConstants.h.
This way, new architecture does not need to import RCTBridge.h just for the constants.
Reviewed By: sammy-SC
Differential Revision: D39085713
fbshipit-source-id: 40177cbed72a326b40ec448c98751d1dd3464504
Summary:
In an app using `UIScene`, `Alert` no longer pops up because the window
that gets created are not attached to a scene.
## Changelog
[iOS] [Fixed] - Fix `Alert` not showing in an app using `UIScene`
Pull Request resolved: https://github.com/facebook/react-native/pull/34562
Test Plan: Use the test plan in https://github.com/facebook/react-native/issues/29295. This should not regress that fix.
Reviewed By: cipolleschi
Differential Revision: D39276976
Pulled By: lunaleaps
fbshipit-source-id: e48e985ed4abec77d6f01a6c17292d664ed88f13
Summary:
This PR aims to add support for objectFit a partial equivalent to the resizeMode style and prop of Image.
## Changelog
[General] [Added] - Add support for objectFit style of Image.
Pull Request resolved: https://github.com/facebook/react-native/pull/34576
Test Plan:
1. Open the RNTester app and navigate to the Image page
2. See the Object Fit section.

Reviewed By: rickhanlonii
Differential Revision: D39261176
Pulled By: jacdebug
fbshipit-source-id: 1eefd76b6c11ed5fc52b2c524ad78c91051077f6
Summary:
Changelog: [internal]
This replaces all direct references to the `ReactNative` module (which is the Paper renderer) to `RendererProxy` which would select between Paper and Fabric correctly.
The implementation of these functions is exactly the same right now.
As per the removal of the fix for T55744311 in `ScrollView`, I verified this doesn't cause any issues in the screen where it failed before.
Reviewed By: javache
Differential Revision: D39270691
fbshipit-source-id: 03882748fe4b754b9a2c5e9d4c4f003b94ed49ef
Summary:
This replaces all direct references to `ReactNative` within the `react-native` package to use `findNodeHandle` with a reference obtained from `RendererProxy`, which will allow us to select the correct renderer.
Changelog: [internal]
Reviewed By: javache
Differential Revision: D39270689
fbshipit-source-id: a39875281ba7b7b1b00128564124b6adcacebc4d
Summary:
This diff creates a proxy module to interact with the React Native renderer. The goal of this proxy is to decouple usages of several functions (e.g.: `findNodeHandle`, etc.) from the actual renderer used in an app. This way, we can easily switch between renderers without having to change code depending on it.
This will be useful to remove a specific renderer from an app bundle when it's no longer used (e.g.: Paper on the Facebook App).
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D39205975
fbshipit-source-id: 05289c0c3c8cd26d81aa1d2163097c73ec40c6ad
Summary:
The `Systrace` module implements a polyfill for the User Timing API that's:
1. Incompatible with the Web standard. This polyfill expects `performance.mark` and `performance.measure` to be used exactly like `Systrace.beginEvent` and `Systrace.endEvent` respectively. If not used like those functions, they throw an error at runtime, which is really bad.
2. Never actually used. See below.
This polyfill is only installed if we're actually profiling on startup:
https://www.internalfb.com/code/fbsource/[4d888a933920]/xplat/js/react-native-github/Libraries/Core/setUpSystrace.js?lines=17-21
While the only code that we have that uses this API is actually not installed if we're profiling:
https://www.internalfb.com/code/fbsource/[4d888a933920]/xplat/js/react-native-github/Libraries/Core/setUpDeveloperTools.js?lines=20-21
This should be safe to remove then.
We have plans to add proper support for this API in the short term, so this also gets out of the way of doing that.
Additionally, installing this polyfill was the only reason why we had `setupSystrace`, so we can get rid of that too :)
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D39210813
fbshipit-source-id: a90b6237c311d2157069b41975d10b33f1f464ef
Summary:
This unifies the Android only `autoComplete` and the iOS only `textContentType` TextInput props with the web `autoComplete` values as requested on https://github.com/facebook/react-native/issues/34424. I left the `textContentType` prop and the current supported `autoComplete` values untouched in order to avoid having a breaking change. This also updates RNTester to include test cases using the new `autoComplete` values
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[General] [Changed] - Unify TextInput autoComplete and textContentType props
Pull Request resolved: https://github.com/facebook/react-native/pull/34523
Test Plan:
1. Open the RNTester app and navigate to the TextInput page
2. Test the `TextInput` component through the `Text Auto Complete` section
https://user-images.githubusercontent.com/11707729/187118267-3b509631-7b84-47b7-a580-567a7f5b483f.mov
Reviewed By: NickGerleman
Differential Revision: D39104545
Pulled By: cipolleschi
fbshipit-source-id: a0d4b1b9ab336854a741a9efe4a62c3da0b5c0f4
Summary:
This adds `aria-live` alias for `accessibilityLiveRegion`, it unifies aria-live and accessibilityLiveRegion and also maps `aria-live='off'` to `accessibilityLiveRegion='none'` as requested on https://github.com/facebook/react-native/issues/34424
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[General][Added] - Added aria-live alias for accessibilityLiveRegion.
Pull Request resolved: https://github.com/facebook/react-native/pull/34555
Test Plan:
```js
<View aria-live="polite">
<Text>Clicked {this.state.count} times</Text>
</View>
<View aria-live="off">
<Text>Clicked {this.state.count} times</Text>
</View>
```
Reviewed By: cipolleschi
Differential Revision: D39206291
Pulled By: jacdebug
fbshipit-source-id: fd2019e7047ff7ff6133fed39f1a70b5a9396f89
Summary:
The keys of the current debian version expired again. This PR is an attempt to use a different version
## Changelog
[General] [Fixed] - Update debian version
Pull Request resolved: https://github.com/facebook/react-native/pull/34634
Test Plan: CircleCI is green
Reviewed By: sammy-SC
Differential Revision: D39350344
Pulled By: cipolleschi
fbshipit-source-id: 6c77cc60cbc56a9fe8362ffa0472f96bce58b28e
Summary:
Noticed this marker was not properly ended in the case where an early return happens. The fact that that early return is happening there is problematic too, so added a warning to follow-up on.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D39271917
fbshipit-source-id: 86dd5b1a46978629584f7cb0d615f2ad99d5a2f8
Summary:
FillRateHelper accesses frame metrics based on passed state/cellsAroundViewport on scroll. cellsAroundViewport may be [0, -1] for no items. Usually this is captured by the check that item count is zero, but it is possible to have items without yet expanding state to render the items. This adds a check to bail early if we are not yet rendering any viewport-related cells.
Also renamed "state" to "cellsAroundViewport" for more consistent naming with the new list, where it is no longer the only state.
Reviewed By: javache
Differential Revision: D39345705
fbshipit-source-id: 198ab46ff2c8e8fe64076c9150edd4914dd745d7
Summary:
UIImplementation(Provider) is not compatible with the new renderer (Fabric) and the relevant constructors have been marked deprecated for a while. While ReactInstanceManagerBuilder creates a default instance, it's not even used by CoreModulesPackage.
Changelog: [Android][Removed] Removed deprecated UIImplementationProvider
Reviewed By: NickGerleman
Differential Revision: D39271916
fbshipit-source-id: 20a3b02843ea9a2ba4bfc1352037239febbafc64
Summary:
Currently for codegen to work for a library on iOS, it needs to be located
inside `node_modules`. This patch adds support for libraries defined in
`react-native.config.js`.
This is useful when developing libraries as well as monorepos where the library
may exist outside of the `node_modules`.
Example:
```js
// react-native.config.js
const path = require('path');
module.exports = {
dependencies: {
'react-native-library-name': {
root: path.join(__dirname, '..'),
},
},
};
```
## Changelog
[Internal] [Added] - Support custom library paths in `react-native.config.js` for codegen on iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/34580
Test Plan:
Tested on a test application and ensured that codegen finds the library specified in `react-native.config.js`
https://user-images.githubusercontent.com/1174278/188141056-bce03730-2a13-4648-8889-9727aaf2c3c4.mp4
I have also added a basic test case for this scenario.
Reviewed By: jacdebug, cortinico
Differential Revision: D39257919
Pulled By: cipolleschi
fbshipit-source-id: 131189f1941128a59b9b1e28af61a9038eb4536b
Summary:
This adds support for the `userSelect` style attribute, mapping the already existing selectable attribute as requested on https://github.com/facebook/react-native/issues/34425. This PR also updates the TextExample.android and TestExample.ios on the RNTester in order to facilitate the manual QA of this.
## Changelog
[General] [Added] - Add support for `userSelect` style
Pull Request resolved: https://github.com/facebook/react-native/pull/34575
Test Plan:
- open the RNTester app and navigate to the Text page
- Check the `Selectable Text` through the Selectable text section
<Image src="https://user-images.githubusercontent.com/22423684/188112863-65acd145-76b0-47ba-8bc6-f72298077096.png" height="600" width="300" />
Reviewed By: yungsters
Differential Revision: D39252798
Pulled By: jacdebug
fbshipit-source-id: f7fabf20ee68778d75461f511c56f94d0d756d9c
Summary: VirtualizedList would more gracefully handle out of range cells than VirtualizedList_EXPERIMENTAL, which treats it as an invariant violation. D39244112 (https://github.com/facebook/react-native/commit/7aa203beda3cd358703c2fa535ed045771761612) attempted to fix an issue where recalculation of cells around viewport can include out of range cells, but it is still showing up later. This change adds a bounds check to the remaining branch we control, and an assertion that `computeWindowedRenderLimits` is not returing something out of range to discover if that is the cause.
Reviewed By: yungsters
Differential Revision: D39267445
fbshipit-source-id: 64c99da28b5b01ef61784079b586e355f73764a1
Summary:
Non-integer `initialScrollIndex` or values to `scrollToIndex` would produce a reasonable result, with the caveat that it always falls back to layout estimation (will only be correct when all items are the same size), and breaks if getItemLayout() is supplied. It has usage though, so this diff adds proper support for non-integer scrollIndex, to offset a given amount into the length of the specific cell.
This overlaps a bit with the optional `viewOffset` and `viewPosition` arguments in `scrollToIndex`, but there isn't really the equivalent API for `initialScrollIndex`.
Changelog:
[General][Added]- Add proper support for fractional scrollIndex in VirtualizedList
Reviewed By: yungsters
Differential Revision: D39271100
fbshipit-source-id: 4d93887eed4497e9f6abcd1a6117ac7fdaebf2b1
Summary:
D38460203 (https://github.com/facebook/react-native/commit/e6ef0836c132d6b798e2ff1fc1e1a66c7e238e0b) was reverted because it broke OSS, the root cause is that OSS doesn't have MapBuffer module.
Fixed the issue in this diff by moving MapBuffer usage to fb internal class (FBReactModule) and will re-land.
Changelog:
[iOS][Changed] Replace Folly with MapBuffer for passing js error data
Reviewed By: sammy-SC
Differential Revision: D39210957
fbshipit-source-id: dda0e8c55dbd13bc96310e10a3b09ea53978e8bc
Summary:
This PR is for adding the support for `crossOrigin`, `referrerPolicy`, `width`, `height` and `srcSet` props to Image Component and mapping the `src` prop to `source.uri` of Image Component for the issue https://github.com/facebook/react-native/issues/34424. An example is also added in the RNTester ImageExample.
## Changelog
[General] [Changed] - Map the `src` prop to `source.uri` prop in Image Component.
[General] [Added] - added `crossOrigin`, `referrerPolicy`, `width`, `height` and `srcSet` props to Image Component.
Pull Request resolved: https://github.com/facebook/react-native/pull/34481
Test Plan:
1. Navigate to Image Component Example in the RNTester app.
2. Contains an example of the Image component using the `src` and `srcSet` prop.
3. For headers, inspect the Image request using Flipper.
<img src="https://user-images.githubusercontent.com/32268377/186153246-d7b72ce3-e082-46d9-87d1-aefacd3af34f.png" height="500" />
Reviewed By: christophpurrer
Differential Revision: D38982041
Pulled By: cipolleschi
fbshipit-source-id: dd6594e39b8f3b36cfcdafa35695254034f1fb7f
Summary:
## Summary
This PR adds expanded support for CSS Colors, as requested on https://github.com/facebook/react-native/issues/34425. It updates the current regex used to match the functional notation for colors, e.g `rgb()` to accept space as a valid separator between values as specified on [CSS Color Module Level 4](https://www.w3.org/TR/css-color-4/) definition. This also adds support for the `hwb` notation.
## Changelog
[General] [Added] - Add expanded support for CSS Colors
Pull Request resolved: https://github.com/facebook/react-native/pull/34600
Test Plan: We can test different color scenarios through the new test cases added to the already existing normalizeColor-test.js
Reviewed By: necolas
Differential Revision: D39269360
Pulled By: cipolleschi
fbshipit-source-id: 449158d17256bbab8bd9fd0da29245660225fb92
Summary:
The `JSDevSupport` module is incompatible with Fabric. Given it's not used internally and it's undocumented in OSS, we decided to remove it altogether.
Changelog: [Internal]
Reviewed By: javache, nlutsenko
Differential Revision: D39305892
fbshipit-source-id: 82455701a0b9ba83e6f971fc774280dceb2b22e0
Summary:
This adds the ` aria-hidden` prop to `Pressable`, `TouchableBounce`, `TouchableHighlight`, `TouchableNativeFeedback`, `TouchableOpacity`, `TouchableWithoutFeedback` and `View` components as requested on https://github.com/facebook/react-native/issues/34424, being an alias `importantforAccessibility='no-hide-descendants'` on Android and an alias for `accessibilityElementsHidden` on iOS. This PR also updates RNTester AccessibilityExample in order to facilitate the manual QA.
## Changelog
[General] [Added] - Add aria-hidden prop to Pressable, View and Touchables components
Pull Request resolved: https://github.com/facebook/react-native/pull/34552
Test Plan:
1. Open the RNTester app and navigate to the Accessibility page
2. Test the `aria-hidden` prop through the `View with hidden children from accessibility tree` section, this can be tested either by enabling Voice Over if you're using a real device or through the Accessibility Inspector if you're using a simulator
https://user-images.githubusercontent.com/11707729/187814455-6937e33e-7edd-434e-b7d3-ee6c03f635ca.mov
Reviewed By: NickGerleman
Differential Revision: D39206245
Pulled By: jacdebug
fbshipit-source-id: 551dc671fbcedc824f253e22b8d7753c466838c7
Summary:
This PR runs the Jest test for the Codegen package in CI.
## Changelog
[General] [Added] - Run Codegen Tests in CI
Pull Request resolved: https://github.com/facebook/react-native/pull/34596
Test Plan: CircleCI should show a new job for the tests. The job should be green.
Reviewed By: NickGerleman
Differential Revision: D39275645
Pulled By: cipolleschi
fbshipit-source-id: 29133c933f134802029406ff255b62d27681c8ff
Summary:
During the CoreContributor summit, we discovered that the `react-native-codegen` tests cannot be executed in the OSS due to this [issue with Jest](https://github.com/facebook/jest/issues/2567).
This PR moves the required variables inside the proper closure so that we can run tests in the OSS.
## Changelog
[General] [Fixed] - Enable the `react-native-codegen` tests in the OSS.
Pull Request resolved: https://github.com/facebook/react-native/pull/34594
Test Plan:
1. Run `yarn install` in the `react-native-codegen` folder.
2. Run `yarn jest`, see the test fail.
3. Apply the changes in this diff.
4. Run `yarn jest`, see the test pass.
Reviewed By: cortinico
Differential Revision: D39259164
Pulled By: cipolleschi
fbshipit-source-id: 7c4c0a7baa3c9b5e90a7ef75a37a0ec9d1b89db0
Summary:
changelog: [internal]
Add more clang tidy rules to prevent common class of bugs.
Reviewed By: javache
Differential Revision: D39245194
fbshipit-source-id: 5521c5c4653d7005b96ebba494e810ba5075afbc
Summary:
This PR adds some tests to verify that we can build the template in every Debug configuration using Flipper and without Flipper.
## Changelog
[iOS] [Added] - Add CircleCI tests to verify that we can run the Template with and without Flipper
Pull Request resolved: https://github.com/facebook/react-native/pull/34595
Test Plan: CircleCI is green
Reviewed By: cortinico
Differential Revision: D39262137
Pulled By: cipolleschi
fbshipit-source-id: dae45b106cd13fb69442ea216005cee114d861f4
Summary: VirtualizedList would more gracefully handle out of range cells than VirtualizedList_EXPERIMENTAL, which treats it as an invariant violation. This attempts to fix an issue where recalculation of cells around viewport can include out of range cells.
Reviewed By: rshest
Differential Revision: D39244112
fbshipit-source-id: 20fe6ea552035061d9d00720fcab77b29a785771
Summary:
# WIP
Adds changelog for new release.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - add changelog entry for 0.70.0
Pull Request resolved: https://github.com/facebook/react-native/pull/34202
Test Plan: N/A
Reviewed By: cortinico, cipolleschi
Differential Revision: D39258933
Pulled By: dmytrorykun
fbshipit-source-id: 3aa19301b47aa8cacd5afe35015c2820e96ab4fa
Summary:
This adds `pointerEvents` style which is equivalent to `pointerEvents` prop as requested in https://github.com/facebook/react-native/issues/34425
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[General] [Added] - Added pointerEvents style equivalent to pointerEvents prop
Pull Request resolved: https://github.com/facebook/react-native/pull/34586
Test Plan:
```
<View
style={{
pointerEvents: 'none'
}}
>
</View>
```
Reviewed By: cipolleschi
Differential Revision: D39252830
Pulled By: jacdebug
fbshipit-source-id: 94f265a6b6940a4371e7985d5de3b8143693e069
Summary:
While working on https://github.com/facebook/react-native/pull/34552 I noticed that a couple of words inside the Accessibility example files were misspelled.
## Changelog
[Internal] [Fixed] - Fix accessibility example typos
Pull Request resolved: https://github.com/facebook/react-native/pull/34559
Test Plan: Shouldn't require much testing as this is just fixing some typos inside Accessibility example
Reviewed By: cipolleschi
Differential Revision: D39252742
Pulled By: jacdebug
fbshipit-source-id: 0d3860f438c55d58d0816b9ae65e52925864c8d3
Summary:
This PR should fix the issues introduced by commit c34659a5d3.
The problem is that `Collections.emptyList` creates a `List<Object>` which is not compatible with the `List<TargetView>` type.
## Changelog
[Android] [Fixed] - Make Android CI build again.
Pull Request resolved: https://github.com/facebook/react-native/pull/34573
Test Plan: test_buck and the "test Docker android" must be green.
Reviewed By: cipolleschi
Differential Revision: D39235674
Pulled By: cortinico
fbshipit-source-id: 574338e74aeb4635c67d91de28780fb784c9f405
Summary:
Changelog: [Internal] - Key cached values between different MotionEvents by pointerId.
Currently the implementation uses one cached list and array to store the last hitPath and event coordinates. We use these to determine if we've entered or left any views.
With more pointers, we need to be tracking these values for each pointer.
As well, clean up usage of `mLastTargetCoordinates`. This doesn't need to be a global as its an array that's updated by reference in `findTargetPathAndCoordinatesForTouch`
Reviewed By: vincentriemer
Differential Revision: D39152528
fbshipit-source-id: 28c18629bf974f41950401c7726a4757ad43ac28
Summary:
Changelog: [iOS][Internal] - Rework button/buttons handling on pointer events & add a new test checking for move events on chorded mouse button presses
This is a larger diff that largely stems from implementing a new pointer event platform test about chorded mouse button presses (adapted from https://github.com/web-platform-tests/wpt/blob/master/pointerevents/pointerevent_pointermove_on_chorded_mouse_button.html). In order to implement this test I added a new method, `step`, to an async test instance to allow you to run ad-hoc assertions labeled by the async test (like it's done in the original web platform test).
Once implementing the test I also discovered my current logic for handling the `button` and `buttons` properties was insufficient so I reworked it to handle more/most cases by making the `button` property instead determined by the change in the `buttons` property. This largely works but unfortunately due to what seems to be a bug in UIKit, chorded pointer "up" events receive the wrong button mask values so it's currently impossible to get this test fully passing on iOS. I've since submitted a bug report to Apple but my hopes aren't high that it will be focused on since it's such a niche issue.
Reviewed By: lunaleaps
Differential Revision: D38951159
fbshipit-source-id: 426b7cf7930ed8329151382fafee487493e568de
Summary:
Changelog: [Internal] - Fix more pointer event platform tests.
* Fix the coordinate system to use DIP
* Set some properties for when pointerType="mouse"
Reviewed By: vincentriemer
Differential Revision: D39184713
fbshipit-source-id: d86f798f3e0a377ff1c159fb308329a2c9ae03ff
Summary:
Changelog: [Internal] - Refactor JSPointerDispatcher to group secondary actions (pointer_up, pointer_down) to use same logic and emit non-direct events
This diff re-arranges some code and re-uses some logic for different MotionEvent types.
Specifically, before our code for handling a motionEvent looked like
```
func onMotionEvent(event) {
if (event is HOVER_MOVE) {
handleHoverEvent(event)
}
if (event is ACTION_DOWN) {
// logic for dispatching down, enter, over
}
if (event is ACTION_POINTER_DOWN) { // this represents any secondary pointer going down
// logic for dispatching down
}
if (event is ACTION_MOVE) {
// logic for dispatching touch move
}
if (event is ACTION_UP) {
// logic for dispatching up, out, leave
}
if (event is ACTION_POINTER_UP) { // this represents any secondary pointer going up
// logic for dispatching up
}
....
}
```
now, we've refactored it to be like:
```
func onMotionEvent(event) {
if (event is HOVER_MOVE) { // Still keep this as separate because it does some special things. Will refactor in follow-up diff
handleHoverEvent(event)
}
switch() {
case ACTION_DOWN or ACTION_POINTER_DOWN:
// do same logic
break;
case ACTION_UP or ACTION_POINTER_UP:
// do same logic
break;
case ACTION_MOVE:
// do same logic, we will want to converge this logic with HOVER_MOVE, todo in a follow-up
break;
...
}
....
}
```
This refactor adds the functionality of `enter, over, out, leave` to secondary pointer events in which they weren't fired before.
Reviewed By: vincentriemer
Differential Revision: D39142820
fbshipit-source-id: 8b89db6dc22f24583f8c14dbb8392d4dc8ff6e4d
Summary:
Changelog:
[General][Added] - Added an overlay similar to Inspector.js that allows directly selecting elements on RN from React DevTools
This diff updates DevToolsHighlighter into DevToolsOverlay. It now also allows DevTools user to select an element to inspect directly from DevTools.
Depends on https://github.com/facebook/react/pull/25111 to work.
TODOs:
- Currently once an element selected on RN, the inspector toggle isn't turned off automatically.
- Fabric support depends on https://github.com/facebook/react/pull/25118
Reviewed By: lunaruan
Differential Revision: D38815494
fbshipit-source-id: 7e1e3a78f6594960b5dfaec142bafd3ca4b146af
Summary:
Changelog: [Internal] - Make sure `onChildEndedNativeGesture` is called for view managers that call `onChildStartedNativeGesture`
This affects `JSTouchDispatcher`, `JSPointerDispatcher` as they track what view is reporting native gesturing handling.
This is a bug that view managers never shared the fact that they've stopped managing a native gesture. Both `JSTouchDispatcher`, `JSPointerDispatcher` get around this by manually resetting their internal flag on ACTION_DOWN event (we will get rid of this in a later diff)
Reviewed By: javache
Differential Revision: D38850609
fbshipit-source-id: ef4afb591249bb621f42667608dc1ef20424b65c
Summary:
This PR is the dual of the Matrix Tests we added to the Android Template a couple of weeks ago. It adds the same tests to iOS, to verify that the template builds with both architectures and with both configurations (Debug/Release).. And it tests that the template works with both Hermes and without it.
## Changelog
[iOS] [Added] - Test iOS template with both architectures and configurations
Pull Request resolved: https://github.com/facebook/react-native/pull/34469
Test Plan: CI is green in all the 8 new jobs.
Reviewed By: hramos, cortinico
Differential Revision: D39087876
Pulled By: cipolleschi
fbshipit-source-id: 1205b2339bac87cf11b4f356a2e50e1e93ba52bc
Summary:
Fix `KeyboardAvoidingView` height on iOS when "Prefer Cross-Fade Transitions" is enabled by adding an additional check to `_relativeKeyboardHeight` verifying if `prefersCrossFadeTransitions()` is true and `keyboardFrame.screenY` is `0` and treating this special case. The issue was caused by the native RCTKeyboardObserver where the `endFrame` reported by `UIKeyboardWillChangeFrameNotification` returns `height = 0` when Prefer Cross-Fade Transitions" is enabled
and unfortunelly there isn't much we can do on the native side to fix it.
Closes https://github.com/facebook/react-native/issues/31484
Closes https://github.com/facebook/react-native/issues/29974
## Changelog
[iOS] [Fixed] - Fix KeyboardAvoidingView height when "Prefer Cross-Fade Transitions" is enabled
Pull Request resolved: https://github.com/facebook/react-native/pull/34503
Test Plan:
**On iOS 14+**
1. Access Settings > "General" > "Accessibility" > "Reduce Motion", enable "Reduce Motion" then enable "Prefer Cross-Fade Transitions".
2. Open the RNTester app and navigate to the KeyboardAvoidingView page
3. Focus and blur inputs and observe the keyboard behaving correctly
https://user-images.githubusercontent.com/11707729/186822671-801872be-7db1-4c5c-904b-1987441c1326.mov
Reviewed By: jacdebug
Differential Revision: D39055213
Pulled By: cipolleschi
fbshipit-source-id: fac17cbe02867e0fe522397f6cb59a8b51c1840f
Summary:
This adds the `tintColor` prop to the Image component to replace the non-standard `style.tintColor` as requested on https://github.com/facebook/react-native/issues/34424, so that React Native for Web does not have to deopt styles for Image rendering. I didn't have to change anything on Android as `tintColor` was already being passed down to the native component as a prop. This PR also updates RNTester ImageExample in order to facilitate the manual QA.
## Changelog
[General] [Added] - Add tintColor prop to Image component
Pull Request resolved: https://github.com/facebook/react-native/pull/34534
Test Plan:
1. Open the RNTester app and navigate to the Image page
2. Test the `tintColor` prop through the `Tint Color` section
https://user-images.githubusercontent.com/11707729/187444761-ce5fd949-89f3-4d73-9717-31d035c6ee6b.mov
Reviewed By: necolas
Differential Revision: D39133292
Pulled By: jacdebug
fbshipit-source-id: 314e0ed47ab65366153e730667a31554bc2b6aa7
Summary:
The hermes profiler doesn't work currently, I tracked down the problem to a couple of things.
- Need to call `registerForProfiling` to enable profiling for a specific runtime. I added the call at the same place where we enable the debugger.
- `runInExecutor` didn't work and call its callback. Not sure exactly why, but using `executor_->add` like we do in a lot of other places to run code on the executor works.
- `GetHeapUsageRequest` seems to cause some deadlocks. JS contexts were not detected reliably, I suspect this is related to deadlocks when trying to run on inspector executor. `GetHeapUsageRequest` doesn't actually need any data from the inspector so there is no need to run it on that queue. To fix it I moved the call to use `runInExecutor` instead.
## 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 hermes profiler
Pull Request resolved: https://github.com/facebook/react-native/pull/34129
Reviewed By: cortinico
Differential Revision: D37669469
Pulled By: philIip
fbshipit-source-id: 6cf3b2857ac60b0a1518837b9c56b9c093ed222f
Summary:
`JNIEnv`'s `FindClass(..)` function takes the classes in the standard
`foo/bar/Baz` class specification (unless they're special, like arrays).
Specifying them with `Lfoo/bar/Baz;` results in a
`ClassNotFoundException` being raised -- which is especially unhelpful
when intending to re-throw an exception.
The docs for `JNIEnv#FindClass(..)` can be found [here][jnienv].
[jnienv]:
https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/functions.html#:~:text=The%20name%20argument,java/lang/String%22
## Changelog
[Android] [Fixed] - Correctly resolve classes with FindClass(..)
Pull Request resolved: https://github.com/facebook/react-native/pull/34533
Test Plan:
No exact test plan. However, if an exception is thrown during the
rendering process, a fatal `ClassNotFoundException` is raised, rather
than having the error be passed up to the `ReactNativeManager`.
Fixes: facebook/yoga#1120
Reviewed By: amir-shalem
Differential Revision: D39133326
Pulled By: jacdebug
fbshipit-source-id: 86283b7d21aed49ed0e9027b2aef85f0108cdf9a
Summary:
Improve errors thrown when prop conversion fails by adding the property being converted. Removes the specialization of convertRawProp for std::optional since we can handle that in a fromRawValue specialization instead.
To make this work, we need to remove noexcept from a number of calls. This noexcept behaviour was making these exceptions effectively uncatcheable. The original motivation of D23787492 (https://github.com/facebook/react-native/commit/57dd48b2464ac04b860f2f69cb4f131990fe4dbd) is correct, as we cannot reliably pass on exceptions to JS and assume that the state will be recoverable, so instead we log an error and carry on with the default value available. We should improve how the error gets reported to the user, as it will currently be hidden in logcat.
Changelog: [Internal]
Differential Revision: D39052812
fbshipit-source-id: 9692633930555e64a3769116fc484a19e534aa3f
Summary:
This adds the `inputMode` prop to the TextInput component as requested on https://github.com/facebook/react-native/issues/34424, mapping web [inputMode types](https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/inputmode) to equivalent [keyboardType](https://reactnative.dev/docs/textinput#keyboardtype) values. This PR also updates RNTester TextInputExample in order to facilitate the manual QA.
### Caveats
~~This only adds support to `text`, `decimal`, `numeric`, `tel`, `search`, `email`, and `url` types.~~
#### `inputMode="none"`
**Currently mapped to `default` keyboard type.**
The main problem with this input mode is that it's not supported natively neither on Android or iOS. Android `TextView` does accept `none` as `android:inputType` but that makes the text not editable, which wouldn't really solve our problem. `UITextInput` on iOS on the other hand doesn't even have something similar to avoid displaying the virtual keyboard.
If we really want to add the support for `inputMode="none"` one interesting approach we could take is to do something similar to what WebKit has done (https://github.com/WebKit/WebKit/commit/3b5f0c8ecf9de23f79524ed02e290837ab8334cd). In order to achieve this behavior, they had to return a `UIView` with a bounds of `CGRectZero` as the inputView of the `WKContentView` when inputmode=none is present.
~~I guess the real question here should be, do we really want to add this? Or perhaps should we just map `inputMode="none"` to `keyboardType="default"`~~
Android docs: https://developer.android.com/reference/android/widget/TextView#attr_android:inputType
iOS docs: https://developer.apple.com/documentation/uikit/uikeyboardtype?language=objc
#### `inputMode="search"` on Android
**Currently mapped to `default` keyboard type.**
Android `TextView` does not offers any options like `UIKeyboardTypeWebSearch` on iOS to be used as `search` with `android:inputType` and that's probably the reason why `keyboardType="web-search"` is iOS only. I checked how this is handled on the browser on my Android device and it seems that Chrome just uses the default keyboard, maybe we should do the same?
### Open questions
- ~~What should be done about `inputMode="none"`?~~ Add it and map it to `default` keyboard type.
- ~~Which keyboard should we show on Android when `inputMode="search"`?~~ Use the `default` keyboard the same way Chrome does
## Changelog
[General] [Added] - Add inputMode prop to TextInput component
## Test Plan
1. Open the RNTester app and navigate to the TextInput page
2. Test the `TextInput` component through the `Input modes` section
https://user-images.githubusercontent.com/11707729/185691224-3042e828-a008-4bd0-bb3d-010a6a18dfd5.mov
Pull Request resolved: https://github.com/facebook/react-native/pull/34460
Reviewed By: necolas
Differential Revision: D38900724
Pulled By: cipolleschi
fbshipit-source-id: 60d405ccdbfad588b272fbb6b220b64ffdfc4b14
Summary:
When the webview is updated by play store, all apps that has loaded webview gets killed. For background see https://issuetracker.google.com/issues/228611949?pli=1
We have a long-running app and don't want this to happen and while we are not using webview anywhere, we are using websockets that loads it for reading cookies, however we are not using cookies to authenticate the websocket and thus want to disable the webview to avoid loading it unnecessarily and then getting killed unnecessarily.
The webview has support for beeing disabled https://developer.android.com/reference/android/webkit/WebView#disableWebView() however as-is this crashes React Native. It seems to me like this case is very similar to not having web view installed and should be handled in the same way.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Android] [Fixed] - Avoid crash in ForwardingCookieHandler if webview is disabled
Pull Request resolved: https://github.com/facebook/react-native/pull/34483
Test Plan: Add `WebView.disableWebView();` as the first line in `MainActivity.onCreate`.
Reviewed By: christophpurrer
Differential Revision: D38981827
Pulled By: cipolleschi
fbshipit-source-id: 335a8420568ad0c80b834ae8a3b164e55ebe26f3
Summary:
Configure the runtime to allow use of the sampling profiler in the Chrome Debug Server.
Note: this does not actually start and stop the profiler; this change just makes the sampling profiler available to the runtime.
Changelog: [Internal]
Reviewed By: neildhar
Differential Revision: D39100833
fbshipit-source-id: 60d1f4e5ea2191fdf88b7f2e733557fa6128e205
Summary:
The `sed` workaround here in `__apply_Xcode_12_5_M1_post_install_workaround`:
https://github.com/facebook/react-native/blob/main/scripts/react_native_pods.rb#L293-L298
does not work when the react native project has a parent folder with a space in the the name, for example:
`/Users/myuser/Some Folder/my-project/ios/Pods/RCT-Folly/folly/portability/Time.h`
This is because the `sed` command thinks that the part after the space is a separate argument.
This bug caused one of our engineers to not be able to run our React Native project through no fault of his own, so I would like to propose this change to help other engineers avoid this in the future.
## Changelog
Add single quotes around the file parameter in the `sed` command
[iOS] [Fixed] - Fixed Time.h:52:17: error when a folder in the file path has a space
Pull Request resolved: https://github.com/facebook/react-native/pull/34510
Test Plan:
Checkout the main branch.
Create a React Native project in a folder that has a space in the name.
When you run `pod install`, you should notice a `sed` error indicating that the text replacement failed.
Run the build to reproduce the `Time.h:52:17: error`.
Checkout this branch.
Run `pod install` and notice the `sed` error is gone.
Run the build, the error should be gone.
Reviewed By: sammy-SC
Differential Revision: D39082262
Pulled By: cipolleschi
fbshipit-source-id: 211099234edc6c9ee959bb61a760a6ca04a7a301
Summary:
when integrates with swift, the compiler will build clang module based on the *React-Core-umbrella.h*. however, the include chain reaches some c++ headers that are not available from swift. it will cause build error.

this pr adds `#ifdef __cplusplus` guard for it.
## Changelog
[iOS] [Fixed] - Fix React module build error with swift integration on new architecture mode
Pull Request resolved: https://github.com/facebook/react-native/pull/34527
Test Plan:
one thing we didn't figure out is that we require reanimated to repro the build error.
1. `npx react-native init RN070 --version 0.70.0-rc.4`. # can also repro this issue on 0.69
2. `cd RN070`
3. `yarn add react-native-reanimated@next`
4. `cd ios && rm -rf Pods build && RCT_NEW_ARCH_ENABLED=1 pod install`
5. add `import React;` in `main.m` for clang module generation
```diff
--- a/ios/RN070/main.m
+++ b/ios/RN070/main.m
@@ -1,5 +1,6 @@
#import <UIKit/UIKit.h>
+@import React;
#import "AppDelegate.h"
int main(int argc, char *argv[])
```
6. `yarn ios`
Reviewed By: cipolleschi
Differential Revision: D39128716
Pulled By: jacdebug
fbshipit-source-id: d9e9130f99e3b9e5f7807c475a24cdd84880e720
Summary:
There are cases where we want to pass an enum type into a TurboModule method which is handy to restrict certain arguments to a restricted set of values, e.g. restricting quality to ```enum Quality { SD, HD, }```
Approach:
- We are not generating an ```enum``` type in C++ but rather just cast type safe to the corresponding member type.
- We don't support mixed enum types at this time, e.g. ```export enum StringOption { One = 'one', Two = 2, Three = 'three', };``` will not work. See: https://www.typescriptlang.org/docs/handbook/enums.html#heterogeneous-enums
- We only support untyped (default to String), String, and Number enum properties
This is for C++ only, Java and ObjC are not supported atm.
Changelog:
[General][Added] - react-native-code-gen Add Enum Type support for C++ TurboModules
Reviewed By: RSNara
Differential Revision: D38880963
fbshipit-source-id: f2399b29948306bc555429b6f96c43ea4c39c46e
Summary:
This adds the `tabIndex` Android only prop to View as requested on https://github.com/facebook/react-native/issues/34424 mapping the existing `focusable` prop to `tabIndex` so that `tabIndex={0}` maps to `focusable={true}` and `tabIndex={-1}` represents ` focusable={false}`.
## Changelog
[Android] [Added] - Add tabIndex prop to View component
Pull Request resolved: https://github.com/facebook/react-native/pull/34486
Test Plan: I'm still investigating the best way to test this but we're are just mapping this to an existing prop
Reviewed By: GijsWeterings
Differential Revision: D38957303
Pulled By: necolas
fbshipit-source-id: d00db854e11cb3457329c1547b69cff60afb34cf
Summary:
## Context
```isRootViewVisible``` doesn't work as expected for non-Venice: when enter Marketplace tab, ```isRootViewVisible``` should returns true with Marketplace tab's rootViewTag, but it returns false.
## Root cause
```rootViewTag``` is added to "mVisibleRootTags" in "FbReactRootVisibilityTracker" when ```BaseFbReactFragment.onViewDidAppear()``` gets called, but ```BaseFbReactFragment.onViewDidAppear()``` is called earlier than when the ```rootViewTag``` is set.
## Fix
Move setRootViewTag to earlier when RootView is created instead of in startSurface or mounting.
Changelog:
[Android][Changed] - Move setRootViewTag to earlier when RootView is created
Reviewed By: RSNara
Differential Revision: D38586584
fbshipit-source-id: aec3ed37eb62289a19794e68b1a6b5ca213cb14a
Summary:
This diff introduces the API that will be used to describe React Native Components written in C++
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D38725766
fbshipit-source-id: 292e28409ac6be8f9a1c2209b8c558e0e2cb96ea
Summary:
Implement Runtime.compileScript, which is a dev tools request to compile a given script, optionally persisting the compiled result.
There are 3 main cases:
- Unsuccessful compilation, populates the exception details output. (We could retrieve the line and column number from the exception message, but it felt a bit too hacky.)
- Successful unpersisted output, returns an empty result, indicating success
- Successful persisted output, returns a result with a unique scriptID that identifies the prepared script.
The script IDs end with an index that can be used to infer the location in the vector storing persisted scripts.
Changelog: [Internal]
Reviewed By: jpporto
Differential Revision: D38761119
fbshipit-source-id: 504faad0149d1637682fa11d285f71736c3133e5
Summary:
Small typo fix.
## Changelog
[General] [Fixed] - Typo in AssetSourceResolver
Pull Request resolved: https://github.com/facebook/react-native/pull/34520
Test Plan: No test plan is required. Just check the file changes.
Reviewed By: NickGerleman
Differential Revision: D39087572
Pulled By: cipolleschi
fbshipit-source-id: a79253d2486ee21fbf5683177b21ec534607d65d
Summary:
- Just a small typo fix
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Android] [Fixed] - Typo in build.gradle
Pull Request resolved: https://github.com/facebook/react-native/pull/34517
Test Plan: - Check out the diff changes
Reviewed By: lunaleaps
Differential Revision: D39082272
Pulled By: cipolleschi
fbshipit-source-id: d62938d5a1e6802c6e7f44186adbbfa1a6715cf8
Summary: Changelog: [Internal] - Make AccessibilityInfo public type an exact object
Reviewed By: NickGerleman
Differential Revision: D38921820
fbshipit-source-id: 6f264595814a817fb1101788942f9127d9cc85c1
Summary:
Changelog: [Internal][iOS] Modularlize RCTBridgeModule.h 1/n - Move RCTBundleManager.h to its own file in ReactInternal target
# Why clean up RCTBridgeModule.h?
Clean up one unnecessary import of RCTBridgeModule.h.
RCTBridgeModule includes a lot of header files, and this header is imported everywhere. The ultimate goal is that files (especially React Native infra files) should only import only what they need and not import the entirely of RCTBridgeModule.h whenever possible.
This way, certain headers that are Bridge-only can be compiled out of the new architecture with a flag.
The other benefit of splitting up the headers like this is that it'll be much easier for developers to navigate between the .h and .mm files.
Reviewed By: philIip
Differential Revision: D38943262
fbshipit-source-id: 90876324de9fae25bf33c7aef820a32d7c6ce2f8
Summary:
Adds changelog for new patch.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - add changelog entry for 0.69.5
Pull Request resolved: https://github.com/facebook/react-native/pull/34499
Test Plan: N/A
Reviewed By: dmitryrykun
Differential Revision: D39051081
Pulled By: cipolleschi
fbshipit-source-id: 857e24a19a77b85f0593945e6838216ceb5b0f5d
Summary:
This adds the Android only `rows` prop to TextInput as requested on https://github.com/facebook/react-native/issues/34424 mapping the existing `numberOfLines` prop to `rows`. This PR also updates the TextInputExample.android on the RNTester in order to facilitate the manual QA of this.
## Changelog
[Android] [Added] - Add rows prop to TextInput component
Pull Request resolved: https://github.com/facebook/react-native/pull/34488
Test Plan:
1. On Android open the RNTester app and navigate to the TextInput page
2. Test the `TextInput` component through the `Fixed number of lines` section
https://user-images.githubusercontent.com/11707729/186300173-7de79799-25b8-48af-99c0-8e3abeae334f.mov
Reviewed By: christophpurrer
Differential Revision: D38981953
Pulled By: cipolleschi
fbshipit-source-id: d4d84b3c0dac7342ba9a65e2491928fbc61ff4f1
Summary:
https://github.com/facebook/react-native/issues/31056#issuecomment-786349025
>Re-implement accessibilityHint on Android so that rather that concatenate into the contentDescription, it sets the toolTipText property on the AccessibilityNodeInfo (not on the view). This is the closest analog to iOS's hint that Android has, as the text is announced after the contentDescription rather than part of it. It will will not adhere to users preferences on whether they want hints disabled or not, and still has no pause before it like real hints have, but it's far closer than using the contentDescription directly.
fixes https://github.com/facebook/react-native/issues/31056
## Changelog
[Android] [Fixed] - Re-implement accessibilityHint on Android to use AccessibililltyNodeInfo#setToolTipText instead of contentDescription
Pull Request resolved: https://github.com/facebook/react-native/pull/34427
Test Plan: https://user-images.githubusercontent.com/24992535/184837154-5c65dbf1-1031-4d56-ac1e-066af7e08edc.mp4
Reviewed By: christophpurrer
Differential Revision: D38982158
Pulled By: cipolleschi
fbshipit-source-id: 7a616e6df9f83bd21ca02cc26b5918986a1d64f8
Summary:
from the original design of `StyleSheet.setStyleAttributePreprocessor()` in https://github.com/facebook/react-native/issues/11138, the overwriting warning shows when the existing preprocess is be overwritten. the behavior changes from https://github.com/facebook/react-native/commit/33b385825c72. This PR revises the logic back to original design.
## Changelog
[Internal] [Fixed] - Show warning only when overwriting existing preprocessor in `StyleSheet.setStyleAttributePreprocessor()`
Pull Request resolved: https://github.com/facebook/react-native/pull/34479
Test Plan:
Unit Test
```
PASS Libraries/StyleSheet/__tests__/StyleSheet-test.js
setStyleAttributePreprocessor
✓ should not show warning when set preprocessor first time (2 ms)
✓ should show warning when overwrite the preprocessor (1 ms)
```
Reviewed By: dmitryrykun
Differential Revision: D38940676
Pulled By: cipolleschi
fbshipit-source-id: 80cf30fff62f4a02c17f7f42b3260a6011d5fc82
Summary:
When a view is rendered with a combination of `overflow: hidden` and `borderRadius: >0`, the `ReactViewGroup` would apply the border radius using Canvas `clipPath`. In Android graphics, clipPath is not an anti-aliased operation and caused aliasing artifacts.
Changing the method to a bitmask using the `PorterDuff` method results in the same functionality, but with hardware accelerated antialiasing.
https://github.com/facebook/react-native/issues/24486
Changelog:
[Android][Change] - Views with overflow: hidden and borderRadius: >0 now render anti-aliased borders.
Reviewed By: javache
Differential Revision: D38914878
fbshipit-source-id: 45ac7e4aece7a76c4216412175e49d3d73b6f391
Summary:
The motivation of this PR is for the Alert to follow the same style override (`overrideUserInterfaceStyle` being light/dark) as the one used by the root window (`UIApplication.sharedApplication.delegate.window`).
This is something that has worked previously because `RCTPResentedViewController()` was used to present the Alert (the behavior has changed in https://github.com/vonovak/react-native/commit/f319ff321c4b7c0929b99e3ebe7e1ce1fa50b34c). With the former approach, the alert would "inherit" the `userInterfaceStyle` of the view controller it was presented within (and that one, in turn, would "inherit" from `UIApplication.sharedApplication.delegate.window`).
With the current approach, the "style inheritance" does not work with the view controller being created [here](https://github.com/facebook/react-native/blob/f3db6cc52792e3006a16408df4ae40f3aee19a86/React/CoreModules/RCTAlertController.m#L24).
Because this viewcontroller instance does not have where to "inherit" the styling from, the styling might be different from the rest of the app. This PR fixes that.
## Changelog
[iOS] [Fixed] - fix: RCTAlertController's UserInterfaceStyle to follow root window
Pull Request resolved: https://github.com/facebook/react-native/pull/34218
Test Plan:
Instead of
```
self.overrideUserInterfaceStyle = UIApplication.sharedApplication.delegate.window.overrideUserInterfaceStyle;
```
you can do
```
self.overrideUserInterfaceStyle = UIUserInterfaceStyleDark;
```
and observe the result. So if the override is set, it'll manifest itself. If it's not set, the value of `UIApplication.sharedApplication.delegate.window.overrideUserInterfaceStyle` will be `UIUserInterfaceStyleUnspecified`, and it'll have no effect.
<details>
<summary>screenshot</summary>

</details>
Reviewed By: dmitryrykun
Differential Revision: D38660799
Pulled By: cipolleschi
fbshipit-source-id: c979266900e27be7a4732bdb6e9a496906534931
Summary:
Improve errors thrown when prop conversion fails by adding the property being converted. Removes the specialization of convertRawProp for std::optional since we can handle that in a fromRawValue specialization instead.
To make this work, we need to remove noexcept from a number of calls. This noexcept behaviour was making these exceptions effectively uncatcheable. The original motivation of D23787492 (https://github.com/facebook/react-native/commit/57dd48b2464ac04b860f2f69cb4f131990fe4dbd) is correct, as we cannot reliably pass on exceptions to JS and assume that the state will be recoverable, so instead we log an error and carry on with the default value available. We should improve how the error gets reported to the user, as it will currently be hidden in logcat.
Changelog: [Internal]
Reviewed By: philIip
Differential Revision: D38938632
fbshipit-source-id: 1dc9a544ca679463a8aad5cc632bd918f42b15d1
Summary:
There are cases where we want to pass a union type into a TurboModule method which is handy to restrict certain arguments to a restricted set of values, e.g. restricting quality to ```'low'```, ```high``` or resolution to ```720```, ```1080```.
- We are not generating an ```union``` type in C++ but rather just cast type safe to the corresponding member type.
- We don't support mixed primitive union types at this time, e.g. ```export type ChooseSomething = 'One' | 'Two' | 3 | false;``` does not work.
- We can support mixed object union types such as ... ```export type ChooseObject = {} | {low: string};``` - which need special logic in the C++ TM to correctly parse the resulting jsi::Object
This is for C++ only, Java and ObjC are not supported atm.
Changelog:
[General][Added] - react-native-code-gen Add Union Type support for C++ TurboModules
Reviewed By: javache
Differential Revision: D38919688
fbshipit-source-id: 0fd37545b32b4f2059a8babda62dab4a85de37a9
Summary:
This PR bumps the Hermes cache keys because they got corrupted due to some sync delay between Hermes and React Native.
## Changelog
[iOS] [Fixed] - CI broken due to Hermes Commit
Pull Request resolved: https://github.com/facebook/react-native/pull/34491
Test Plan: CI should be green
Reviewed By: dmitryrykun
Differential Revision: D38976132
Pulled By: cipolleschi
fbshipit-source-id: 16df11ede8947d8376d316b126eefcf0177d16de
Summary:
Noticed this logging was broken when enabling the flag.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D38616851
fbshipit-source-id: acf0ab75918b389586cb713c2edf5a6bf83ee7a2
Summary:
This adds the `readOnly` prop to TextInput as requested on https://github.com/facebook/react-native/issues/34424 mapping the existing `editable` prop to `readOnly` so that `readOnly={false}` maps to `editable={true}` and `readOnly={true}` represents ` editable={false}`. This PR also updates the TextInputExample on the RNTest in order to facilitate the manual QA of this.
## Changelog
[General] [Added] - Add readOnly prop to TextInput component
Pull Request resolved: https://github.com/facebook/react-native/pull/34444
Test Plan:
1. Open the RNTester app and navigate to the TextInput page
2. Test the `TextInput` component through the `Editable and Read only` section
https://user-images.githubusercontent.com/11707729/185295132-036443c8-1d5e-4567-a15e-5f1173cb0526.mov
Reviewed By: lunaleaps
Differential Revision: D38912786
Pulled By: necolas
fbshipit-source-id: faeb59ed8695732be682ec55406a2de0cb7e619a
Summary:
Changelog: [iOS][Internal] - Fix buttons property value for non-hoverable pointers
The previous diff ensured that on iOS you could run through the entirety of the non-hoverable pointer event attributes test but that also revealed some failing tests related to the `buttons` property when using a non-hoverable pointer. This diff fixes that by ensuring that we only forward the result of the `buttonMask` to `buttons` when the pointer is a mouse, and assume that it is an emulated left click otherwise.
Reviewed By: lunaleaps
Differential Revision: D38914239
fbshipit-source-id: c573e934d0e9c0ac2af4945dc5360840ddc87d4d
Summary:
changelog: [internal]
Call flushQueue directly from useAnimatedProps to avoid mismatch between `NativeAnimatedHelper.API.setWaitingForIdentifier` and `NativeAnimatedHelper.API.unsetWaitingForIdentifier`
Previously, animation queue only got called if every `setWaitingForIdentifier` call was matched by `unsetWaitingForIdentifier`. If an error is thrown, this is not the case and they get out of sync. WHen they get out of sync, they never recover and animation queue is never flushedddddd.
Reviewed By: yungsters
Differential Revision: D38938858
fbshipit-source-id: c38fdef05cc70ce274b8e16114ffe49cc2dcb9b3
Summary:
X-link: https://github.com/facebook/hermes/pull/793
Add a JSI API for constructing `ArrayBuffer`s from a user provided
`jsi::MutableBuffer`.
Changelog: [General][Added] Added ability to construct ArrayBuffers from existing memory buffers.
Reviewed By: jpporto
Differential Revision: D37744467
fbshipit-source-id: 9d9ece00d1dbde341846c45fa30c935b5fa81e9a
Summary:
As per title, the shallow checkout was breaking some workflows, so we are reverting it
## Changelog
[General] [Changed] - Revert shallow checkout
Pull Request resolved: https://github.com/facebook/react-native/pull/34480
Test Plan: CI should be green
Reviewed By: dmitryrykun
Differential Revision: D38940528
Pulled By: cipolleschi
fbshipit-source-id: 691faf2749911278923ca2d42c974e5307a06261
Summary:
ScrollView has special-case logic to dismiss keyboard on tap, controlled via the `keyboardShouldPersistTaps` property. The first click does not propagate to children of the scrollview if the tap causes the keyboard to be dismissed. This behavior is motivated by a soft keyboard on phones which takes away space from the viewport.
ScrollView historically determined if a soft-keyboard was open via querying if there was a focused TextInput. This meant that clicks to a ScrollView would be eaten, even on form factors using phsyical keyboards.
A couple years ago I added https://github.com/facebook/react-native/pull/30374 to only eat clicks when keyboard events have indicated that a soft keyboard is present. I special-cased Android out of the change, because of platform issues with its reliability of keyboard events.
After D38500859 (https://github.com/facebook/react-native/commit/1e48274223ee647ac4fc2c21822b5240f3c47e4c) rolls out we can start to remove that special-casing, of devices which report "android" for Platform.OS.
Reviewed By: javache
Differential Revision: D38528887
fbshipit-source-id: a745b478b18abe4ef32cbdd8a14ca6dfdb5e738f
Summary:
If currently focused on a TextInput, clicking an item in a ScrollView takes two clicks.
This is because of `keyboardShouldPersistTaps`, which will fire despite a lack of keyboard events on Android due to special-casing.
This behavior is jarring in scenarios like VR where the soft keyboard is detached from the application. This change avoids eating taps, in this case, where a soft keyboard is open but not inset.
Reviewed By: genkikondo
Differential Revision: D38529237
fbshipit-source-id: a10c5dbf04e6288e0e9e0c805215054bc883339f
Summary:
Improve errors thrown when prop conversion fails by adding the property being converted. Removes the specialization of `convertRawProp` for `std::optional` since we can handle that in a `fromRawValue` specialization instead.
To make this work, we need to remove `noexcept` from a number of calls. This noexcept behaviour was making these exceptions effectively uncatcheable. The original motivation of D23787492 (https://github.com/facebook/react-native/commit/57dd48b2464ac04b860f2f69cb4f131990fe4dbd) is correct, as we cannot reliably pass on exceptions to JS and assume that the state will be recoverable, so instead we log an error and carry on with the default value available. We should improve how the error gets reported to the user, as it will currently be hidden in logcat.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D37055069
fbshipit-source-id: 8ce121a9b187f068d3ab790c6fae66d53e6338d2
Summary:
- Fix a typo in the word "feture" (-> "feature")
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[iOS] [Fixed] - Typo in AppDelegate.mm
Pull Request resolved: https://github.com/facebook/react-native/pull/34462
Test Plan: - Read the diff change
Reviewed By: dmitryrykun
Differential Revision: D38900680
Pulled By: cipolleschi
fbshipit-source-id: cdc5fb183cb7f5485a553dde7ea381f27f83e903
Summary:
Changelog:
[iOS][Fixed] - When source maps are enabled, clean up temporary files from the build directory. Reduces bundle size by at least 1MB.
Reviewed By: cipolleschi
Differential Revision: D38866158
fbshipit-source-id: 0f46faf4e767bb7417b24f283fbe19cfa022941a
Summary:
This PR removes unused variable `NODE_MODULES_DIR` passed from `build.gradle` to `CMakeLists.txt` which causes the following CMake warnings to appear in the logs:
```
> Task :app:configureCMakeDebug[arm64-v8a]
C/C++: debug|arm64-v8a :CMake Warning:
C/C++: debug|arm64-v8a : Manually-specified variables were not used by the project:
C/C++: debug|arm64-v8a : NODE_MODULES_DIR
```
First I changed the value of `NODE_MODULES_DIR` to some non-existent path (i.e. `-DNODE_MODULES_DIR=/foo/bar`) to confirm that the variable is indeed unused. Then I completely removed it from `arguments` and the CMake warning disappeared.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Android] [Fixed] - Removed unused variable `NODE_MODULES_DIR` from `build.gradle` in app template
Pull Request resolved: https://github.com/facebook/react-native/pull/34459
Test Plan:
1. Create a new RN 0.70.0-rc.3 app from template with `npx react-native@next init RN070RC3 --version 0.70.0-rc.3`
2. Set `newArchEnabled=true` in `settings.gradle`
3. Open `android` directory in Android Studio
4. Run Gradle Sync
5. Build the app
6. Search for `NODE_MODULES_DIR` in the logs
7. Notice the CMake warning
8. Remove the line from this PR
9. Build the app again
10. Search for `NODE_MODULES_DIR` in the logs
11. Confirm there are no occurrences
Reviewed By: neildhar
Differential Revision: D38864127
Pulled By: cortinico
fbshipit-source-id: b41440edcdba63945e3b08cef897a250686c13ba
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34452
This will unblock the RN `test_android` CI Job as currently two versions
of `hermes-parser` are picked up during package resolution.
Changelog:
[Internal] [Fixed] - Blacklist sdks/hermes from Metro resolution
Reviewed By: cipolleschi
Differential Revision: D38856931
fbshipit-source-id: 49d941f762ba0ef953c5c42b0ca13ac1c74b5ba5
Summary: Changelog: [Internal] - Create a type declaration for AccsesibilityInfo for clearer signal when our public API types change
Reviewed By: yungsters
Differential Revision: D38712552
fbshipit-source-id: cc7c727d41fb03ca714cb05fd10dc32038374fd0
Summary:
Changelog: [iOS][Internal] - Apply pointer entering/leaving tracking to touch-initiated pointer events
This diff takes the refactoring done in the previous diff in this stack and applies it to the pointer events which are converted from discrete touch events. In addition this adds a check when an ActiveTouch is created to see if the pointer in question was hovering before the touch started or not, which is stored and leveraged once the touch is lifted to determine if we should treat the pointer as leaving the screen entirely or not.
Reviewed By: lunaleaps
Differential Revision: D38762330
fbshipit-source-id: 08452783e01bf5944c57b94a292805b2d69d4384
Summary:
Changelog: [iOS][Internal] - Refactor hover tracking to prepare for support of tracking the entering/leaving of poitners on non-hover pointer events
This diff begins the work in preparing the touch handler class to track pointer's entering & leaving of views on events other than a hover move by refactoring it to 1) support multiple/simultaneous pointers and 2) abstract the pointer tracking out of the hover recognizer callback so that it can be used for other events in the future (to be done in future diffs, this diff is simply a refactor and keeps the status quo).
Reviewed By: lunaleaps
Differential Revision: D38760358
fbshipit-source-id: f05629ddaa76daed9a3e59ce5d4af6f62ba83755
Summary:
ScrollView has special behavior when the keyboard is open, but starts listening to keyboard events on mount. This means a ScrollView mounted after the keyboard is already up (e.g. for a typeahead) is not initialized to the keyboard being up.
This change adds `Keyboard.isVisible()` and `Keyboard.metrics()` APIs to allow seeding initial keyboard metrics.
Changelog:
[General][Fixed] - Inform ScrollView of Keyboard Events Before Mount
Reviewed By: JoshuaGross, yungsters
Differential Revision: D38701976
fbshipit-source-id: 42b354718fbf5001ca4b90de0442eeab0be91e7a
Summary:
As title, replace json serialization/deserialization and folly with MapBuffer for js error handling in Android.
Changelog:
[Android][Changed] Replace Folly with MapBuffer for passing js error data
(Note: this ignores all push blocking failures!)
Reviewed By: RSNara
Differential Revision: D38460202
fbshipit-source-id: e13a47722964baa9e0a16bb138456a19350f809e
Summary:
Updating flow-parser to a more recent version which also supports parsing enums
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D38832380
fbshipit-source-id: e3ef477abf85939ce3c9d92844e28dc59d8231c1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34446
I'm adding another class to the .defaults package. This will take care of setting the RootView
with Fabric enabled/disabled as well as controlling concurrent root.
Changelog:
[Android] [Added] - Introduce the DefaultMainActivityDelegate to simplify enabling/disabling Fabric for new apps.
Reviewed By: cipolleschi
Differential Revision: D38823181
fbshipit-source-id: 2293b9df6b0d8fa79695bd52a8e0bb46b44c43c8
Summary:
With react-native 0.70-rc.3 and new arch, codegen may fail if it encounters `.d.ts` files because specs may appear to be unused.
## Changelog
[General] [Fixed] - Codegen should ignore `.d.ts` files
Pull Request resolved: https://github.com/facebook/react-native/pull/34439
Test Plan:
See repro in https://github.com/microsoft/react-native-test-app/pull/1052. The build will fail without manually patching this in.
If you prefer to use your own test app, try adding [react-native-safe-area-context](https://github.com/th3rdwave/react-native-safe-area-context) as a dependency.
Reviewed By: cipolleschi
Differential Revision: D38826388
Pulled By: cortinico
fbshipit-source-id: eb7c9be2d49286bae86b2428862fbf20f6f32ca5
Summary:
Currently we expose native code (.h, .cpp) inside the src/main/java folder.
This is making impossible for users on New Architecture to open the project
inside Android Studio.
The problem is that the src/main/java is reserved to Java/Kotlin sources only.
AGP 7.2 also removed support for mixed source roots:
https://developer.android.com/studio/releases/gradle-plugin#duplicate-content-roots
This is essentially forcing users to write Java code without any autocompletion
as all the React Native Java classes are considered C++ files.
I'm addressing this issue folder by folder by moving them
from ReactAndroid/src/main/java/com/facebook/... to ReactAndroid/src/main/jni/react/...
This is the diff for turbomodule
I've also updated all the internal usages and references to the new path.
Changelog:
[Internal] [Changed] - Do not store .cpp/.h files inside src/main/java - turbomodule
Reviewed By: cipolleschi
Differential Revision: D38820638
fbshipit-source-id: febb3f8cef18b30e82c3a4776baa85d0c0d19e4b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34445
This commit simplifies the new app template by encapsulating a lot of configuration
by using the `DefaultReactNativeHost` from the .defaults package.
This should work for most of the users while still allowing advanced use cases
by using the good old ReactNativeHost.
Changelog:
[Android] [Changed] - Simplify the template for New Architecture using the .defaults package
Reviewed By: cipolleschi
Differential Revision: D38820111
fbshipit-source-id: 4e9529a92e1681610e3a1a89fdf82e6d10a18809
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34440
While testing some recent changes on a nightly, I realized that if we install the dependencies using RCT_NEW_ARCH_ENABLED=1 and we forget to change the flag in the Podfile, Fabric dependencies won't be installed.
However, Fabric is required by the New Architecture. This fix makes sure that we install Fabric dependencies when the New Architecture is enabled.
## Changelog
[iOS][Changed] Install Fabric dependencies when RCT_NEW_ARCH_ENABLED=1
Reviewed By: cortinico
Differential Revision: D38786978
fbshipit-source-id: 664151de0250577a19af949f8850e5efa8a13373
Summary:
This is an attempt to fix the broken `test_buck` as the `/textinput` target now needs to access the Kotlin stdlib dependencies
## Changelog
[Internal] - Fix test_buck by providing exported deps for textinput target
Pull Request resolved: https://github.com/facebook/react-native/pull/34436
Test Plan: Will wait for a CircleCI result
Reviewed By: cipolleschi
Differential Revision: D38782473
Pulled By: cortinico
fbshipit-source-id: 72265c34092372189d75df732b64a1e370453472
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34435
Currently we expose native code (.h, .cpp) inside the src/main/java folder.
This is making impossible for users on New Architecture to open the project
inside Android Studio.
The problem is that the src/main/java is reserved to Java/Kotlin sources only.
AGP 7.2 also removed support for mixed source roots:
https://developer.android.com/studio/releases/gradle-plugin#duplicate-content-roots
This is essentially forcing users to write Java code without any autocompletion
as all the React Native Java classes are considered C++ files.
I'm addressing this issue folder by folder by moving them
from ReactAndroid/src/main/java/com/facebook/... to ReactAndroid/src/main/jni/react/...
This is the diff for fabricjni
Changelog:
[Internal] [Changed] - Do not store .cpp/.h files inside src/main/java - fabricjni
Reviewed By: cipolleschi
Differential Revision: D38741130
fbshipit-source-id: f9e3e4514d3ae0ddeac65256928d71d5134d08f8
Summary:
CMake gens running debug
- `android/app/.cxx/Debug/*`
- `android/app/.cxx/RelWithDebInfo/*`
Neither/nothing during release.
So probably want the 87 debug files untracked.
Follow-up: https://github.com/facebook/react-native/pull/34354
_macOS 13b, RN 0.70.0-rc.3_
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Android] [Added] - Update template to gitignore `android/app/.cxx`
Pull Request resolved: https://github.com/facebook/react-native/pull/34430
Test Plan: Everything builds and runs as expected
Reviewed By: cipolleschi
Differential Revision: D38752097
Pulled By: cortinico
fbshipit-source-id: 61c31317d5e45f831445841f3e14da871b3903e5
Summary:
Currently the PropSetter parser parses all border{TopLeft,TopRight,...}Radius props except for `borderRadius`.
This is the fix.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D38678226
fbshipit-source-id: 8c5d67a652c2b327aa50a997e8e886630fe139c0
Summary:
Unfortunately my last diff didn't completely fix this; now there are more printed parameters than arguments provided to the formatter.
Easy fix, confirmed this works by running internally.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D38678116
fbshipit-source-id: 51f32905debc1946bc260f06a5bdc2f43141ddf4
Summary:
Changelog:
[General][Changed] - Copied and refactored the current devtools highlighting code from Inspector into its own module and add to the top level `AppContainer`. The effect is that the highlight stills shows without Inspector opened.
This diff copies the current devtools highlighting logic from Inspector into a module and add to the top level `AppContainer`. The effect is without Inspector opened, the highlight will still show.
## Context
This is the first diff for "Component Tab Automatically Highlight Elements". The idea is to replicate the behavior on Web to RN.
## Behavior
on Web:
- highlight shows whenever an element in the component list is hovered
- Selecting an element doesn't keeps the highlight showing.
on RN (before this diff):
- when RN inspector opens: selecting an element keeps the highlight showing
- when RN inspector closes: stop showing highlihgintg.
on RN(this diff)
- selecting an element keeps the highlight showing
## TODO
- See if highlighting event can be sent on hover, instead of when an element is selected.
Reviewed By: lunaruan
Differential Revision: D38568135
fbshipit-source-id: d168874677d08a9c5526a7f896943579da804565
Summary:
Changelog: [RNTester][Internal] nohover pointerevent attributes platform test fixes
In implementing full support of nohover pointerevents I discovered a couple issues with my initial port of the web platform test — specifically I forgot to update the calls to `checkPointerEventAttributes` to be "touch" instead of "mouse" and I had forgotten to remove the `pointerMove` event from the expected pointer event order.
Reviewed By: lunaleaps
Differential Revision: D38718994
fbshipit-source-id: d189a4b5cf3042c9f493ac876062f4f60219ae2b
Summary:
I'm applying the same fix I applied to the Template.
This allows us to load Flipper without using reflection on RN Tester.
Changelog:
[Internal] [Changed] - Do not use reflection to load Flipper on RN Tester
Reviewed By: cipolleschi
Differential Revision: D38745404
fbshipit-source-id: c17fbd74df31441467e448f21c35171a7f2532ff
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34418
This is an attempt to relax the need of specifying a custom `TurboModuleManagerDelegate` and a `JSIModulePackage` in new apps for New Architecture.
Users can just specify the name of the dynamic library to load and they'll default to use the `DefaultTurboModuleManagerDelegate` and `DefaultJSIModulePackage`.
Users will still have to provide a C++ implementation for it for the time being, but this at least removes
one extra file that we requested them to create and maintain.
If we're fine with this approach, I'll replicate it inside the default template.
Changelog:
[Android] [Added] - Provide defaults for TurboModuleManagerDelegate and JSIModulePackage
Reviewed By: cipolleschi
Differential Revision: D38701180
fbshipit-source-id: eec302c5789990700eb75353d97751358ca6799f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34421
Currently we expose native code (.h, .cpp) inside the src/main/java folder.
This is making impossible for users on New Architecture to open the project
inside Android Studio.
The problem is that the src/main/java is reserved to Java/Kotlin sources only.
AGP 7.2 also removed support for mixed source roots:
https://developer.android.com/studio/releases/gradle-plugin#duplicate-content-roots
This is essentially forcing users to write Java code without any autocompletion
as all the React Native Java classes are considered C++ files.
I'm addressing this issue folder by folder by moving them
from ReactAndroid/src/main/java/com/facebook/... to ReactAndroid/src/main/jni/react/...
This is the diff for reactnativeblob
Changelog:
[Internal] [Changed] - Do not store .cpp/.h files inside src/main/java - reactnativeblob
Reviewed By: cipolleschi
Differential Revision: D38703092
fbshipit-source-id: 3d4391d8ee5587b199efa4001f68c6d4ed3ce2c2
Summary:
This is a nit cleanup of RNTester's build.gradle.
1. We should not create new configurations such as `hermesDebugImplementation` as those are automatically created by AGP.
2. We should not add imports of external .jar as we don't have them (and this generates a warning on console).
Changelog:
[Internal] [Changed] - Remove unnecessary configs from RNTester
Created from CodeHub with https://fburl.com/edit-in-codehub
Reviewed By: cipolleschi
Differential Revision: D38737330
fbshipit-source-id: e23f234f68c839af065d4948af6c780186cbdf3d
Summary:
Currently we expose native code (.h, .cpp) inside the src/main/java folder.
This is making impossible for users on New Architecture to open the project
inside Android Studio.
The problem is that the src/main/java is reserved to Java/Kotlin sources only.
AGP 7.2 also removed support for mixed source roots:
https://developer.android.com/studio/releases/gradle-plugin#duplicate-content-roots
This is essentially forcing users to write Java code without any autocompletion
as all the React Native Java classes are considered C++ files.
I'm addressing this issue folder by folder by moving them
from ReactAndroid/src/main/java/com/facebook/... to ReactAndroid/src/main/jni/react/...
This is the diff for mapbuffer
Changelog:
[Internal] [Changed] - Do not store .cpp/.h files inside src/main/java - mapbuffer
Reviewed By: cipolleschi
Differential Revision: D38699253
fbshipit-source-id: c1c8f8693b6da4e3428f8f280e1ca4d5c5d0f853
Summary:
Changes the React Native base ESLint configuration to consume `react-native-community/eslint-config` as a [yarn workspace](https://classic.yarnpkg.com/lang/en/docs/workspaces/), so that any dependencies of `react-native-community/eslint-config` can also be resolved from the root directory of `react-native`.
Previously, `~/.eslintrc.js` extended `react-native-community/eslint-config` using a relative file path. This is problematic because if any dependencies (notably, optional peer dependencies such as some of the TypeScript dependencies) are not already installed at the root directory of `react-native`, running ESLint could fail to resolve any required dependencies. In other words, there was an implicit dependency that `react-native/yarn.lock` would also contain any dependencies required by `react-native/packages/eslint-config-react-native-community/yarn.lock`.
With this change, running `yarn` from the root directory of `react-native` will also install any dependencies of `react-native-community/eslint-config`, and it will also symlink `react-native/node_modules/react-native-community/eslint-config` to `../../packages/eslint-config-react-native-community` (meaning any local changes to the config will still be reflected during active development).
## Changelog
[Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/34423
Test Plan:
Successfully install dependencies and run ESLint.
```
$ cd react-native
$ yarn
$ yarn lint
```
Successfully run Danger on https://github.com/facebook/react-native/pull/34401 (which would previously fail because `typescript-eslint/eslint-plugin` could not be resolved from the root directory of `react-native`):
```
$ cd react-native/bots
$ yarn
$ node ./node_modules/.bin/danger pr https://github.com/facebook/react-native/pull/34401
```
Reviewed By: NickGerleman
Differential Revision: D38710285
Pulled By: yungsters
fbshipit-source-id: a06ceea0884a90be60f6f5db9a5d42be52a951d5
Summary:
Changelog: [iOS][Internal] - Add iOS implementation of the button property of the PointerEvent object
This implements the `button` property on the PointerEvent object by storing the button which caused the down event in the `ActiveTouch` and reporting that button through `pointerdown` and `pointerup` events and -1 on all others. This diff also includes a small fix to the `pressure` property which was introduced due to `button` being correctly implemented.
Reviewed By: yungsters
Differential Revision: D38632543
fbshipit-source-id: 9dbbb23a9251f2e661faf37fdf206b9f0b26bc5f
Summary:
This adds an option to the Error Reporting pipeline of React Native to attach custom extra data to Exceptions passed to the native ExceptionsManager. This allows for error logging abstractions such as Meta's FBLogger to attach extra fields to the reported error. This can help with more detailed error reports without having to stringify all data in the error message.
Note: The field (which is technically on ExtendedError) is keyed using a Symbol. This is to make sure that any use of this ability is extremely deliberate, as (accidentally) adding tons of data (or unserializable data) can cause issues we send down the data to the native ExceptionsManager implementation. Data sent using this method should be strictly controlled, hence opting in is a concious effort using the symbol in ExceptionsManager
Changelog:
[Internal] [Added] - Ability to add custom data to extraData field of exceptions passed to the ExceptionsManager
Reviewed By: yungsters
Differential Revision: D36099191
fbshipit-source-id: ce3f0dae52acd742de98b71868323c5878eaa677
Summary:
Changelog:
[General][Fixed] - Run ExceptionsManager unit tests in both __DEV__ and prod mode
This suite of unittests use a `__DEV__` check in various places to check that the correct data is sent to either LogBox (in __DEV__) or the Native ExceptionsManager (in PROD). However, we're not actually running both modes, so half of the assert branches in these tests aren't ever utilized.
This diff uses the same approach as ReactNativeVersionCheck-test.js to execute this test suite twice: Once in DEV and once in PROD mode.
Reviewed By: motiz88
Differential Revision: D36099190
fbshipit-source-id: 40b8ea26f1d9e093202f3c3f3b55111110a8d64c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34420
Currently we expose native code (.h, .cpp) inside the src/main/java folder.
This is making impossible for users on New Architecture to open the project
inside Android Studio.
The problem is that the src/main/java is reserved to Java/Kotlin sources only.
AGP 7.2 also removed support for mixed source roots:
https://developer.android.com/studio/releases/gradle-plugin#duplicate-content-roots
This is essentially forcing users to write Java code without any autocompletion
as all the React Native Java classes are considered C++ files.
I'm addressing this issue folder by folder by moving them
from ReactAndroid/src/main/java/com/facebook/... to ReactAndroid/src/main/jni/react/...
This is the diff for hermes/reactexecutor and hermes/instrumentation
Changelog:
[Internal] [Changed] - Do not store .cpp/.h files inside src/main/java - hermes modules
Reviewed By: yungsters
Differential Revision: D38700760
fbshipit-source-id: 50cf38a0dae4f617e6d78317e5fe2a858290d0c0
Summary:
Those flags are always true and it doesn't really make sense to keep them around at this
moment as the Template setup relies on a single flag (newArchEnabled) and this adds
yet another discrepancy.
Changelog:
[Internal] [Changed] - Remove unused flags `ENABLE_FABRIC` and `ENABLE_TURBOMODULE` inside RN Tester
Reviewed By: cipolleschi
Differential Revision: D38701673
fbshipit-source-id: f7309e00b61fb56465ee0ec738d6cccc540ac1bf
Summary:
Currently both iOS and Android send over the list of transforms as an array. But there is an if statement that causes other platforms to get a matrix. This prevents other platforms from being able to use the fabric ViewProps class and the conversion functions as they exist in core, as those expect the transforms to be an array.
Stop special casing iOS and android. - Which will allow for example Windows to be able to share more fabric code.
## Changelog
[Internal] [Changed] - All platforms should get transform sent to native as an array of transform operations instead of a matrix
Pull Request resolved: https://github.com/facebook/react-native/pull/33579
Test Plan:
Similar change made in react-native-windows.
https://github.com/microsoft/react-native-windows/issues/9797
Reviewed By: NickGerleman
Differential Revision: D38615676
Pulled By: cortinico
fbshipit-source-id: 8861afe6bf34bebb09dd82f7365faf007dd79cbf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34396
Current we expose native code (.h, .cpp) inside the src/main/java folder.
This is making impossible for users on New Architecture to open the project
inside Android Studio.
The problem is that the src/main/java is reserved to Java/Kotlin sources only.
AGP 7.2 also removed support for mixed source roots:
https://developer.android.com/studio/releases/gradle-plugin#duplicate-content-roots
This is essentially forcing users to write Java code without any autocompletion
as all the React Native Java classes are considered C++ files.
I'm addressing this issue folder by folder by moving them
from ReactAndroid/src/main/java/com/facebook/... to ReactAndroid/src/main/jni/react/...
This is the diff for jscexecutor
Changelog:
[Internal] [Changed] - Do not store .cpp/.h files inside src/main/java - jscexecutor
Reviewed By: sshic
Differential Revision: D38615007
fbshipit-source-id: e5085130579f37f052b5c8a5702d2c0f1b332bee
Summary:
Currently we expose native code (.h, .cpp) inside the src/main/java folder.
This is making impossible for users on New Architecture to open the project
inside Android Studio.
The problem is that the src/main/java is reserved to Java/Kotlin sources only.
AGP 7.2 also removed support for mixed source roots:
https://developer.android.com/studio/releases/gradle-plugin#duplicate-content-roots
This is essentially forcing users to write Java code without any autocompletion
as all the React Native Java classes are considered C++ files.
I'm addressing this issue folder by folder by moving them
from ReactAndroid/src/main/java/com/facebook/... to ReactAndroid/src/main/jni/react/...
This is the diff for uimanager
Changelog:
[Internal] [Changed] - Do not store .cpp/.h files inside src/main/java - uimanager
Reviewed By: dmitryrykun
Differential Revision: D38656400
fbshipit-source-id: f52487160fa6c05ec382842e2a6125a5c4cb1e86
Summary:
Make sure the new app template uses the correct project CMake project name: `helloworld_appmodules`, otherwise the app will fail to load the dynamic library.
This was a copy-n-paste error from RNTester.
## Changelog
[Internal] - Make sure the template project name is `helloworld_appmodules`
Pull Request resolved: https://github.com/facebook/react-native/pull/34417
Test Plan: Will test an app created with the New App template
Reviewed By: cipolleschi
Differential Revision: D38698682
Pulled By: cortinico
fbshipit-source-id: b09331a52989b3b131ea8ba627057febcb535ef8
Summary:
As the title says, android.sourceSets.main.jni is deprecated in AGP. We should not be accessing it. Here we were setting it to the empty array (the default value).
It will cause the build to break in a future AGP bump, hence I'm removing it.
Changelog:
[Internal] [Changed] - Remove deprecated jni.srcDirs from ReactAndroid build file
Created from CodeHub with https://fburl.com/edit-in-codehub
Reviewed By: cipolleschi
Differential Revision: D38655857
fbshipit-source-id: 2eb6897964554da462bde58937a6de708bc047dc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34384
This Diff aims to create a RCTAppDelegate library to offer a subclass which automates some operations required to set up the new architecture.
## Changelog
[iOS][Added] - Added the RCTAppDelegate library
Reviewed By: cortinico
Differential Revision: D38580424
fbshipit-source-id: 38f6c4b8ff2790a2ce9e23d385b36307701cffb7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34398
This Diff cleans up the codegen folder for iOS when we install the pods. This is useful to start from a clean situation. The codegen runs after this step and we make sure that the file system is clean
## Changelog
[iOS][Changed] - Cleanup codegen build folder before installing the pods
Reviewed By: cortinico
Differential Revision: D38657027
fbshipit-source-id: 8a914457d7963521d6d8dc7819eba864736f50a0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34403
This change mirrors D38457812 (https://github.com/facebook/react-native/commit/063c2b4668b279ccbca639f98f7a0a5c4d7c5690) which added -Wpedantic to ReactCommon targets, but for the Android build used by OSS. This should ensure contributors see the same warnings locally as the internal build would produce.
Changelog:
[Android][Changed] - Enable -Wpedantic in OSS Android Targets
Reviewed By: cortinico
Differential Revision: D38632454
fbshipit-source-id: 19a036ee3f902eb9d47c568aef448af9d8562358
Summary:
Sometime over the past few months (and with changes such as migrating to the `hermes-eslint` parser), a bunch of lint warnings crept into the codebase.
This does a pass to clean them all up, ignore generated files, and refactor some code to be... better.
There should be no observable behavior changes as a result of this.
Changelog:
[Internal]
Reviewed By: NickGerleman
Differential Revision: D38646643
fbshipit-source-id: a7b55d1e4cd5700340cc5c21f928baf3ea1d5a58
Summary:
Cleans up a few minor Flow suppression comments in `FlatList`. This reveals a new Flow error that is the result of `FlatList`'s props object being inexact whereas `VirtualizedList`'s props object is exact. For now, I introduce another -- but more specific -- Flow suppression for that type error.
The code changes should not have any consequential behavior change.
Changelog:
[Internal]
Reviewed By: NickGerleman
Differential Revision: D38646228
fbshipit-source-id: f4f9b0ad95323157ff1519353b38e8486adc841d
Summary:
The `RuntimeAdapter` may be used after `disableDebugging` has been called. To ensure the `RuntimeAdapter` is alive long enough for this use, the Inspector should continue to control `RuntimeAdapter`'s lifetime (which is currently done via a `unique_ptr` that's moved into the Inspector).
Callers need a way to identify the `RuntimeAdapter` after it has been moved into the Inspector so that debugging can be disabled via `disableDebugging`.
This could be done by switching from a `unique_ptr` to a `shared_ptr` (so the caller can keep a copy), but consumers don't really have a reason to hang onto the `RuntimeAdapter` instance. Instead, leave the `RuntimeAdapter` inside a `unique_ptr`, and have consumers use a token to identify instances.
Update all consumers of this API to use this new token interface.
Changelog: [Internal]
Reviewed By: jpporto
Differential Revision: D38513256
fbshipit-source-id: 33580747cd8365d25dbddbe289f0c41141e3bc6a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34386
Current we expose native code (.h, .cpp) inside the src/main/java folder.
This is making impossible for users on New Architecture to open the project
inside Android Studio.
The problem is that the src/main/java is reserved to Java/Kotlin sources only.
AGP 7.2 also removed support for mixed source roots:
https://developer.android.com/studio/releases/gradle-plugin#duplicate-content-roots
This is essentially forcing users to write Java code without any autocompletion
as all the React Native Java classes are considered C++ files.
I'm addressing this issue folder by folder by moving them
from `ReactAndroid/src/main/java/com/facebook/...` to `ReactAndroid/src/main/jni/react/...`
This is the diff for reactperflogger
Changelog:
[Internal] [Changed] - Do not store .cpp/.h files inside src/main/java - reactperflogger
Reviewed By: cipolleschi
Differential Revision: D38584681
fbshipit-source-id: 8b65b3fa47a7f106c7fea79fd739f0e4e37efa2a
Summary:
Improves upon the existing prop types error messages to first recommend migrating to a type system (before recommending the usage of `deprecated-react-native-prop-types`).
## Changelog
[General][Changed] - Minor change to PropTypes error message.
Pull Request resolved: https://github.com/facebook/react-native/pull/34392
Test Plan: Careful code inspection.
Reviewed By: rickhanlonii
Differential Revision: D38632723
Pulled By: yungsters
fbshipit-source-id: 88e44116475c7d93bc561c9ab6883855d6d79a7e
Summary:
needsOffscreenAlphaCompositing is supported on both iOS and Android, but was missing from the view config for Android.
https://reactnative.dev/docs/view#needsoffscreenalphacompositinghttps://fburl.com/code/hfxkrur1
Changelog:
[Internal][Fixed] - Add needsOffscreenAlphaCompositing to view config
Reviewed By: NickGerleman
Differential Revision: D38580371
fbshipit-source-id: 9b577079e575d73c94d7c0d0298ba880c1438099
Summary:
This is an attempt to fix the `test_buck` CI after the land of https://github.com/facebook/react-native/commit/063c2b4668b279ccbca639f98f7a0a5c4d7c5690
There were references to internal args that are causing Buck OSS to fail. I'm removing them all.
## Changelog
[Internal] - Do not use kwargs which are not known in Buck OSS
Pull Request resolved: https://github.com/facebook/react-native/pull/34388
Test Plan: If CI is green, we can merge this 👍
Reviewed By: motiz88
Differential Revision: D38619542
Pulled By: cortinico
fbshipit-source-id: e00b4b5da7e181365e63e10aa50d0ecde8024359
Summary:
Add ability to store and retrieve a list of MapBuffer as an entry of MapBuffer.
```
Example:
MapBuffer1
{
key1: "test string",
key2: MapBuffer2,
key3: [MapBuffer3, MapBuffer4]
}
```
Changelog:
[General][Added] Add ability to store and retrieve a list of MapBuffer
Reviewed By: JoshuaGross
Differential Revision: D38460204
fbshipit-source-id: 3e721418be2dca6d5f15f665753844d6f531e31c
Summary:
Bump CLI to latest v9 alpha so that I can then chery-pick in 0.70-stable branch for next RC
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[General] [Changed] - bump CLI to latest v9-alpha11
Pull Request resolved: https://github.com/facebook/react-native/pull/34385
Test Plan: N/A
Reviewed By: robhogan
Differential Revision: D38615615
Pulled By: dmitryrykun
fbshipit-source-id: ea5dd7b93f4ed3bb82347fd730b8e65e8a89a6ca
Summary:
Followup to https://github.com/facebook/react-native/issues/34379 by danilobuerger
Loading Flipper via reflection is type unsafe and requires extra code + exception handling that we can get rid of. The recommended way to use Flipper on Android is either via a `no-op` artifact or by using build flavors.
As we already had a setup for Flipper for `debug`, I'm creating the `release` equivalent which is just a stub. This allows us to get rid of some code inside `MainApplication.java`
## Changelog
[Android] [Changed] - Do not load Flipper via reflection
Pull Request resolved: https://github.com/facebook/react-native/pull/34383
Test Plan: Will wait for a CI result on this.
Reviewed By: cipolleschi
Differential Revision: D38615257
Pulled By: cortinico
fbshipit-source-id: 66bb2c46c5df36a15c1b27512209a849f55d64c9
Summary:
Folly's molly target combines a number of targets that are supposed to be useable on mobile. Since we're trying to move away from folly, we should instead list explicitly which parts of folly we're using so we can remove them over time, and track which targets no longer have any folly dependencies.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D38352060
fbshipit-source-id: 09d0d84793692f97f4d49390c99c38b23441df54
Summary:
React Native is compiled downstream with MSVC, meaning the introduction of code depending on language extensions specific to gcc/clang may cause breakage.
We can enable `-Wpedantic` to flag any behavior not officially supported by the specified C++ standard. This will includes rules beyond what MSVC has trouble with, but seems to not have too many "noisy warnings".
This change enables -Wpedantic in BUCK targets within ReactCommon.
This makes the OSS C++ build for Android/iOS slightly more permissive than the internal build, A followup is to add the changes to OSS build logic as well, to avoid contributors seeing more errors upon internal submission. (checking with cortinico on how to do this for Android).
react-native-windows uses a higher warning level than `-Wall`, which is an additional cause of compilation failures, but is not addressed as part of this change.
Changelog:
[Internal][Changed] - Enable -Wpedantic for targets inside ReactCommon
Reviewed By: rshest
Differential Revision: D38457812
fbshipit-source-id: 014da1ac0b7ad8f78154e6e447ed58def6bd0d47
Summary:
This isolates and parallelize all the BUCK related work inside a `test_buck` job, so it's immediately clear where a failure happend.
I've also added a couple of minor improvements:
- Don't clone okbuck just to consume a script. I've copied the script over instead.
- Removed unnecessary `buck_cache_key`
This should reduce ~5 minute of build time from Test Android which was already beyond 10 minutes.
## Changelog
[Internal] - Isolate the buck OSS commands inside test_buck
Pull Request resolved: https://github.com/facebook/react-native/pull/34378
Test Plan: Let's wait for a `test_buck` and `test_android` output.
Reviewed By: cipolleschi
Differential Revision: D38580359
Pulled By: cortinico
fbshipit-source-id: 8b3915bbc28b4a7a169011fe9047f402c2d1f6ee
Summary:
Calling `setPivotX` and `setPivotY` internally sets `isPivotExplicitlySet` in Android UI, which causes some transforms to no longer use the right transform. Instead use `resetPivot` to get the desired behaviour.
Changelog: [Android][Fixed] Bug with view transforms when view recycling is enabled
Reviewed By: NickGerleman
Differential Revision: D38579267
fbshipit-source-id: 36186286c6765f92aabaa44994546e06f34c2be0
Summary:
RN for Android fires `keyboardDidShow` and `keyboardDidHide` by observing changes to viewable window size. This isn't always reliable, such as when an activity has `awindowSoftInputMode` set to not have the system adjust the viewport when a keyboard is opened.
Android 11 added the direct ability to measure and check visibility of the soft keyboard via `WindowInsets`, which fixes these issues. This is exposed downlevel to API 23 via WindowInsetsComapt` with the same limitations as previously, but using it simplifies our calculations a lot.
Changelog:
[Android][Fixed] - Use WindowInsetsCompat for Keyboard Events
Reviewed By: javache
Differential Revision: D38500859
fbshipit-source-id: d4ad41d7e75e4b9c14a485539a5f9de19de74362
Summary:
Changelog: [iOS][Internal] - Fix ghost pointer leave/out events firing due to view recycling on iOS
While implementing the properties on the PointerEvent object on iOS I noticed that in certain specific scenarios I was seeing pointerLeave events being fired seemingly without corresponding pointerEvent events and even more strangely, when the pointer wasn't even close to the view in question.
After a lot of research I discovered that this was caused by an incompatibility between my strategy of keeping track/identifying views which are being hovered and RN's handling of creating/deleting views on iOS. See on iOS RN has the `RCTComponentViewRegistry` class which manages the creation & deletion of UIViews and adds an optimization of recycling views instead of outright deleting them.
This is causing issues with my tracking of which views are hovered because I compare the view's object references which, while accurate towards confirming equality of an underlying UIView — isn't accurate in confirming the equality of views from react's perspective.
This diff addresses this issue by adding a simple wrapper class that can be used around the UIViews which stores the view's react ID at initialization time ensuring it doesn't get updated even if the underlying view's react id is. As an additional precaution the wrapper class will also not return the view it's wrapping if their react tags do not match.
Reviewed By: lunaleaps
Differential Revision: D38546628
fbshipit-source-id: 8b732d52da0e61a5447001e8940e4439f49c6baf
Summary:
BaseViewManager.setPointerEnter was never called on ReactTextViews, and thus text views would not receive hover events.
Changelog:
[Internal][Fixed] - Add pointer events to text view config
Reviewed By: lunaleaps, javache
Differential Revision: D38557546
fbshipit-source-id: cfc0e5442efbd7c76d1b47acf56496d10ef78cf5
Summary:
Previously published by [grgr-dkrk][2] as [https://github.com/facebook/react-native/issues/31296][3], fixes the following issues:
1) ImportantForAccessibility="no" does not work on Text, Button
2) ImportantForAccessibility="no-hide-descendants" does not work on Text, Button, or ImageBackground.
Note: On ImageBackground, focus is prevented on the imageBackground node itself, but focus is not prevented on its descendants.
Note: [Button component expected behavior for prop importantForAccessibility][4]
>Some components like Button seem like atomic units, but they end up rendering a hierarchy of components for example a wrapper View with a Text inside them. Allowing those descendants to become focusable, breaks the model of these being a single component to consider and forcing no-hide-descendants makes sense here.
>The other option is always to render any descendants of these elements with importantForAccessibility="no", so they can never be focusable on their own. This would have the same result, **BUT may potentially cause issues when the descendant content is supposed to automatically get moved up to the focusable ancestor to act as a label** (which is what Talkback does with unfocusable text elements by default).
Note: [importantForAccessibility="no" does not allow screenreader focus on nested Text Components with accessibilityRole="link" or inline Images][5]
fixes https://github.com/facebook/react-native/issues/30850 related https://github.com/facebook/react-native/pull/33690
## Changelog
[Android] [Fixed] - adding importantForAccessibility for Text, Button, ImageBackground
Pull Request resolved: https://github.com/facebook/react-native/pull/34245
Test Plan:
1) testing ImageBackground importantForAccessiblity ([link to test][1])
2) importantForAccessibility="no" does not allow screenreader focus on nested Text Components with accessibilityRole="link" or inline Images ([link to test][5])
3) testing ImageBackground importantForAccessiblity ([link to test][6])
4) Button with importantForAccessibility=no ([link to test][7])
[1]: https://github.com/facebook/react-native/pull/31296#issuecomment-1192341626 ""
[2]: https://github.com/grgr-dkrk "grgr-dkrk"
[3]: https://github.com/facebook/react-native/pull/31296 "https://github.com/facebook/react-native/issues/31296"
[4]: https://github.com/facebook/react-native/pull/31296#discussion_r616184584 "expected behaviour with prop importantForAccessibility in Button component"
[5]: https://github.com/facebook/react-native/issues/30850#issuecomment-1192286477 "importantForAccessibility=no does not allow screenreader focus on nested Text Components with accessibilityRole=link or inline Images"
[6]: https://github.com/facebook/react-native/pull/34245#issuecomment-1192446124 "testing ImageBackground importantForAccessiblity"
[7]: https://github.com/facebook/react-native/pull/34245#issuecomment-1192443589 "Button with importantForAccessibility=no"
Reviewed By: cipolleschi
Differential Revision: D38121992
Pulled By: dmitryrykun
fbshipit-source-id: 368b4dcb47d7940274820aa2e39ed5e2ca068821
Summary:
Hermes is enabled by default. We set `USE_HERMES` envvar to `false` to explicilty disable Hermes. The only valid way to check it would be to compare it against `false`. Everything else will produce invalid results if `USE_HERMES` is not defined. For example `$USE_HERMES != true` will turn into `'' != true`, which evaluates to `true`.
Due to this bug source maps were not generated by default.
Changelog:
[iOS][Fixed] - USE_HERMES envvar check fixed in react-native-xcode.sh. Now source maps are generated by default.
Reviewed By: cipolleschi
Differential Revision: D38571971
fbshipit-source-id: bc6b505c225c56d62ee773b401b66d821965e106
Summary:
We ran an experiment to test different implementations of TurboModules HostObjects, as the current one has various inefficiencies, such as re-creating HostFunctions on every property access. The strategy we found to be most efficient and flexible longer-term is to represent the TurboModule with a plain JavaScript object and use a HostObject as its prototype. Whenever a property is accessed through the prototype, we cache the property value on the plain object, so it can be efficiently resolved by the VM for future accesses.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D38355134
fbshipit-source-id: 59253091412d0c6827ad7a4b1ac7dc0c7fe89cc2
Summary:
After https://github.com/facebook/react-native/issues/34370, Danger started failing because the `DANGER_GITHUB_API_TOKEN` was not properly set.
This PR fixes it.
## Changelog
[General] [Changed] - Set back the `DANGER_GITHUB_API_TOKEN`.
Pull Request resolved: https://github.com/facebook/react-native/pull/34375
Test Plan: Danger GitHub action is executed correctly.
Reviewed By: cortinico
Differential Revision: D38571718
Pulled By: cipolleschi
fbshipit-source-id: 51168098b4f910f6fefd2872f917e12daad1ec4c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34373
By introducing a RCTAppDelegate base class, we can simplify the migration step to supports TM
## Changelog
[iOS][Changed] - Simplified migration steps for TM
Reviewed By: cortinico
Differential Revision: D38509891
fbshipit-source-id: 716c1e668a05ecbd9c679558889564780816e491
Summary:
`toJs()` resolution trips up on converting the plain old jsi values.
In order to help it - remove the automatic inference of template types, since we already know that `T` in this case is going to be the concrete jsi type.
This allows using implicit conversions on Sync/Async Callback types, as well as AsyncPromise.
Without it - AsyncPromise/Callback trip up on trying to convert Convertor<T> to jsi type.
Changelog:
[General][Added] SyncCallback/AsyncCallback/AsyncPromise bridging types in C++ now allow wrapping JSI types.
Reviewed By: JoshuaGross
Differential Revision: D38529799
fbshipit-source-id: 860de2d771899f331bf1a4ff0dade4eccc875618
Summary:
Changelog: [RNTester][Internal] - Add a pointer event attributes test variant for no-hover pointers
This adds a slightly different version of the existing PointerEventAttributesHoverablePointers test but for pointers that cannot hover (such as touches)
Reviewed By: lunaleaps
Differential Revision: D38401888
fbshipit-source-id: 4ed782cc2157dcaa8f6c294ae3589843d020bc92
Summary:
Fixed Flipper not recognizing app when using custom Xcode configuration names.
This fixes the problem that renaming the "Debug" Xcode configuration causes Flipper to not work. Despite using the recommended `:configurations` parameters and instructing Cocoapods that it was a debug build (see https://github.com/facebook/react-native/issues/34332), it still wouldn't recognize the app due to missing C preprocessor flags, specifically it was missing `-DFB_SONARKIT_ENABLED=1`.
## 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] - Flipper now supports custom Xcode build configuration names
Pull Request resolved: https://github.com/facebook/react-native/pull/34333
Test Plan:
I applied the PR change to 0.68.2 (which work similarly but code was refactored since then). I then used `patch-package` to test the change and the fix worked on 2 separate projects.
Patch-package change equivalent:
```diff
diff --git a/node_modules/react-native/scripts/react_native_pods.rb b/node_modules/react-native/scripts/react_native_pods.rb
index f2ceeda..2ea57d6 100644
--- a/node_modules/react-native/scripts/react_native_pods.rb
+++ b/node_modules/react-native/scripts/react_native_pods.rb
@@ -180,7 +180,7 @@ def flipper_post_install(installer)
# Enable flipper for React-Core Debug configuration
if target.name == 'React-Core'
target.build_configurations.each do |config|
- if config.name == 'Debug'
+ if config.debug?
config.build_settings['OTHER_CFLAGS'] = "$(inherited) -DFB_SONARKIT_ENABLED=1"
end
end
```
**Screen shot of Xcode after the patch has been applied, for RN v0.68.2:**

Reviewed By: dmitryrykun
Differential Revision: D38373812
Pulled By: cipolleschi
fbshipit-source-id: d2949927084160bf0c6f8af37a7966dd22fea9a6
Summary:
This is a nit. Did some cleanups on our Danger setup.
The most substantial work is:
- Moved over danger to run on `pull_request_target`. This allow us to re-use the Github Action access token without having to provide one.
- Fixed an issue with the `Pick Request` label which was not applied correctly.
- Removed the danger_id as we were not passing it correctly.
## Changelog
[Internal] - Let danger run on `pull_request_target`
Pull Request resolved: https://github.com/facebook/react-native/pull/34370
Test Plan: Tested locally with `yarn danger pr https://github.com/facebook/react-native/pull/34197`
Reviewed By: cipolleschi
Differential Revision: D38533144
Pulled By: cortinico
fbshipit-source-id: 178ce411eb956870563c4d51719ed4dae1f1536d
Summary:
This is a nit, but at least will help us reduce requests to rebase for PRs which maybe have a broken CI due to a stale base commit.
I've limited the scope to members and owners. A `/rebase` will trigger a rebase authored by Github Action bot.
We can play a bit around with it, and remove it if it doesn't really work well for us.
## Changelog
[Internal] - Setup Automatic Rebase given a /rebase comment
Pull Request resolved: https://github.com/facebook/react-native/pull/34369
Test Plan: Nothing to test here.
Reviewed By: cipolleschi
Differential Revision: D38509480
Pulled By: cortinico
fbshipit-source-id: 1df3927638b162d4a787c81372a835d583159498
Summary:
The Android version of PlatformConstants exposes the device's [UI Mode]( https://developer.android.com/guide/topics/resources/providing-resources#UiModeQualifier). It is missing the case for 'vrheadset', added in Android API 26. We should return the expected result when this is queried.
Changelog:
[Android][Added] - Expose UI_MODE_TYPE_VR_HEADSET in PlatformConstants
Reviewed By: rshest
Differential Revision: D38495875
fbshipit-source-id: fd904bd11213448415b7d75145d9ba6311ed407b
Summary:
This adds a simple debug UI to verify the keyboard events "keyboardDidShow" and "keyboardWillShow"
Changelog:
[Internal][Added] - Add "KeyboardExample" to RNTester
Reviewed By: cortinico
Differential Revision: D38500869
fbshipit-source-id: 99913a05849a7dd27dfdee2d622058b9c2604a7f
Summary:
- Current version of clang-format does not work on Apple M1/M2/... chipsets https://github.com/angular/clang-format/issues/78
Changelog:
[General][Fixed] - Make clang-format work in M1 (Apple Silicon)
Reviewed By: cortinico
Differential Revision: D38505844
fbshipit-source-id: c94a71dea82217e725a3609d72692a15a8fe22e0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34368
When a user runs `RCT_NEW_ARCH_ENABLED=1 pod install` to install the dependencies for the New Architecture, Cocoapods prints a warning because of React Native is still set up with a legacy configuration.
This diff silences these warnings because they can confuse the final user.
**Note:** We need to keep this legacy configuration to support both the legacy and the New Architecture.
## Changelog
[iOS][Changed] - Silence warning due to react-native internal details.
Reviewed By: cortinico
Differential Revision: D38503405
fbshipit-source-id: b89857aa88435b1c64da52875606003239ff2e05
Summary:
Adds changelog for new patch.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - add changelog entry for 0.68.3
Pull Request resolved: https://github.com/facebook/react-native/pull/34366
Test Plan: N/A
Reviewed By: christophpurrer
Differential Revision: D38500055
Pulled By: dmitryrykun
fbshipit-source-id: 0ef857ef1822522372a5743e9471b791d11e0181
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34354
This change simplifies the setup for New Architecture for users on Android.
Instead of using the Android.mk file, users can now use a CMake file which
encapsulate a lot of the complexities and reduces the maintainance cost.
Android.mk support is kept for backward compatibility.
Changelog:
[Android] [Changed] - Update the new app template to use CMake instead of Android.mk
Reviewed By: cipolleschi
Differential Revision: D38460536
fbshipit-source-id: 9d4c3b15be751921d34023b24c174044537e6f02
Summary:
Fixes https://github.com/facebook/react-native/issues/34229
Basically, the react android conflicts with the kotlin version that's defined in the top level build.gradle. To resolve it, the approach was to get the `kotlinVersion` defined in top level build.gradle and use it. If it's not defined, we use the default(1.6.10 as of now).
The reason behind not using the DSL is that it doesn't allow us to use the variables due to it's constrained syntax.
See [here](https://docs.gradle.org/current/userguide/plugins.html#sec:constrained_syntax)
So the idea was to use the build script to resolve the kotlin plugin and it works 👍 .
Kindly asking for review cortinico :)
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Android] [Changed] - refactored usage of kotlin plugin
Pull Request resolved: https://github.com/facebook/react-native/pull/34255
Test Plan: Ran the node ./scripts/run-ci-e2e-tests.js --js --android --ios to verify it doesn't introduce any unexpected issues.
Reviewed By: dmitryrykun
Differential Revision: D38468567
Pulled By: cortinico
fbshipit-source-id: f9ab635fcf033f1d337ed90793ba1667957b8e01
Summary:
## Summary
Fixes https://github.com/facebook/react-native/issues/32497
Fixes https://github.com/facebook/react-native/issues/34212
The assigned HBC_SOURCEMAP_FILE path is incorrect as it does not reference the hermes bundle source map file
See: https://github.com/facebook/react-native/issues/32497#issuecomment-1171379674
## Changelog
[General] [Fixed] - using SOURCEMAP_FILE during xcode build phase with Hermes enabled
Pull Request resolved: https://github.com/facebook/react-native/pull/34111
Test Plan:
1. In a blank react-native project
1. Enable Hermes
1. Go to xCode -> Project -> Build Phases -> Bundle React Native code and images
3. Add `export SOURCEMAP_FILE="$(pwd)/../ios.jsbundle.map"` before `react-native-xcode.sh`
e.g.
```sh
export NODE_BINARY=node
export SOURCEMAP_FILE="$(pwd)/../ios.jsbundle.map"
../node_modules/react-native/scripts/react-native-xcode.sh
```
4. Make a release build `npx react-native run-ios --configuration Release` or `CMD + I` in xCode
5. Verify the build is successful
6. Verify the `.map` file is outputted at the specified path (`ios.jsbundle.map` in project root for the example above)
Reviewed By: cipolleschi
Differential Revision: D38460586
Pulled By: dmitryrykun
fbshipit-source-id: 54c1594b37fa2253896ce9739c1a9a712deecd0f
Summary:
Adds changelog for new patch.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - add changelog entry for 0.68.3
Pull Request resolved: https://github.com/facebook/react-native/pull/34367
Test Plan: N/A
Reviewed By: dmitryrykun
Differential Revision: D38500554
Pulled By: huntie
fbshipit-source-id: f2fd48b3a0a608d488c1edb85ea8c424029bd9c9
Summary:
changelog: [internal]
`_forceDispatchNextScrollEvent` is already called inside `- (void)scrollToOffset:(CGPoint)offset animated:(BOOL)animated`. No need to call it before.
Reviewed By: cipolleschi
Differential Revision: D38499299
fbshipit-source-id: cf6635e02bf582346869f77194cf06be7939351f
Summary:
I'm extending `test_android_template` to use a CI Matrix. This will allow us to make sure that we test a new app template against Debug/Release and against New/Old Arch.
This will make sure we catch a lot of bugs early on 👍
## Changelog
[Internal] - Setup a build matrix for test_android_template
Pull Request resolved: https://github.com/facebook/react-native/pull/34355
Test Plan: Will wait for a green CI
Reviewed By: cipolleschi
Differential Revision: D38499773
Pulled By: cortinico
fbshipit-source-id: 5a24c21d111fb4ae0f4600d86b786021f6ad2abe
Summary:
https://github.com/facebook/react-native/pull/34310 introduced Gradle 7.5.0, but I noticed that the Gradle team actually missed to remove the `Incubating` annotation for the Java 18 support. The latest 7.5.1 is fixing that. More details can be found here: https://github.com/gradle/gradle/releases/tag/v7.5.1
## Changelog
[Android] [Changed] - Bump Gradle to 7.5.1
Pull Request resolved: https://github.com/facebook/react-native/pull/34359
Test Plan: Successfully build on a local project. I can share the actual branch if needed.
Reviewed By: cipolleschi
Differential Revision: D38497804
Pulled By: cortinico
fbshipit-source-id: 792b83707d5b6aaf7ef29531f82a1bc9224b3204
Summary:
We have a older version of caniuselite in the yarn.lock.
This is causing several warnings on console which I'm resolving with:
`npx browserslist@latest --update-db`
Changelog:
[Internal] [Changed] - Update caniuse-lite with `npx browserslist@latest --update-db`
Reviewed By: cipolleschi
Differential Revision: D38459471
fbshipit-source-id: 4476e2f925f693e4aff457b80906faa51247772c
Summary:
Use of `__attribute__` and `__unused` is compiler specific. Opt for standard `[[maybe_unused]]` instead.
## Changelog
[General] [Fixed] - Remove compiler-specific syntax.
Pull Request resolved: https://github.com/facebook/react-native/pull/34357
Test Plan: Built on react-native-windows.
Reviewed By: cipolleschi
Differential Revision: D38498481
Pulled By: javache
fbshipit-source-id: af43206788f54dda3b747b6417e20096c7d520e8
Summary:
After. D38153924 (https://github.com/facebook/react-native/commit/e24ce708abffee8ec4521ba8162ea8964eb4429f), layout mount items have 7 int arguments but the logger only pulls out and displays 6, which leads to the following exception: "Caught exception trying to print java.lang.IllegalArgumentException: Invalid type argument to IntBufferBatchMountItem"
Changelog: [Internal]
Created from CodeHub with https://fburl.com/edit-in-codehub
Differential Revision: D38472664
fbshipit-source-id: 1583a5514c2ab662eaf5c4ce4bf33c958cb05282
Summary:
This diff is part of an overall stack, meant to fix incorrect usage of `setState()` in `VirtualizedList`, which triggers new invariant checks added in `VirtualizedList_EXPERIMENTAL`. See the stack summary below for more information on the broader change.
## Diff Summary
This adds a `StateSafePureComponent`, which will override `setState`, along with `this.props` and `this.state`, in order to add runtime enforcement that `this.props` and `this.state` are not accessed during a state update where we should be relying on parameter instead. This should be landed after the fixes for unsafe `this.props`/`this.state` usage.
## Stack Summary
`VirtualizedList`'s component state is a set of cells to render. This state is set via the `setState()` class component API. The main "tick" function `VirtualizedList._updateCellsToRender()` calculates this new state using a combination of the current component state, and instance-local state like maps, measurement caches, etc.
From: https://reactjs.org/docs/state-and-lifecycle.html#state-updates-may-be-asynchronous
---
> React may batch multiple setState() calls into a single update for performance. Because this.props and this.state may be updated asynchronously, you should not rely on their values for calculating the next state. For example, this code may fail to update the counter:
```
// Wrong
this.setState({
counter: this.state.counter + this.props.increment,
});
```
> To fix it, use a second form of setState() that accepts a function rather than an object. That function will receive the previous state as the first argument, and the props at the time the update is applied as the second argument:
```
// Correct
this.setState((state, props) => ({
counter: state.counter + props.increment
}));
```
---
`_updateCellsToRender()` transitively calls many functions which will read directly from `this.props` or `this.state` instead of the value passed by the state updater. This intermittently fires invariant violations, when there is a mismatch.
This diff migrates all usages of `props` and `state` during state update to the values provied in `setState()`. To prevent future mismatch, and to provide better clarity on when it is safe to use `this.props`, `this.state`, I overrode `setState` to fire an invariant violation if it is accessed when it is unsafe to:
{F756963772}
Changelog:
[Internal][Changed] - Enable setState() hooks
Reviewed By: rshest
Differential Revision: D38294338
fbshipit-source-id: d04ff39f68df90adc9f4680887d308d997903675
Summary:
Current creation of the errorProcessor lambda does a full copy of folly::dynamic object, which for large objects can cause 1000's of memory allocations, and thus increasing app's memory footprint and speed.
Changelog:
[General][Fixed] - Avoid full copy of large folly::dynamic objects in JSIExecutor#defaultTimeoutInvoker
Reviewed By: sammy-SC
Differential Revision: D38368392
fbshipit-source-id: 88579a7069891828cf6dae130c4964db6b494565
Summary:
Make the interface to enable/disable debugging symmetrical; both enabling and disabling are done by passing in a reference to the RuntimeAdapter.
Doing so requires moving ownership of the RuntimeAdapter, so each caller (java2js, arfx engine, React Native, react-native-github, and venice) has been updated to own their adapter.
Additionally, the two implementations of the Inspector connection (react-native-github and arfx engine) have been updated to expect and use the new argument.
`Connection::getRuntime` could be removed and replaced with calls to `Connection::getRuntimeAdapter::getRuntime`. I've left that choice to a followup diff, as this one is getting messy enough as it is.
Changelog: [Internal]
Reviewed By: jpporto
Differential Revision: D38242964
fbshipit-source-id: f2a3354f9d424b203a76d2c15122a6515a0926f2
Summary:
Changelog: [Internal]
Debugging is enabled via `enableDebugging` with a `RuntimeAdapter` that provides a `HermesRuntime`. This same `HermesRuntime` should be passed to `disableDebugging`, not a decorated version. Change the argument type of `disableDebugging` to steer callers in the right direction.
Reviewed By: jpporto
Differential Revision: D38051662
fbshipit-source-id: ae436a4af12fa01143bfbcdb97e65e4fca90154d
Summary:
Changelog: [Internal]
Provide a `HermesRuntime` from the `RuntimeAdapter` (instead of a decorated Hermes runtime).
As the Inspector can now directly access the `HermesRuntime` (which exposes access to the debugger), `RuntimeAdapter::getDebugger` is no longer necessary; remove it.
Reviewed By: jpporto
Differential Revision: D38050821
fbshipit-source-id: fa83165a9348bdff0dce1b04ec1afb81d2b1c3e2
Summary:
Changelog: [Internal]
Make runtime use more consistent, always using the same undecorated runtime. This prevents the previous mixing of decorated and undecorated runtimes.
Reviewed By: jpporto
Differential Revision: D38035166
fbshipit-source-id: 81929e42ccc4de6d5c5c09ee7ee31f055af82735
Summary: Changelog: [Internal] Add logic for `isPrimary` for PointerEvent object and set other properties to their default value
Reviewed By: javache
Differential Revision: D38363163
fbshipit-source-id: 5ec9de69fb5b34295f1da6daedd5c67e3bd3727e
Summary:
Changelog: [Internal] - Instead of using toolType which is a property per pointer in the MotionEvent, let's use [getSource](https://developer.android.com/reference/android/view/MotionEvent#getSource()) which is the source for the entire event (all pointers).
This aligns with what we've seen on Android when we have a mouse and touch input, there is only one active source input device.
And removes the need for checking a flag we set here: D36958947
Reviewed By: NickGerleman
Differential Revision: D37702090
fbshipit-source-id: ba2a4f0c28e1aff2b8b04314fe6f737b66ed0be3
Summary:
Expo Go was using `nativeInjectHMRUpdate` for [snack](https://snack.expo.io/) to provide stack traces to OTA errors. `nativeInjectHMRUpdate` was replaced with `globalEvalWithSourceUrl` [here](https://github.com/facebook/react-native/commit/71c84cf6bebba701bb23b135e079aa68c05f4441). The issue with `globalEvalWithSourceUrl` is that it is stripped in RELEASE builds, and Expo Go is installed via the App Store, making it a release build.
I propose we keep the method, `eval` is still exposed in production so there's no increase in security risk, simply provides a better DX for multipurpose development clients.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Android] [Added] - Expose `globalEvalWithSourceUrl` in production builds.
[iOS] [Added] - Expose `globalEvalWithSourceUrl` in production builds.
Pull Request resolved: https://github.com/facebook/react-native/pull/34319
Test Plan: - Function should be available as `global.globalEvalWithSourceUrl` in a production build.
Reviewed By: christophpurrer
Differential Revision: D38312111
Pulled By: motiz88
fbshipit-source-id: adcd83ad1103c8fd4c6d5d7aec765f27881e0432
Summary:
Resolves https://github.com/facebook/react-native/issues/34116.
In a nutshell, the problem was a missing `.exe` extension on the `hermesc` binary path when running on Windows OS. The missing extension causes the method `.exists()` of the File instance to always return false, so none of the conditions ever met and an error was thrown whenever a release build with Hermes enabled was run on Windows. More details can be found in the comments on the above issues.
## 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 error of release builds with Hermes enabled for Windows users
Pull Request resolved: https://github.com/facebook/react-native/pull/34151
Test Plan:
### Reproduce
Changes on Gradle scrips are better tested on an actual application. To reproduce the issue you can:
1. Create or reuse a React Native application with version `v0.69.1` on a Windows machine
2. Enable Hermes on Android following the steps on the [documentation](https://reactnative.dev/docs/hermes#enabling-hermes)
3. Clean the build folder: `cd android && ./gradlew clean`
4. Bundle the JS and assets for a release version: `./gradlew bundleReleaseJsAndAssets`
5. The build fails with the following error:
```shell
Execution failed for task ':app:bundleReleaseJsAndAssets'.
> java.lang.Exception: Couldn't determine Hermesc location. Please set `project.ext.react.hermesCommand` to the path of the hermesc binary file. node_modules/react-native/sdks/hermesc/%OS-BIN%/hermesc
```
### Test the changes
Follow the same steps above using the fix on this PR and the error should disappear 🙂
Reviewed By: NickGerleman
Differential Revision: D37755468
Pulled By: cortinico
fbshipit-source-id: 2ad0ced583555b907259df116f64a45da6d153f3
Summary:
This Pull Request aims at removing the making of reactnativeutilsjni as it is built from the same sources as reactnativejni. It also replaces references to reactnativeutilsjni with reactnativejni.
This should get rid of `reactnativeutilsjni.so` while reusing `reactnativejni.so` in it's place. This should give us some size improvements in the finally built apk.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Android] [Changed] - Replaced reactnativeutilsjni with reactnativejni in the build process to reduce size
Pull Request resolved: https://github.com/facebook/react-native/pull/34339
Test Plan:
1. Ran the CMakelist.txt file using CMake and I could see that reactnativeutilsjni.dir is no longer generated with my changes.
2. Built the aar from this branch in Android Studio and build happened successfully.
I am not sure if we could run any more tests. Please let me know in case anymore testing is required and I can do accordingly
Reviewed By: cortinico
Differential Revision: D38400481
Pulled By: genkikondo
fbshipit-source-id: 592736e56441328389ae89135667c336ff8018e6
Summary:
This PR fixes an edge case where `prepare_hermes_workspace` job was using a commit to build hermes but `build_hermes_macos` was using a different one. This resulted in cache poisoning where subsequent jobs thoughts to be using a version of Hermes while the restored cache was loading a different one.
<img width="1440" alt="Screenshot 2022-08-03 at 06 26 14" src="https://user-images.githubusercontent.com/11162307/182570809-5c6d9323-c3fb-4834-952f-7d07b99c4880.png">
This PR simplifies the flow, creating a single `.hermesversion` file in the `prepare_hermes_workspace` workspace and using that file as key for all the caches.
## Changelog
[iOS] [Changed] - upload test result as artifact
Pull Request resolved: https://github.com/facebook/react-native/pull/34329
Test Plan:
CircleCI is now green and all the caches are using the same file to create the checksum.
We can verify that by looking at the `Save cache`/`Restore cache` commands related to Hermes. (In the workflow, their hash is always `B1NEL0P0OKhQYtk8DE150bXSoGrdWUweedHKmqNqnjo`)
Also, we removed completely the code that could create a version misalignment.
Reviewed By: cortinico
Differential Revision: D38382895
Pulled By: cipolleschi
fbshipit-source-id: 5f5501a7ef313eb56abda336716b24b486a34a1f
Summary:
Fixes https://github.com/facebook/react-native/issues/34034.
The FlatList doesn't call renderItem on nullish values when numColumns > 1, but it does when numColumns is not set (or equals 1).
I think the behavior should be consistent, so I updated the code so renderItems is called for every items.
I believe the condition `item != null` was here to make sure renderItem isn't called for index outside of data range, so I replaced it with `itemIndex < data.length`.
## 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 FlatList not calling render items for nullish values when numColumns > 1
Pull Request resolved: https://github.com/facebook/react-native/pull/34205
Test Plan:
- I added a failing test corresponding to the issue, and the test now succeeds.
- I used the same code as in the test on a newly initialized app on RN 0.69 and made sure renderItem was called for every items as expected.
Reviewed By: NickGerleman
Differential Revision: D38185103
Pulled By: lunaleaps
fbshipit-source-id: 4baa55caef9574c91c43c047f9e419016ceb39db
Summary:
Changelog:
[Android][Fixed] - Fix regression when setting shadow node properties.
Also simplified the corresponding macros to avoid using lambdas altogether, as they are not required.
Note that this **does not** modify any constexpr-related semantics of the existing code, as the main constexpr macro, `CONSTEXPR_RAW_PROPS_KEY_HASH` evaluation result is still contstexpr value, and the other ones already involved non-const parts (see my comments).
Reviewed By: NickGerleman
Differential Revision: D38356411
fbshipit-source-id: 22c330d3425c8aed36693f4652f1b257d2dc96be
Summary:
Some custom logic is applied to workaround a platform bug where velocity may be incorrect on Android P. [The bug in question](https://issuetracker.google.com/issues/112385925) appears to have been fixed before Android `Q` was released, so we shouldn't *need* to apply the workaround on other versions.
As described in https://github.com/facebook/react-native/issues/34226 the workaround can adversely affect certain scroll behaviors, which can easily be reproduced when you briefly scroll one direction then quickly fling the opposite direction (see the video in the linked ticket).
This PR changes the workaround to *only* be applied on Android P, in order to avoid causing weird scroll behavior on versions that are not actually affected by the bug the workaround is working around.
## Changelog
```
[Android] [Fixed] - Fix occasionally incorrect ScrollView fling behavior
```
Pull Request resolved: https://github.com/facebook/react-native/pull/34233
Test Plan:
- Repro the strange fling behavior in the current version (See video attached in https://github.com/facebook/react-native/issues/34226)
- Verify that the string fling behavior is fixed with this patch
- Verify that fling behavior still works as expected on Android versions affected by the [original bug](https://issuetracker.google.com/issues/112385925), and those immediately following it (to verify that the bug being worked around was, in fact, fixed as expected).
Reviewed By: javache
Differential Revision: D38287277
Pulled By: ryancat
fbshipit-source-id: 2c786872c4d41655b3849bb92e02f1f16c663b41
Summary:
This PR runs eslint in PR using Danger.
## Changelog
[General] [Changed] - Run ESLint in CI
Pull Request resolved: https://github.com/facebook/react-native/pull/34305
Test Plan:
1. Add a JS lint error in the package/react-native-codegen package.
2. Observe the CI task post a message with the errors
3. Fix the errors
4. Observe the CI task report completion with no errors
Reviewed By: cortinico
Differential Revision: D38315268
Pulled By: cipolleschi
fbshipit-source-id: 9984402ee427dd62d47dd716f73c030e6d0f7b5e
Summary:
This diff is part of an overall stack, meant to fix incorrect usage of `setState()` in `VirtualizedList`, which triggers new invariant checks added in `VirtualizedList_EXPERIMENTAL`. See the stack summary below for more information on the broader change.
## Diff Summary
`_createViewToken()` is called during state changes. Use explicit props passed in.
## Stack Summary
`VirtualizedList`'s component state is a set of cells to render. This state is set via the `setState()` class component API. The main "tick" function `VirtualizedList._updateCellsToRender()` calculates this new state using a combination of the current component state, and instance-local state like maps, measurement caches, etc.
From: https://reactjs.org/docs/state-and-lifecycle.html#state-updates-may-be-asynchronous
---
> React may batch multiple setState() calls into a single update for performance. Because this.props and this.state may be updated asynchronously, you should not rely on their values for calculating the next state. For example, this code may fail to update the counter:
```
// Wrong
this.setState({
counter: this.state.counter + this.props.increment,
});
```
> To fix it, use a second form of setState() that accepts a function rather than an object. That function will receive the previous state as the first argument, and the props at the time the update is applied as the second argument:
```
// Correct
this.setState((state, props) => ({
counter: state.counter + props.increment
}));
```
---
`_updateCellsToRender()` transitively calls many functions which will read directly from `this.props` or `this.state` instead of the value passed by the state updater. This intermittently fires invariant violations, when there is a mismatch.
This diff migrates all usages of `props` and `state` during state update to the values provied in `setState()`. To prevent future mismatch, and to provide better clarity on when it is safe to use `this.props`, `this.state`, I overrode `setState` to fire an invariant violation if it is accessed when it is unsafe to:
{F756963772}
Changelog:
[Internal][Fixed] - Thread props to _createViewToken()
Reviewed By: genkikondo
Differential Revision: D38294339
fbshipit-source-id: dc215e267f126a3789742c14c35479f509822710
Summary:
This diff is part of an overall stack, meant to fix incorrect usage of `setState()` in `VirtualizedList`, which triggers new invariant checks added in `VirtualizedList_EXPERIMENTAL`. See the stack summary below for more information on the broader change.
## Diff Summary
`_onCellFocusCapture()` derives state from existing state, so it should be wrapped in a state updater to compare against the latest value in the batch.
## Stack Summary
`VirtualizedList`'s component state is a set of cells to render. This state is set via the `setState()` class component API. The main "tick" function `VirtualizedList._updateCellsToRender()` calculates this new state using a combination of the current component state, and instance-local state like maps, measurement caches, etc.
From: https://reactjs.org/docs/state-and-lifecycle.html#state-updates-may-be-asynchronous
---
> React may batch multiple setState() calls into a single update for performance. Because this.props and this.state may be updated asynchronously, you should not rely on their values for calculating the next state. For example, this code may fail to update the counter:
```
// Wrong
this.setState({
counter: this.state.counter + this.props.increment,
});
```
> To fix it, use a second form of setState() that accepts a function rather than an object. That function will receive the previous state as the first argument, and the props at the time the update is applied as the second argument:
```
// Correct
this.setState((state, props) => ({
counter: state.counter + props.increment
}));
```
---
`_updateCellsToRender()` transitively calls many functions which will read directly from `this.props` or `this.state` instead of the value passed by the state updater. This intermittently fires invariant violations, when there is a mismatch.
This diff migrates all usages of `props` and `state` during state update to the values provied in `setState()`. To prevent future mismatch, and to provide better clarity on when it is safe to use `this.props`, `this.state`, I overrode `setState` to fire an invariant violation if it is accessed when it is unsafe to:
{F756963772}
Changelog:
[Internal][Fixed] - Use correct form of setState() in _onCellFocusCapture()
Reviewed By: genkikondo
Differential Revision: D38293583
fbshipit-source-id: 1d0e5152e6c1757408e39dff225e07accc5ee49f
Summary:
This diff is part of an overall stack, meant to fix incorrect usage of `setState()` in `VirtualizedList`, which triggers new invariant checks added in `VirtualizedList_EXPERIMENTAL`. See the stack summary below for more information on the broader change.
## Diff Summary
Use supplied props in `_keyExtractor()`, which is used to map between frame index and identity.
## Stack Summary
`VirtualizedList`'s component state is a set of cells to render. This state is set via the `setState()` class component API. The main "tick" function `VirtualizedList._updateCellsToRender()` calculates this new state using a combination of the current component state, and instance-local state like maps, measurement caches, etc.
From: https://reactjs.org/docs/state-and-lifecycle.html#state-updates-may-be-asynchronous
---
> React may batch multiple setState() calls into a single update for performance. Because this.props and this.state may be updated asynchronously, you should not rely on their values for calculating the next state. For example, this code may fail to update the counter:
```
// Wrong
this.setState({
counter: this.state.counter + this.props.increment,
});
```
> To fix it, use a second form of setState() that accepts a function rather than an object. That function will receive the previous state as the first argument, and the props at the time the update is applied as the second argument:
```
// Correct
this.setState((state, props) => ({
counter: state.counter + props.increment
}));
```
---
`_updateCellsToRender()` transitively calls many functions which will read directly from `this.props` or `this.state` instead of the value passed by the state updater. This intermittently fires invariant violations, when there is a mismatch.
This diff migrates all usages of `props` and `state` during state update to the values provied in `setState()`. To prevent future mismatch, and to provide better clarity on when it is safe to use `this.props`, `this.state`, I overrode `setState` to fire an invariant violation if it is accessed when it is unsafe to:
{F756963772}
Changelog:
[Internal][Fixed] - Thread props to _keyExtractor()
Reviewed By: genkikondo
Differential Revision: D38293586
fbshipit-source-id: e50823bacdf45adad3b8b655d66d305a1762e9b8
Summary:
This diff is part of an overall stack, meant to fix incorrect usage of `setState()` in `VirtualizedList`, which triggers new invariant checks added in `VirtualizedList_EXPERIMENTAL`. See the stack summary below for more information on the broader change.
## Diff Summary
This forwards props to `__getFrameMetricsApprox()` and `_getFrameMetrics()` . This is called in a variery of places, so we need to pass `FrameMetricProps` through more places, and update public/test usage.
## Stack Summary
`VirtualizedList`'s component state is a set of cells to render. This state is set via the `setState()` class component API. The main "tick" function `VirtualizedList._updateCellsToRender()` calculates this new state using a combination of the current component state, and instance-local state like maps, measurement caches, etc.
From: https://reactjs.org/docs/state-and-lifecycle.html#state-updates-may-be-asynchronous
---
> React may batch multiple setState() calls into a single update for performance. Because this.props and this.state may be updated asynchronously, you should not rely on their values for calculating the next state. For example, this code may fail to update the counter:
```
// Wrong
this.setState({
counter: this.state.counter + this.props.increment,
});
```
> To fix it, use a second form of setState() that accepts a function rather than an object. That function will receive the previous state as the first argument, and the props at the time the update is applied as the second argument:
```
// Correct
this.setState((state, props) => ({
counter: state.counter + props.increment
}));
```
---
`_updateCellsToRender()` transitively calls many functions which will read directly from `this.props` or `this.state` instead of the value passed by the state updater. This intermittently fires invariant violations, when there is a mismatch.
This diff migrates all usages of `props` and `state` during state update to the values provied in `setState()`. To prevent future mismatch, and to provide better clarity on when it is safe to use `this.props`, `this.state`, I overrode `setState` to fire an invariant violation if it is accessed when it is unsafe to:
{F756963772}
Changelog:
[Internal][Fixed] - Thread props to __getFrameMetrics()
Reviewed By: genkikondo
Differential Revision: D38293591
fbshipit-source-id: c1499d722b69eb4b5953124ee8b8c3d15e912d93
Summary:
This diff is part of an overall stack, meant to fix incorrect usage of `setState()` in `VirtualizedList`, which triggers new invariant checks added in `VirtualizedList_EXPERIMENTAL`. See the stack summary below for more information on the broader change.
## Diff Summary
Use passed props in `computeWindowedRenderLimits()`, which is called during a state update.
## Stack Summary
`VirtualizedList`'s component state is a set of cells to render. This state is set via the `setState()` class component API. The main "tick" function `VirtualizedList._updateCellsToRender()` calculates this new state using a combination of the current component state, and instance-local state like maps, measurement caches, etc.
From: https://reactjs.org/docs/state-and-lifecycle.html#state-updates-may-be-asynchronous
---
> React may batch multiple setState() calls into a single update for performance. Because this.props and this.state may be updated asynchronously, you should not rely on their values for calculating the next state. For example, this code may fail to update the counter:
```
// Wrong
this.setState({
counter: this.state.counter + this.props.increment,
});
```
> To fix it, use a second form of setState() that accepts a function rather than an object. That function will receive the previous state as the first argument, and the props at the time the update is applied as the second argument:
```
// Correct
this.setState((state, props) => ({
counter: state.counter + props.increment
}));
```
---
`_updateCellsToRender()` transitively calls many functions which will read directly from `this.props` or `this.state` instead of the value passed by the state updater. This intermittently fires invariant violations, when there is a mismatch.
This diff migrates all usages of `props` and `state` during state update to the values provied in `setState()`. To prevent future mismatch, and to provide better clarity on when it is safe to use `this.props`, `this.state`, I overrode `setState` to fire an invariant violation if it is accessed when it is unsafe to:
{F756963772}
Changelog:
[Internal][Fixed] - Thread props to computeWindowedRenderLimits()
Reviewed By: genkikondo
Differential Revision: D38293588
fbshipit-source-id: 1330a003c1354bbd63c0b7b33a013e85e96fdc64
Summary:
This diff is part of an overall stack, meant to fix incorrect usage of `setState()` in `VirtualizedList`, which triggers new invariant checks added in `VirtualizedList_EXPERIMENTAL`. See the stack summary below for more information on the broader change.
## Diff Summary
Change `_updateViewableItems()` to accept an explicit set of props, and a CellRenderMask, instead of using `this.props` and `this.state`. The eventual sink are the `_getFrameMetric*` functions, so a minimal projection of props is added that we can pass through to it.
## Stack Summary
`VirtualizedList`'s component state is a set of cells to render. This state is set via the `setState()` class component API. The main "tick" function `VirtualizedList._updateCellsToRender()` calculates this new state using a combination of the current component state, and instance-local state like maps, measurement caches, etc.
From: https://reactjs.org/docs/state-and-lifecycle.html#state-updates-may-be-asynchronous
---
> React may batch multiple setState() calls into a single update for performance. Because this.props and this.state may be updated asynchronously, you should not rely on their values for calculating the next state. For example, this code may fail to update the counter:
```
// Wrong
this.setState({
counter: this.state.counter + this.props.increment,
});
```
> To fix it, use a second form of setState() that accepts a function rather than an object. That function will receive the previous state as the first argument, and the props at the time the update is applied as the second argument:
```
// Correct
this.setState((state, props) => ({
counter: state.counter + props.increment
}));
```
---
`_updateCellsToRender()` transitively calls many functions which will read directly from `this.props` or `this.state` instead of the value passed by the state updater. This intermittently fires invariant violations, when there is a mismatch.
This diff migrates all usages of `props` and `state` during state update to the values provied in `setState()`. To prevent future mismatch, and to provide better clarity on when it is safe to use `this.props`, `this.state`, I overrode `setState` to fire an invariant violation if it is accessed when it is unsafe to:
{F756963772}
Changelog:
[Internal][Changed] - Move Props to VirtualizedListProps
Reviewed By: genkikondo
Differential Revision: D38293587
fbshipit-source-id: 164fd4af7c370d905af53b0e9aafb3592d8659cc
Summary:
Fix macro errors for Windows. Current syntax breaks the build of the React Common project on Windows because the ({...}) syntax is not supported; must be replaced with lambda expressions.
Resolves https://github.com/facebook/react-native/issues/34090
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[General] [Fixed] - Fix macro errors for Windows.
lyahdav JoshuaGross
Pull Request resolved: https://github.com/facebook/react-native/pull/34299
Test Plan: Build on react-native-windows repo. Tested in RNW app.
Reviewed By: javache
Differential Revision: D38272966
Pulled By: NickGerleman
fbshipit-source-id: e76eac11cde173ef49465d01d793c593017f2ab7
Summary:
This diff is part of an overall stack, meant to fix incorrect usage of `setState()` in `VirtualizedList`, which triggers new invariant checks added in `VirtualizedList_EXPERIMENTAL`. See the stack summary below for more information on the broader change.
## Diff Summary
Remove `this.props` usage during state update where we can just use the props directly.
## Stack Summary
`VirtualizedList`'s component state is a set of cells to render. This state is set via the `setState()` class component API. The main "tick" function `VirtualizedList._updateCellsToRender()` calculates this new state using a combination of the current component state, and instance-local state like maps, measurement caches, etc.
From: https://reactjs.org/docs/state-and-lifecycle.html#state-updates-may-be-asynchronous
---
> React may batch multiple setState() calls into a single update for performance. Because this.props and this.state may be updated asynchronously, you should not rely on their values for calculating the next state. For example, this code may fail to update the counter:
```
// Wrong
this.setState({
counter: this.state.counter + this.props.increment,
});
```
> To fix it, use a second form of setState() that accepts a function rather than an object. That function will receive the previous state as the first argument, and the props at the time the update is applied as the second argument:
```
// Correct
this.setState((state, props) => ({
counter: state.counter + props.increment
}));
```
---
`_updateCellsToRender()` transitively calls many functions which will read directly from `this.props` or `this.state` instead of the value passed by the state updater. This intermittently fires invariant violations, when there is a mismatch.
This diff migrates all usages of `props` and `state` during state update to the values provied in `setState()`. To prevent future mismatch, and to provide better clarity on when it is safe to use `this.props`, `this.state`, I overrode `setState` to fire an invariant violation if it is accessed when it is unsafe to:
{F756963772}
Changelog:
[Internal][Fixed] - Remove _isVirtualizationDisabled()
Reviewed By: genkikondo
Differential Revision: D38293589
fbshipit-source-id: af18f867fc880d5363134fe0d6f985efaf8be6c5
Summary:
This diff is part of an overall stack, meant to fix incorrect usage of `setState()` in `VirtualizedList`, which triggers new invariant checks added in `VirtualizedList_EXPERIMENTAL`. See the stack summary below for more information on the broader change.
## Diff Summary
This moves public VirtualizedList types to a new file, shared between both `VirtualizedList`, and `VirtualizedList_EXPERIMENTAL`. This allows us to make public interface changes in a single place.
## Stack Summary
`VirtualizedList`'s component state is a set of cells to render. This state is set via the `setState()` class component API. The main "tick" function `VirtualizedList._updateCellsToRender()` calculates this new state using a combination of the current component state, and instance-local state like maps, measurement caches, etc.
From: https://reactjs.org/docs/state-and-lifecycle.html#state-updates-may-be-asynchronous
---
> React may batch multiple setState() calls into a single update for performance. Because this.props and this.state may be updated asynchronously, you should not rely on their values for calculating the next state. For example, this code may fail to update the counter:
```
// Wrong
this.setState({
counter: this.state.counter + this.props.increment,
});
```
> To fix it, use a second form of setState() that accepts a function rather than an object. That function will receive the previous state as the first argument, and the props at the time the update is applied as the second argument:
```
// Correct
this.setState((state, props) => ({
counter: state.counter + props.increment
}));
```
---
`_updateCellsToRender()` transitively calls many functions which will read directly from `this.props` or `this.state` instead of the value passed by the state updater. This intermittently fires invariant violations, when there is a mismatch.
This diff migrates all usages of `props` and `state` during state update to the values provied in `setState()`. To prevent future mismatch, and to provide better clarity on when it is safe to use `this.props`, `this.state`, I overrode `setState` to fire an invariant violation if it is accessed when it is unsafe to:
{F756963772}
Changelog:
[Internal][Changed] - Move Props to VirtualizedListProps
Reviewed By: genkikondo
Differential Revision: D38293585
fbshipit-source-id: 344d94466a2741ee67eb5754de5506eb3e265c5b
Summary:
This diff is part of an overall stack, meant to fix incorrect usage of `setState()` in `VirtualizedList`, which triggers new invariant checks added in `VirtualizedList_EXPERIMENTAL`. See the stack summary below for more information on the broader change.
## Diff Summary
Replace usages of `this.state` and `this.props` where we are already passed the newer revision of the state we want.
## Stack Summary
`VirtualizedList`'s component state is a set of cells to render. This state is set via the `setState()` class component API. The main "tick" function `VirtualizedList._updateCellsToRender()` calculates this new state using a combination of the current component state, and instance-local state like maps, measurement caches, etc.
From: https://reactjs.org/docs/state-and-lifecycle.html#state-updates-may-be-asynchronous
---
> React may batch multiple setState() calls into a single update for performance. Because this.props and this.state may be updated asynchronously, you should not rely on their values for calculating the next state. For example, this code may fail to update the counter:
```
// Wrong
this.setState({
counter: this.state.counter + this.props.increment,
});
```
> To fix it, use a second form of setState() that accepts a function rather than an object. That function will receive the previous state as the first argument, and the props at the time the update is applied as the second argument:
```
// Correct
this.setState((state, props) => ({
counter: state.counter + props.increment
}));
```
---
`_updateCellsToRender()` transitively calls many functions which will read directly from `this.props` or `this.state` instead of the value passed by the state updater. This intermittently fires invariant violations, when there is a mismatch.
This diff migrates all usages of `props` and `state` during state update to the values provied in `setState()`. To prevent future mismatch, and to provide better clarity on when it is safe to use `this.props`, `this.state`, I overrode `setState` to fire an invariant violation if it is accessed when it is unsafe to:
{F756963772}
Changelog:
[Internal][Fixed] - Remove bad usage in _adjustCellsAroundViewport()
Reviewed By: genkikondo
Differential Revision: D38293584
fbshipit-source-id: 807f36600d2fd82c87205195dd61956785bdbd2c
Summary:
This diff fixes the bug T127619309 by exit early during calculateTransformedFrames if currentShadowNode cannot be casted
This is a bug that fired in fb4a but we didn't have a way to reproduce locally.
We are going to release this and enable feature flag with a MC
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D38280674
fbshipit-source-id: 1c42c17678d8473564e4075a78d3c688efed1a23
Summary:
While doing some testing with cipolleschi on React Native 0.70.0 we realized that custom Java Package is not properly propagated when invoking codegen for external libraries.
This PR fixes it.
## Changelog
[Internal] - Introduce findPackageJsonFile to address issue with GenerateCodegenArtifactsTaskTest
Pull Request resolved: https://github.com/facebook/react-native/pull/34321
Test Plan: Added JUnit tests + Tested locally with cipolleschi
Reviewed By: cipolleschi
Differential Revision: D38314770
Pulled By: cortinico
fbshipit-source-id: ec2de1ba59ffc8fb0644f422521ced642b38d2c7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34307
There are unreleased changes on eslint-config-react-native-community, I'm bumping the version for this package so we can publish it.
Changelog:
[General] [Changed] - Bump eslint-config-react-native-community
Reviewed By: dmitryrykun
Differential Revision: D38279512
fbshipit-source-id: 46492f7e99d31c0a5917d41726ecc20fada1582f
Summary:
Calculation of TransformedFrames was a method introduced by D37994809 (https://github.com/facebook/react-native/commit/64528e5faa445907b8287b412c344f30c20fca61) to fix rendering of inverted flat lists.
We found that this operation is crashing in fb4a causing the UBN T127619309
This diff creates a feature flag to disable the calculation of TransformedFrames in Layoutable ShadowNodes. **The goal of this diff is to revert the behavior introduced by D37994809 (https://github.com/facebook/react-native/commit/64528e5faa445907b8287b412c344f30c20fca61)**
The featureFlag is disabled in fb4a and enabled in react AR (because ReactAr apps relies on the calculation of TransformedFrames and these apps are not affected)
The root cause of the bug will be fixed by D38280674 (which still requires more testing and investigation)
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D38286857
fbshipit-source-id: 721cd0554ae6a6b369b3f8dbb584160a270d0f18
Summary:
This change adds the following methods to jsi::BigInt
* [static] fromInt64(value): creates a jsi::BigInt from a signed 64-bit value
* [static] fromUint64(value): creates a jsi::BigInt from an unsigned 64-bit value
* [static] strictEquals(a, b): return a === b, a and b are BigInts
* asInt64(): truncates the BigInt to a single signed 64-bit integer; throws a JSIException if the truncation is lossy.
* getInt64(): truncates the BigInt to a single signed 64-bit integer
* isInt64(): returns true if the BigInt can be truncated losslessly to an int64_t
* asUint64(): truncates the BigInt to a single unsigned 64-bit integer; throws a JSIException if the truncation is lossy.
* getUint64(): truncates the BigInt to a single unsigned 64-bit integer
* isUint64(): returns true if the BigInt can be truncated losslessly to an uint64_t
* toString(radix): converts the BigInt to a string representing the number in the given radix.
A lossy truncation is one that yields a result from which the BigInt cannot be reconstructed from, i.e.,
* BigInt::fromInt64(b.toInt64()) !== b
* BigInt::fromUint64(b.toUint64()) !== b
Changelog: [Internal]
Reviewed By: kodafb
Differential Revision: D37909139
fbshipit-source-id: 172848024f8367aed73cc602f38cde22f03cac8f
Summary:
The `codegenConfig` unified configuration for New Architecture on Android relies on the Gradle plugin finding the package.json correctly. Currently we use the `root` folder to resolve the package.json. This works fine when invoking the codegen for the app module, but it doesn't work well when invoking the codegen for modules.
This extends the algo to make sure we first, look for a `package.json` in `..` and fallback to the one in the root if not found.
## Changelog
[Internal] - Improve package.json search mechanism for codegenConfig support
Pull Request resolved: https://github.com/facebook/react-native/pull/34298
Test Plan: It's hard to write a unit test for this as it's inside a lambda, I'll look into doing this though. I've tested this on RNNewArchitectureApp and it works fine.
Reviewed By: cipolleschi
Differential Revision: D38249663
Pulled By: cortinico
fbshipit-source-id: 3cfd6a31e9f75d7b19b15f77bbd5131af42be9d3
Summary:
While I was working on rewriting `react-native-slider` to Fabric I found a weird bug that prevented the slider to be set as disabled (to be exact: call the method `slider.setEnabled(false)`. As it turned out the `accessibilityState` (with value: `accessibilityState={{disabled: true}}` prop occurred after the `enabled={false}` prop that I was passing to the slider, which lead to both of this props overwrite each other.
Handling of `accessibilityState` props inside view leads to always overwriting the enabled prop to true (even if we explicitly set it to `{disabled: false}`.
Workaround for this was to reorder the props, so that the `accesibilityState` occur before `disabled`, but I think it's better to not set `view.setEnabled(true)` if we are passing a disabled property.
## Changelog
[Android] [Fixed] - Fix accessibilityState overwriting view's disabled state on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/34287
Test Plan:
Change order of props inside native component implementation (that `disabled` occurs before `accesibilityState`). For example: `Libraries/Components/Slider/Slider.js`
<details>
<summary>Video showing the bug in RNTester (using Switch component)</summary>
https://user-images.githubusercontent.com/52801365/181287547-964f50e2-55dc-450f-b413-0d1c14d4bb83.mp4
</details>
Reviewed By: NickGerleman
Differential Revision: D38209232
Pulled By: dmitryrykun
fbshipit-source-id: 93d423716f89b45251be9d5aefcf01f7bd776f2c
Summary: Changelog: [General][Changed] - `eslint-plugin-specs` package has prepack hook that changes `PACKAGE_USAGE` variable of `react-native-modules.js` to `true`. This changed file is can then be published to NPM, but should not be committed to the repo. This diff adds postpack hook that reverts the change, so we do not have to do it manually.
Reviewed By: cipolleschi
Differential Revision: D38244367
fbshipit-source-id: 818dbdea82e7e4b89094b3e27ae2d63b9e736659
Summary:
I've realized that the gradle plugin is currently looking at `.js` files for task re-execution. This means that, while the *.ts would still be considered when the codegen is invoked, an edit on one of those file, won't retrigger the codegen on Android.
This change fixes it so that we consider both `*.ts` and `*.js` files.
## Changelog
[Android] [Fixed] - Make sure *.ts files are considered for task avoidance in the Gradle Plugin
Pull Request resolved: https://github.com/facebook/react-native/pull/34296
Test Plan: Tests are attached.
Reviewed By: cipolleschi
Differential Revision: D38246125
Pulled By: cortinico
fbshipit-source-id: 80efcc9ef747c598ca040d65b25d270593c8aed2
Summary:
VirtualizedList state is represented in terms of [first, last] ranges, where it is possible to express a zero-cell range by having [n, n-1]. This includes some awkward examples, like [0, -1] being valid.
CellRenderMask assumes `addCells` is called with at least one cell, with VirtualizedList previously guarding against adding the no cell case. This guard is present for adding main cell regions, but not for `_initialRenderRegion()`, which can be overridden to have a zero length as well.
This moves the `CellRenderMask` to be permissive of zero-length cell regions, and removes the caller guard.
Changelog:
[Internal][Fixed] - Allow empty cell ranges in CellRenderMask
Reviewed By: rshest
Differential Revision: D38184444
fbshipit-source-id: d2dadfdd9628b24f894126d63b1eb93f6387b877
Summary:
Fixes https://github.com/facebook/react-native/issues/34120
The new React Native architecture doesn't check `needsCustomLayoutForChildren` so it wrongly positions native views on Android. In https://github.com/facebook/react-native/issues/34120 there are videos comparing the positioning of a native action view in the old and the new architecture.
This PR passes the parent tag to the `updateLayout` method of the `SurfaceMountingManager`. The `SurfaceMountingManager` calls `needsCustomLayoutForChildren` on the parent view manager (copied the code from the `NativeViewHierarchyManager` in the old architecture).
**NOTE** - I wasn't sure where to get the parent shadow view from so I've put in my best guesses where I could and left it as `{}` otherwise.
## Changelog
[Android] [Fixed] - Migrate `needsCustomLayoutForChildren` check to the new architecture
Pull Request resolved: https://github.com/facebook/react-native/pull/34254
Test Plan:
I checked the fix in the repro from https://github.com/facebook/react-native/issues/34165. Here is a video of the action view closing using the native button that is now visible in the new architecture.
https://user-images.githubusercontent.com/1761227/180607896-35bf477f-4552-4b8a-8e09-9e8c49122c0c.mov
Reviewed By: cipolleschi
Differential Revision: D38153924
Pulled By: javache
fbshipit-source-id: e2c77fa70d725a33ce73fe4a615f6d884312580c
Summary:
The current `test-manual-e2e.sh` script is broken on Android + Hermes + New App Template.
This commit fixes it. Specifically:
- There is no need to generate Maven Artifacts for RN Tester, as RN Tester consumes them from source.
- There is instead a need to generate Maven Artifacts for New App Template, as they need to be included inside the NPM package.
- The `:ReactAndroid:hermes-engine:installArchives` task needs to invoked to also generate the Hermes-engine .aar for bundling.
## Changelog
[Internal] - Fix test-manual-e2e on Android/Hermes for New App Template
Pull Request resolved: https://github.com/facebook/react-native/pull/34294
Test Plan: I've tested this against the `0.70-stable` branch and I was able to run an App from the New Template properly.
Reviewed By: dmitryrykun
Differential Revision: D38239238
Pulled By: cortinico
fbshipit-source-id: b3d95bad21515b12a91e29147e70ba8323896660
Summary:
Existing code may pass negative values for `initialScrollIndex`, which the previous implemnentation handled gracefully. Handle the case gracefully in VirtualizedList_EXPERIMENTAL as well.
Changelog:
[Internal][Fixed] - Gracefully handle negative initialScrollIndex in VirtualizedList_EXPERIMENTAL
Reviewed By: rshest
Differential Revision: D38183625
fbshipit-source-id: 9aea91c4cf3ce2190d769f34ce728a109efc88d4
Summary:
If FlatList is passed non-array data it will return `undefined` as the result of `getItemCount()` to VirtualizedList. This change makes it return `0` instead, to signify there are no valid items to attempt to accces.
There are a set of invariants on properties passed to FlatList, to curb incorrect types at runtime, but there is existing code which runs into the condition.
Changelog:
[Internal][Fixed] - Guard FlatList getItemCount() against non-array data
Reviewed By: javache
Differential Revision: D38198351
fbshipit-source-id: 9efd0df7eeeba17078e2c838d470c4b0d621b9a0
Summary:
VirtualizedList_EXPERIMENTAL has a different flow signature from VirtualizedList. This does not cause an error in unit tests, which are untyped, but prevents injecting VirtualizedList_EXPERIMENTAL via the current API from flowtype. This diff updates the injection interface to allow a more relaxed type, validating safety at runtime.
Changelog:
[Internal][Changed] - Allow injecting looser VirtualizedList
Reviewed By: javache
Differential Revision: D38143682
fbshipit-source-id: 054bbc5092823f4e4413d69d3d72a7ecdd71a6a2
Summary:
Implements most of systrace using androidx.tracing, this makes it usable using Android Studio profiler systrace.
## Changelog
[Android] [Added] - Improve OSS systrace
Pull Request resolved: https://github.com/facebook/react-native/pull/34252
Test Plan:
Run a systrace in Android Studio for RN Tester and make sure RN specific sections are there.
<img width="1263" alt="image" src="https://user-images.githubusercontent.com/2677334/180593493-fc087b4a-2253-43e1-b246-bed3e7bba7ac.png">
Reviewed By: NickGerleman
Differential Revision: D38116890
Pulled By: dmitryrykun
fbshipit-source-id: 744bedbf9ad4004488340a5b4e93d936d9a1e582
Summary:
Flow and TypeScript are two very similar programming languages. They are both recognizable as inputs for turbo module codegen. It is reasonable to require equivalent Flow and TypeScript turbo module definition generates the same output.
I add some test cases to ensure this. Glad that no functional inconsistency is found here.
## Changelog
[General] [Changed] - codegen: ensure equivalent Flow and TypeScript TM definition generates the same output
Pull Request resolved: https://github.com/facebook/react-native/pull/34251
Test Plan: `yarn jest` passed in `packages/react-native-codegen`
Reviewed By: dmitryrykun
Differential Revision: D38116756
Pulled By: cipolleschi
fbshipit-source-id: 476adbd171a35813923f2020c826d21b1fc2eeed
Summary:
cherry-pick changes from https://github.com/facebook/react-native/issues/34214 to main. because the `react_native_pods.rb` on main is quite different from 0.69, i have separated pr for the change.
## Changelog
[iOS] [Fixed] - Fix React-bridging headers import not found
Pull Request resolved: https://github.com/facebook/react-native/pull/34271
Test Plan: RNTester + pod install and verify pod targets to have `React-bridging` in header search paths.
Reviewed By: cipolleschi
Differential Revision: D38122074
Pulled By: dmitryrykun
fbshipit-source-id: 64569abbfa3a684f0d6b84c9e3222bfc9a171061
Summary:
I've noticed that `BackHandler.removeEventListener()` performs two same `indexOf()` calls on an array that is not changing. By removing extra `indexOf` we can slightly improve time complexity of `BackHandler.removeEventListener()` from O(2n) to O(n)
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Android] [Fixed] - Remove extra indexOf call in BackHandler.removeEventListener
Pull Request resolved: https://github.com/facebook/react-native/pull/34281
Test Plan:
1. Add the following code to any function component
```javascript
BackHandler.addEventListener('hardwareBackPress', () => true).remove();
```
2. Press on hardware back button
Expected result: Application closes
Reviewed By: dmitryrykun
Differential Revision: D38198510
Pulled By: javache
fbshipit-source-id: eab6a57689a536623138a4b3ebddbf9ba87d281f
Summary:
At the moment we are having a bug that whenever we hit a "Done" button in an input field, a value is not submitted back, so the users cannot complete their work. Here is an example:
https://pxl.cl/28xFq
To fix it, we call a textInputShouldSubmitOnReturn method on Accessory button click.
Changelog
[IOS][Fixed] - Fix keyboard accessory button not triggering onSubmitEditing
Reviewed By: dmitryrykun
Differential Revision: D38152974
fbshipit-source-id: fc026dffd641966cd3d342d95a56c43c71008036
Summary:
The removeEventListener method has been removed from AccessibilityInfo and Linking in this PR: https://github.com/facebook/react-native/issues/33580, so I believe we can remove it from the mocks.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Removed] - Remove removeEventListener from AccessibilityInfo and Linking mocks
Pull Request resolved: https://github.com/facebook/react-native/pull/34260
Test Plan: I executed jest and everything is still green.
Reviewed By: dmitryrykun
Differential Revision: D38198653
Pulled By: GijsWeterings
fbshipit-source-id: 72d10ca54cd505d7c76e7531c9df718b1a9b9ed1
Summary:
# This Change
https://github.com/react-native-community/discussions-and-proposals/pull/335 discussed a set of problems with VirtualizedList and focus. These were seen as severe externally for a11y on desktop. The issues center on users of keyboard and accessibility tools, where users expect to be able to move focus in an uninterrupted loop.
The design and implementation evolved to be a bit more general, and without any API-surface behavior changes. It was implemented and rolled out externally as a series of changes. The remaining changes that were not upstreamed into RN are rolled into https://github.com/facebook/react-native/pull/32646
This diff brings this change into the repo, as a separate copy of VirtualizedList, to measure its impact to guardrail metrics, without yet making it the default implementation. The intention is for this to be temporary, until there is confidence the implementation is correct.
## List Implementation (more on GitHub)
This change makes it possible to synchronously move native focus to arbitrary items in a VirtualizedList. This is implemented by switching component state to a sparse bitset. This was previously implemented and upstreamed as `CellRenderMask`.
A usage of this is added, to keep the last focused item rendered. This allows the focus loop to remain unbroken, when scrolling away, or tab loops which leave/re-enter the list.
VirtualizedList tracks the last focused cell through the capture phase of `onFocus`. It will keep the cell, and a viewport above and below the last focused cell rendered, to allow movement to it without blanking (without using too much memory).
## Experimentation Implementation
A mechanism is added to gate the change via VirtualizedListInjection, mirroring the approach taken for Switch with D27381306 (https://github.com/facebook/react-native/commit/683b825b327e7fa71e87e3d613cb9acd37c24288).
It allows VirtualizedList to delegate to a global override. It has a slight penalty to needing to import both modules, but means code which imports VirtualizedList directly is affected the changes.
Changelog:
[Internal][Added] - Add VirtualizedList_EXPERIMENTAL (CellRenderMask Usage)
Reviewed By: lunaleaps
Differential Revision: D38020408
fbshipit-source-id: ad0aaa6791f3f4455e3068502a2841f3ffb40b41
Summary:
This change is in preparation of adding a separate `VirtualizedList_EXPERIMENTAL` component.
Both the original, and experimental lists use `VirtualizedListContext`, which itself references back to the VirtualizedList class type. VirtualizedList private methods are currently included in the type system, and are called in other VirtualizedList code (see https://github.com/facebook/react-native/commit/b2f871a6fa9c92dd0712055384b9eca6d828e37d). This prevents Flow from seeing the two classes are compatible if "private" methods change.
My first attempt was to parameterize the context, to allow both `VirtualizedList`, and `VirtualizedList_EXPERIMENTAL` to use the same code without sacrificing type safety or adding further duplication. This added more complexity than it is worth, so I am instead loosening the type on VirtualizedListContext to pass around a more generic handle.
Changelog:
[Internal][Changed] - Allow VirtualizedListContext to support different component type
Reviewed By: javache
Differential Revision: D38017086
fbshipit-source-id: 91e8f6ab2591d3ae9b7f9263711b4a39b78f68e0
Summary:
Bumping main to latest version of CLI available; in particular, we want to ensure to propagate this fix https://github.com/react-native-community/cli/pull/1655.
After merging, we'll cherry-pick in the `0.70-stable` branch.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[General] [Changed] - bump CLI to v9.0.0-alpha.5
Pull Request resolved: https://github.com/facebook/react-native/pull/34275
Test Plan: CI
Reviewed By: NickGerleman
Differential Revision: D38151383
Pulled By: dmitryrykun
fbshipit-source-id: afdafb496a159ad766dd322a4aab4bda6146edf0
Summary:
The `NSMutableAttributedString` was initialized with the same backing store as the cached attributed string on the shadow queue (background thread), but then passed to the main thread and ultimately the JS thread.
This explicitly copies the mutable attributed string into an immutable one on the shadow thread before passed off to other threads, which hopefully will address the `convertIdToFollyDynamic` crash that always includes `RCTBaseTextInputShadowView` touching an attributed string on the shadow queue in the trace.
Changelog:
[iOS][Fixed] - Possible fix for convertIdToFollyDynamic crash in RCTBaseTextInputView and RCTEventDispatcher
Reviewed By: sammy-SC
Differential Revision: D38133150
fbshipit-source-id: f371da5d17a32c3341287cd3e9730b31a98495f9
Summary:
Changelog: [iOS][Internal] - Add isPrimary property implementation to the PointerEvent object
This diff adds the `isPrimary` property to the PointerEvent object iOS implementation. In addition this adds a related change where we "reserve" the 0 touch identifier for mouse events and the 1 identifier for apple pencil events. This is an easy way to ensure that these pointers are always consistent no matter what happens. Since mouse & pencil pointers should always be considered the primary pointer, that allows us to focus the more advanced primary pointer differentiation purely on touch events.
The logic for this touch event primary pointer differentiation is essentially setting the first touch it recieves as a primary pointer, setting it on touch registration, and sets all subsequent touchs (while the first touch is down) as not the primary pointers. When that primary pointer is lifted, the class property keeping track of the primary pointer is reset and then the **next** pointer (secondary pointers which had already started before the previous primary pointer was lifted are not "upgraded" to primary) is marked as primary. A new platform test is also included in this diff in order to verify the aforementioned behavior.
Reviewed By: lunaleaps
Differential Revision: D37961707
fbshipit-source-id: ae8b78c5bfea6902fb73094fca1552e4e648ea44
Summary:
In `0.70-stable` we started seeing `yarn run lint` fail; turns out, this is happening because the latest release of `react-native/eslint-plugin-specs` 0.0.4 (from https://github.com/facebook/react-native/commit/ea8d8e2f49ea3ce15faeab500b661a1cacacf8a8) is faulty: the underlying reason is that since 0.0.2 there was this local workaround in place https://github.com/facebook/react-native/commit/2d06e6a4c9261bb7790cf217b66145415301bc54 (that changes a flag from false to true) but in NPM 8 the lifecycle hook `prepublish` has [been deprecated](https://docs.npmjs.com/cli/v8/using-npm/scripts#life-cycle-scripts) so this pre publishing script to change the flag was not run (you can easily verify by checking the node_module and see `react-native-modules.js` the flag on L17 is set to false).
This PR addresses it by moving to the new lifecycle hook `prepack` (and modifies the other files accordingly).
After this PR is merged, we'll need to cherry pick it into 0.70 and do both a new release from the 0.70 branch and one from the main branch to have new versions of this module with the flag set correctly.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[General] [Fixed] - Fix eslint-plugin-specs prepack npm lifecycle hook now that we use npm 8
Pull Request resolved: https://github.com/facebook/react-native/pull/34273
Test Plan: Go in the `eslint-plugin-specs` folder, run `npm pack`, unzip the generated tar file, go into `package`, verify that L17 of `react-native-modules.js` is correctly changed to `const PACKAGE_USAGE = true;` (instead of false - which is what happen without this fix).
Reviewed By: GijsWeterings
Differential Revision: D38151433
Pulled By: dmitryrykun
fbshipit-source-id: 7c4f13dae70eb731d57cbafa90f7be05c9bb8576
Summary:
Add capture-phase focus events to the type system, for use in the refactored VirtualizedList https://github.com/facebook/react-native/pull/32646/files
Tracking the last focused child is done via focus events. Focus events are bubbling (vs direct events like onLayout), and are given both a "capture" phase, and "bubbling phase", like DOM events on the web. https://stackoverflow.com/questions/4616694/what-is-event-bubbling-and-capturing
The VirtualizedList change wants to know if a child will receive focus. This is not possible to reliably capture in the bubbling phase, since a child may stop propagation.
See https://github.com/react-native-community/discussions-and-proposals/pull/335#discussion_r584851337 for some discussion with Scott Kyle about this issue back in the day
This is done by convention in React by adding a "capture" variant of the `onXXX` method. For all platforms I've seen with focus events, these map the `topFocus` native event to `onFocus` for bubbling phase, and `onFocusCapture` for capture phase. See https://reactjs.org/docs/events.html#supported-events
Changelog:
[General][Added] - Add types for onFocusCapture/onBlurCapture
Reviewed By: javache
Differential Revision: D38013861
fbshipit-source-id: 7bda22e1a4d5e36ac5e34e804abf6fb318a41baf
Summary:
We are already returning the `remove` function, and the `removeEventListener` method has been removed in this PR: https://github.com/facebook/react-native/issues/33580. So I believe this comment is now outdated and no longer relevant.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Removed] - Remove outdated TODO in AppState
Pull Request resolved: https://github.com/facebook/react-native/pull/34264
Reviewed By: dmitryrykun
Differential Revision: D38120344
Pulled By: GijsWeterings
fbshipit-source-id: c6c4d42f5b631a67bb6ad49c14df1a772f1cc71b
Summary:
A crash encountered in react-native-macOS is very similar to one fixed by https://github.com/microsoft/react-native-macos/pull/489#discussion_r451789471 (see discussion), and it's possible this `replacement` string also suffers from sharing the same backing store as the attributed string (maybe only when the range encompasses the entire string?) and therefore should be copied as well.
Changelog:
[iOS][Fixed] - Possible fix for convertIdToFollyDynamic crash in RCTBaseTextInputView and RCTEventDispatcher
Reviewed By: sammy-SC
Differential Revision: D38064551
fbshipit-source-id: 9c15f2a980155ab3cbb3fde79fcb93b24ee2091a
Summary:
The purpose of this diff is to un-deprecate the method DisplayMetrics.getWindowDisplayMetrics().
As React Native is used in devices with multiple screens and displays, we need to provide a non-deprecated way to access display metrics (e.g. screen density) for the window that's used to render react native views.
This diff doesn't make any change in behavior, but it un-deprecates the API
changelog: [Android][Added] Un-deprecate DisplayMetrics.getWindowDisplayMetrics() method
Reviewed By: javache
Differential Revision: D37871954
fbshipit-source-id: d8eb97cfae096f2f62ed1389a6de17a892a46b43
Summary:
This method assumes a semicolon existed before the closing bracket (`>`), but only does on iOS. This instead puts the content before the closing bracket, which is always there on both platforms.
Changelog:
[macOS][Fixed] - Fix exception thrown by [RCTTextView description] on macOS
Reviewed By: sammy-SC
Differential Revision: D38074642
fbshipit-source-id: f46d15c2bf2d966d1c1430568f083e4d501d4b40
Summary:
Adds changelog for new patch.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - add changelog entry for 0.69.3
Pull Request resolved: https://github.com/facebook/react-native/pull/34270
Test Plan: N/A
Reviewed By: lunaleaps
Differential Revision: D38116297
Pulled By: dmitryrykun
fbshipit-source-id: 962e34b4cfd58947cf6d95ae05affda7b9271716
Summary:
In D37873933, we update the buildifier binaries, which apply some minor changes to existing lint. Specifically, entries are now properly sorted.
Update the files in xplat such that updating buildifier does not cause lint changes in users diffs.
drop-conflicts
allow_many_files
#nocancel
#forcetdhashing
(Note: this ignores all push blocking failures!)
Reviewed By: d16r
Differential Revision: D37873936
fbshipit-source-id: f31d9c50d64ae99f99298977b471bf13e7ed5262
Summary:
Currently, with the Alert API on iOS, the only way to bold one of the buttons is by setting the style to "cancel". This has the side-effect of moving it to the left. The underlying UIKit API has a way of setting a "preferred" button, which does not have this negative side-effect, so this PR wires this up.
See preferredAction on UIAlertController https://developer.apple.com/documentation/uikit/uialertcontroller/
Docs PR: https://github.com/facebook/react-native-website/pull/2839
## Changelog
[iOS] [Added] - Support setting an Alert button as "preferred", to emphasize it without needing to set it as a "cancel" button.
Pull Request resolved: https://github.com/facebook/react-native/pull/32538
Test Plan:
I ran the RNTesterPods app and added an example. It has a button styled with "preferred" and another with "cancel", to demonstrate that the "preferred" button takes emphasis over the "cancel" button.

Luna:
* Also tested this on Catalyst
{F754959632}
Reviewed By: sammy-SC
Differential Revision: D34357811
Pulled By: lunaleaps
fbshipit-source-id: 3d860702c49cb219f950904ae0b9fabef03b5588
Summary:
When building `igios-no-extensions` with buck2 on linux, we the following analysis error:
```
When running analysis for `fbsource//fbobjc/Apps/Instagram/Instagram:InstagramNoExtensions (fbsource//tools/build_defs/config/platform/apple:Instagram-125ae32099392ce8)`
Caused by:
0: When running analysis for `fbsource//fbobjc/Apps/Instagram/Instagram:InstagramARVRFrameworkDylibFramework (fbsource//tools/build_defs/config/platform/apple:Instagram-125ae32099392ce8)`
1: When running analysis for `fbsource//fbobjc/Apps/Instagram/Instagram:InstagramDependencyPoolForLinkGroupsFramework (fbsource//tools/build_defs/config/platform/apple:Instagram-125ae32099392ce8)`
2: When running analysis for `fbsource//fbobjc/Libraries/FBReactKit:RCTNetInfo (fbsource//tools/build_defs/config/platform/apple:Instagram-125ae32099392ce8)`
3: When running analysis for `fbsource//xplat/js/RKJSModules/Libraries/NetInfo:FBReactNativeNetInfoSpecApple (fbsource//tools/build_defs/config/platform/apple:Instagram-125ae32099392ce8)`
4: When running analysis for `fbsource//xplat/js/react-native-github:RCTTypeSafety (fbsource//tools/build_defs/config/platform/apple:Instagram-125ae32099392ce8)`
5: Traceback (most recent call last):
* fbcode/buck2/prelude/apple/apple_library.bzl:48, in <module>
constructor_params, swift_providers = apple_library_rule_constructor_params_a...
* fbcode/buck2/prelude/apple/apple_library.bzl:111, in apple_library_rule_constructor_params_and_swift_providers
args = [cmd_args(get_framework_search_path_flags(ctx))],
* fbcode/buck2/prelude/apple/apple_frameworks.bzl:46, in get_framework_search_path_flags
return _get_framework_search_path_flags(_get_non_sdk_framework_directories(ct...
* fbcode/buck2/prelude/apple/apple_frameworks.bzl:59, in _get_non_sdk_framework_directories
return dedupe(filter(None, [_non_sdk_framework_directory(ctx, x) for x in fra...
* fbcode/buck2/prelude/apple/apple_frameworks.bzl:95, in _non_sdk_framework_directory
expanded_framework_path = _expand_sdk_framework_path(ctx, framework_path)
* fbcode/buck2/prelude/apple/apple_frameworks.bzl:81, in _expand_sdk_framework_path
expanded_path = expanded_path.replace(path_variable, path_value)
error: Type of parameter `new` doesn't match, expected `str`, actual `artifact`
--> fbcode/buck2/prelude/apple/apple_frameworks.bzl:81:25
|
81 | expanded_path = expanded_path.replace(path_variable, path_value)
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
```
This is related to running on Linux with buck2 and how we get the framework paths for linux/pika toolchains for non SDK frameworks. However, Foundation is an SDK framework, and updating it to be as such allows us to build, both with buck1 and buck2.
Differential Revision: D38080376
fbshipit-source-id: b226c3511e3312d0bf0ddb792dbe4ca99768cad1
Summary:
How the Hermes cache worked had a concurrency issue. It used to work by asking the Hermes repository for the latest commit and using that commit as cache key to try and retrieve a built version of Hermes to avoid to compile it more than once.
The problem happened when the `build_hermes_macos` was building Hermes using a commit A.
While building, another PR could be merged into `hermes:main`, creating commit B.
When this happened, the tasks `test_ios` and `test_ios_rntester`would try to retrieve a cached version of Hermes using commit B. That version did not exist because Hermes was created using commit A, and the job would either fail or trying to build Hermes from source, ending up taking a lot of time.
This PR attaches the `.hermes-cache-key-file` to the workspace and restores it in the other jobs, making sure that the same cache key is used in all three jobs.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[General] [Changed] - Attach the `.hermes-cache-key-file` to the workspace to avoid race conditions for new PR landing on Hermes and changing the head commit between the time Hermes is built and the time it has to be consumed.
Pull Request resolved: https://github.com/facebook/react-native/pull/34235
Test Plan:
Tested manually, looking at the messages in CI.
**build_hermes_macos**
<img width="881" alt="Screenshot 2022-07-21 at 15 40 02" src="https://user-images.githubusercontent.com/11162307/180241834-776f2291-63bb-4bb2-8837-14434b50fe61.png">
**test_ios_rntester**: notice that the `echo` is not executed, meaning that the `if` does not evaluate to true and, therefore, the file has been correctly attached.
<img width="956" alt="Screenshot 2022-07-21 at 15 40 52" src="https://user-images.githubusercontent.com/11162307/180242004-d9db0336-18d3-4321-a997-b538baa6beee.png">
**test_ios**: notice that the `echo` is not executed, meaning that the `if` does not evaluate to true and, therefore, the file has been correctly attached.
<img width="900" alt="Screenshot 2022-07-21 at 15 46 33" src="https://user-images.githubusercontent.com/11162307/180243359-79de5c7a-d2f0-4331-90c6-5bd2c0b5e1ac.png">
Reviewed By: cortinico
Differential Revision: D38037386
Pulled By: cipolleschi
fbshipit-source-id: 4db4f7c478e1afb2e4a18ba3d3f70896ed41d235
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34232
This diff simplify the logic to decide whether we want to build hermes from source or not.
The requirement we have is that we don't want our users to build hermes.
So, we don't want to build hermes when there is a precompiled tarball available, while we want to build hermes in CI.
## Changelog
[General][Changed] - Build hermes when in CI and not when there is a tarball
Reviewed By: cortinico
Differential Revision: D37999748
fbshipit-source-id: 7d9cab51c37fb47db216055c057a22081e10df07
Summary:
Minor improvements to NativeState implementation and test. Does not change the API.
Changelog:
[Internal][Changed] - Minor improvements to jsi::NativeState
Reviewed By: neildhar
Differential Revision: D37961515
fbshipit-source-id: b87dcf2458ace883c784f3127a13f5a6c296d4a2
Summary:
Turbo module codegen for component parse `readonly T[]` and `readonly Object[][]` incorrectly. In this change, it is fixed, with necessary test cases added.
## Changelog
[General] [Added] - Support TypeScript array types for turbo module (component only)
Pull Request resolved: https://github.com/facebook/react-native/pull/34216
Test Plan: `yarn jest` passed in `packages/react-native-codegen`
Reviewed By: sammy-SC
Differential Revision: D37953004
Pulled By: cipolleschi
fbshipit-source-id: b71ea35eb9c4bd5dc41130f1dcf9201704ec298e
Summary:
changelog: [internal]
This was used as a kill switch, it has been in place for over 4 months, let's get rid of it.
Reviewed By: mdvacca
Differential Revision: D37921377
fbshipit-source-id: 594586033694766e13d0f2ab2bcd73b28ba180a9
Summary:
changelog: [internal]
Vertical and horizontal inversion was not taken into account in `computeRelativeLayoutMetrics`. To fix it, we precompute frames to include inversions.
Reviewed By: mdvacca
Differential Revision: D37994809
fbshipit-source-id: 043e6f19b6fa577f61fa3c739ce2d751ef973cc3
Summary:
Changelog: [Android][Fixed] - Fix such that when the scrollviews call `onChildStartedNativeGesture`, they appropriately call `onChildEndedNativeGesture` to unlock the native gesture such that `JSTouchDispatcher` or `JSPointerDispatcher` will continue to emit events.
### How did we find this issue?
As React Native is adding pointer event support for different input types, we noticed after pressing and dragging on a ScrollView, hover events would not fire.
### Why was this not an issue before?
This was always an issue -- it was just that `JSTouchDispatcher` worked its way around it by explicitly setting `mChildIsHandlingNativeGesture = false` on a `ACTION_DOWN` event, [code pointer](https://github.com/facebook/react-native/blob/main/ReactAndroid/src/main/java/com/facebook/react/uimanager/JSTouchDispatcher.java#L76). Similarly, `JSPointerDispatcher` [copied this logic](https://github.com/facebook/react-native/blob/main/ReactAndroid/src/main/java/com/facebook/react/uimanager/JSPointerDispatcher.java#L106).
With new hover support in `JSPointerDispatcher` no similar workaround was put in (or even a good place to insert).
### What's next?
* As a follow-up, we should look at removing this workaround (at least for `JSPointerDispatcher`)
* By searching for usages of where we `notifyNativeGestureStarted`, it looks like `ReactDrawerLayout` and `ReactSwipeRefreshLayout` both do and don't call the symmetric `notifyNativeGestureEnded`. This will likely be an issue in the future (or maybe if we remove the workaround)
Reviewed By: mdvacca
Differential Revision: D37977982
fbshipit-source-id: 0d18767f4debbf24cfb24b54df1310f6f96a0d03
Summary:
Currently, iOS jobs takes up to 2 hours to run.
This is firstly due to Hermes being rebuilt at least 3 times during the CI process.
One issue I discovered is that the `Hermes-SDK-Cache-Key` was depending on the `{{ .Environment.CIRCLE_JOB }}` which is different from all the jobs (`test_ios_rntester`, `test_ios` and `build_hermes_macos`) which forced hermes to be build 3 times.
Another issue I found was that we were not caching hermes at all the first time we build it, during the `build_hermes_macos` step.
To ensure that `test_rn_tester` and `test_ios` has a valid version of Hermes from the cache, they now depend on the `build_hermes_macos` job
## Changelog
[iOS] [Changed] - Add caching for Hermes when we build it, updated the hermes_sdk_cache_key, update job dependencies
Pull Request resolved: https://github.com/facebook/react-native/pull/34209
Test Plan:
CircleCI must be green and take less than 2 hrs
**Before**
{F753846143}
**After**
{F753846214}
Reviewed By: cortinico
Differential Revision: D37959500
Pulled By: cipolleschi
fbshipit-source-id: c3435717bfa71e7488326894cd1ad7638044004e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34224
This Diff is a copy of this [PR](https://github.com/facebook/react-native/pull/34228) that we have against 0.69-stable.
This Diff makes sure we can build Hermes also in PR that are created against a stable branch
## Changelog
[General] [Changed] - Make sure we can build Hermes from source when PR are opened agains -stable
Reviewed By: cortinico
Differential Revision: D37961092
fbshipit-source-id: 65577fcc69f0e2a68377cbd46e3bd3a6af24e7c3
Summary:
Adds changelog for new patch.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - add changelog entry for 0.69.2
Pull Request resolved: https://github.com/facebook/react-native/pull/34227
Test Plan: N/A
Reviewed By: cipolleschi
Differential Revision: D37993752
Pulled By: cortinico
fbshipit-source-id: 339f2b6bf42547360d0bca9984e2a3fd45299cc0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34230
The OS static class is accessed inside app/build.gradle but the import is on
the top level Gradle file. This is causing an app created from template to fail
building.
This is needed to be cherry-picked on the 0.70-stable branch.
Changelog:
[Android] [Fixed] - Fix missing import on New Architecture build script in template
Reviewed By: cipolleschi
Differential Revision: D37995897
fbshipit-source-id: aad22100cee004944c4fa0841f5ef0dfc6ea1e94
Summary:
The native module might be null, and that should not be an exception thrown by the subclassed method.
Changelog:
[Android][Internal] - Mark getModule API to be nullable
Reviewed By: mdvacca, makovkastar
Differential Revision: D37900294
fbshipit-source-id: a4ecc9804b95bf0512554e96985f272b435e33b2
Summary:
There are many files across fbobjc relying on -include_pch and therefore they miss Foundation.h and UIKit.h includes. This diff was generated by a codemod and fixes these missing includes.
More details on the missing imports https://fb.workplace.com/groups/929548250966094/permalink/981237982463787/
Changelog: [Internal]
Reviewed By: yannickl
Differential Revision: D37282740
fbshipit-source-id: 0f419025b3cf2f811e96ff464cb19e8e5a25aa09
Summary:
This resolves issues where the node_modules structure is not hoisted (like with pnpm). Since the template does not directly depend on the cli, it doesn't exist in the pnpm node_modules root. Moving it to the rn scripts makes sure that the relative require starts in the correct directory for both hoisted and pnpm structures.
## Changelog
[iOS] [Fixed] - Fix cocoapods cli native_modules require for pnpm node_modules
Pull Request resolved: https://github.com/facebook/react-native/pull/34215
Test Plan:
1. react-native init
2. rm -rf node_modules
3. pnpm i
4. bundle install
5. bundle exec pod install --project-directory=ios
This should succeed. Without the patch, it will fail with
```
[!] Invalid `Podfile` file: cannot load such file -- /.../node_modules/react-native-community/cli-platform-ios/native_modules.
# from /.../ios/Podfile:2
# -------------------------------------------
# require_relative '../node_modules/react-native/scripts/react_native_pods'
> require_relative '../node_modules/react-native-community/cli-platform-ios/native_modules'
#
# -------------------------------------------
```
Reviewed By: cortinico
Differential Revision: D37959152
Pulled By: cipolleschi
fbshipit-source-id: 7fa9af4a8c153cfd38360f57eca415a8c252dbd5
Summary:
This fix is necessarly to ensure that when working on the codebase in the `0.XX-stable` branches (ex. when you are working on a release) the Hermes podfile is correctly set against the right commit for that branch, and not latest commit from main branch of Hermes repo.
I didn't add a check to verify that the file `.hermesversion` exists because I think it's safe to assume that the file and the tag correctly exists when this step (doing a pod install on the `0.XX-stable` branch).
Once this is merged, we need to cherry pick it on both the 0.69 and 0.70 branches
## Changelog
[iOS] [Fixed] - Hermes pod: change logic to use the hermes tag to set the pod source correctly
Pull Request resolved: https://github.com/facebook/react-native/pull/34221
Test Plan:
* git clone the repo
* checkout 0.69-stable branch
* follow https://reactnative.dev/contributing/release-testing
* without this commit, when testing RNTester + iOS + Hermes the app will insta-crash on opening
* with it, the app gets build successfully
Reviewed By: cortinico
Differential Revision: D37957660
Pulled By: cipolleschi
fbshipit-source-id: 4e50099ed712b1ad8e6439822e3f530142982c1b
Summary:
I just opened another PR and noticed the changelog page in the wiki redirected to the react native documentation.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[Internal] [Changed] - Update link to changelog documentation in PULL_REQUEST_TEMPLATE
Pull Request resolved: https://github.com/facebook/react-native/pull/34206
Reviewed By: NickGerleman
Differential Revision: D37920424
Pulled By: cortinico
fbshipit-source-id: f4e47172a13fe5b42c29e320d34816b490a14b6c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34177
This Diff destructures the parameters of the use_react_native! function. It does that in a backward compatible way, so we there should be no disruptions.
It also adds documentation to the various public method we want to export to our users.
## Changelog
[iOS][Changed] - Destruct use_reactnative parameters and ad ddocumentation
Reviewed By: cortinico
Differential Revision: D37787365
fbshipit-source-id: 27f9030db2e8c6c66b9548b4c1287eb8165ae5fc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34176
It extracts the code related to the codegen from the main `react_native_pods` script to a dedicated file, adding also tests.
## Changelog
[iOS][Changed] - Move codegen in separate files
Reviewed By: cortinico
Differential Revision: D37755818
fbshipit-source-id: 99760d1def26ddbf065fdd234e0d183c2795513c
Summary:
D37801394 (https://github.com/facebook/react-native/commit/51f49ca9982f24de08f5a5654a5210e547bb5b86) attempted to fix an issue of TextInput values being dropped when an uncontrolled component is restyled, and a defaultValue is present. I had missed quite a bit of functionality, where TextInput may have child Text elements, which the native side flattens into a single AttributedString. `lastNativeValue` includes a lossy version of the flattened string produced from the child fragments, so sending it along with the children led to duplicating of the current input on each edit, and things blow up.
With some experimentation, I found that the text-loss behavior only happens on Fabric, and is triggered by a state update rather than my original assumption of the view manager command in the `useLayoutEffect` hook. `AndroidTextInputShadowNode` will compare the current and previous flattened strings, to intentionally allow the native value to drift from the React tree if the React tree hasn't changed. This `AttributedString` comparison includes layout metrics as of D20151505 (https://github.com/facebook/react-native/commit/061f54e89086af1c80e5b0460ec715533f99bdb7) meaning a restyle may cause a state update, and clear the text.
I do not have full understanding of the flow of state updates to layout, or the underlying issue that led to the equality check including layout information (since TextMeasurementCache seems to explicitly compare LayoutMetrics). D18894538 (https://github.com/facebook/react-native/commit/254ebab1d2b6fac859ab1ae0c9503328fc99a6d0) used a solution of sending a no-op state update to avoid updating text for placeholders, when the Attributed strings are equal (though as of now this code is never reached, since we return earlier on AttributedString equality). I co-opted this mechanism, to avoid sending text updates if the text content and attributes of the AttributedString has not changed, disregarding any layout information. This is how the comparison worked at the time of the diff.
I also updated the fragment hashing function to include layout metrics, since it was added to be part of the equality check, and is itself hashable.
Changelog:
[Android][Fixed] - Fix `AttributedString` comparison logic for TextInput state updates
Reviewed By: sammy-SC
Differential Revision: D37902643
fbshipit-source-id: c0f8e3112feb19bd0ee62b37bdadeb237a9f725e
Summary:
Log whether bridgeless mode is enabled or not when calling into a JavaScript module method fails.
We are seeing a surge of these crashes in MessageQueue.js bridgeless mode. This temporary log will help us drill down into the issue.
Changelog: [Internal]
Created from CodeHub with https://fburl.com/edit-in-codehub
This should not mess with the sitevar overrides.
These are the two diffs where we mapped the venice and bridge errors to the same mid: D36649249, D36649249.
Reviewed By: fkgozali
Differential Revision: D37898744
fbshipit-source-id: 0ab337c8c0d73bd70c4756a16b8ece8ba8730c47
Summary:
Add API for setting/getting native state.
When present, the internal NativeState property of an object always stores a NativeState with a pointer to a heap-allocated shared_ptr + a finalizer that simply `delete`s it.
Changelog:
[Internal][Added] - JSI API for setting/getting native state on a JS object
Reviewed By: jpporto
Differential Revision: D36499239
fbshipit-source-id: a1ff1905811db1aac99ece3f928b81d0abfb342b
Summary:
Changelog: [RNTester][Internal] - Add the ability for platform tests to be marked as skipped
There are some properties/tests in the web platform tests that we don't want to especially priorities (especially if they aren't especially relevant to the specification and just legacy browser compat) so this adds the ability for us to mark these tests as skipped. This is so that we can ensure that our platform tests are "complete" while decreasing the noise and distraction from failing tests that don't really apply to RN.
Reviewed By: lunaleaps
Differential Revision: D37889470
fbshipit-source-id: 6516ac90c242d662518a95cb9ba8ce643f6bb09c
Summary:
Changelog: [iOS][Internal] - Add key modifier properties to the PointerEvent interface
This diff adds implementations of the `ctrlKey`, `shiftKey`, `altKey`, and `metaKey` properties on the PointerEvent interface for iOS.
Reviewed By: lunaleaps
Differential Revision: D37869377
fbshipit-source-id: b187bae93fbfc97b6ca1d8d9786ad85343484b3d
Summary:
Changelog: [internal]
- Upgrade ESLint version to the latest
- Upgrade ESLint plugin versions to the latest to ensure compatibility
- Switch from eslint-plugin-flowtype to eslint-plugin-ft-flow
- Updates lint suppressions - all `flowtype/` rules to `ft-flow/`
### `flowtype` vs `ft-flow`
`eslint-plugin-flowtype` is well out of date and no-longer maintained. It's been abandoned by its owner. This means it crashes on ESLint v8.
`eslint-plugin-ft-flow` is a fork of the above and is maintained by the same people that own the `flow-typed` project.
Reviewed By: jacdebug
Differential Revision: D37727177
fbshipit-source-id: 516be42f947fec9c886526c182a608b3311c0b50
Summary:
According Flow's document, a maybe type of T means `T | null | undefined`, instead of `T | null | void`.
I think keeping TypeScript and Flow being consistent to each other is better.
## 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] - Accept TypeScript type `T | null | undefined` as a maybe type of T in turbo module.
Pull Request resolved: https://github.com/facebook/react-native/pull/34158
Test Plan: `yarn jest` passed in `packages/react-native-codegen`
Reviewed By: yungsters
Differential Revision: D37731169
Pulled By: philIip
fbshipit-source-id: b6d9b7e8991f60e12c1004bed5b937b34fb02c47
Summary:
changelog: [internal]
Original commit changeset: 290ae428a720
Original Phabricator Diff: D37881453 (https://github.com/facebook/react-native/commit/e98a835bfc7b01bccb1b7cdee94db248a0a90607)
in the original diff I made a mistake. The default value for RN is never, we override it in one of our subclasses.
Reviewed By: cortinico
Differential Revision: D37884715
fbshipit-source-id: 3c5b5ef5550120034e33ae9047292f38159dea3e
Summary:
Now that [exact_empty_objects has been enabled](https://fb.workplace.com/groups/flowlang/posts/1092665251339137), we can codemod `{...null}` to `{}` - they are now equivalent.
1) Run my one-off jscodeshift codemod
2) `scripts/flow/tool update-suppressions .` (as some suppressions move around due to the change)
drop-conflicts
Reviewed By: bradzacher
Differential Revision: D37834078
fbshipit-source-id: 6bf4913910e5597e5dd9d5161cd35deece6a7581
Summary:
Changelog: [RNTester][Internal] - Fix incorrect pointer event name in move test
We recently removed the '2' suffix from certain pointer event names and I forgot to update this test.
Reviewed By: lunaleaps
Differential Revision: D37857862
fbshipit-source-id: 6f37dce139772cd16d663961dbcbbf68dde83101
Summary:
Changelog: [iOS][Internal] - Implement offsetX/offsetY properties on the PointerEvent interface
Simple diff implementing the offsetX/offsetY properties on PointerEvent — thankfully the touch events already kept track of these so it was mostly a matter of forwarding that data to the pointer events.
Reviewed By: lunaleaps
Differential Revision: D37830139
fbshipit-source-id: 77f33a99393350d32cbe449e6a009bdeb2a12d08
Summary:
Automatically create a GitHub Release draft when a new React Native release is created.
The GitHub Release will be created by the same Circle CI job that publishes the package to npm.
This job will also upload the built Hermes binaries to the GitHub release.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D36646696
fbshipit-source-id: 0a863dc4e3215fc95f7852f8dc43858cdd852aaa
Summary:
This cleans up a bit our dependency list inside `ReactAndroid`. I've re-sorted the lists, and exported everything I could in the `gradle.properties`.
I wish we could move to the Gradle Version Catalog for Android, but that's not possible at the moment (it will make impossible for users to build from source).
## Changelog
[Internal] - Cleanup some of the dependencies inside ReactAndroid
Pull Request resolved: https://github.com/facebook/react-native/pull/34191
Test Plan: Will rely on a Green CircleCI
Reviewed By: huntie
Differential Revision: D37828614
Pulled By: cortinico
fbshipit-source-id: f433d08d691db4145e0c72ca4dab2f0350e4101f
Summary:
Changelog:
[general][change] - Use RuntimeConfig instead of VM Experiment Flag to set up the micro task queue.
Reviewed By: neildhar
Differential Revision: D37353947
fbshipit-source-id: 5c8f35c0a79d70cb0d234e881e55058cffb44ac8
Summary:
Changelog: [iOS][Internal] - Implement screenX/screenY properties on the PointerEvent interface
This diff implements the screenX/screenY properties which report the position of a pointer in the device's physical screen coordinates.
Reviewed By: lunaleaps
Differential Revision: D37794415
fbshipit-source-id: 6c39c3651812f99e66b93647579a2935598ef6f2
Summary:
The empty object literal `{}` now has the type `{}` - i.e. an exact empty object - rather than being unsealed.
Enable the option in the github flowconfigs
Changelog: [Internal]
Reviewed By: pieterv
Differential Revision: D37836634
fbshipit-source-id: 8ef0cfaf1d0420ae71723e04163f00c43c550e07
Summary:
A layout-impacting style change will trigger a layout effect hook within `TextInput`. This hook fires a ViewManager command to set the text input based on the known JS value: https://github.com/facebook/react-native/blob/d82cd3cbce1597512bb2868fde49b5b3850892a0/Libraries/Components/TextInput/TextInput.js#L1009
The JS value is determined using `value` if set, falling back to `defaultValue`. If a component uses `TextInput` as an uncontrolled component, and does not set this value, the command wipes text input back to the default value. This does not happen on re-render of the JS side, despite setting text prop, since the underlying native property never changes/triggers a rerender.
This change alters the logic to prefer `lastNativeText` instead of `defaultValue` when available, to retain the updated `TextInput` content on relayout.
Reviewed By: javache
Differential Revision: D37801394
fbshipit-source-id: d56c719d56bebac64553c731ce9fca8efc7feae9
Summary:
Turbo module codegen supports arrays in both Flow and TypeScript, but it only recognize `Array<T>` and `ReadonlyArray<T>` in TypeScript.
In this change, `T[]` and `readonly T[]` are made recognizable in codegen.
## Changelog
[General] [Added] - Support TypeScript array types for turbo module (module only)
Pull Request resolved: https://github.com/facebook/react-native/pull/34183
Test Plan: `yarn jest` passed in `packages/react-native-codegen`
Reviewed By: lunaleaps
Differential Revision: D37812638
Pulled By: cipolleschi
fbshipit-source-id: d63b0585497a43c274d50e1877baab5d1cc3f8fa
Summary: Changelog: [Internal] - Add an example of pointermove using AnimatedEvent
Reviewed By: vincentriemer
Differential Revision: D37769263
fbshipit-source-id: 25de0ae88b55148d23fa388768707ea859e9ae4d
Summary:
The RN Hermes Inspector keeps a mapping of pageId to
Connection. This mapping is created in the call to
enableDebugging. Later, when disableDebugging is invoked,
the inspector will iterate over the pageId to Connection map
to find which page to is being disabled.
The DecoratedRuntime enables debugging on construction, and
disables on destruction. When disabling debugging, the
DecoratedRuntime then passes the "naked" hermesRuntime,
which in turn gets checked against all connections' runtimes.
It turns our that ```HermesExecutorRuntimeAdapter::getRuntime```
returns the runtime **wrapped** by the DecoratedRuntime, and
not hermesRuntime itself.
This means that no connections match the request for
disabling debugging. Which means the Connection never
gets deleted, which in turns keep its underlying adapter (in
this case, the ```HermesRuntimeExecutorAdapter```) alive,
which has a shared_ptr to the runtime wrapped by the DecoratedRuntime.
Other than effectively leaking this connection (and thus the runtime),
this also causes an issue when the app tries to re-load the page -- at
which point the inspector will remove the old entry from the page to
connection mapping, thus initiating the destruction of the (leaked)
Runtime in a thread other than the thread that created the runtime.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D37809467
fbshipit-source-id: e73caa357a300a0d48e69aa3a1a8b00a97519f24
Summary:
Changelog: [iOS][Internal] - add x/y & pageX/Y implementations to PointerEvent interface
This diff adds the x/y properties, which are defined as aliases of clientX/clientY respectively. In addition this diff adds pageX/pageY which, while not definted as aliases of clientX/clientY, are effectively aliases in React Native since the root view is not scrollable (client and page points only differ on the web when a user has scrolled the document element).
Reviewed By: lunaleaps
Differential Revision: D37766818
fbshipit-source-id: c7ad3750460b1913889c6d1a55b4c1edc6918f5b
Summary:
Changelog: [RNTester][Internal] - Fix layout measurement in hoverable pointer attributes test
This diff addresses an issue I've found with the hoverable pointer attributes test where before it was measuring the view seemingly on mount and it appears that for *some reason* that would be incorrect on the first mount of the view. This diff ensures that doesn't happen by measuring the view JIT when an event is recieved instead.
Reviewed By: lunaleaps
Differential Revision: D37765614
fbshipit-source-id: 8594677d98be8d3d4e75dbf5394c92ca49355d6d
Summary:
Changelog: [iOS][internal] - Add twist property to PointerEvent interface
This adds the twist property to the PointerEvent implementation on iOS which similarly to tangentialPressure doesn't really apply so we default to a hard-coded value of 0.
Reviewed By: lunaleaps
Differential Revision: D37760511
fbshipit-source-id: f1fccfd6b5d07024cea83d86925a9bfc2e6cc8cf
Summary:
Changelog: [iOS][internal] - Add tangentialPressure property to PointerEvent interface
This diff adds the tangentialPressure property to the PointerEvent implementation on iOS. This one is pretty simple considering iOS doesn't have the concept of tangential pressure so we just hard code it to 0 as defined by the spec.
Reviewed By: lunaleaps
Differential Revision: D37759634
fbshipit-source-id: 7ca0e47267f5fde76ace2b96d05ea2e154cb4b8f
Summary:
This change replaces the text in `ColorStylesExample` with two different spans of nested text, which requires special attention with the native driver.
Changelog:
[Internal][Added] - Add Nested Text Animated Color RNTester Example
Reviewed By: genkikondo
Differential Revision: D37762708
fbshipit-source-id: 755e6dd922432781645cd84749a77f29ec57665d
Summary:
Before this change, during the "Start Packager" Xcode build step that runs the packager, `packager.sh` was using my system node version and not the one from `nvm` that is meant to be used with the project.
## Changelog
[iOS] [Fixed] - Use `NODE_BINARY` from `.xcode.env` when running packager from Xcode
Pull Request resolved: https://github.com/facebook/react-native/pull/34121
Test Plan: Perform a build using Xcode and confirm that the packager is using the correct version of node.
Reviewed By: cortinico
Differential Revision: D37746951
Pulled By: cipolleschi
fbshipit-source-id: de697c27fe86ce65e8e3646cb30309ecc7f6c247
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34161
This is a follow up to D37648363 (https://github.com/facebook/react-native/commit/64fe67695be3c038414c5ed3e02d487c449702b6) which breaks up `TestBundle.js` into two modules. This enables `TestApps.js` (which defines and exports the set of integration test apps) to be required in the Meta-specific dependency graph without violating our internal naming pattern for JS entry points.
`force_include_bundles` is removed from the `js_glob` macro signature.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D37686883
fbshipit-source-id: 492c13dfcdd76ea8347d4d11c85818e31777c663
Summary:
Fix todo and inconsistency across codebase. It's better to have just one way to refer to these types.
Changelog: [Internal]
Reviewed By: philIip
Differential Revision: D37653146
fbshipit-source-id: e82f09caa6cd6eec5512b78f413708d9c04a7a83
Summary:
Ahead of enabling the `exact_empty_objects` option, suppress errors so that actually enabling the option is easier. We can do this without enabling the option by codemoding `{}` to `{...null}` in files that have errors.
Process:
1) Get list of files with errors when enabling the option
2) Codemod `{}` to `{...null}` in those files
3) Suppress resulting errors
4) Land diff with `drop-conflicts` flag
5) Announce and enable option (with many fewer files to edit)
6) Codemod all `{...null}` to `{}`
drop-conflicts
We are working on making the empty object literal `{}` have the type `{}` - i.e. exact empty object - rather than being unsealed.
More info in these posts: https://fb.workplace.com/groups/flowlang/posts/903386663600331, https://fb.workplace.com/groups/floweng/posts/8626146484100557
Reviewed By: pieterv
Differential Revision: D37731004
fbshipit-source-id: a9305859ba4e8adbdb8ae8feff3ec8a2f07ed236
Summary:
Subclassing a ViewManager means an additional PropsSetter class is generated (and other overheads). Instead we can use a Factory/Provider to construct ReactTextViewManager, since we don't actually need a subclass.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D36411098
fbshipit-source-id: 11c5ba5c9683a3ae4741cf61338f1983c69d9b69
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34171
Changelog:
[General][Added] - Added files for `avn`, `nodenv`, and other managers that set the node.js version in reactive native project including testing
Reviewed By: cortinico
Differential Revision: D37683291
fbshipit-source-id: ef0df0fb07f5cc0fa3591dde487f65e4b1b5f73f
Summary:
Changelog: [Internal][iOS] Minor: Rename RCTNotAllowedInAppWideFabric to RCTNotAllowedInFabricWithoutLegacy
`RCTNewArchitectureValidationPlaceholder(RCTNotAllowedInBridgeless` is to track Bridge APIs that are okay in Fabric but not in Bridgeless.
`RCTNewArchitectureValidationPlaceholder(RCTNotAllowedInFabricWithoutLegacy` is to track legacy APIs that should not exist if the app was using Fabric **without any legacy architecture**. e.g. RCTBridgeModule, legacy interop view components.
Reviewed By: fkgozali
Differential Revision: D37659105
fbshipit-source-id: aee4e083820e83a8dac19eb3b5efc49b37d90039
Summary:
Changelog: [RNTester][Internal] - Create more mobile-friendly version of the platform test results UI
The original UI design for displaying the test results was done with only really tablets in mind so in order to better accomidate mobile screen sizes this diff adds a new expanding UI for the test results.
Reviewed By: lunaleaps
Differential Revision: D37701638
fbshipit-source-id: a1789abb15db7ab162fe90afc32d23c435f1bdb5
Summary:
Changelog: [RNTester][Internal] - Add README for RNTesterPlatformTest framework
This diff adds some initial documentation for `RNTesterPlatformTest` to give other pointers on how to contribute their own platform tests (both internally and externally).
Reviewed By: lunaleaps
Differential Revision: D37566632
fbshipit-source-id: c203045f79c3c5488fd0dcbb8077e9041bd62b0f
Summary:
Changelog: [iOS][Internal] - Add `buttons` implementation to the PointerEvent interface
This diff adds an implementation of the `buttons` property by leveraging `UIEvent`'s `buttonMask` property.
Reviewed By: lunaleaps
Differential Revision: D37430270
fbshipit-source-id: 69fd3aebcb403e665349a24283a04c0eb82ff3e2
Summary: Changelog: [Internal] - If any relevant view events (pointer, touch events, gesture responder, etc.) are declared on view, then the view must form stacking context. We need this change for pointer events specifically to determine whether we've entered/exited a view
Reviewed By: vincentriemer
Differential Revision: D37678352
fbshipit-source-id: 02641549ef608b1c9468ac693c7da629143212cb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34100
This Diff continue the effort of refactor and test the cocoapods script, moving hermes setup in a dedicated `hermes.rb` file and adding some tests on the logic of the hermes handling.
## Changelog
[iOS][Changed] - move and test Hermes setup from react_native_pods script into a dedicated file
Reviewed By: cortinico
Differential Revision: D37522432
fbshipit-source-id: 91112476aac576a30110e5dcd4e46fa12241962a
Summary:
These changes are a side-effect of a Meta-internal Buck macro change. This does not affect how RNTester is built in open source.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D37648363
fbshipit-source-id: 6fd5d56a7a7a9ea71dc3d0df91e510fcd45a1e17
Summary:
This diffs replaces uses of the deprecated fields from HermesInternal.getInstrumentedStats() with the ones from Hermes' TimedRuntime.
Changelog:
[General][Added] - JSITimerInternal descriptor
Reviewed By: rubennorte
Differential Revision: D36625701
fbshipit-source-id: fbdb554e5cfb0b3556fcbe01f9e2930ace66a619
Summary:
Changelog: [Internal]
Add `RCTNewArchitectureValidationPlaceholder(RCTNotAllowedInAppWideFabric)` to track RCTViewManagers used in Fabric using the legacy interop layer. They work for now in the interop layer, but they need to be migrated to Fabric to remove potential issues with using the legacy architecture and the new architecture simultaneously. RCTNewArchitectureValidationPlaceholder is a no-op used for tracking unmigrated callsites that may be used often.
`RCTNewArchitectureValidationPlaceholder(RCTNotAllowedInBridgeless` is to track Bridge APIs that are okay in Fabric but not in Bridgeless.
This diff adds the validation placeholder to legacy components registered in [RCTLegacyViewManagerInteropComponentView.mm](https://github.com/facebook/react-native/blob/743d0706e2099514b4603855bfc2b6505fcc10a5/React/Fabric/Mounting/ComponentViews/LegacyViewManagerInterop/RCTLegacyViewManagerInteropComponentView.mm#L92-L99).
Reviewed By: fkgozali
Differential Revision: D37635613
fbshipit-source-id: 5399dad822c8f5c11ef3b32297bf25214fd857dd
Summary:
This diff fixed a NPE in horizontal scroll view when calling scrollToEnd API in side effect.
The problem here is we may trigger side-effects before the required view got mounted for performance reasons. We've been fixing this with retry logic on those side-effects and we've already done this in vertical scroll view. This is to fix on the horizontal scroll as well.
Changelog:
[Android][Fixed] - Fixed HorizontalScrollView API scrollToEnd causing NPE in side-effects.
Reviewed By: lunaleaps, JoshuaGross
Differential Revision: D37571847
fbshipit-source-id: 0a4dc38381008350fd09908aa3ebb64e3e65a424
Summary:
Upgrade React Native's direct dependencies on Metro packages from 0.71.2 to 0.71.3
Metro release notes: https://github.com/facebook/metro/releases/tag/v0.71.3
Changelog:
[General] Update direct Metro dependencies to 0.71.3
Reviewed By: robhogan
Differential Revision: D37647746
fbshipit-source-id: cb798c2c0d0d763ce5dd2af48f3877fab8e9fc0d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34142
The `||=` operator in an expression like `x = a ||= b` works in a way that:
- if a is null, it assigns b to x
- if a is `falsy`, it assigns b to x
- otherwise, it assigns a to x.
In our setup, if the user set `hermes_enabled` to `false` in the Podfile (one of the suggested way to disabled Hermes), the `options[:hermes_enabled]` part will evaluate to false and, therefore, `hermes_enabled` will obtain the value of `true`.
## Changelog
[iOS][Changed] - Use the correct operator to decide whether Hermes is enabled or not.
Reviewed By: cortinico
Differential Revision: D37643845
fbshipit-source-id: 387f7bd642250c40873400d22d7d85451462c073
Summary: Changelog: [Internal] Allow for MotionEvents to indicate whether they are dispatched from an input device that supports hoverability
Reviewed By: javache
Differential Revision: D37543296
fbshipit-source-id: 4f70d2bf69ff1c563d8e4a6b5eb6b13b53996b9a
Summary: Changelog: [Internal] - We can now remove the '2' suffix as we had an internal implementation that was not truly aligned with W3C pointers but used the same name. We have aligned the internal types to match w3c so we can now remove the suffix that differentiates them.
Reviewed By: vincentriemer
Differential Revision: D37545813
fbshipit-source-id: 6f2336ae9e314066c340161113268c1f28621a71
Summary:
Internal tests are indicating that there's an OOM that happens during the RemoveDeleteTree worker loop while trying to expand the size of the tag stack.
In practice during manual testing I was not able to get the capacity beyond 40, but for deletions of very large trees, it's easy to imagine the size of the stack growing to at least the number of nodes in the tree being deleted. To mitigate this, we relax our requirements around the order in which onViewStateDeleted can be called and call it top-down instead of bottom up to maintain a smaller stack (see comments for more details).
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D37619259
fbshipit-source-id: 8f7af0137a868606a72fdc7bdca13c5e89b69573
Summary:
After D37553813, there are no more TV apps in `fbsource`. Thus, we can begin the sequential teardown of all of the `APPLETVOS` variants in the codebase, which should migrating to `select()` and buck parse times a bit faster.
#nocancel
Reviewed By: natestedman
Differential Revision: D37594789
fbshipit-source-id: 830e40266654f948f39f5d10c32a080e970cf9d7
Summary:
Changelog: [RNTester][Internal] - Add the ability to filter PlatformTest results by test name substrings
In certain tests (such as the hoverable pointer attributes test) there are a super large number of results which can make it hard to focus on the ones you're actively trying to work on fixing. This diff adds the ability to filter those results with a simple substring filter on the test name of the results.
Reviewed By: lunaleaps
Differential Revision: D37558411
fbshipit-source-id: 8f4b19fed9bb9f1b08fd7470cd79d68b6c721c13
Summary:
If you don't list `Cxx` as a supported platform, we will use Android builds, even when using `buck run` for local execution.
Changelog: [Internal]
Reviewed By: derolf
Differential Revision: D37600464
fbshipit-source-id: 6ba8566cde4180524351c9d8c647ce1d4ac5279d
Summary:
Upgrade React Native's direct dependencies on Metro packages from 0.71.1 to 0.71.2.
Metro release notes: https://github.com/facebook/metro/releases/tag/v0.71.2
Changelog:
[General] Update direct Metro dependencies to 0.71.2
Reviewed By: jacdebug
Differential Revision: D37593257
fbshipit-source-id: f56db766a6c63b74ab9feab31a9d7a1f50c5af23
Summary:
Changelog: [Internal]
- Make the new architecture validation easier to understand by enabling validation with `RCTNewArchitectureSetMinValidationLevel(level)`.
- When `RCT_ONLY_NEW_ARCHITECTURE` flag is enabled:
- `RCTErrorNewArchitectureValidation` calls `RCTLogAssert` instead of `RCTLogError`.
- `RCTNewArchitectureValidationPlaceholder` calls `RCTLog`, instead of no-op.
Reviewed By: fkgozali
Differential Revision: D37555667
fbshipit-source-id: 2c725c287a2dec19e8946c7fe5d8fa111e4a17fa
Summary:
There is a very small volume of production errors caused by a View that is already in the hierarchy being added to the hierarchy again; this results in a crash on the Android platform layer.
We detect and attempt to silently recover from this case, while logging and collecting more diagnostics. This will still crash in debug mode.
It is unclear what layer this error is coming from: it could be an issue with the C++ differ (ordering, or something more tricky); that is unlikely but there are few other hypotheses at the moment.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D37557663
fbshipit-source-id: ffe320ff646e314fa921a2c2cf8058254713505c
Summary:
The initial version of this would result in LayoutAnimations running potentially much faster than 60FPS (incorrectly). Resolve by calling tryDispatchMountItems directly instead of the frame callback runner.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D37543693
fbshipit-source-id: 91dbd961ecc155221c84148cb6b252a4aac9ec91
Summary:
This PR adds a new method called **__apply_mac_catalyst_patches** to **scripts/react_native_pods.rb**. If it is enabled in the Podfile, it will apply three patches necessary for successful building not only for iOS and tvOS targets, but also for macOS using Apple's Mac Catalyst technology.
These 3 patches are:
- Fixing bundle signing issues by altering CODE_SIGN_IDENTITY
- Explicitly setting dead code stripping flag in project.pbxproj
- Modifying library search paths
The details were discussed here https://github.com/reactwg/react-native-releases/discussions/21#discussioncomment-2754289
## Changelog
[iOS] [Added] - Add Mac Catalyst compatibility (can be enabled in Podfile)
Pull Request resolved: https://github.com/facebook/react-native/pull/34026
Test Plan:
1. Go to project settings in Xcode, to General tab. Enable "iPad" and "Mac Catalyst" checkboxes
2. Go to "Signing & Capabilities" tab, ensure that a correct bundle id and development team are set
3. Edit Podfile, uncomment **__apply_mac_catalyst_patches(installer)** line
4. Run `pod install` in ios directory
5. Get back to Xcode, select "My Mac (Mac Catalyst)" as a target device
6. Build & run
Reviewed By: cipolleschi
Differential Revision: D37362054
Pulled By: cortinico
fbshipit-source-id: 74636f716f112289ab40968bbc8e52406c1e9579
Summary:
```js
async () => {
let blobs = [];
for (let i = 0; i < 4; i++) {
const res = await fetch();
blobs = [...blobs, await res.blob()]
}
const blob = new Blob(blobs); // <<<<<<<<<<<<<<< a
return await new Promise((resolve, reject) => {
const fileReader = new FileReader();
fileReader.onload = async () => {
await RNFS.writeFile(destPath, (fileReader.result as string).split(',')[1], 'base64');
resolve(destPath);
};
fileReader.onabort = () => {
reject('');
};
fileReader.onerror = (event) => {
reject('');
};
fileReader.readAsDataURL(blob); // <<<<<<<<<<<<<<< b
});
}
```
Sometime `fileReader.readAsDataURL` is unable to get blob from the dictionary after `new Blob(blobs)` and then reject with `Unable to resolve data for blob: blobId` in iOS or `The specified blob is invalid` in android. Because line `a` and `b` can be run in different thread. `new Blob([])` is in progress and `fileReader.readAsDataURL` accesses the blob dictionary ahead of the blob creation.
The expected behaviour is it should finish new Blob([]) first and then readAsDataURL(blob)
To fix that, there should be a lock inside the method `createFromParts`. For iOS, It needs to be a recursive_mutex to allow same thread to acquire lock
## 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] - fix the race condition when calling readAsDataURL after new Blob(blobs)
Pull Request resolved: https://github.com/facebook/react-native/pull/34096
Reviewed By: cipolleschi
Differential Revision: D37514981
Pulled By: javache
fbshipit-source-id: 4bf84ece99871276ecaa5aa1849b9145ff44dbf4
Summary:
LA needs to ignore the new RemoveDeleteTree mutation coming from the differ.
Changelog: [Internal]
Reviewed By: jehartzog
Differential Revision: D37531217
fbshipit-source-id: c05b4106b6e955083e5e7e93619a13c4a2858404
Summary:
MSVC doesn't like Clang macros. Oops!
Constraints with this bit of code:
1. I'm trying to enforce constexpr in the most obvious, intuitive way possible. Macros are ugly but a "proper" solution would result in 10x as much code that is, totally subjectively, less readable to me.
2. This is evaluating at compile-time a hash of a string which is usually used in the `case` line of a switch statement.
For now I'm just hoping that MSVC will allow us to shadow `hash` which Xcode doesn't like. We might need to add a special pragma(s) for MSVC if it still doesn't like this.
Changelog: [Internal]
Reviewed By: lyahdav
Differential Revision: D37529949
fbshipit-source-id: 9aa605a9786bf5d194819ef8dade778875ae744e
Summary:
Before
```
"If you want to override a property, don't addthe ReactProp annotation to the property in the subclass",
```
After
```
"If you want to override a property, don't add the ReactProp annotation to the property in the subclass",
```
Reviewed By: michaeltangelo
Differential Revision: D37526541
fbshipit-source-id: 850424a1b5a5aeb0abe64b6defcf6db96d2000cc
Summary:
Updating changelog for 0.69.1
## 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] - Update changelog for 0.69.1
Pull Request resolved: https://github.com/facebook/react-native/pull/34097
Reviewed By: cortinico
Differential Revision: D37518312
Pulled By: cipolleschi
fbshipit-source-id: ba0784c371f0b771fc4f164a29aa24a1e7a46aa8
Summary:
Crashes can occur if we try to disassemble trees not managed by React Native - for example a native component tree, Litho hierarchies, etc.
As we disassemble the tree, ensure that children are managed before disassembling a subtree.
Changelog: [Internal]
Reviewed By: ryancat
Differential Revision: D37493854
fbshipit-source-id: fee4d303133edcef663abfe8637bce6b24627724
Summary:
Due to the way we're dispatching queued MountItems on Android, we could be doing nothing on the UI thread for up to 15.99...ms before the start of the next frame, resulting in a delayed paint of up to 1 full (16ms) frame.
The delay is totally random and depends only on when the work is scheduled.
The tl;dr is that currently all MountItems are dispatched starting only at the /beginning/ of a UI frame. If we schedule work at FrameStart+0.000001ms, it will not be operated on until the start of the next frame, 16ms later. So the "wasted" time could be anywhere from 0 to ~16ms, but will result in at least 1 wasted frame regardless.
The fix is fairly trivial: start working on large buffered work as soon as we schedule it.
Changelog: [Android][Changed] Optimization to paint changes up to 1 frame earlier on Android/Fabric
Reviewed By: NickGerleman
Differential Revision: D37478885
fbshipit-source-id: 8af846736caf3a9d9f0d0c5e33328bebb87b1b32
Summary:
Instead of directly scheduling a Runnable on the UI thread, use a GuardedFrameCallback which (1) guards against exceptions thrown on the UI thread (in this case, errors in deferred remove/delete work really should not disrupt the UI at all or cause user-visible crashes) (2) allows us to split work across multiple frames if necessary (3) is more consistent with how we schedule other work on Android.
The only functionality change is that we might split work across multiple callbacks, in the case of tearing down a particularly large tree.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D37470531
fbshipit-source-id: d9d1fc85c29e53addea886db975c0d914581e618
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34085
Hermes is now the default engine on iOS.
Apps can choose to continue using JSC by setting `hermes_enabled` to `false` in their Podfile.
The RNTester app now uses Hermes, as well. Use JSC in RNTester by setting `USE_HERMES=0` when running `pod install`.
Changelog:
[iOS][Changed] Hermes is now the default engine on iOS. This setting is controlled via `flags[:hermes_enabled]` in the Podfile.
Reviewed By: cortinico, cipolleschi
Differential Revision: D37361468
fbshipit-source-id: e6dda6a23eea4a824ad157d1a26f17e181db33cd
Summary:
This fix solves a problem very well evaluated [here](https://github.com/Expensify/App/issues/2727) as well as this [one](https://github.com/facebook/react-native/issues/29290).
The issue is that when the app goes to background, in landscape mode, the RCTDeviceInfo code triggers an orientation change event that did not physically happen. Due to that, we get swapped values returned when going back to the app.
I debugged the react-native code, and to me it seems that react native publishes the orientation change event one extra time when switching the state of the app to 'inactive'. Here is what is happening:
1. iPad is in landscape.
2. We move the app to inactive state.
3. Native Code queues portrait orientation change (no such change happened physically), and immediately after it triggers landscape change (same as we had in point 1).
4. We restore the app to active state.
5. The app receives two queued orientation change events, one after another.
6. The quick transition between portrait and landscape happens even though it never went back to portrait.
Fresh `react-native init` app repro case can be found here: https://github.com/lbaldy/issue-34014-repro
Video presenting the issue (recorded while working on: https://github.com/Expensify/App/issues/2727 ): https://www.youtube.com/watch?v=nFDOml9M8w4
## 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] - Fix the way the orientation events are published, to avoid false publish on orientation change when app changes state to inactive
Pull Request resolved: https://github.com/facebook/react-native/pull/34014
Test Plan:
### Test Preparation
1. Make sure you have a working version of E/App.
2. Open App/src/components/withWindowDimensions.js and update the constructor by changing this line:
`this.onDimensionChange = _.debounce(this.onDimensionChange.bind(this), 100);`
to
`this.onDimensionChange = this.onDimensionChange.bind(this);`
3. Open the NewExpensify.xcodeproj in xCode.
4. Open the RCTDeviceInfo.mm file and replace it's contents with the file from this PR.
5. Select your device of choice (I suggest starting with iPad mini) and run the app though xCode.
6. From this point you can move to the test scenarios described below.
### iPad Mini tests:
Reproduction + Fix test video (Test 1): https://youtu.be/jyzoNHLYHPo
Reproduction + Fix test video (Test 2): https://youtu.be/CLimE-Fba-g
**Test 1:**
1. Launch app in portrait, open chat - no sidebar visible.
7. Switch to landscape - sidebar shows.
8. Put app to background.
9. Put app back to foreground - make sure the side menu doesn't flicker.
**Test 2:**
1. Launch app in portrait, open chat - no sidebar visible.
2. Switch to landscape - sidebar shows.
3. Put app to background. Switch orientation back to portrait.
4. Put app back to foreground - make sure the side menu hides again as it should be in portrait.
### iPad Pro tests:
Reproduction + Fix test video (Test 3, Test 4): https://youtu.be/EJkUUQCiLRg
iPad mini test 1 applies.
Scenario 2 does not as the screen is too wide in both orientations and iPad pro shows sidebar always.
**Test 3:**
1. launch the app.
2. Make sure you're in landscape mode.
3. See split screen with some other app. Make sure the side bar is visible.
4. Play with the size of the view, resize it a bit. When the view shrinks it should hide the sidebar, when it grows it should show it.
10. Move the app to background and back to foreground, please observe there are no flickers.
**Test 4:**
1. Launch the app.
2. Make sure you're in landscape mode.
3. Make the multitasking view and make Expensify app a slide over app.
4. Move back to fullscreen/split screen. Make sure the menu is shown accordingly
5. Move the app to background and back to foreground, please observe there are no flickers.
### iPhone:
Non reg with and without the fix video: https://youtu.be/kuv9in8vtbk
Please perform standard smoke tests on transformation changes.
Reviewed By: cipolleschi
Differential Revision: D37239891
Pulled By: jacdebug
fbshipit-source-id: e6090153820e921dcfb0d823e0377abd25225bdf
Summary:
`InputAccessoryView` works fine on iOS, but crashes on Android - you can see that by using an Android device on the [Expo Snack from the official doc](https://reactnative.dev/docs/inputaccessoryview).
It forces the developer not to render the component on Android, which is usually good, but other components have implemented other, safer ways to deal with incompatibility issues.
I am of course open to discussion about this change, as well as other implementation ideas.
## Changelog
[Android] [Fixed] - Fix InputAccessoryView crash on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/33803
Test Plan:
`yarn test` gives out the following output:

Reviewed By: cipolleschi
Differential Revision: D37215394
Pulled By: cortinico
fbshipit-source-id: 66c4401f7c61b745ea893969d69c8dde3e5afb03
Summary:
I'm simplifying the `Android.mk` file inside the template as it was confusing. There are two ways to include the generated code from the codegen:
1. Importing the generated Android.mk file
2. Include the generate source files in the `_appmodules` source files.
Those two approaches are mutually exclusive (as doing both will lead to duplicate symbols). Our template comments were confusing and were suggesting a combination of both.
I'm simplifying the comments here by removing the one suggesting to go with option `1` instead.
## Changelog
[Android][Changed] - Simplify the Android.mk file in the App Template
Pull Request resolved: https://github.com/facebook/react-native/pull/34080
Test Plan: Nothing to test here as it's a comments only change
Reviewed By: cipolleschi
Differential Revision: D37463222
Pulled By: cortinico
fbshipit-source-id: 30ecc6fbbbcaf484272b4c724600cda588146506
Summary:
This is the companion PR of https://github.com/react-native-community/cli/pull/1630
It extends the `ReactNative-application.cmake` file with instructions to pickup the autolinked libraries.
## Changelog
[Internal] [Changed] - Extend the RN Application.cmake file to support Android autolinking
Pull Request resolved: https://github.com/facebook/react-native/pull/34082
Test Plan: Tested locally as we don't have a way to test autolinking on CI.
Reviewed By: cipolleschi
Differential Revision: D37463203
Pulled By: cortinico
fbshipit-source-id: 0b28e7f214c265ebfec4ccc59ae321f682299cf8
Summary:
setFocusable(int) was added in Android O, and setHyphenationFreqauency was added in M.
Changelog: [Internal]
Reviewed By: kacieb
Differential Revision: D37462117
fbshipit-source-id: e59d2de49dbdcddfdba25def6bb39695c65efe89
Summary:
We will use this error reporting pipeline for all js errors not only early js errors, so remove all "early" prefixes.
Changelog:
[General][Changed] - Remove "Early" in Js error reporting pipeline
Reviewed By: fkgozali
Differential Revision: D37379339
fbshipit-source-id: d44772818ead977a164c8632c081863851046be6
Summary:
Removes the `isTVOS` check, which just duplicated and returned the `isTV` check anyway.
## 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] - Remove deprecated `isTVOS` constant.
Pull Request resolved: https://github.com/facebook/react-native/pull/34071
Test Plan: Run against CI, and apply changes as needed.
Reviewed By: cipolleschi
Differential Revision: D37434978
Pulled By: cortinico
fbshipit-source-id: 2b38253125251b0ce28cf10c88471d8f16704999
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34025
This diff moves the monkeypatch LocalPodspecPatch to a dedicated ruby file.
It also adds test for that
## Changelog
[iOS][Changed] - Move LocalPodspecPatch to dedicated file
Reviewed By: cortinico
Differential Revision: D37069361
fbshipit-source-id: 28fddb197484f45aa20ccac516c874e79448e999
Summary:
TL;DR: For applications using JS navigation, save 50-95% of CPU during mounting phase in N>2 navigations that replace ~most of screen.
During investigation of performance on the UI thread of React Native applications, I noticed that the /initial/ render of an screen for an application using JS navigation is /mostly/ consumed (on the UI thread) by tearing-down the previous View hierarchy. In one 185ms segment on the UI thread in production, 95% of the CPU time was Remove/Delete instructions and only 5% of CPU time was consumed by actually displaying the new hierarchy (this is specific to Android and also assumes that View Preallocation is being used, so post-commit work consists of Insert and UpdateLayout mutations primarily).
There are /some/ cases where the C++ differ knows that we are deleting an entire subtree and therefore we could communicate this to the mounting layer. All that matters is that these Views are removed from the View hierarchy immediately; and secondarily that their memory is cleaned up ASAP, but that doesn't need to happen immediately.
Some additional constraints and notes:
1) As noted in the comments, we cannot simply stop producing Remove and Delete instructions. We need to produce /both/ the new RemoveDeleteTree instruction, /and/ produce all the Remove/Delete instructions, primarily because LayoutAnimations relies heavily on these Remove/Delete instructions and certain things would break if we removed those instructions entirely. However, we can mark those Remove/Delete instructions as redundant, process them only in LayoutAnimations, and not send them to the Android mounting layer.
2) We want to make sure that View Recycling is not impacted. Since Android cannot take advantage of View Recycling until /after/ the second major render (preallocation of views will happen before any views are recycled), this doesn't impact View Recycling and we'll make sure Views are recycled whenever they are deleted.
Thus, we do two things:
1) Introduce a new RemoveDeleteTree operation that can delete an entire subtree recursively as part of one operation. This allows us to avoid serializing hundreds or thousands of instructions and prevents JNI traffic.
2) Besides removing the topmost View from the View hierarchy, and ensuring it's not drawn, the full teardown and recycling of the tree can happen /after/ the paint.
In some flows with JS navigation this saves us 95% of CPU during the mount phase. In the general case it is probably closer to 25-50% of CPU time that is saved and/or deferred.
Changelog: [Android][Changed] Significant perf optimization to Fabric Remove/Delete operations
Reviewed By: ryancat
Differential Revision: D37257864
fbshipit-source-id: a7d33fc74683939965cfb98be4db7890644110b2
Summary:
Changelog: [Internal] - Fix a bug in dispatch filtering that was too aggressively filtering out events to fire.
My flaw in logic was limiting the `isListening(view, bubble)` logic to `i==0` for relevant `ViewTargets`, when in reality, we need to be checking if every `ViewTarget` passed to `filterByShouldDispatch` is listening to a bubble event.
Further, as vincentriemer pointed out, `ancestorListening` should only be set true if a `ViewTarget` is listening to a capture event.
Reviewed By: vincentriemer
Differential Revision: D37423952
fbshipit-source-id: 2ed08038632677c24766bca6214dc00013fa2446
Summary:
Changelog: [iOS][Internal] - Emit move PointerEvents when hovering with an indirect pointer
This diff ensures that when a user is hovering an RN app w/ an indirect pointer (mouse/trackpad/ect.) that `pointermove` events are emitted. Previously `pointermove` was only fired on touch interactions on iOS.
Reviewed By: lunaleaps
Differential Revision: D37353158
fbshipit-source-id: 30366324ea10c91a38dbbc1be1032c021fd8a0e0
Summary:
Provides necessary changes for the autolinking to work in new architecture on Android. Depends on https://github.com/react-native-community/cli/pull/1603 and is subject to change.
Upgraded the RN CLI to v9.0.0-alpha.0 so that it's testable locally.
## 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] [Change] - Adapt template to new architecture autolinking on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/33777
Test Plan: CI
Reviewed By: cipolleschi
Differential Revision: D36478984
Pulled By: cortinico
fbshipit-source-id: 970fa7bcb77898d9defae18c20026a7783ba4108
Summary:
Add annotations to function parameters required for Flow's Local Type Inference project. This codemod prepares the codebase to match Flow's new typechecking algorithm. The new algorithm will make Flow more reliable and predictable.
Details:
- Codemod script: `scripts/flow/tool add-comments --all --code missing-local-annot --comment "The type annotation(s) required by Flow's LTI update could not be added via codemod" .`
- Local Type Inference announcement: [post](https://fb.workplace.com/groups/flowlang/posts/788206301785035)
- Codemod announcement: [post](https://fb.workplace.com/groups/flowlang/posts/917522612186736)
- Support group: [Flow Support](https://fb.workplace.com/groups/flow)
bypass-lint
drop-conflicts
Reviewed By: evanyeung
Differential Revision: D37403582
fbshipit-source-id: 2024542952042dd93e2c123ba047410e1feca749
Summary:
`getCurrentPriorityLevel` is a function which should return the priority level on invocation.
Changelog: [Internal]
Reviewed By: ryancat
Differential Revision: D37314727
fbshipit-source-id: fe385af02af49d1ca444beb881a4893f7f0712f0
Summary:
`asHostObject` should throw a `JSINativeException` like the other `as*`
functions. This should be a safe change to make in most cases, since
this function already did not work when JSI was being provided by a
dynamic library. However, I defer to mhorowitz.
Changelog: [Fixed] Throw JSINativeException from asHostObject
Reviewed By: jpporto
Differential Revision: D36873355
fbshipit-source-id: 589ac50ebb4ecec4bacfd923d8b0795c0a6c0e34
Summary: Add annotations to function parameters required for Flow's Local Type Inference project. This codemod prepares the codebase to match Flow's new typechecking algorithm. The new algorithm will make Flow more reliable and predictable.
Reviewed By: bradzacher
Differential Revision: D37388949
fbshipit-source-id: cdcbc98035ce9b6994842005ea46df42de54f9b8
Summary:
The current implementation of **getDefaultJSExecutorFactory** relies solely on try catch to load the correct .so file for jsc or hermes based on the project configuration.
Relying solely on try catch block and loading jsc even when project is using hermes can lead to launch time crashes especially in monorepo architectures and hybrid apps using both native android and react native.
So we can make use of an additional **ReactInstanceManager :: setJsEngineAsHermes** method that accepts a Boolean argument from the host app while building ReactInstanceManager which can tell which library to load at startup in **ReactInstanceManagerBuilder** which will now have an enhanced getDefaultJSExecutorFactory method that will combine the old logic with the new one to load the dso files.
The code snippet in **ReactInstanceManager** for adding a new setter method:
```
/**
* Sets the jsEngine as JSC or HERMES as per the setJsEngineAsHermes call
* Uses the enum {link JSInterpreter}
* param jsEngine
*/
private void setJSEngine(JSInterpreter jsEngine){
this.jsEngine = jsEngine;
}
/**
* Utility setter to set the required JSEngine as HERMES or JSC
* Defaults to OLD_LOGIC if not called by the host app
* param hermesEnabled
* hermesEnabled = true sets the JS Engine as HERMES and JSC otherwise
*/
public ReactInstanceManagerBuilder setJsEngineAsHermes(boolean hermesEnabled){
if(hermesEnabled){
setJSEngine(JSInterpreter.HERMES);
}
else{
setJSEngine(JSInterpreter.JSC);
}
return this;
}
```
The code snippet for the new logic in **ReactInstanceManagerBuilder**:
1) Setting up the new logic:
Adding a new enum class :
```
public enum JSInterpreter {
OLD_LOGIC,
JSC,
HERMES
}
```
A setter getting boolean value telling whether to use hermes or not and calling a private setter to update the enum variable.
```
/**
* Sets the jsEngine as JSC or HERMES as per the setJsEngineAsHermes call
* Uses the enum {link JSInterpreter}
* param jsEngine
*/
private void setJSEngine(JSInterpreter jsEngine){
this.jsEngine = jsEngine;
}
/**
* Utility setter to set the required JSEngine as HERMES or JSC
* Defaults to OLD_LOGIC if not called by the host app
* param hermesEnabled
* hermesEnabled = true sets the JS Engine as HERMES and JSC otherwise
*/
public ReactInstanceManagerBuilder setJsEngineAsHermes(boolean hermesEnabled){
if(hermesEnabled){
setJSEngine(JSInterpreter.HERMES);
}
else{
setJSEngine(JSInterpreter.JSC);
}
return this;
}
```
2) Modifying the getDefaultJSExecutorFactory method to incorporate the new logic with the old one:
```
private JavaScriptExecutorFactory getDefaultJSExecutorFactory(
String appName, String deviceName, Context applicationContext) {
// Relying solely on try catch block and loading jsc even when
// project is using hermes can lead to launch-time crashes especially in
// monorepo architectures and hybrid apps using both native android
// and react native.
// So we can use the value of enableHermes received by the constructor
// to decide which library to load at launch
// if nothing is specified, use old loading method
// else load the required engine
if (jsEngine == JSInterpreter.OLD_LOGIC) {
try {
// If JSC is included, use it as normal
initializeSoLoaderIfNecessary(applicationContext);
JSCExecutor.loadLibrary();
return new JSCExecutorFactory(appName, deviceName);
} catch (UnsatisfiedLinkError jscE) {
if (jscE.getMessage().contains("__cxa_bad_typeid")) {
throw jscE;
}
HermesExecutor.loadLibrary();
return new HermesExecutorFactory();
}
} else if (jsEngine == JSInterpreter.HERMES) {
HermesExecutor.loadLibrary();
return new HermesExecutorFactory();
} else {
JSCExecutor.loadLibrary();
return new JSCExecutorFactory(appName, deviceName);
}
}
```
### **Suggested changes in any Android App's MainApplication that extends ReactApplication to take advantage of this fix**
```
builder = ReactInstanceManager.builder()
.setApplication(this)
.setJsEngineAsHermes(BuildConfig.HERMES_ENABLED)
.setBundleAssetName("index.android.bundle")
.setJSMainModulePath("index")
```
where HERMES_ENABLED is a buildConfigField based on the enableHermes flag in build.gradle:
`def enableHermes = project.ext.react.get("enableHermes", true)
`
and then
```
defaultConfig{
if(enableHermes) {
buildConfigField("boolean", "HERMES_ENABLED", "true")
}
else{
buildConfigField("boolean", "HERMES_ENABLED", "false")
}
}
```
Our app was facing a similar issue as listed in this list: **https://github.com/facebook/react-native/issues?q=is%3Aissue+is%3Aopen+DSO**. Which was react-native trying to load jsc even when our project used hermes when a debug build was deployed on a device using android studio play button.
This change can possibly solve many of the issues listed in the list as it solved ours.
## Changelog
[GENERAL] [ADDED] - An enum JSInterpreter in com.facebook.react package:
```
/**
* An enum that specifies the JS Engine to be used in the app
* Old Logic uses the legacy code
* JSC/HERMES loads the respective engine using the revamped logic
*/
public enum JSInterpreter {
OLD_LOGIC,
JSC,
HERMES
}
```
[GENERAL] [ADDED] - An enum variable storing the default value of Js Engine loading mechanism in ReactInstanceManagerBuilder:
```
private JSInterpreter jsEngine = JSInterpreter.OLD_LOGIC;
```
[GENERAL] [ADDED] - A new setter method and a helper method to set the js engine in ReactInstanceManagerBuilder:
```
/**
* Sets the jsEngine as JSC or HERMES as per the setJsEngineAsHermes call
* Uses the enum {link JSInterpreter}
* param jsEngine
*/
private void setJSEngine(JSInterpreter jsEngine){
this.jsEngine = jsEngine;
}
/**
* Utility setter to set the required JSEngine as HERMES or JSC
* Defaults to OLD_LOGIC if not called by the host app
* param hermesEnabled
* hermesEnabled = true sets the JS Engine as HERMES and JSC otherwise
*/
public ReactInstanceManagerBuilder setJsEngineAsHermes(boolean hermesEnabled){
if(hermesEnabled){
setJSEngine(JSInterpreter.HERMES);
}
else{
setJSEngine(JSInterpreter.JSC);
}
return this;
}
```
[GENERAL] [ADDED] - Modified **getDefaultJSExecutorFactory** method
```
private JavaScriptExecutorFactory getDefaultJSExecutorFactory(
String appName, String deviceName, Context applicationContext) {
// Relying solely on try catch block and loading jsc even when
// project is using hermes can lead to launch-time crashes especially in
// monorepo architectures and hybrid apps using both native android
// and react native.
// So we can use the value of enableHermes received by the constructor
// to decide which library to load at launch
// if nothing is specified, use old loading method
// else load the required engine
if (jsEngine == JSInterpreter.OLD_LOGIC) {
try {
// If JSC is included, use it as normal
initializeSoLoaderIfNecessary(applicationContext);
JSCExecutor.loadLibrary();
return new JSCExecutorFactory(appName, deviceName);
} catch (UnsatisfiedLinkError jscE) {
if (jscE.getMessage().contains("__cxa_bad_typeid")) {
throw jscE;
}
HermesExecutor.loadLibrary();
return new HermesExecutorFactory();
}
} else if (jsEngine == JSInterpreter.HERMES) {
HermesExecutor.loadLibrary();
return new HermesExecutorFactory();
} else {
JSCExecutor.loadLibrary();
return new JSCExecutorFactory(appName, deviceName);
}
}
```
Pull Request resolved: https://github.com/facebook/react-native/pull/33952
Test Plan:
The testing for this change might be tricky but can be done by following the reproduction steps in the issues related to DSO loading here: https://github.com/facebook/react-native/issues?q=is%3Aissue+is%3Aopen+DSO
Generally, the app will not crash anymore on deploying debug using android studio if we are removing libjsc and its related libraries in **packagingOptions** in build.gradle and using hermes in the project.
It can be like:
```
packagingOptions {
if (enableHermes) {
exclude "**/libjsc*.so"
}
}
```
Reviewed By: lunaleaps
Differential Revision: D37191981
Pulled By: cortinico
fbshipit-source-id: c528ead126939f1d788af7523f3798ed2a14f36e
Summary:
Changelog: [Internal] Fixing a recent optimization to prevent event dispatches for events that are not listened for. An incorrect hitpath was passed in for `leave` events.
Refactored the PointerEvent optimization such that `filterByShouldDispatch` determines what views should dispatch a PointerEvent, and `dispatchEventForViewTargets` to actually dispatch them. We are separating this because the order of dispatch differs between `enter` and `leave` events.
Reviewed By: vincentriemer
Differential Revision: D37348726
fbshipit-source-id: a09a04df3ae027cce95e0d93a4163c2015fe3fe3
Summary:
We need to check that the animated node exists prior to executing the animation. The native animated node lifecycle is not synced with Fabric and nodes are frequently destroyed and re-created on rerenders. Therefore, there is a possibility that the the animated node does not exist when the native event is dispatched, in particular with native call batching.
Changelog:
[Internal] - Make NativeAnimatedNodesManager.getNodeById public
Reviewed By: JoshuaGross
Differential Revision: D37323138
fbshipit-source-id: ed0567871b4189c454b6b3145b853ecdfe844840
Summary:
This improves errors significantly, which is especially helpful as the runtime scheduler only implements a subset of the JS API.
Example error: `Error: Exception in HostObject::get for prop 'unstable_next': undefined property`
Changelog: [Internal]
Reviewed By: rickhanlonii
Differential Revision: D37313924
fbshipit-source-id: b53bc67b9cc36dee34dba86c07fdcf2353338c72
Summary:
As we changed the deps for react-native/eslint-plugin-specs, let's release a new version of it.
Changelog:
[General] [Changed] - Bump react-native/eslint-plugin-specs to 0.0.4
Reviewed By: jacdebug
Differential Revision: D37353474
fbshipit-source-id: dc77c987ee06d72903d246544c63816a64ecd7f6
Summary: Add annotations to function parameters required for Flow's Local Type Inference project. This codemod prepares the codebase to match Flow's new typechecking algorithm. The new algorithm will make Flow more reliable and predicatable.
Reviewed By: bradzacher
Differential Revision: D37363351
fbshipit-source-id: a9d3df7db6f9d094ac2ce81aae1f3ab4f62b243a
Summary: Add annotations to function parameters required for Flow's Local Type Inference project. This codemod prepares the codebase to match Flow's new typechecking algorithm. The new algorithm will make Flow more reliable and predicatable.
Reviewed By: evanyeung
Differential Revision: D37353648
fbshipit-source-id: e5a0c685ced85a8ff353d578b373f836b376bb28
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34049
This just flips the switch for having Hermes on by default
on new projects for React Native.
Changelog:
[Android] [Changed] - Make Hermes the default engine on Android
Reviewed By: neildhar, jpporto
Differential Revision: D37354079
fbshipit-source-id: cb0391eb3927d13432e7d4b9efef7b8812938a98
Summary:
This removes the `hermes-engine` NPM package from the RN package.json.
Users are not supposed to use this package anymore as we now ship Hermes
bundled with React Native.
More on this here: https://reactnative.dev/architecture/bundled-hermes
Changelog:
[General] [Changed] - Do not depend on hermes-engine NPM package anymore
Reviewed By: neildhar
Differential Revision: D37353977
fbshipit-source-id: b049d18e945a72c1f37c3e4b040af83b5e395774
Summary: Add annotations to function parameters required for Flow's Local Type Inference project. This codemod prepares the codebase to match Flow's new typechecking algorithm. The new algorithm will make Flow more reliable and predicatable.
Reviewed By: evanyeung
Differential Revision: D37360113
fbshipit-source-id: 870bcfe680542b3861fefbaf372db0ae8b32cbf3
Summary:
ThemedReactContext should be what is stored as the context on all RN views, but some legacy components use other things like an Activity.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D37356865
fbshipit-source-id: bc914cd06a8846037506a50f254995a6e10c8a9c
Summary:
[`babel-eslint`](https://github.com/babel/babel-eslint) is deprecated now. We should use the new Babel parser.
## 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] - Use new Babel parser instead of deprecated one
Pull Request resolved: https://github.com/facebook/react-native/pull/34020
Test Plan: Ensure lint is working as expected.
Reviewed By: cortinico
Differential Revision: D37239826
Pulled By: jacdebug
fbshipit-source-id: f5fa5d7f829d6d3ae5cffd855ed6c8542c7d46de
Summary:
This PR is a follow up for the contributing content move on the website:
* https://github.com/facebook/react-native-website/pull/3120
It replaces most of the CONTRIBUTING file content with a reference to the contributing overview page on the website, which has been based off the content of this file.
Additionally I have searched thought the code for the wiki links and replaces theme with the correct website links. There was an instance where comment was referring to an old and removed a while ago wiki page, so I just get rid of this link.
## Changelog
[Internal] [Chore] - Update CONTRIBUTING.md, replace wiki links
Pull Request resolved: https://github.com/facebook/react-native/pull/34035
Test Plan: N/A
Reviewed By: lunaleaps
Differential Revision: D37318814
Pulled By: cortinico
fbshipit-source-id: d3f5e5c5bd477c0de5c4f0f1d5de81f464b9f5b4
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
-->
[Internal] - Changelog for 0.69.0
Pull Request resolved: https://github.com/facebook/react-native/pull/33730
Reviewed By: lunaleaps
Differential Revision: D36007445
Pulled By: cortinico
fbshipit-source-id: adb9070a83b992f7138e93710a0508be59f07832
Summary:
Fix crashes that can occur on older versions of Android due to not-yet-implemented APIs.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D37321713
fbshipit-source-id: a27aaf4b28e19a86f4cb10808162102177b9f306
Summary:
Bumping RTC-Folly version used to address CVE-2022-24440.
## 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][Security] - Bump RTC-Folly to 2021-07-22
Pull Request resolved: https://github.com/facebook/react-native/pull/33841
Reviewed By: Andjeliko, philIip
Differential Revision: D36425598
Pulled By: cortinico
fbshipit-source-id: d38c5f020dbecf794b10f12ed2da30e1825071af
Summary:
Original commit changeset: 78387999f94e
Original Phabricator Diff: D34392529 (https://github.com/facebook/react-native/commit/086c13dd5fba3f77acbc70c9bdedc9299118b526)
Backing this out because it breaks univeral hot reload support. We should probably find a way to support this *without* relying on swizzling. This was originally backed out it because it was blocking app store submission, but this is gated by `RN_DEV` so should never be included in a release build.
Changelog:
[General][Removed] - The diffs renames the required variable which was causing conflicts in names with Apple core SDK's
Reviewed By: cipolleschi
Differential Revision: D37311377
fbshipit-source-id: 18abb1b53a5be054098cd3717705ea5086c4f595
Summary:
# Context
ScrollView sticky headers rely on this bit of code to work:
```
AnimatedImplementation.attachNativeEvent(
this._scrollViewRef,
'onScroll',
[{nativeEvent: {contentOffset: {y: this._scrollAnimatedValue}}}],
);
```
What this code means:
When the ScrollView host component receives the "onScroll" event, assign event.nativeEvent.contentOffSet.y to the this._scrollAnimatedValue AnimatedValue.
How this subscription mechanism is set up:
NativeAnimatedTurboModule subscribes to events dispatched by RCTEventDispatcher sendEvent. Then, whenever RCTEventEmitter sendEvent executes, NativeAnimatedTurboModule also updates the AnimatedValue for that event.
# Problem
Previously, in bridgeless, we started dispatching RCTScrollView via the RCTEventDispatcher sendEvent to update the AnimatedValue for ScrollView. This meant that we started dispatching the onScroll event to JavaScript via RCTEventEmitter.receiveEvent JSModule, which isn't supported in the Fabric renderer.
With this diff, we dialed back that solution. Instead of (1) notifying NativeAnimatedTurboModule and (2) sending the onScroll event to JavaScript, we're only doing (1) (i.e: notifying NativeAnimatedTurboModule).
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D37257719
fbshipit-source-id: 7dea3cf8b9ae78f6b0fd40414b8f224d43367a5a
Summary:
`use_frameworks!` is broken again in react-native 0.69 because React-bridging. in the `use_frameworks!` mode, header structures are flattened, so `#include <react/bridging/CallbackWrapper.h>` is not reachable to the header. to somehow workaround the issue without touch React-bridging imports, the pr do these things:
- use `header_mappings_dir` to keep `react/bridging` header structure
- because the header structure is not default framework header structure, explicitly `HEADER_SEARCH_PATHS` is necessary.
- forward declare `CallbackWrapper` and use it internally in ReactCommon. so that we don't need to add `HEADER_SEARCH_PATHS` for React-bridging to every pods depending on `ReactCommon/turbomodule/core`, e.g. React-RCTSettings.podspec.
## Changelog
[iOS] [Fixed] - Fix use_frameworks! for 0.69
Pull Request resolved: https://github.com/facebook/react-native/pull/34011
Test Plan:
```sh
$ npx react-native init RN069 --version next
# add `use_frameworks!` to ios/Podsfile
# comment out use_flipper!() in ios/Podfile
# patch node_modules/react-native with these changes
$ yarn ios
```
Reviewed By: cortinico, cipolleschi
Differential Revision: D37169699
Pulled By: dmitryrykun
fbshipit-source-id: 309c55f1c611a2fc3902a83e8af814daaf2af6a0
Summary:
This PR is fixing the build errors on iOS when `use_frameworks!` and `:hermes_enabled` are both enabled. There are two errors:
- fmt/compile.h include not found: This PR adds fmt in header search paths.
- undefined symbols `_jump_fcontext` and `_make_fcontext` from boost. the two symbols are actually not be unused. because to generate the shared library in dynamic framework mode, LTO (Link-Time-Optimization) is not as powerful as generating a single executable.
## Changelog
[iOS] [Fixed] - Fix RCT-Folly build error when use_frameworks! and hermes are both enabled
Pull Request resolved: https://github.com/facebook/react-native/pull/34030
Test Plan:
- CI passed
-
```
$ npx react-native init RN069 --version next
# edit RN069/ios/Podfile to enable use_frameworks! and hermes_enabled
# patch node_modules/react-native from both https://github.com/facebook/react-native/issues/34011 and this prs' patch
$ pod install
$ yarn ios
```
Reviewed By: cortinico
Differential Revision: D37284084
Pulled By: dmitryrykun
fbshipit-source-id: 923fa03d7844d1d227880919c8b2c8614c848d59
Summary:
Rewrites `EventEmitter` as a simple, type-safe abstraction with a minimal interface.
The public interface of `EventEmitter` is unchanged. This rewrite was made possible only after deprecating and removing public methods that imposed restrictions on implementation details (e.g. deleting `removeListener`).
However, this includes a subtle breaking change that makes it behave the same as `EventEmitter` in Node.js and `EventTarget` in the DOM. The set of listeners being notified by `emit` will no longer be influenced by changes made during the course of notifying the existing listeners.
Changelog:
[General][Changed] - `EventEmitter#emit` now freezes the set of listeners before iterating over them, meaning listeners that are added or removed will not affect that iteration.
Reviewed By: javache
Differential Revision: D22153962
fbshipit-source-id: 81b87113590dee0296eff61374bf732171855453
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33990
This diff moves the setting of some CPP flags from the main React native pods file to a dedicated file.
It also introduces some tests and it improves the Test Mocks we have
## Changelog
[iOS][Changed] - Move the `modify_flags_for_new_architecture` method to separate ruby file
Reviewed By: cortinico
Differential Revision: D37040927
fbshipit-source-id: 037ddaf123d01f3a2fd622b8a0cd10535da70b92
Summary:
Currently `ListHeaderComponent` & `ListFooterComponent` allow to use React Componetn & Elemelen
```tsx
<FlatList
ListHeaderComponent={<View />} // valid
ListHeaderComponent={View} // valid
/>
```
But when you try to pass `ItemSeparatorComponent` as React Element it will throw an error
```tsx
<FlatList
ItemSeparatorComponent={View} // ok
ItemSeparatorComponent={<View />} /* not valid:
Error: Element type is invalid: expected a string (for built-in components) or a class/function
(for composite components) but got: object.
Check the render method of `CellRenderer`.
*/
/>
```
So, this PR adds this ability
## 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 ability to pass `ItemSeparatorComponent` as React Element
Pull Request resolved: https://github.com/facebook/react-native/pull/32748
Test Plan: ...
Reviewed By: lyahdav
Differential Revision: D37227719
Pulled By: cortinico
fbshipit-source-id: 1c4943fa9d42bf5e61fbd999d1f5be46b51ecb14
Summary:
Fixes a trivial crash that occurs when running View Recycling on pre-Android P devices.
Changelog: [Internal]
Reviewed By: bvanderhoof
Differential Revision: D37242858
fbshipit-source-id: 74f3912d60799172c47c67a87f662b4ff8fb1e35
Summary:
LogBox was using AppRegistry to render on to the screen. Switch LogBox over to using SurfaceRegistry instead.
Changelog: [Internal]
Reviewed By: sshic
Differential Revision: D37223641
fbshipit-source-id: 59001ad290c1e2c2f14828d38a96f48bd1ab39ca
Summary:
Original commit changeset: 4c0afc95abe8
Original Phabricator Diff: D37155957 (https://github.com/facebook/react-native/commit/d1321d88bdc80b209aeb781991d8143d6ce2f9a9)
See attached UBN task for more details, I am reverting the whole diff now while investigating the root cause.
Changelog:
[General][Changed] - Revert "React Native sync for revisions d300ceb...256aefb"
jest_e2e[run_all_tests]
=== update
klein did a bisect for S276290, it seems Original Phabricator Diff: D37155957 (https://github.com/facebook/react-native/commit/d1321d88bdc80b209aeb781991d8143d6ce2f9a9) is the blame diff.
jackworden also has verified backout can fix it for both ios and android.
Reviewed By: ahujap-fb, kacieb
Differential Revision: D37205394
fbshipit-source-id: 600e6593532da064631c016aace317932f290c67
Summary:
`hermes-eslint` is built by Meta to work with the latest Flow code.
It follows the latest ESLint standards and AST, and has a true scope analyser to ensure best compatibility with core ESLint rules.
Reviewed By: motiz88
Differential Revision: D37181192
fbshipit-source-id: 1f59e01f306792e67a4977435c5c77e0000d960a
Summary:
See commentary at top of stack.
Changelog: [Added][Fabric] New API for efficient props construction
Reviewed By: javache
Differential Revision: D37051020
fbshipit-source-id: 643e433c0d0590cfcd17bc7a43d105bed6ff12ef
Summary:
See commentary at top of stack.
Changelog: [Added][Fabric] New API for efficient props construction
Reviewed By: javache
Differential Revision: D37050961
fbshipit-source-id: 170a09c08d7406b6aac51d7e78cf295a72fdcf91
Summary:
See commentary at top of stack.
Changelog: [Added][Fabric] New API for efficient props construction
Reviewed By: javache
Differential Revision: D37050376
fbshipit-source-id: 2bea35a6d604704cf430bd3b2914988227d1abf8
Summary:
Perf numbers for this stack are given in terms of before-stack and after-stack, but the changes are split up for ease of review, and also to show that this migration CAN happen per-component and is 100% opt-in. Most existing C++ components do not /need/ to change at all.
# Problem Statement
During certain renders (select critical scenarios in specific products), UIManagerBinding::createNode time takes over 50% of JS thread CPU time. This could be higher or lower depending on the specific product and interaction, but overall createNode takes a lot of CPU time. The question is: can we improve this? What is the minimal overhead needed?
The vast, vast majority of time is taken up by prop parsing (specifically, converting JS values across the JSI into concrete values on the C++ props structs). Other methods like appendChild, etc, do not take up a significant amount of time; so we conclude that createNode is special, and the JSI itself, or calling into C++, is not the problem. Props parsing is the perf problem.
Can we improve it? (Spoiler: yes)
# How does props parsing work today?
Today, props parsing works as follows:
1. The ConcreteComponentDescriptor will construct a RawPropsParser (one per component /type/, per application: so one for View, one for Image, one for Text... etc)
2. Once per component type per application, ConcreteComponentDescriptor will call "prepare" on the RawPropsParser with an empty, default-constructed ConcreteProps struct. This ConcreteProps struct will cause RawProps.at(field) for every single field.
3. Based on the RawProps::at calls in part 2, RawPropsParser constructs a Map from props string names (width, height, position, etc) to a position within a "value index" array.
4. The above is what happens before any actual props are parsed; and the RawPropsParser is now ready to parse actual Props.
5. When props are actually being parsed from a JSI dictionary, we now have two phases:
1. The RawPropsParser `preparse`s the RawProps, by iterating over the JSI map and filling in two additional data structures: a linear list of RawValues, and a mapping from the ValueIndex array (`keyIndexToValueIndex_`; see step 3) to a value's position in the values list (`value_` in RawPropsParser/RawProps);
2. The ConcretePropT constructor is called, which is the same as in step 2/3, which calls `fieldValue = rawProps.at("fieldName")` repeatedly.
3. For each `at` call, the RawProps will look up a prop name in the Map constructed in step 3, and either return an empty value, or map the key name to the `keyIndexToValueIndex_` array, which maps to a value in `values_`, which is then returned and further parsed.
So, a few things that become clear with the current architecture:
1. Complexity is a property of the number of /possible/ props that /can/ be parsed, not what is actually used in product code. This violates the "only pay for what you use" principal. If you have `<View opacity={0.5} />`, the ViewProps constructor will request ~170 properties, not 1!
2. There's a lot of pre-parsing which isn't free
3. The levels of indirection aren't free, and make cache misses more likely and pipelining is more challenging
4. The levels of indirection also require more memory - minor, but not free
# How can we improve it?
The goal is to improve props parsing with minimal or zero impact on backwards-compability. We should be able to migrate over components when it's clear there's a performance issue, without requiring everything gets migrated over at once. This both (1) helps us prove out the new architecture, (2) derisks the project, (3) gives us time, internally and externally, to perfect the APIs and gradually migrate everything over before deleting the old infrastructure code entirely.
Thus, the goal is to do something that introduces a zero-cost abstraction. This isn't entirely possible in practice, and in fact this method slightly regresses components that do not use the new architecture /at all/, while dramatically improving migrated components and causing the impact of the /old/ architecture to be minimal.
# Solution
1. We still keep the existing system in place entirely.
2. After Props are constructed (see ConcreteComponentDescriptor changes) we iterate over all the /values/ set from JS, and call PropsT::setProp. Incidentally, this allows us to easily reuse the same prop for multiple values for "free", which was expensive in the old system.
3. It's worth noting that this makes a Props struct "less immutable" than it was before, and essentially now we have a "builder pattern" for Props. (If we really wanted to, we could still require a single constructor for Props, and then actually use an intermediate PropsBuilder to accumulate values - but I don't think this overhead would be worth for the conceptual "immutability" win, and instead a "Construct/Set/Seal" model works fine, and we still have all the same guarantees of immutability after the parsing phase)
# Implementation Details
# How to properly construct a single Prop value
Minor detail: parsing a single prop is a 3-step process. We imagine two scenarios: (1) Creating a new ShadowNode/Props A from nothing/void, so the previous Props value is just the default constructor. (2) Cloning a ShadowNode A->B and therefore Props A must be copied to Props B before parsing.
We will denote this as a clone from A->B, where A may or may not be a previous node or a default-constructed Props node; and imagine in particular that we're setting the "opacity" value for PropsB.
We must first (1) copy a value over from the previous version of the Props struct, so B.opacity = A.opacity; (2) Determine if opacity has been set from JS. If so, and there is a value, B.opacity = parse(JSValue). (3) If JS has passed in a value for the prop, BUT the value is `null`, it means that JS is resetting or deleting the prop, so we must set it BACK to the default. In this case we set PropsB.opacity = DefaultConstructedProps.opacity.
We must take care in general to ensure that the correct behavior is achieved here, which should help to explain some of the code below.
## String comparisons vs hash comparisons
In the previous system, a RawPropsKey is three `const char*` strings, concatenated together repeatedly /at runtime/. In practice, the ONLY reason we have the prefix, name, suffix Key structure is for the templated prop parsing in ViewProps and YogaStyableProps - that's it. It's not used anywhere else. Further, the key {"margin", "Left", "Width"} is identical to the key {"marginLeftWidth", null, null} and we don't do anything fancy with matching prefixes before comparing the whole string, or similar. Before comparison, keys are concatenated into a single string and then we use `strcmp`. The performance of this isn't terrible, but it's nonzero overhead.
I think we can do better and it's sufficient to compare hashed string values; even better, we can construct most of these /at compile time/ using constexpr, and using `switch` statements guarantee no hash collisions within a single Props struct (it's possible there's a collision between Props.cpp and ViewProps.cpp, for example, since they're different switch statements). We may eventually want to be more robust against has collisions; I personally don't find the risk to be too great, hash collisions with these keys are exceedingly unlikely (or maybe I just like to live dangerously). Thus, at runtime, each setProp requires computing a single hash for the value coming from JS, and then int comparisons with a bunch of pre-compiled values.
If we want to be really paranoid, we could be robust to hash collisions by doing `switch COMPILED_HASH("opacity"): if (strcmp(strFromJs, "opacity") == 0)`. I'm happy to do this if there's enough concern.
## Macros
Yuck! I'm using lots of C preprocessor macros. In general I found this way, way easier in reducing code and (essentially) doing codegen for me vs templated code for the switch cases and hashing prop names at compile-time. Maybe there's a better way.
Changelog: [Added][Fabric] New API for efficient props construction
Reviewed By: javache
Differential Revision: D37050215
fbshipit-source-id: d2dcd351a93b9715cfeb5197eb0d6f9194ec6eb9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34015
I noticed this was a very slow part of my build because each instance of the binary would run its own yarn install. Instead use the yarn_workspace approach to share a single yarn setup.
Changelog: [Internal]
Reviewed By: IanChilds
Differential Revision: D37178005
fbshipit-source-id: cba51e168c5a2f2ee6468acb8c144db4ad352d95
Summary:
A huge set of props use YGValue directly, say something really basic like `margin`/`position`/`padding`/`border`.
All of these according to CSS spec actually support `number | "em" | "px" | %` units, but we are going to throw and hard crash on `em` and `px`, which are unsupported in React Native.
Using `tryTo` instead of `to` (noexcept vs throwing method) for conversion, and treating things like `margin: 50px` same way as we would treat `margin: false` which is not really supported.
Changelog:
[General][Fixed] - Fixed a crash on deserialization of props when using 'px'/'em' units.
Reviewed By: bvanderhoof
Differential Revision: D37163250
fbshipit-source-id: 59cbe65a821052f6c7e9588b6d4a0ac14e344684
Summary: Some files relying on -include_pch and therefore they miss Foundation.h and UIKit.h includes. This diff is fixing missing imports
Reviewed By: rmaz
Differential Revision: D37140239
fbshipit-source-id: bc57921e0c8365e0e9a5a571d607ba40ff1b31f3
Summary:
Changelog: [Internal][Changed]
The diff I'm backing out accidentally made Hover events in Felios apps that use RN under the hood stopped working in headsets (Oculus, Arcata). So we can't test our apps properly without these events.
We, with the diff author Luna tried to fix that but it turned out to be not easy so we decided to revert the commit in order to unblock experiences teams.
Original commit changeset: d6b5c32ae50b
Original Phabricator Diff: D36601638 (https://github.com/facebook/react-native/commit/40769f2212dcd85cba2e54973179c7de445499a4)
(Note: this ignores all push blocking failures!)
Reviewed By: arhelmus
Differential Revision: D37135208
fbshipit-source-id: 4f7d5f168b795690e951ce7063ae3feec3338772
Summary:
Adds support for handling animations in response to events on the platform side, without needing a JS round trip. With this TM, NativeViewEvents will no longer affected by JS thread - hover events will not be delayed when JS thread is busy. This makes a significant difference for VR panel apps - see test plan for an example for the before and after in Store.
Changelog:
[Internal] - Make NativeAnimatedNodesManager public
Reviewed By: JoshuaGross
Differential Revision: D37082069
fbshipit-source-id: 330acd78c547587de5545b61895e0d821fb99552
Summary:
We currently wrap colors in an object to make it look similar to a `PlatformColor` object, but since this is a hot codepath, let's just optimize it to a simple array of strings. The next step is to apply a layer of caching here, but this should be a simple improvement.
Changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D31057046
fbshipit-source-id: f68e17167ddd5bba3b545d039600c7c9b40808f5
Summary:
In https://github.com/facebook/react-native/pull/32695, the `Performance.now()` implementation changed to use unix epoch timestamps instead of a monotonic clock.
This is problematic, because it means that performance measurements get skewed if the device clock changes between two measurements.
With this change, the clock is now monotonic (and the implementation stays consistent between platforms).
More details and repro steps can be found in [this issue](https://github.com/facebook/react-native/issues/33977)
Closes https://github.com/facebook/react-native/issues/33977
## Changelog
[General] [Fixed] - Use monotonic clock for performance.now()
Pull Request resolved: https://github.com/facebook/react-native/pull/33983
Test Plan:
Run on iOS and Android:
```
const now = global.performance.now()
console.log(`${Platform.OS}: ${now}`)
```
Reviewed By: JoshuaGross, cipolleschi
Differential Revision: D37066999
Pulled By: dmitryrykun
fbshipit-source-id: 298547bf39faea1b025c17ff2d2e1a03f929865b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33982
This Diff moves another part of the utilities from the `react_native_pods` file to a specific `utils.rb` file.
It adds tests for these utils and improve our test mocks.
The goal is to simplify the `react_native_pods.rb` so it's easier to work with it.
I decided to split this diff in 2 because it was becoming quite big.
## Changelog
[iOS][Changed] - Refactoring part of the react_native_pods.rb script
Reviewed By: cortinico
Differential Revision: D37006265
fbshipit-source-id: ffaac3270cb098fa30b73c97ce7cd350dfb8d7d6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33978
This Diff moves part of the utilities from the `react_native_pods` file to a specific `utils.rb` file.
It adds tests for these utils and improve our test mocks.
The goal is to simplify the `react_native_pods.rb` so it's easier to work with it.
I decided to split this diff in 2 because it was becoming quite big.
## Changelog
[iOS][Changed] - Refactoring part of the react_native_pods.rb script
Reviewed By: cortinico
Differential Revision: D37004347
fbshipit-source-id: a5156f7c199d082d5d895a58af80948556c51c2a
Summary:
Reverts https://github.com/facebook/react-native/pull/29012
It is not really possible to properly validate if ENTRY_FILE exists since it is resolved by metro, and the server is not always running from the app root, like in a monorepo with multiple RN apps running on the same metro server.
In my case I run metro on the repo root and entry file will be something like `apps/app/index.js`. `-f "$ENTRY_FILE"` will fail since the script is run from the project folder (`PROJECT_ROOT`, in my case the `apps/app` folder, so it tries to resolve `apps/app/apps/app/index.js`).
I don't think this check is actually useful since metro will report the error if the entry file is invalid (fixed in https://github.com/facebook/react-native/pull/30150). The error is not as user friendly, but I think it is still fine. Maybe it could be improved in metro.
## Changelog
[iOS] [Fixed] - Don't validate ENTRY_FILE in react-native-xcode.sh
Pull Request resolved: https://github.com/facebook/react-native/pull/32762
Test Plan:
Before
<img width="854" alt="image" src="https://user-images.githubusercontent.com/2677334/146100834-39310c9f-1767-496a-8698-1026726a1120.png">
After if file is actually missing
<img width="987" alt="image" src="https://user-images.githubusercontent.com/2677334/146100893-d01e2247-c787-4174-ac60-2f308c338c8f.png">
After if file exists, builds successfully.
Reviewed By: cortinico
Differential Revision: D37066073
Pulled By: cipolleschi
fbshipit-source-id: 8f6b149099a39d9179996bb965daa6cd9e06feac
Summary:
Please see this issue https://github.com/facebook/react-native/issues/33034 for details on the problem solved by this PR.
## 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] [TYPE] - Message
[ios] [changed] - HTTP Response headers added to the error object passed to JS code.
Pull Request resolved: https://github.com/facebook/react-native/pull/33880
Test Plan:
Tested:
(All tests done on images in rn-tester app, which is a part of this repo)
1. onError method in case image has an HTTP Error
2. onError method in case of non http error (DNS error)
3. Successful image load
Reviewed By: cortinico
Differential Revision: D37066159
Pulled By: cipolleschi
fbshipit-source-id: 546f7678fa0321fe6c6fbef55288715cb6ddc2fd
Summary:
The idea behind this is to encapsulate as much build logic as possible inside a `.cmake` file which is contained inside React Native.
This reduces the API surface for the users, once we apply this change to the `template` project, and makes easier for us to evolve native library dependencies on Android, without having to worry about asking users to replicate those changes.
Currently the change is only on RN Tester, will replicate to the template afterwards
## Changelog
[Internal] [Changed] - Encapsulate all the CMake build logic inside a `ReactNative-application.cmake` file for RN Tester
Pull Request resolved: https://github.com/facebook/react-native/pull/33985
Test Plan: Circle CI
Reviewed By: cipolleschi
Differential Revision: D37039658
Pulled By: cortinico
fbshipit-source-id: 536593e3b7227158acba3f0fb6561efaaa9720a5
Summary:
Changelog:
[Internal][Fixed] - https://github.com/facebook/react-native/pull/33973 breaks the internal CI, as it depends on the outdated offline mirror for `Pods/Target Support Files`.
Reviewed By: cortinico
Differential Revision: D37038213
fbshipit-source-id: 1d27c9c32f2c3ddecd15a83935c520d1e1524b21
Summary:
It turned out the previous attempt to rely on the Event's UIManagerType wasn't sufficient, as not all Fabric touch event had a surfaceId set on them, e.g. Modal etc.
This brings back the UIManagerType detection based on reactTag, but do it only for non-rootView to keep handling touch via the right dispatcher for rootView as well.
Changelog: [Fixed][Android] Bring back non-rootview touch handling based on reactTag
Reviewed By: JoshuaGross, sshic
Differential Revision: D37063335
fbshipit-source-id: 76e2d7ae5f00006c5ecaf50c86920ea6e85155b7
Summary:
TurboCxxModule doesn't use the the default JSI getter that TurboModule offers, and has custom behaviour for `getConstants` which broke the I18nAssets module in the binding experiment.
Changelog: [Internal]
Reviewed By: ryancat
Differential Revision: D37030917
fbshipit-source-id: 187f159abc76f792ad2c7045dc2852d216ea978d
Summary:
[A recent fix](https://github.com/facebook/react-native/pull/33076) to Android to set focusable to true when accessible is true, and this caused several components not to work correctly.
This JS change essentially reverts the default back to Text not being focusable unless it is explicitly set. Android's "auto" behavior is better than setting `accessible=true`, and it's also the behavior React Native has had since accessibility on Android was implemented.
# Wall of Text Explanation
Explanation From Brett's comment [here](https://www.internalfb.com/diff/D35908559?dst_version_fbid=700876567897063&transaction_fbid=477905564133412)
blavalla
Generally speaking, "accessible" in react native maps to "focusable" in Android views, and the default value for "focusabe" for a TextView (and actually all views) is "auto" not "false". The difference here is that "false" is telling the system to explicitly disallow focus on this element, where as "auto" is telling the system that it's up to whatever service is trying to focus to determine if it should or not.
In the case of text, Talkback generally does default to focusing on Text when it's set to "auto", though it also does try to combine this text together with other not-explicitly focusable siblings and roll the focus up to some common ancestor element.
In the case of TetraButton here, I would expect the default behavior would be that the text is "auto" focusable, so Talkback would combine the text here with the parent <TetraPressable> (which is explicitly focusable via accessible="true").
...
[This diff](https://github.com/facebook/react-native/pull/33076) was to fix the issue with "disabled" not properly announcing on text views, which was commonly occuring due to the description-combining feature described above. Basically, when Talkback decides to combine not-explicitly-focusable elements together, it ignores properties like "disabled", "selected", etc. so when combined only the text is transferred.
The "fix" here was to make sure that if disabled was set, that an element was always explicitly focusable so that it wouldn't be eligible to be combined with others. I think that as a general concept makes sense, but the fix actually surfaced an issue that is likely a much older bug.
This line in <Text>
```
accessible={accessible !== false}
```
Is basically always setting accessible="true" unless it's explicitly set to false, and has been in there for years. It was likely added to force text to be accessible by default for iOS. But until [this diff](https://github.com/facebook/react-native/pull/33076) this line was basically a no-op for Android, since setting accessible="true" on text would do nothing at all.
[This diff](https://github.com/facebook/react-native/pull/33076) changed this so that setting accessible="true" worked how you'd expect, by making the view explicitly focusable, which was necessary for the disabled behavior to work properly. But that means that now by default all text views are explicitly focusable on both iOS and Android, and this there is likely many components that were built that don't expect this to be the case.
It doesn't seem like the right fix here is to revert this behavior to its previous state, as it wasn't working how anyone would expect it to if they looked at the code, and it seems like we were relying on some fairly undocumented behavior of Talkback to get it to work how we wanted. If we truly only wanted accessible="true" to be set on all TextViews for iOS, we should be explicit about it and do a platform check before setting that property. If we didn't want this to be iOS-specific, then everything is now actually working as originally intended.
For reference, this is the diff that introduced the default-accessible text - https://www.internalfb.com/diff/D1561326, and the description makes it clear that this was only tested on iOS, and the behavior was explicitly trying to map to iOS norms such as not allowing nested accessible elements.
Changelog:
[Android][Fixed] Make Text not focusable by default
Reviewed By: ryancat
Differential Revision: D36991394
fbshipit-source-id: c45d2ada72bb2d6ffeee6947d676a07fb8899449
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33885
When building Hermes for React Native, point to the React Native JSI location to ensure both React Native and Hermes use the exact same version of JSI.
Changelog:
[iOS] [Changed] - When Hermes is enabled, it will use the same copy of JSI as React Native
Reviewed By: cortinico, cipolleschi
Differential Revision: D36567471
fbshipit-source-id: 97d954ef34007bd31f008fab451512194060d670
Summary:
Allow an arbitrary path to hermes-runtime-darwin-vX.Y.Z.tgz to be specified. This can be used in CI or in local e2e tests to test with Hermes enabled without having a matching GitHub release.
Usage:
```
HERMES_ENGINE_TARBALL_PATH=~/Downloads/hermes- runtime-darwin-v0.69.0.tar.gz \
USE_HERMES=1 \
pod install
```
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D36985477
fbshipit-source-id: 853829c89e6f0ac3f63781c7f290cf3994b8e0cd
Summary:
Changelog: [iOS][Fixed] - `_scrollViewComponentView` is set to `RCTPullToRefreshViewComponentView's` superview:
```
_scrollViewComponentView = [RCTScrollViewComponentView findScrollViewComponentViewForView:self];
```
It should be safe to make it weak.
Reviewed By: javache
Differential Revision: D36998626
fbshipit-source-id: 2130b743d181e15986cb68636d60507a986968e1
Summary:
This fixes an issue in the C++ TurboModule codegen where optional return types would result in a compiler error because they were not being defaulted to `null` when converting to `jsi::Value`.
Changelog:
Internal
Reviewed By: javache
Differential Revision: D36989312
fbshipit-source-id: 525f9ce7a5638ba5a655fa69ba9647978030ab0b
Summary:
This diff adds an assertion to make sure the pending events are enqueued only when the event emitter is null. This is to avoid unexpected workflow when we queue events but we should just dispatch them.
Changelog:
[Android][Internal] - Make sure we only queue events when event emitter is null
Reviewed By: javache
Differential Revision: D36916482
fbshipit-source-id: fff305615b302ece26bc2482c826b74de4f70266
Summary:
`OTHER_CFLAGS` doesn't seem to work when the file is imported from Objc++. This causes flipper to not be included.
## Changelog
[iOS] [Fixed] - Use `GCC_PREPROCESSOR_DEFINITIONS` to set `FB_SONARKIT_ENABLED`
Pull Request resolved: https://github.com/facebook/react-native/pull/33972
Test Plan: Tested the change in an app. Used a breakpoint to see that flipper code is not executed before this change, and is after. Also made sure other `GCC_PREPROCESSOR_DEFINITIONS` set by cocoapods are still properly inherited.
Reviewed By: cipolleschi
Differential Revision: D37001624
Pulled By: dmitryrykun
fbshipit-source-id: 920f3fe368a9fbe2cde9aa1e6d5b3b883c42119d
Summary:
D36784563 (https://github.com/facebook/react-native/commit/ec307e0167deca7f17640cd3c5a60f6be5f47b62) caused some issues with TextInputs with numeric keyboard types not respecting the secureTextEntry prop
Changelog
[Android] [Fixed] - Revert PR 33924 because of issues with TextInputs with numeric keyboard types not respecting the secureTextEntry prop
Reviewed By: makovkastar
Differential Revision: D36994688
fbshipit-source-id: 89cd556ca1cf8fd89560aeb9ead129607b4c13c6
Summary:
D36902220 (https://github.com/facebook/react-native/commit/a04195167bbd8f27c6141c0239a61a345cac5a88) changed Animated to only use value of natively driven nodes on initial render.
However, there remained a case where we could end up with a race condition between Fabric prop update (via SurfaceMountingManager.updateProps) and Animated (via NativeAnimatedNodesManager.runUpdates), when an animation on a node that was created natively is triggered close to render (such as in componentDidUpdate). This happens as Animated and Fabric aren't synchronized, and at the platform level, they do not know each other's state.
Say we have two items, where opacity is used to indicate whether the item is selected. On initial render, A's opacity is set to 1, and animated sets opacity to 1; B's opacity is set to 0, and animated sets opacity to 0. When B is selected (and causes A and B to rerender), A's opacity is now set to null, and animated sets opacity to 0; B's opacity is also now set to null, and animated sets opacity to 1. A's props have changed, and thus the default opacity value of 1 is applied via Fabric, but Animated also sets the opacity to 0 - either may end up being the value visible to the user due to the nondeterministic order of Fabric update props and Animated. This is what is causing T122469354.
This diff addresses this edge case by using the initial prop values for native animated nodes, for subsequent renders, to ensure that values of native animated nodes do not impact rerenders.
This diff also fixes a bug in OCAnimation where translateX/Y values of 0 in transition will result in render props containing translateX/Y instead of transform, resulting in potentially incorrect pressability bounds.
Changelog:
[Internal][Fixed] - Only use initial value of natively driven nodes on render
Reviewed By: JoshuaGross, javache
Differential Revision: D36958882
fbshipit-source-id: 10be2ad91b645fa4b8a4a12808e9299da33aaf7d
Summary:
Changelog:
[Android][Fix] - When `onEndReachedThreshold` is set to 0 `onEndReached` function on `VirtualizedList` properly fires once the user scrolls to the bottom of the list.
Reviewed By: genkikondo
Differential Revision: D36488189
fbshipit-source-id: b95f3291f2957273280696d8840c1e000d669380
Summary:
This change is mostly needed to support the new react-native architecture with Swift. Some private yoga headers end up being included in the swift build and result in compilation failure since swift cannot compile c++ modules. See https://github.com/facebook/react-native/pull/33381.
The most reliable fix is to include all headers as public headers, and add `#ifdef __cplusplus` to those that include c++. This is already what we do for other headers, this applies this to all headers.
Tested in the YogaKitSample, and also in a react-native app.
Changelog:
[iOS] [Changed] - Make all Yoga headers public and add #ifdef __cplusplus
X-link: https://github.com/facebook/yoga/pull/1150
Reviewed By: dmitryrykun
Differential Revision: D36966687
Pulled By: cortinico
fbshipit-source-id: a34a54d56df43ab4934715070bab8e790b9abd39
Summary:
https://github.com/facebook/react-native/commit/3337add547c60b84816ef5dad82f4ead2e8742ef made some changes to method signature but the template wasn't updated. This adds the missing changes.
## Changelog
[Internal] [Fixed] - Pass string by ref in TurboModule template
Pull Request resolved: https://github.com/facebook/react-native/pull/33970
Test Plan: Didn't test the template directly, but the change is trivial.
Reviewed By: cortinico
Differential Revision: D36964481
Pulled By: dmitryrykun
fbshipit-source-id: 561e32f218baf398b8d4d8c77381a2642e22ef42
Summary:
Seems like an obvious typo! Whoops!
Not causing any known issues, but... this should be fixed.
Changelog: [Internal]
Reviewed By: genkikondo
Differential Revision: D36940476
fbshipit-source-id: d534ca3763b1f91e41c56953bf3d665e86db9e2b
Summary:
This diff address an edge case when the pending events are enqueued when the surface is stopped. In this case we will reset map that holds view state to null, which will cause NPE.
Changelog:
[Android][Fixed] - Fix edge case when we enqueue a pending event to views on stopped surface
Reviewed By: javache, gorodscy
Differential Revision: D36912786
fbshipit-source-id: 3ae5a4b08a0a6bf55538d69ac80a101c2c3d899a
Summary:
When tapping on ReactRootView and having Fabric enabled, the touch logic mistakenly dispatch the event to JS via the legacy renderer. This is because the destination was computed based on reactTag (odd = legacy, even = Fabric), but root view tag happens to be always odd (always ends with 1). This change uses the right destination based on what the Event itself tells us, instead of deriving from the reactTag.
Changelog: [Android][Fixed] Fix Fabric touch event dispatching for root views
Reviewed By: JoshuaGross, sshic
Differential Revision: D36917300
fbshipit-source-id: 838b4e135d7df07c37040bd47d71370ff10df067
Summary:
Problem - Error when trying to publish to Apple Store in debug scheme
Error thread - https://github.com/facebook/react-native/issues/31507
## 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] - The diffs renames the required variable which was causing conflicts in names with Apple core SDK's
Pull Request resolved: https://github.com/facebook/react-native/pull/33153
Reviewed By: lunaleaps
Differential Revision: D34392529
Pulled By: sshic
fbshipit-source-id: 78387999f94e0db71f5d3dafff51e58d7d0c1847
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33937
This moves the build of RNTester from Unix Make to CMake
This will serve as a blueprint for users that are looking into using CMake end-to-end in their buildls.
In order to make this possible I had to:
* Add an `Android-prebuilt.cmake` file that works similar to the `Android-prebuilt.mk` for feeding prebuilt .so files to the consumer build.
* Update the codegen to use `JSI_EXPORT` on several objects/classes as CMake has stricter visibility rules than Make
* Update the sample native module in `nativemodule/samples/platform/android/` to use CMake instead of Make
Changelog:
[Internal] [Changed] - Build RN Tester with CMake
Reviewed By: cipolleschi
Differential Revision: D36760309
fbshipit-source-id: b99449a4b824b6c0064e833d4bcd5969b141df70
Summary:
This diff fixes the rendering of transparent borders in RN Android views
The fix clips the view ONLY when there is a border color that's non transparent
This change unifies the rendering of transparent and semitransparent borders for Views between RN Android, iOS and Web
Changelog: [Android][Fix] Fix rendering of transparent borders in RN Android
Reviewed By: JoshuaGross
Differential Revision: D36890856
fbshipit-source-id: 38fc2ae215f136160a73ca470e03fada8cb81ced
Summary:
Changelog:
[iOS][Fixed][Internal] - Protect handlers in RCTNetworking with mutex even if RCTNetworking has been deallocated
# The Logview
We get this error in LogView: `Unhandled JS Exception: Error: Exception in HostFunction: mutex lock failed: Invalid argument`, which is an C++ std::error. "This typically happens when .lock() is called on a mutex that is not yet constructed, or has already been destructed."
# Hypothesis of issue
The LogView says the line that throws this softerror is [RCTNetworking.ios.js](https://github.com/facebook/react-native/blob/8bd3edec88148d0ab1f225d2119435681fbbba33/Libraries/Network/RCTNetworking.ios.js#L87).
Inside RCTNetworking, there's only [one mutex and only one line where is is being used](https://github.com/facebook/react-native/blob/8bd3edec88148d0ab1f225d2119435681fbbba33/Libraries/Network/RCTNetworking.mm#L207-L215
), to protect the _handlers array.
My guess is that RCTNetworking was deallocated, which made `_handlersLock` nil, so it resulted in this error when we tried to lock it.
# This diff
* Add `std::lock_guard<std::mutex> lock(_handlersLock);` to `invalidate()`
* Move `_handlersLock` logic to its own method instead of using a lambda. If `self` is being deallocated, I would guess that this method (`[self prioritizedHandlers]`) would return nil.
Referencing this for correct ways to use lock_guard with mutex: https://devblogs.microsoft.com/oldnewthing/20210709-00/?p=105425
Reviewed By: fkgozali
Differential Revision: D36886233
fbshipit-source-id: 60246f4d9bbc1d834497e4fb8a61d9c0e9623510
Summary:
The current implementation of `throwJSError` places it in jsi.cpp, but
does not actually export it. This means that when JSI is being provided
by a dynamic library, `detail::throwJSError` will not be available.
To fix this, move the definition of `throwJSError` into jsi-inl.h,
similar to all of the other functions in the `detail` namespace. This
uses a roundabout implementation of `throwJSError` in order to avoid
directly using `throw`, which would fail to compile when exceptions are
turned off.
Changelog: [Internal]
Reviewed By: jpporto
Differential Revision: D36873154
fbshipit-source-id: bbea48e0d4d5fd65d67a029ba12e183128b96322
Summary:
D36612758 (https://github.com/facebook/react-native/commit/40f4c662bc7a66e5caea4909d74f435f5b72190c) attempted to remove the check that the animated node was native when fetching animated prop values for render, in order to fix an issue that arises when a node is converted to native before the initial call to render to mount the component, where the initial value is not applied.
However, this causes issues for cases where we call setValue on an animated node soon after render, such as on componentDidUpdate. setValue first updates the animated node value on JS side, then calls the native API setAnimatedNodeValue. The problem is that the next render will then use these updated values in the style props (because we removed the check for native in D36612758 (https://github.com/facebook/react-native/commit/40f4c662bc7a66e5caea4909d74f435f5b72190c)), resulting in a diff in props. Since Animated and Fabric aren't synchronized, there's a race condition between SurfaceMountingManager.updateProps and NativeAnimatedNodesManager.runUpdates
To allow proper rendering of initial values of native animated nodes, and mitigate the issue when calling setValue on an animated node soon after render, during initial render we use the initial values of both native and non-native driven nodes, and on subsequent renders we only use the initial values of non-native driven nodes.
An alternative considered was to add internal state to the nodes themselves (AnimatedProps, AnimatedStyle), but keeping it in sync with the component state is not easy/clean as AnimatedProps can be recreated and reattached at any time for a mounted component.
Changelog:
[Internal][Fixed] - Only use value of natively driven nodes on initial render
Reviewed By: JoshuaGross
Differential Revision: D36902220
fbshipit-source-id: c20f711aa97d18a2ed549b5f90c6296bf19bb327
Summary:
In the constructor we should get the default gravity params (as we did previously) and then never change these; thus, we can also make these fields final. These are used in `initView` during construction and upon recycling to reset vertical and horizontal alignment to their defaults.
Changelog: [Internal]
Reviewed By: genkikondo
Differential Revision: D36885646
fbshipit-source-id: 2f4d0b125b8645a380a08965e08db3ba1f12cae3
Summary:
See also D36889794. This is a very similar idea, except the core problem is that BaseTextProps is accessing the same props as ViewProps; and for ParagraphProps parsing, it first defers to ViewProps' parser and then BaseTextProps. RawPropsParser is optimized to access the same props in the same order, *exactly once*, so if we access a prop out-of-order, or for a second time, that access and the next access are deoptimized. Paragraph/Text, in particular, were quite bad because we did this several times, and each out-of-order access requires scanning /all/ props.
This fixes the issue, at least partially, by (1) pulling all the duplicate accesses to the beginning of BaseTextProps, and (2) accessing them all in the same order as ViewProps, relatively (some props are skipped, but that matters less).
Practically what this means is that now, all of Props' accesses have a cost of O(1) for lookup, or a total of O(n) for all of them; each access is at the n+1 position in the internal RawPropsParser array, so each access is cheap. BaseTextProps' duplicate accesses, even though there are only 4 of them: (1) the first one scans the entire array until we reach the prop in question; (2) the next accesses require scans, but not whole-array scans, since they're in order. (3) The BaseTextProps accesses /after/ the duplicate accesses are all O(1).
tl;dr is that before we had something like O(n*6) cost for BaseTextProps parsing and now it is O(n*2).
Similar to my summary in the last diff: we may want to revisit the RawPropsParser API... but I want to tread gently there, and this gets us a large improvement without major, risky changes.
Empirically, based on a couple of systraces, average time for a single UIManager::createNode called from JS thread, before this stack: 17us. After: 667ns (3% as long). On average, for every 60 createNode calls, we will save 1ms on the UI thread. The savings will be greater for certain screens that use many Views or Text nodes, and lesser for screens that use fewer of these components.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D36890072
fbshipit-source-id: 5d24b986c391d7bb158ed2f43d130a71960837d1
Summary:
Without getting into the weeds too much, RawPropParser "requires" that props be accessed in the same order every time a Props struct is parsed in order to most optimally fetch the values in a linear-ish fashion, basically ensuring that each rawProps.at() call is an O(1) operation, and overall getting all props for a particular component is O(n) in the number of props for a given struct. If props are called out of order, this breaks and worst-case we can end up with an O(n^2) operation.
Unfortunately, calling .at(x) twice with the same prop name triggers the deoptimized behavior. So as much as possible, always fetch exactly once and in the same order every time. In this case, we move initialization of two fields into the constructor body so that we can call .at() a single time instead of twice.
In the debug props of ViewProps I'm also reordering the fields to fetch them in the same order the constructor fetches them in, which will make this (debug-only) method slightly faster.
What's the impact of this? If you dig into the Tracery samples, the average/median RawPropsParser::at takes 1us or less. However, in /every single/ call to createNode for View components, there is at least one RawPropsParser::at call that takes 250+us. This was a huge red flag when analyzing traces, after which it was trivial (for View) to find the offending out-of-order calls. Since this is happening for every View and every type of component that derives from View, that's 1ms lost per every 4 View-type ShadowNodes created by ReactJS. After just 100 views created, that's 25ms. Etc.
There are other out-of-order calls lurking in the codebase that can be addressed separately. Impact scales with the size of the screen, the number of Views they render, etc.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D36889794
fbshipit-source-id: 91e0a7ca39ed10778e60a0f0339a4b4dc8b14436
Summary: Creates a base TurboModule for Catalyst.
Reviewed By: ann-ss
Differential Revision: D36707915
fbshipit-source-id: 9a246f238efdcdde45e0332f7b868478deadf50e
Summary:
I'm backporting PR https://github.com/facebook/react-native/pull/33945 to main
as it was merged on the release branch to unblock 0.69.
Those changes are necessary as Hermes was not being donwloaded at all during `pod install`
on .69 and the app was failing to build with a missing `hermes/hermes.h` import.
Changelog:
[iOS] [Fixed] - Fix Hermes not being properly downloaded during pod install
Reviewed By: hramos
Differential Revision: D36810787
fbshipit-source-id: f898e61b6536dfcfc81feeff740703fbd697b000
Summary:
Right now, when we change the keyboardType on android between between default and email, the value keyboard type stays as email (specially noticeable with the key next to the spacebar, that changes between the comma (`,`) to the at sign (`@`)).
This is because the mask we are using when updating the input is only taking into account the class, and not the flags nor the variations.
We don't apply all masks because it may interfere with flags assigned by other props, like multiline or secure text entry. Therefore, we have created our own mask, taking into account all the variations and flags that the keyboardType prop may set. This may be hard to maintain, since whenever we add any other keyboard type, we have to take these flags into mind.
The error I was trying to fix was in particular regarding going back and forward from email, but this fix may solve other similar issues with other keyboard styles.
## Changelog
[Android] [Fixed] - Fix a bug where the keyboard, once set as email, won't change back to default.
Pull Request resolved: https://github.com/facebook/react-native/pull/33924
Test Plan: In order to test this PR, any test code with a TextInput, and a way to change the value of the keyboardType should work. We should be able to see how the keyboard changes to the correct type without staying, for example, on the email state.
Reviewed By: lunaleaps
Differential Revision: D36784563
Pulled By: makovkastar
fbshipit-source-id: 74d7b61b3c07feea4e4050d7a07603a68b98e835
Summary:
I was reading source code, and I noticed the _subscriptions attribute (and the _clearSubscriptions method) of the FileReader is not used.
## 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] - Remove unused _subscriptions attribute in FileReader
Pull Request resolved: https://github.com/facebook/react-native/pull/33946
Test Plan: I checked that flow and jest are still green as I can't think about another way.
Reviewed By: lunaleaps
Differential Revision: D36807828
Pulled By: cortinico
fbshipit-source-id: 9bb599bbc7b79d2b4c010ba84cc8777e29b974ca
Summary:
tldr; `ReactEditText` and Android's emoji support in Android's AppCompat 1.4.0 / 1.4.x conflict in an odd way, causing NPEs.
`ReactEditText` defines an `InternalKeyListener`, `mKeyListener`, that it uses to make sure input from all keyboards works correctly. This listener is normally initialized at the end of the constructor.
Unfortunately, some versions of `AppCompatEditText`, most notably the version in the App Compat `1.4.0-alpha0x`, the [minimum version required for the Play Store's emoji compliance](https://developer.android.com/guide/topics/ui/look-and-feel/emoji2#appcompat) call `setInputType` from `AppCompatEditText`'s constructor. `ReactEditText` operates on the key listener inside of `setInputType` and since the `AppCompatEditText` constructor is called via call to `super` before the key listener is initialized, these versions of app compat can cause NPEs when used with React Native.
The fix is simple; check to see if `mKeyListener` is null, and initialize it if it is. This is necessary in both the constructor and inside of `setInputType`.
## 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
-->
https://github.com/facebook/react-native/wiki/Changelog
[Android] [Fixed] - NPE in `ReactEditText.setInputType` when React Native is used with some versions of a AppCompat 1.4.x. (and possibly others)
Pull Request resolved: https://github.com/facebook/react-native/pull/33920
Test Plan:
1. Build an app with both React Native and load it inside an app that is using AppCompat 1.4.x
2. Add a text field using React Native.
3. Open the screen of the app that contains the text field.
If you're working from this branch, you'll be fine. If you're working from main you'll get an NPE.
I can put together a test repo if needed.
Reviewed By: kacieb
Differential Revision: D36802622
Pulled By: cortinico
fbshipit-source-id: e7646da9a1ef0e0334152aecab0f972ca25092ec
Summary:
The sdks/.hermesversion file should be included inside the React Native NPM package.
While this file is available on the release branch, so it's effectively used during artifact preparation,
the file should also be included inside the react-native NPM package.
This commit addresses it.
Changelog:
[Internal] - Make sure sdks/.hermesversion is included inside the NPM package
Reviewed By: dmitryrykun
Differential Revision: D36785480
fbshipit-source-id: 1152de77818e92814b402a57ca5a05c235747eac
Summary:
Adding a flag to prepare for the phase 3 of the new architecture. This is still work in progress, not usable yet.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D36767843
fbshipit-source-id: 338d775681f2890461608b403749c3a7f05f84ff
Summary:
Followups to View Recycling diffs to improve things / clean up things a bit. This also fixes memory warnings which were not hooked up before.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D36707792
fbshipit-source-id: 410e70bf0eeec5569566138af547e1601394d0e6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33914
Add test coverage for the new hermesc functions in hermes-utils.js
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D36361612
fbshipit-source-id: 270f30917245c8d81baf136d9f58da4d77f7ad55
Summary:
Turns on the ssa env mode in Flow, which supercedes constrained writes with additional fixes
to refinement invalidation.
Reviewed By: SamChou19815
Differential Revision: D36717890
fbshipit-source-id: 20ee963591e8b454458273ac5aa86798e94a8bbd
Summary:
This diff upgrades xplat to 0.178.1 and pre-suppresses errors from turning on constrained writes.
To generate this diff I:
* Modified every `env_mode=constrain_writes` to `env_mode=ssa` and made a commit (this is so our upgrade script will work)
* Ran scripts/flow/upgrade.sh 0.178.1 to upgrade all the flowconfigs to 178.1 and suppress new-env errors
* Modified arvr/js/flowconfig.ejs to use 0.178.1 and ran `scripts/gen-flowconfig/gen-flowconfig --project arvr`
* Modified xplat/js/flowconfig.ejs to use 0.178.1 and ran `scripts/gen-flowconfig/gen-flowconfig --project xplat`
* Unstacked from the commit in point 1
Reviewed By: SamChou19815
Differential Revision: D36676019
fbshipit-source-id: c3032f18ed838afc327f00de563e7f20713bdc26
Summary:
`pod install --project-directory=ios` silently fails to prep Hermes:
```
% pod install --project-directory=ios
[Codegen] Generating ios/build/generated/ios/React-Codegen.podspec.json
[Hermes] Downloading Hermes source code for commit 515e112edc267ad58d3c70991b3d9a721cc66b19
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 9478k 0 9478k 0 0 3939k 0 --:--:-- 0:00:02 --:--:-- 5591k
[Hermes] Expanding Hermes tarball for commit 515e112edc267ad58d3c70991b3d9a721cc66b19
[Hermes] Using pre-built HermesC
[!] One or more resources were not found and will not be included in the project. If they are found later and you want to include them, run `pod install` again.
warn Multiple Podfiles were found: ios/Podfile,macos/Podfile. Choosing ios/Podfile automatically. If you would like to select a different one, you can configure it via "project.ios.sourceDir". You can learn more about it here: https://github.com/react-native-community/cli/blob/master/docs/configuration.md
Auto-linking React Native module for target `ReactTestApp`: ReactTestApp-DevSupport
Analyzing dependencies
Fetching podspec for `DoubleConversion` from `../node_modules/react-native/third-party-podspecs/DoubleConversion.podspec`
[Codegen] Found FBReactNativeSpec
Fetching podspec for `RCT-Folly` from `../node_modules/react-native/third-party-podspecs/RCT-Folly.podspec`
Fetching podspec for `boost` from `../node_modules/react-native/third-party-podspecs/boost.podspec`
Fetching podspec for `glog` from `../node_modules/react-native/third-party-podspecs/glog.podspec`
[!] No podspec found for `hermes-engine` in `../node_modules/react-native/sdks/hermes/hermes-engine.podspec`
% ls -l node_modules/react-native/sdks
total 0
hermes-engine
hermesc
```
## Changelog
[iOS] [Fixed] - `pod install --project-directory=ios` fails when Hermes is enabled
Pull Request resolved: https://github.com/facebook/react-native/pull/33909
Test Plan: Instead of running `pod install` inside `ios` folder, run `pod install --project-directory=ios`.
Reviewed By: cortinico
Differential Revision: D36693625
Pulled By: hramos
fbshipit-source-id: 8757a9c388348276b07c785c211979ec8f2e2f84
Summary:
This target is not a good idea for a number of reasons:
1. It groups up multiple targets which breaks the dependency graph
2. It does not handle dependency remapping correctly
3. It has no mirror into fbcode
We should warn people this is a bad idea
Reviewed By: alexmalyshev
Differential Revision: D36519357
fbshipit-source-id: d60ca3237c7710118732578fecd1b2fc8903321b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33897
Now the exception will display the class which caused the exception as well as helpful information as to why.
We've seen this happen a bunch due and have been very confused by the error message. It turns out that this processor runs before the classes listed are compiled. This means that if there's a compile error (or a missing import) the user will only see that this processor crashed, and not the compile error.
The additional information in the error is:
`java.lang.RuntimeException: Could not load classes set in ReactModuleList.nativeModules. Check that they exist and are imported correctly on class: com.meta.x.y.ReactPackage`
In this case, `com.meta.x.y.ReactPackage` is the class which needs to be fixed. Before, the error message made no mention of this class or the annotation.
Changelog: [Internal] This will change the way the annotation processor crashes. It will throw a RuntimeException instead of a ClassCastException.
Reviewed By: javache
Differential Revision: D36606279
fbshipit-source-id: aedf9682286fba49e23716b7eda16b2dd3b13422
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33915
We don't need to import shelljs as a dependency anymore,
plus we had a duplicated entry in the files array for package.json
Changelog:
[Internal] [Changed] - Remove shelljs dependency and duplicated scripts in files
Reviewed By: dmitryrykun
Differential Revision: D36698750
fbshipit-source-id: 94f449f2c3c5d73d0f9ffd29df6b26f5fd6ef129
Summary:
See previous diff for details on general approach and benchmarks.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D36676887
fbshipit-source-id: b177dcd19f1ea687bf7d2d4f2f637d2924723340
Summary:
Followup task for S271544.
There were no tests covering RTL on FlatLists, which would have prevented the above SEV. Adding an RNTester example for this.
Changelog:
[Internal] - Added RNTester example FlatList with RTL
Reviewed By: lunaleaps, javache
Differential Revision: D36601583
fbshipit-source-id: 054ac4eee876a514152f83ecc0522c62337cfea5
Summary:
When a JavaScript module is not registered as callable, the bridge will throw an error. Let's clean up the error message so that it's more helpful.
Now, it logs the number of registered callable JavaScript modules, as well as the list of callable JavaScript modules.
Changelog: [Internal]
Reviewed By: sshic
Differential Revision: D36646936
fbshipit-source-id: 62d091cda35e296ef9e569b444cd5b6f09b8bc54
Summary:
Changelog: [Internal][Changed] - Make the same optimization on enter/leave/move pointer events being dispatched by a mouse input.
If any ancestor view is listening to enter/leave events (just capture) then we dispatch the enter/leave event.
Reviewed By: vincentriemer
Differential Revision: D36601638
fbshipit-source-id: d6b5c32ae50bcf000100bcb878ca2ca89bd5c02e
Summary:
Upgrade the version of Xcode used in Sandcastle to Xcode 13.3.1, and the version used on Circle CI to Xcode 13.3.1.
Added a reminder to the Circle CI config to ensure we keep these versions in sync in future updates.
Circle CI software manifest: https://circle-macos-docs.s3.amazonaws.com/image-manifest/v7555/index.html
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D36671468
fbshipit-source-id: 8c028915d38738c92b5f759186b0fb95a9274211
Summary:
In AnimatedComponent.render, we get the initial values of any styles backed by AnimatedNode, but ONLY for non-native animations. Thus, if convert an animated node to native before the call to render to mount the component, we will end up not applying the initial value until after the component is mounted. This may result in a visible flicker as the expected value is applied some time after the component is mounted and visible.
- Without native driver: BaseViewManager.setTransform called during view preallocation (ViewManager.createViewInstance)
- With native driver: BaseViewManager.setTransform called during MountingManager.updateProps (called from PropsAnimatedNode.updateView)
This diff removes the isNative check in AnimatedStyle and AnimatedProps when traversing style props. This shouldn't be a problem:
- Created as non-native, animated with JS driver
- This diff does not affect this scenario
- Created as non-native, animated with native driver
- Initial value is applied correctly on render/mount. On subsequent renders, the outdated value from JS side will not apply on the platform view as it has not changed.
- Created as native, animated with native driver
- Initial value is applied correctly on render/mount. On subsequent renders, the outdated value from JS side will not apply on the platform view as it has not changed.
Changelog:
[Internal][Fixed] - Set correct initial value for AnimatedComponent for styles backed by native animated nodes
Reviewed By: JoshuaGross, javache
Differential Revision: D36612758
fbshipit-source-id: 922d6534c605b3eb0a1d9476753111b726f138f2
Summary:
RN-Tester is currently crashing at startup time due to an NPE.
This PR fixes it.
## Changelog
[Android] [Fixed] - Fix NPE on `ReactEditText` due to null mFabricViewStateManager
Pull Request resolved: https://github.com/facebook/react-native/pull/33910
Test Plan: Tested locally that RN Tester runs both in Debug and in Release
Reviewed By: cipolleschi
Differential Revision: D36666440
Pulled By: cortinico
fbshipit-source-id: f004ff228fb4f9ff339aac606858d47de3706426
Summary:
There are two methods in ReactRootView to handle touch events "onInterceptTouchEvent" and "onTouchEvent", for Venice we have ReactSurfaceView inherits ReactRootView but the implementation for above 2 touch handling methods still calls into it's super implementation which uses the bridge.
In this diff we make ReactSurfaceView inherits ReactRootView's "dispatchJSTouchEvent" and "dispatchJSPointerEvent". So that Venice has separate implementation for touch events handling.
Changelog:
[Android][Changed] - Revamp touch event dispatching methods
Reviewed By: fkgozali, JoshuaGross
Differential Revision: D36629466
fbshipit-source-id: fb7c5950afe6249d22edd3fac3fa5d3b83b3af84
Summary:
This op code was incorrectly configured to take two args, while it only takes one.
Changelog: [Internal]
Differential Revision: D36664590
fbshipit-source-id: 6e1fdb9f64bbd32fbe05bbd174f94ae57292bcf9
Summary:
This diff cleans up several Android Makefiles which we're not using anymore
as they've been replaced by CMake files.
There are still 3 Makefiles left, which I'm aiming to remove in the near future.
Changelog:
[Internal] [Changed] - Remove unused Makefiles from React Native core
Reviewed By: javache
Differential Revision: D36660902
fbshipit-source-id: 8afffac74d493616b0f9414567821cd69f4ef803
Summary:
There's no need for this to be a setter/getter, as there are no side-effects, and it means we can use the same helper method to read it as other feature flags.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D36595602
fbshipit-source-id: d27c01bd39d03606a6f8c17ba181a8cd0bf58dbb
Summary:
Enables two new experiments (and the current behaviour as default) to speed up access to TurboModule methods from JS.
1) HostObject - Current behaviour
2) Prototype - Connect the TM HostObject via `__proto__`, and cache any methods accessed on the wrapper object.
3) Eager - Eagerly store all methods on the wrapper object, do not expose the HostObject to JS at all (TurboModules no longer need to be HostObjects in this scenario)
Changelog: [Internal]
Reviewed By: JoshuaGross, rubennorte, mdvacca
Differential Revision: D36590018
fbshipit-source-id: c9565eb239eb6aeee0f06b581ff8cd72a92073fc
Summary:
* Make constructor private, all access is through install()
* Use nullability of longLivedObjectCollection_ instead of separate bool disableGlobalLongLivedObjectCollection_
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D36592492
fbshipit-source-id: d65e779e1ac9fbe121937c5a20763aefcd589795
Summary:
In D36345402 (https://github.com/facebook/react-native/commit/56e9aa369f5c13af38cf80ba47e9eb29d835ec89) I changed the behaviour for mount items to be skipped if they were just setting zero values. AndroidTextInput is the only component that I'm aware of that has non-zero padding by default, and we account for this when creating the native shadow node. This optimization broken TextInput use-cases that explicitly request zero-padding, since we end up ignoring it.
To keep this optimization, explicitly init ReactTextInput's padding to 0, but only in Fabric. `updateState` was the closest thing I could find to a Fabric-only callback, once it's fully rolled out, we can also move this to the constructor.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D36545775
fbshipit-source-id: 07bb96032c69d7e350980b0b975e637b66c307ed
Summary:
Update `hermes-engine.podspec` to use pre-built Hermes artifacts from the corresponding React Native GitHub Release when targeting a specific React Native release.
Otherwise, fallback to building Hermes from source.
Changelog: [Internal]
Reviewed By: cortinico, cipolleschi
Differential Revision: D36609257
fbshipit-source-id: 6179c9e255558c7eaf1417ff46a2e7db120295f0
Summary:
Due to invalid utf-8 data NSString may return nil during initialisation and this leads to crash when nil goes to NSDictionary or NSArray
Changelog: [Internal]
Differential Revision: D36623628
fbshipit-source-id: 23efad87cc9fe4a23c5e90dad63e0d74036b62fa
Summary:
This fixes an issue where nullability was lost on readonly types in TurboModules specs. The "outside" nullability would be ignored in favor of only respecting the "inside" nullability (i.e. `?$ReadOnly<{}>` vs `$ReadOnly<?{}>`). It now ensure either is propagated correctly.
Changelog:
[General][Fixed] Fix nullability lost on readonly types in TurboModule specs
Reviewed By: RSNara
Differential Revision: D36615346
fbshipit-source-id: 42408d9298703f4c382657f573480d2574d6c973
Summary:
There are cases where we want to pass arbitrary types to a TurboModule, which may then handle the values appropriately, but we haven't supported this use case. Since C++ TurboModules can accept any `jsi::Value` (unlike Java/ObjC) and we have real-world need for this (otherwise we must require JSON serialization), this now allows `mixed` (`unknown` in TypeScript) for C++-only TurboModules.
Changelog:
[General][Added] C++ TurboModule methods can now use mixed types
Reviewed By: RSNara
Differential Revision: D36611299
fbshipit-source-id: bbf29dfcc6aed67e213bb3eab06537c18c7db1fe
Summary:
The new Hermes scripts need to be included in the `react-native` npm.
The `shelljs` dependency that was used by the Hermes scripts is a dev dependency, so instead of adding to the `react-native` npm size, we refactored its use out of hermes-utils.js.
Changelog:
[General][Added] - Add Hermes scripts to package
Reviewed By: cortinico
Differential Revision: D36387135
fbshipit-source-id: 12d0bc29d365c4cb18d33a0d390e6e7d34864b7a
Summary:
`test_android` is now red because I had to specify a root for RN tester.
The job is now failing as it fails to find the correct platforms for the bundler command.
This PR fixes it.
## Changelog
[Internal] - Attempt to fix test_android by moving react-native.config.js
Pull Request resolved: https://github.com/facebook/react-native/pull/33901
Test Plan: Tested locally + will wait for a CI result
Reviewed By: cipolleschi
Differential Revision: D36625857
Pulled By: cortinico
fbshipit-source-id: 01852cc966e611c6724ba528ea351a17011d62e2
Summary:
This PR tries to simplify the `use_flipper` logic:
- makes `use_flipper` a configuration inside `use_react_native`'s options
- uses the already present `production` flag in the `use_react_native`'s options to decide if add or not the Flipper pods
- Simplifies the logic to download the flipper dependencies
This PR also adds a workaround for https://github.com/facebook/react-native/issues/33764
## 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] - Move `use_flipper` logic inside `use_react_native` and simplify the Flipper dependencies logic
Pull Request resolved: https://github.com/facebook/react-native/pull/33882
Test Plan: Executed a pod install with and without flipper and with isProduction true
Reviewed By: cipolleschi
Differential Revision: D36592338
Pulled By: f-meloni
fbshipit-source-id: 3c3f773151513e27e251f18865986e942a96ffd9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33893
The previous diff was breaking the external CI tests on Windows because of the file separators.
The fix was to use UNIX separator but to apply `path.normalize` to make sure that the path is platform agnostic.
## Changelog
[General][Fixed] - Make tests pass for windows
Reviewed By: cortinico
Differential Revision: D36597593
fbshipit-source-id: 47731f34a08c778268a6cc9674257403985d4599
Summary:
I have never seen these asserts fire in production. They're pretty cheap but the cost is not zero. We will use annotations and test carefully in debug if we need to ensure that something runs on a particular thread - which we do anyway.
Motivation: this method is called /extremely frequently/, everywhere in the mounting layer. And 99.99% of the time it's completely useless and results in absolutely no signal. In many cases, it will be called hundreds or thousands of times during a single operation (for example, when executing the IntMountBuffer items, each sub-item will call this many times).
Wall-clock time is usually low according to systrace (sometimes there are odd spikes), but over time these do add up and it seems good to save a few ms here and there.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D36539399
fbshipit-source-id: 3e023be64b8c9f0e6c3c8347c077ce9fa38f74a4
Summary:
It's useful to have more systrace markers that are all the same, so that they can all be aggregated and work underneath them aggregated across an entire trace. As it is, this marker gets treated as unique nearly every time which makes analysis harder.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D36533075
fbshipit-source-id: 925afa7db152eca1166891b41e7c6f6a511840af
Summary:
setImmediate will result in these debounced/queued operations being sent to native immediately at the end of a ReactJS render loop instead of in the next tick, which could result in more fluid animations.
I verified with logs that batching still occurs.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D36521717
fbshipit-source-id: 4f94e26503d4e6e40f52a4120ae407044af0c451
Summary: Changelog: [Internal] - Bypass dispatching an event if no view along the hierarchy is listening to it. Only applied for touch-based interactions. Next change will add optimization for mouse interactions
Reviewed By: vincentriemer
Differential Revision: D35739417
fbshipit-source-id: 134ffefef3bb4f97bf3e63b6bccc0caca464dfbd
Summary:
We don't want to include tests as they're not valuable for our users + the might break users build if they try to run `./gradlew build`.
Changelog:
[Internal] [Changed] - Do not publish Android tests inside the NPM package
Reviewed By: cipolleschi
Differential Revision: D36600831
fbshipit-source-id: b88ee4dc93f276cd0729a2193346f5fcde34323c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33876
WIP. Published so we can export and test on CI.
These two jobs can likely be merged onto the existing build_hermesc_macos job.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D36538847
fbshipit-source-id: e52c39ccfe652e70c54fd4892513c0060c3f021d
Summary:
For published RN releases, use a published hermes-engine pod that corresponds to the current React Native version.
For unpublished RN versions, continue consuming the local hermes-engine pod which requires building Hermes from source.
Changelog: [Internal]
Reviewed By: cortinico, cipolleschi
Differential Revision: D36533683
fbshipit-source-id: 963a0f0e24baaf73a87c9bae4bc20d83757bbfde
Summary:
Introduces option to use pre-built Hermes binaries.
Requires a `hermes-engine` pod release to have been published in the following manner:
```
env hermes-artifact-url='https://github.com/facebook/react-native/releases/download/vX.Y.Z/hermes-runtime-darwin-vX.Y.Z.tar.gz' pod trunk push hermes-engine.podspec
```
...where "vX.Y.Z" corresponds to a published React Native release on GitHub where the `hermes-runtime-darwin-vX.Y.Z.tar.gz` binary was generated and/or uploaded as part of the release process.
Changelog: [Internal]
Reviewed By: cortinico, cipolleschi
Differential Revision: D36532561
fbshipit-source-id: 73bc107158387ff2db359e1b6a973db6ee85995c
Summary:
I've accidentally broke the external CI.
The reason is that root is defaulted to `$rootProject/..`.
The Gradle Plugin assumes there is a package.json there, which is always the case for RN projects, given that root is configured properly.
This was green on internal CIs as it was actually hitting the file on `xplat/js/package.json`. Externally, there is no such file, therefore is failing.
The fix is to specify the root path and don't use the default for ReactAndroid
Changelog:
[Internal] [Fixed] - Set root to be `..` for ReactAndroid
Reviewed By: cipolleschi
Differential Revision: D36597308
fbshipit-source-id: 66638ee1014ef35c81195526e0b325f5cc008b82
Summary:
It seems that using `:` inside the `name` field of our Issue Template broke the parsing of them. I'm fixing it here.
## Changelog
[Internal] - Fix broken `ISSUE_TEMPLATE` due to extra `:`
Pull Request resolved: https://github.com/facebook/react-native/pull/33892
Test Plan:
Tested on:
https://github.com/cortinico/react-native/issues/new/choose
Reviewed By: f-meloni, cipolleschi
Differential Revision: D36596469
Pulled By: cortinico
fbshipit-source-id: 8009a88efc800622bad493a170b054972bb2147c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33891
This diff adds a function to clean up folders and empty files (if any) after the codegen runs in the OSS.
To align how iOS and Android behave in the codegen, we now have to preemptively create folders that we may not need later.
Thanks to this function, we recursively the folders in the codegen and we delete them if they are empty.
## Changelog
[iOS][Added] - Add function to cleanup codegen folders
Reviewed By: cortinico
Differential Revision: D36594999
fbshipit-source-id: 904aa2442c0d9621b7ec77c31f7be9daa4e7b7e1
Summary:
This extends the Gradle plugin to allow configuration for `codegenConfig` from the
`package.json` that lives in one of the root folder.
There are a couple of points open for discussion. The most important one
is that now we're moving from absolute paths to relative paths, from the
package.json location. I'm not entirely sure this will work correctly
for users in monorepos, so we might consider this carefully.
Moreover, I've moved the `codegenJavaPackageName` to be `android.javaPackageName`.
Happy to discuss this further.
Changelog:
[Android] [Added] - Extend the React Native Gradle plugin to accept a config from package.json
Reviewed By: cipolleschi
Differential Revision: D36374475
fbshipit-source-id: fe669ebd5bc92abbbe57677c1995d0e01f2400d7
Summary:
Call `setWaitingForIdentifier` before we do any `setValue` calls to make sure we execute them together (and only call start/finish batch once). Only calll `updateAnimatedNodeConfig` conditionally when we changed nativeColor.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D36517302
fbshipit-source-id: ecbae2d1df69e4456620c58a922275406e22a2f8
Summary:
Splitting these changes of from D36482630, which is a minor improvement to the singleOp experiment. Since we call start/finish already on the native side, we don't need to repeat it from JS.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D36541700
fbshipit-source-id: 7d61669710faca3153be557fb2d214011eda87c5
Summary:
While React Native depends on the `metro` package indirectly (via the CLI package), it depends on some secondary Metro packages directly. This diff updates those direct dependencies to use [Metro 0.71.0](https://github.com/facebook/metro/releases/tag/v0.71.0).
Changelog:
[General] Update direct Metro dependencies to 0.71.0
Reviewed By: motiz88
Differential Revision: D36592469
fbshipit-source-id: 4d95608545a5dff59049f1f48e18b08d4856961f
Summary:
* Make inner classes static where possible
* Make member variables final when set from constructor
* Remove Nullable on `mFabricViewStateManager` and associated checks
* Remove `createInternalEditText` which has moved to the ShadowNode (paper-only)
Changelog: [Internal]
Reviewed By: genkikondo
Differential Revision: D36545807
fbshipit-source-id: 85517511d1734f0e55de5caa012e32feb40e8492
Summary:
ViewManager does a null-check already, and so inside the `updateState` method, we can safely assume this parameter is no longer nullable.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D36545806
fbshipit-source-id: 92eefa518f11c17b91aa3da2e14066d36fa4f4c2
Summary:
`test_android` is currently broken as it tries to build with `source = "7"` (the default).
This is a best guess fix to try to fix this issue.
## Changelog
[Internal] - Attempt to fix test_android by specifying source 8
Pull Request resolved: https://github.com/facebook/react-native/pull/33890
Test Plan: Will rely on CI
Reviewed By: cipolleschi
Differential Revision: D36589814
Pulled By: cortinico
fbshipit-source-id: 8ef50f8531b9d4367d2f2c75a312e8fdaf38fd85
Summary:
Run Danger on all the PRs, not just on the forks, use fail or warning where is needed and make CircleCI fail if danger fails
## 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] - Run Danger on all the PRs and use fail or warning where is needed.
Pull Request resolved: https://github.com/facebook/react-native/pull/33872
Test Plan: Run the change on CirlceCI
Reviewed By: cortinico
Differential Revision: D36516847
Pulled By: f-meloni
fbshipit-source-id: 2c956295a56cc8aa47df4c64f8ca0a211796c73c
Summary:
Changelog:
[iOS][Fixed] - When in an RTL locale on iOS, e.nativeEvent.zoomScale is -1. This seems to cause erratic blank spaces that don't recover as you scroll. Set the value to 1 instead when negative.
Differential Revision: D36499121
fbshipit-source-id: f82812ca00ae4162fbff617df8c716a4964b3a8f
Summary:
As the title says, let's make this field mandatory so we don't have to ask for
a repro over and over again.
Changelog:
[Internal] [Changed] - Make the reproducer mandatory in the issue template
Reviewed By: cipolleschi
Differential Revision: D36552021
fbshipit-source-id: ac6aa0c3b1583afe38b3fcf78c385e5bdfb5f6e2
Summary: Changelog: [Internal] - Make it easier to specify what events to listen to on each `EventfulView`. This is helpful for testing future optimizations to event dispatch filtering. Also removed the switches for triggering events -- the idea being that we're using these examples with Metro and we can just remove the relevant props when we want to not fire any events.
Reviewed By: kacieb
Differential Revision: D36530066
fbshipit-source-id: 3ff45c263bdcacedde8d2720e156ab8156424c53
Summary:
There are use cases of needing to setValue multiple times per second (for example, using PanResponder to update a slider component).
This requires the use of the native driver for perf reasons as using the JS driver will cause a rerender. Currently, the only way to make an animated node native is via setting useNativeDriver: true on an animation config. For example:
```
Animated.timing(animatedValue,
{
toValue: newValue,
duration: 0,
useNativeDriver: true
}).start();
```
To avoid needing to call the above, add a useNativeDriver param to the constructor. When set to true, the node will be made native immediately.
```
const animatedValue = new Animated.Value(0, useNativeDriver);
...
animatedValue.setValue(newValue);
```
Note that, like with useNativeDriver in the animation config, once a node is made native, it cannot be reverted to JS-only.
---
As an aside, PanResponder uses JS-side events, and thus we cannot use Animated.event with native driver; we instead need to setValue on a native AnimatedValue. A much more thorough explanation is in D34564598.
---
Changelog:
[General][Added] - [Animated] Add useNativeDriver as a param for setValue
Reviewed By: JoshuaGross
Differential Revision: D36459457
fbshipit-source-id: 284148a6d16537429efeab8b07184019990909cd
Summary:
When releasing the latest RC, we have noticed `pod install` is broken since the downloaded `react-native` package is missing hermes scripts and `shelljs` dependency (needed by `hermes-utils.js`).
## 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] - Fix compiling hermes in the release version.
Pull Request resolved: https://github.com/facebook/react-native/pull/33881
Test Plan: - Run `test-manual-e2e.sh` with template and Hermes on iOS
Reviewed By: GijsWeterings
Differential Revision: D36546116
Pulled By: cortinico
fbshipit-source-id: 70fe70de7d63193df888b8ece935c4fa97b4dfc8
Summary:
Improve the types of `queueOperation` so flow can assert that the parameters match.
Also in the case of `singleOpBatching == false`, nativeOps is just an alias of NativeModule so there's no overhead.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D36482617
fbshipit-source-id: e000d11b04166cd7a069af024b9c2cc226efa701
Summary:
This will fix a crash on Motorola devices on Android 7, where WebView fails to load due to initialisation issues in the WebViewChromiumFactoryProvider (Caused by org.chromium.base.library_loader.ProcessInitException).
## Changelog
[Android][Fix] - Exception with `Cannot load WebView` message will initialising WebView (along with existing checks)
Pull Request resolved: https://github.com/facebook/react-native/pull/33867
Test Plan: <img width="1368" alt="Screenshot 2022-05-19 at 02 21 57" src="https://user-images.githubusercontent.com/933314/169154293-c442a54f-96f5-4309-a6ce-c8f9c4beeb17.png">
Reviewed By: javache
Differential Revision: D36517673
Pulled By: cortinico
fbshipit-source-id: 4fa5b903529eb04d01ed8fa540cbd883224e8e62
Summary:
With the new architecture, this module should be using the implementation from ReactFabric instead. However, given the ReactNative module had side effects (like registering `RCTEventEmitter`), let's import from ReactFabric only in the latest "new architecture" mode.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D36535626
fbshipit-source-id: 6758b671df9a47607d8caf4a021ac73410f4c6e9
Summary:
I'm finding it useful to keep track of a few additional numbers when doing perf analysis in Fabric.
Also making it easier to enable just these perf logs without all of the other verbose Fabric logs.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D36500518
fbshipit-source-id: e57e1e75131c5d59da876d1decb96d4da386f025
Summary:
We were calling the wrong operation from the MegaOp which caused indices to become offset. Trivial fix.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D36482822
fbshipit-source-id: 83ebc37a8773f0277db4caff9d3e7c9c91931ddb
Summary:
Currently this [section](https://reactnative.dev/docs/next/new-architecture-app-intro#ios-enable-c17-language-feature-support) of the Playbook tells us to set CLANG_CXX_LANGUAGE_STANDARD = "c++17" in the main app target for the new architecture to work.
Would be nice to be able to automate that instead
## 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] [Added] - Cocoapods function to add the `CLANG_CXX_LANGUAGE_STANDARD` to all the targets if needed
Pull Request resolved: https://github.com/facebook/react-native/pull/33863
Test Plan:
I've created some unit tests for the newly added function.
I've executed pod install and the ruby tests locally.
Reviewed By: cipolleschi
Differential Revision: D36484366
Pulled By: f-meloni
fbshipit-source-id: 553b092e747bef11d82195619ae1058985fdc325
Summary:
Noticed we were copying ShadowView, where a reference should suffice.
Changelog: [Internal]
Reviewed By: appden
Differential Revision: D36455200
fbshipit-source-id: 2cd3cf66b9e5ec05bce9ce1d739fbed66f3a6d89
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33864
This Diff aligns the way in which iOS and Android codegen the modules and components.
Android takes all the JS in the project root folder and creates components starting from there.
iOS used to required to specify a specific path for each component, within a JSON field called `libraries`. This Diff let iOS work in the same way as android does
**Backward compatibility:** This diff still support the old way for iOS, but we are deprecating it.
## Changelog
[iOS][Added] - Support codegen from a single folder
Reviewed By: cortinico
Differential Revision: D36473005
fbshipit-source-id: 1e8cf0f9764f529c02e948984c74d1982a84030b
Summary:
Which idiot wrote this? Oh yeah, I did.
This was introduced in D36109810 (https://github.com/facebook/react-native/commit/bf405d70837e1319cfa83e4c5cbb7c9a69abd820) so hasn't been around too long luckily.
Changelog: [Internal]
Reviewed By: cortinico, GijsWeterings
Differential Revision: D36480272
fbshipit-source-id: b0fbb6b820185185359c6c75f77f2921dc892b02
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33870
I'm fixing a broken CI on master for `test_windows` as `metro-memory-fs` doesn't
automatically recognize the platform but needs to have it passed in input.
It was currently failing to parse a `C:\...` path. This fixes it.
Changelog:
[Internal] [Changed] - Fix `test_windows` by passing the correct platform to the Metro Virtual FS
Reviewed By: cipolleschi
Differential Revision: D36507564
fbshipit-source-id: 39dfd7e9ce492d126fbb513a70ec5a60965c61fd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33869
When I disabled the Javadoc pubblication as it was failing on CI,
I forgot to turn off the verification that the -javadoc artifact is included
inside the NPM package. This caused `build_npm_package-1` to fail on main.
I'm fixing it here.
Changelog:
[Internal] [Fixed] - Do not fail if -javadoc.jar are missing in the final NPM package
Reviewed By: cipolleschi
Differential Revision: D36507320
fbshipit-source-id: 3836de5212de91bb44e0e586564b46114ca346b4
Summary:
I'm disabling the publishing of Javadoc as it's currently failing on CI.
The failure is happening due to a concurrency problem during the Kotlin
documentation generation.
As we don't have much Javadoc to export, I'm removing this for now.
Changelog:
[Internal] [Fixed] - Disable Javadoc publishing as it's currently failing on CI
Reviewed By: cipolleschi
Differential Revision: D36481215
fbshipit-source-id: 6f875932013f80779151f75e20d25ba3b71de074
Summary:
Codegen a static field for every caller of `invokeJavaMethod` to cache the jmethodID that should be used for the method, which saves us a string-based name lookup at invocation time.
Changelog: [internal]
Reviewed By: genkikondo
Differential Revision: D36376056
fbshipit-source-id: 298430746a8f25a5337aba05b56876ba789e2344
Summary:
Simplify argument and result conversion by using existing fbjni helpers (which will cache class and method ID lookups already)
Changelog: [internal]
Reviewed By: RSNara
Differential Revision: D36312751
fbshipit-source-id: 16713642b2c5fb4c2b6447c30652d91ddbd88224
Summary: Changelog: [Android][Fixed] Scroll views would still receive scroll events when nested in a view with `pointer-events: "none"`
Differential Revision: D36423921
fbshipit-source-id: 87b8a236e15dda7b648b6fc649187e95a9a2cc42
Summary:
Noticed that we emit a large amount of (admittedly cheap) mountitems as part of node creation for values that are all zero (e.g. padding, overflowinset), which we can assume to be already initialised with these values on the native side.
There's a further opportunity to do this for State as well, as ReactImageComponentState exports just empty maps to Java.
Changelog: [Internal]
Reviewed By: genkikondo
Differential Revision: D36345402
fbshipit-source-id: 8d776ca124bdb9e1cd4de57a04e2785a9a0f918c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33818
This Diff moves the fabric setup from the `react_native_pods` script to its own `fabric` file.
It also introduces tests for the file and some test utilities.
## Changelog
[iOS][Changed] - Move fabric setup to its own file
Reviewed By: cortinico, dmitryrykun
Differential Revision: D36344911
fbshipit-source-id: 586186684be2c0080f247390f26145f2defa9e97
Summary:
Changelog:
[iOS][Fixed] - When in an RTL locale on iOS, e.nativeEvent.zoomScale is -1. This seems to cause erratic blank spaces that don't recover as you scroll. Taking Math.abs of the value fixes it. Blame: D36169686 (https://github.com/facebook/react-native/commit/13a72e0ccceb2db6aeacd03b4f429d200392c17b)
Differential Revision: D36468390
fbshipit-source-id: f18244f1421fc1ccbb0d1035df8a7c6de10ccf62
Summary:
We introduce a few optimizations:
(1) Previous diff: We defer calling any NativeAnimatedModule methods by waiting 1ms before flushing the queue, and debouncing until no flush is requested. Practically, this just means that we'll call NativeAnimatedModule methods N times at once, at the end of a render loop, instead of N times smeared throughout the render loop.
(2) Additionally, instead of calling N methods, we create multi-operation argument buffer and call a single NativeAnimatedModule API, which should essentially throttle NativeAnimatedModule API calls to once-ish per frame. On the native side, this also reduces a lot of overhead associated with scheduling work on the UI thread (we schedule 1 function to run on the UI thread and perform N operations, as opposed to scheduling N functions to run on the UI thread).
TODO:
- implement stubs for iOS
- write gating code so this can be properly tested in VR and in fb4a
Changelog: [Internal]
Reviewed By: genkikondo
Differential Revision: D36338606
fbshipit-source-id: 29ac949b53b874683128a76525586c22def3143b
Summary:
Because of the disconnect between the ReactJS render loop and Animated nodes, we don't know when a render loop begins or ends. Historically we haven't cared about that much,
but now for perf reasons we're attempting to batch them. Scheduling a function to execute at the end of the runloop and canceling until nothing interrupts it achieves that.
Impact seems fairly minimal and this should work everywhere (android, ios, etc) but we may want to gate the behavior as it *could* change things in surprising ways.
Changelog: [Internal]
Reviewed By: genkikondo
Differential Revision: D36338621
fbshipit-source-id: 48e52a1b2e2bcfb3ef13d3abd38d735967356de7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33852
Similarly to buildAll and cleanAll, I'm creating a downloadlAll task
which is aligning the behavior of the download task we're doing on CIs.
I've also updated the Offline Cache as we're now storing a bigger set of dependencies.
Changelog:
[Internal] [Changed] - Setup a toplevel downloadAll task
allow-large-files
Reviewed By: cipolleschi
Differential Revision: D36441728
fbshipit-source-id: f847b5e665c64e0b4b93d984bbc1b64c00a3b4f7
Summary:
I'm adding a readme inside the ./Libraries/Renderer folder
to explain how React and React Native are aligned.
Changelog:
[Internal] [Changed] - Add a note about React/React-Native versioning
Reviewed By: cipolleschi
Differential Revision: D36445819
fbshipit-source-id: cf1b071b9996bcc8222deab2e9458f014766f2a9
Summary:
build_ios is a subset of test_ios.
The Hermes cache takes 20-30 minutes to be downloaded and unarchived, that is the slowest part of both the jobs and that was duplicated.
This means that if we remove build_ios we save a lot of time, and the CI is still covering the build and the testing of the code.
## 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] - Remove build_ios and use only test_ios
Pull Request resolved: https://github.com/facebook/react-native/pull/33837
Test Plan: Checked on CircleCI
Reviewed By: cipolleschi
Differential Revision: D36437775
Pulled By: f-meloni
fbshipit-source-id: 53adf77e3511963d2dbfadf26122fd70b0de1113
Summary:
The bump of AGP to 7.2 caused the tests inside `AndroidConfigurationTest.kt` to fail.
As we're now running `buildAll` both on Sandcastle and on CircleCI, this is now failing
on both CIs. The issue is that AGP 7.2 change the way to introspect resValues and
requires now to specify a type when querying for a value. I'm updating the tests here.
Changelog:
[Internal] [Fixed] - Fix broken AndroidConfigurationTest.kt on main
Reviewed By: cipolleschi
Differential Revision: D36437875
fbshipit-source-id: 58f457a78eae861e86808e58c23f5d04fb196d45
Summary:
We try to remove the use test_ownership_2020 oncall, which was created to enforce oncall field in test module. This diff stack tries its best to guess who the right oncall is for these "unowned" tests.
If you don't think this belongs to you, please
1. Either re-assign to another team to your best knowledge
2. Or delete the test
Every test should have an owner!
Differential Revision: D36404812
fbshipit-source-id: daf57e860d3700928ae4518897d87247a672eae4
Summary:
Noticed that (LockFree)EventDispatcherImpl had NativeAnimatedNodesManager as a listener 100+ times, as listener registration can happen multiple times from Animated node creation. Since listener management on event dispatcher is thread-safe, we can avoid the thread hop for this.
Changelog: [Internal]
Reviewed By: genkikondo
Differential Revision: D36316102
fbshipit-source-id: f2f417b69885def87f88460d8b1e0b35b66726cb
Summary:
elementsThatOverlapOffsets was quite inefficient as it was doing a linear scan over all items without an early out for each input offset.
The number of items can be large, so we'd want to use binary search here.
Before: O(MN), where M is the # offsets and N is the # items
After: O(MlogN)
As a utility method, elementsThatOverlapOffsets should not be responsible for checking that the offsets are in increasing order
'binary-search' dep added via https://www.internalfb.com/intern/wiki/React_Native/Building_Product_Experiences/Third_Party_Packages_(npm)/
Changelog:
[Internal] - Modify VirtualizeUtils.elementsThatOverlapOffsets to use binary search
Reviewed By: javache
Differential Revision: D36292326
fbshipit-source-id: 5f22eb5533b69e2ebe5c1cb34e4f82605838f0a7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33838
The idea behind this diff is to set a top level `buildAll` task that will be responsible
of invoking all the tasks we want to verify both in the internal and in the external CI.
This should ideally remove the breakages of the External CI happening from internal changes.
Changelog:
[Internal] [Changed] - Setup a top level buildAll Gradle task
Reviewed By: cipolleschi
Differential Revision: D36376384
fbshipit-source-id: d810b59577340628bb49562bfedf28440bd0f792
Summary:
I'm adding a new Issue Template for New Architecture issues + I've added a contact entry for the Working Group.
## Changelog
[Internal] - Add issue templates for New Architecture
Pull Request resolved: https://github.com/facebook/react-native/pull/33832
Test Plan:
Tested this here
https://github.com/cortinico/react-native/issues/new/choose
Reviewed By: hramos
Differential Revision: D36376737
Pulled By: cortinico
fbshipit-source-id: b8561a7faf0bb99c033686a92bb2d88e443333c2
Summary:
This diff fixed an edge case that event dispatching is failed after pre-allocation of a view and before the view is mounted.
When a cached image is loaded, we will dispatch the event to JS immediately. This is could happen after the view is created during pre-allocation phase, when the event emitter is not instantiated yet. In that case, we will see [an error](https://github.com/facebook/react-native/blob/main/ReactAndroid/src/main/java/com/facebook/react/fabric/FabricUIManager.java#L927) and the event will effectively be ignored.
To fix that we introduced a queue in this diff for those events. They will be dispatched in order when the view is mounted and the event emitter is non-null.
Changelog:
[Android][Fixed] - Fixed an edge case that event dispatching is failed after pre-allocation of a view and before the view is mounted.
Reviewed By: mullender
Differential Revision: D36331914
fbshipit-source-id: cd065b0b36978cb5f0aac793d8d16f07a48f0881
Summary:
Use pre-built hermesc if available by generating a ImportHermesc.cmake file that points to the hermesc binary. Recent `react-native` releases should have hermesc available in sdks/hermesc.
Hermes build scripts have been updated to support a `HERMES_OVERRIDE_HERMESC_PATH` envvar which can point to this generated ImportHermesc.cmake file.
Pull Request resolved: https://github.com/facebook/react-native/pull/33827
Changelog:
[iOS] [Changed] - Use pre-built HermesC if available in current React Native release
Reviewed By: cortinico
Differential Revision: D36024615
fbshipit-source-id: 476569f73309f9bd142f28cb02d1f7d57b6cbc6a
Summary:
This patches a loophole in the logic that caused some operations to execute immediately and some to be deferred, even within the same render loop. This caused the non-queued operations to be executed out of order. Instead, if an operation is created and a queued exists, we just push the operation to the end of the queue so ordering is preserved.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D36379125
fbshipit-source-id: d9f63f4d47d8453d51add61763b7b9c74ffe9d88
Summary:
Avoid re-building Hermes if a cache hit is found for the required Hermes version.
Cache sdks/hermes and sdks/hermesc in Circle CI iOS jobs: `test_ios_rntester`, `build_ios`, and `test_ios`.
`test_ios_rntester` "Install CocoaPod Dependencies" step reduced from 37m40s to 3m35s.
`test_ios` "Generate RNTesterPods workspace" step reduced from 36m54s to 1m34s.
Pull Request resolved: https://github.com/facebook/react-native/pull/33828
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D36365596
fbshipit-source-id: b5b6fe639f18b1724f80ab61c2262659c4987ff6
Summary:
Currently on Android, React Native can only accept font resource IDs which it internally converts into Typeface objects. This change allows ReactFontManager to be passed a Typeface at runtime to enable e.g. downloading fonts on demand.
Changelog:
[Android][Added] - Ability to pass a Typeface object to ReactFontManager in addition to a font resource ID
Reviewed By: makovkastar
Differential Revision: D36138123
fbshipit-source-id: b314e8c7fc28174b5caa017076b6eb3d4f6dbaa8
Summary:
We are currently seeing warning `Native Component 'X' that calls codegenNativeComponent was not code generated at build time. Please check its definition.` even though we have not opted into Fabric. This warning is not actionable and is just noisy.
See also discussion: https://github.com/reactwg/react-native-releases/discussions/21#discussioncomment-2657180
## Changelog
[General] [Fixed] - Remove unactionable warning about `codegenNativeComponent` when on 'Paper'
Pull Request resolved: https://github.com/facebook/react-native/pull/33830
Test Plan: n/a
Reviewed By: dmitryrykun
Differential Revision: D36377844
Pulled By: cortinico
fbshipit-source-id: 23c9f9dbf0ce1cea60c5dc8caa02d0dc53bd635d
Summary:
The machines have on their env `HOMEBREW_NO_AUTO_UPDATE=1`, hence I believe that `with_brew_cache_span` is not needed anymore.
If this works it should save the cache downloading and unarchiving time
## 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] - Remove with_brew_cache_span from Circle's config
Pull Request resolved: https://github.com/facebook/react-native/pull/33831
Reviewed By: cortinico
Differential Revision: D36374646
Pulled By: f-meloni
fbshipit-source-id: 0e6a35bb2c2dfe44e340e95a1b5e158389a3dfe9
Summary:
Instead of wait for Circle to delete the simulators, we can do it in background and save 40 seconds
Changelog:
[Internal] - Delete iOS simulators in background
Pull Request resolved: https://github.com/facebook/react-native/pull/33822
Reviewed By: cortinico
Differential Revision: D36348573
Pulled By: f-meloni
fbshipit-source-id: 89d9e7caddb44e085734e74f417687ee031dd67b
Summary:
This way we can avoid unnecessary ArrayList copies.
Changelog: [Android][Changed] Generalized the return type of ViewManagerOnDemandReactPackage.getViewManagerNames
Reviewed By: nlutsenko
Differential Revision: D36131516
fbshipit-source-id: 6a42c76cadbcce4c3720875d80062e1ee237bc2f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33811
Use `scripts/hermes/prepare-hermes-for-build.js` in Circle CI, eliminating redundant steps in the `prepare_hermes_workspace` Circle CI job.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D36335122
fbshipit-source-id: b7e8c7aeb2aac5afaf37677cd3ac949ac3f96de1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33825
Updates the CocoaPods build scripts to consume the prepare-hermes-for-build script, replacing the now redundant set of Ruby code that would previously set the filesystem up.
Changelog:
[iOS] [Changed] - When building Hermes from source, the filesystem will now be prepared using the new hermes-utils.js scripts, outside of CocoaPods
Reviewed By: cortinico
Differential Revision: D36336633
fbshipit-source-id: a4506db80c039529b14b0290d2f0b54fae78dcf2
Summary:
Adds a script that uses the new hermes-utils.js functions to prepare the local filesystem for Hermes to be built from source (e.g. download the Hermes source code tarball and extract it into its final location).
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D36334624
fbshipit-source-id: 012f758ecda07931bdb0ab1728b87733bf5af16a
Summary:
Currently, the tasks for downloading, expanding, and preparing Hermes to be built for Apple targets are split across the Circle CI and CocoaPods configs.
This diff sets out to consolidate these tasks into a single hermes-utils.js script that can be reused across CI and build systems.
The release script that is used to assign the Hermes tag for a given React Native version has been moved into `scripts/hermes`.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D36329356
fbshipit-source-id: 0222070adf201fa533b607a183471396d45c6caf
Summary:
Unify the different cache keys in one unique place to avoid duplication, and possible issues with typos.
## Changelog
Pull Request resolved: https://github.com/facebook/react-native/pull/33821
Test Plan: Check Circle CI jobs to verify that caches are working correctly
Reviewed By: cortinico
Differential Revision: D36347758
Pulled By: f-meloni
fbshipit-source-id: 2a02855e938c7cb27eaa5ebee221f5861f72aee9
Summary:
Small win: if the queue is empty we shouldn't start/stop the batch.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D36298399
fbshipit-source-id: b43c07994ba28b4c890fe52af4e81c265a3b8ac7
Summary:
Changelog:
[Internal][Changed] - Remove babel plugins from jest preprocessor which are part of preset metro-react-native-babel-preset
Transformer metro-react-native-babel-transformer has preset metro-react-native-babel-preset which has necessary plugins to transpile the source. So we don’t need to pass it again in the preprocessor.
As part of the change, updated one test to use strict mode since metro-react-native-babel-preset has strictMode is set to false.
Reviewed By: motiz88
Differential Revision: D34868961
fbshipit-source-id: 71678f1ee6f1b5ebf9a0c6fd2d6444a61d7583ac
Summary:
Patch release bumps that just change arm64 slice packaging
See https://github.com/facebook/flipper/issues/3117#issuecomment-1123759397
These pods were just released by lblasa and this PR integrates them - I personally confirm success on an arm64 doing a macCatalyst build for the first time since react-native 0.64, and users report intel works fine as well - no regression
## Changelog
[Catalyst][Fix] - use pods with arm64 macCatalyst slices
Pull Request resolved: https://github.com/facebook/react-native/pull/33809
Test Plan:
Run a macCatalyst build on intel machine and m1 machine, I use this harness as part of release-testers facebook group, and it exercises macCatalyst build if you pass in a valid development team (for signing) https://github.com/mikehardy/rnfbdemo/blob/main/make-demo.sh
(the test harness is locally modified to no longer exclude M1 builds and with a patch-package that implements this PR, pending this merge+release...)
Reviewed By: cortinico
Differential Revision: D36339335
Pulled By: cipolleschi
fbshipit-source-id: d4574fc960e6ff345b31a83ff4629e22edfcf2f7
Summary:
Sometimes this._scrollMetrics.offset is 0 even after initial scroll is triggered, because the offset is updated only upon _onScroll, which may not have been called in time for the next computation of the render limits. Thus, there is a window of time where computeWindowedRenderLimits calculates undesired render limits as it uses the offset. This results in 2 extra rerenders of the VirtualizedList if an initial scroll offset is applied, as the render limits shifts from the expected bounds (calculated using initialScrollIndex), to the 0 offset bounds (calculated using computeWindowedRenderLimits due to offset = 0), back to the expected bounds (onScroll triggers recalculation of render limits via _updateCellsToRender).
This issue was introduced in https://www.internalfb.com/diff/D35503114 (https://github.com/facebook/react-native/commit/c5c17985dae402725abb8a3a94ccedc515428711)
We cannot rely on this._hasDoneInitialScroll to indicate that scrolling *actually* finished (specifically, that _onScroll was called). Instead, we want to recalculate the windowed render limits if any of the following hold:
- initialScrollIndex is undefined or is 0
- initialScrollIndex > 0 AND scrolling is complete
- initialScrollIndex > 0 AND the end of the list is visible (this handles the case where the list is shorter than the visible area) <- this is the case that https://www.internalfb.com/diff/D35503114 (https://github.com/facebook/react-native/commit/c5c17985dae402725abb8a3a94ccedc515428711) attempted to address
Changelog:
[Internal][Fixed] - Fix issue where VirtualizedList rerenders multiple times and flickers when initialScrollIndex is set
Reviewed By: JoshuaGross
Differential Revision: D36328891
fbshipit-source-id: aba26aa06b24f6976657dd1e9f95bb666f60d9a6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33805
When we synced react to 18, we haven't updated repo-config and rn-tester
to also use version 18. I'm updating them here as this is creating confusion
and duplicated entries in the yarn.lock file.
Changelog:
[Internal] [Changed] - Bump React to 18.0.0 inside repo-config
Reviewed By: robhogan
Differential Revision: D36249888
fbshipit-source-id: a89ba1b5592f46987c5a70b707fe9ec57c4fe0ff
Summary:
The `utils/build-apple-framework.sh` script uses the ruby runtime to load `hermes-engine.podspec`, and in the process it will load the Core CocoaPods gem to parse the podspec file.
Since the podspec file uses Pod::UI to print logs, and the CoreUI gem is not loaded when `build-apple-framework.sh` accesses `hermes-engine.podspec`, we would get a warning due to Pod::UI not being defined.
This change will only use Pod::UI when it is defined, therefore limiting it to only executing when `hermes-engine.podspec` is loaded as part of the normal `pod install` build process.
Changelog: [Internal]
Reviewed By: cortinico, neildhar
Differential Revision: D36297856
fbshipit-source-id: ac1ab021f74f9dcaa7be2a2358482c73b827b756
Summary:
Hermes' build scripts use the Ninja build utility if available, otherwise they default to Unix Makefiles. When Unix Makefiles were used, builds would take far too long due to the use of a single core.
To reduce the surface area of issues that may arise as we switch to building Hermes from source, we will now focus on a single build system using Unix Makefiles. We will also ensure all available cores are used when building on macOS.
Changelog: [Internal]
Reviewed By: cortinico, neildhar
Differential Revision: D36296838
fbshipit-source-id: 4be23739fb022e3ae8e974ad3c2c70e7011abb5a
Summary:
Copy Hermes build scripts to React Native repository for greater control over the build pipeline when used in RN.
Changelog: [Internal]
Reviewed By: neildhar
Differential Revision: D36295406
fbshipit-source-id: 54bf4173b6c75db35de828378e6f5782a248ed2e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33802
We use to have a couple of tests for the script phases script that were not running during the CI.
This diff connect them with the two CI, so that they run together with the other ruby tests.
## Changelog
[iOS][Added] - Run script phases tests in CI
Reviewed By: fkgozali
Differential Revision: D36283211
fbshipit-source-id: 01b257cdc99b0bc196d60d49ac76cf044d61a7e9
Summary:
Fixes https://github.com/facebook/react-native/issues/30708.
When given the `--port` option to the `npx react-native run-ios` command, [the React Native CLI passes the `RCT_METRO_PORT` variable when calling `xcodebuild`](https://github.com/react-native-community/cli/blob/ada951606e52ad98346cd72beeb15b56ceda8b7c/packages/platform-ios/src/commands/runIOS/index.ts#L552).
This used to adjust the port used when building on iOS, but this appears to have stopped working when the xcodeproj configuration was removed in favor of CocoaPods ([link, load the diff for React.xcodeproj](https://github.com/facebook/react-native/commit/79a7828b91b405de7399cd8cdc1aaaf610ce9d75#diff-43a2b2682727878049c3283b9361d9ad94964b63105fda6a834ba23baa5b471bL5199-L5205)).
This change re-adds the preprocessor definition that was used to pull the environment variable in, and now the `--port` flag works again.
## Changelog
[iOS] [Fixed] - Fixed the ability to pass the port to use for Metro when running `react-native run-ios --port <port>`.
Pull Request resolved: https://github.com/facebook/react-native/pull/33726
Test Plan:
1. Using an example project generated from the 0.68.1 template, I modified `node_modules/react-native/React-Core.podspec` to have the same changes.
2. Deleted my project's `ios/Pods` folder and re-ran `bundle exec pod install`
3. Ran `yarn ios --port=9900` and verified that the app is connected to Metro, and check again with a refresh of the app.
4. Verified that I saw traffic on port 9900 when refreshing the app with `sudo lsof -i :9900`
5. Stopped the app and tested `yarn ios` without a port, and used `lsof` again to ensure it was using the default port `8081` again
I also ran the iOS tests locally and they passed.
Reviewed By: dmitryrykun
Differential Revision: D36097840
Pulled By: cipolleschi
fbshipit-source-id: c3f31789e15f6cd3386350e917cfa715b2d7fd58
Summary:
An issue that popped up working on:
D36140890
There is already behavior implemented to set the TextInput caret/cursor color independently from the selection box color in Android.
However this handy prop, was not documented or added as one of the available props for the TextInput component.
Associated behavior can be found here:
https://www.internalfb.com/code/fbsource/[f116d651b2e8]/xplat/js/react-native-github/ReactAndroid/src/main/java/com/facebook/react/views/textinput/ReactTextInputManager.java?lines=512
## **Changelog**
[Android] - Add android-only prop documentation at the TextInput js level.
Reviewed By: genkikondo
Differential Revision: D36208656
fbshipit-source-id: a54a2646351d897e0d598d5e1979f2a0c443e9d6
Summary: [RN][iOS] Changelog: [Internal][Fix] Minor fix: Don't display a legacy surface from Logbox if Bridge is invalid
Reviewed By: RSNara
Differential Revision: D36268234
fbshipit-source-id: 227f465fb1fc2953b5d6813485ed6750b1d3dea3
Summary:
During debugging of undesired behavior using VirtualizedList with initialScrollIndex, it was found that zoomScale was sometimes undefined, which resulted in elementsThatOverlapOffsets returning not being able to find the frame at the given offsets.
This does not cause any unexpected behavior when scrolling from the top, as the first item index in VirtualizedList is always calculated to be 0; however, when we set initialScrollIndex, the frame calculations are incorrect, resulting in wasteful re-renders of the VirtualizedList as it renders every frame (row) from the top.
Changelog:
[Internal][Fixed] - Default zoomScale to 1 for computeWindowedRenderLimits and elementsThatOverlapOffsets in order to fix render limit calculation.
Differential Revision: D36294426
fbshipit-source-id: 1e1abec1c95f58a1913bafa2c9680e51e2dc26fa
Summary: Changelog: [iOS][Internal] - Only fire pointerEnter/Leave events if a view in the event path is listening to that event
Reviewed By: yungsters
Differential Revision: D35911045
fbshipit-source-id: 8b3021619622c3e83c15acea46c23bfe3e0f9284
Summary:
Based on Google Play crash logs, crashes due to the assertions in `dispatchViewManagerCommand` is our top source of crashes:
```
com.facebook.react.uimanager.IllegalViewOperationException: Unable to execute operation dispatchViewManagerCommand: blur on view with tag: 17549, since the view does not exists
at com.facebook.react.uimanager.UIImplementation.assertViewExists(UIImplementation.java:830)
at com.facebook.react.uimanager.UIImplementation.dispatchViewManagerCommand(UIImplementation.java:713)
at com.facebook.react.uimanager.UIManagerModule.dispatchCommand(UIManagerModule.java:739)
at com.facebook.react.uimanager.UIManagerModule.dispatchViewManagerCommand(UIManagerModule.java:726)
at com.facebook.react.uimanager.ReanimatedUIManager.dispatchViewManagerCommand(ReanimatedUIManager.java:233)
at java.lang.reflect.Method.invoke(Method.java:-2)
at com.facebook.react.bridge.JavaMethodWrapper.invoke(JavaMethodWrapper.java:372)
at com.facebook.react.bridge.JavaModuleWrapper.invoke(JavaModuleWrapper.java:151)
at com.facebook.react.bridge.queue.NativeRunnable.run(NativeRunnable.java:-2)
```
There are many other places in UIImplementation that instead of throwing a fatal exception, just log a message and continues execution.
Logging a message and discarding the command should be safe for commands like "blur this view". We keep the previous behavior in debug mode, but just log and discard commands in production.
## 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] - Avoid crash by handling missing views in dispatchViewManagerCommand
Pull Request resolved: https://github.com/facebook/react-native/pull/33795
Test Plan: We had a tough time reproducing specific crashes, but we ran with this binary in the latest release of our app and it has eliminated this class of crashes from Google Play and Bugsnag instrumentation.
Reviewed By: cortinico
Differential Revision: D36285603
Pulled By: JoshuaGross
fbshipit-source-id: db0be74926c4cb83f07686398579236da8e586bf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33791
This flag is used as a duplication for the `RCT_NEW_ARCH_ENABLED` flag. There is a [spot](https://github.com/facebook/react-native/blob/d96806bbc67f9a9e42791b319d1dddaf8a3cd34f/scripts/react_native_pods.rb#L31) in the code where, if `RCT_NEW_ARCH_ENABLED`, then the `USE_CODEGEN_DISCOVERY` is set to true as well.
Maintain two different flags for similar reasons is cumbersome and error-prone. This diff removes the `USE_CODEGEN_DISCOVERY` in favor of the `RCT_NEW_ARCH_ENABLED` flag.
## CHANGELOG
[iOS][Removed] - Remove USE_CODEGEN_DISCOVERY flag
Reviewed By: cortinico
Differential Revision: D36244618
fbshipit-source-id: 8e8979268b7aa25b895236b0c3a86fb57c6f2ea6
Summary:
This diff adds a CompositeReactPackageTurboModuleManagerDelegate which can be used to combine 1 or more TurboModuleManagerDelegates into a single one.
This is useful when both the app and one or multiple of its libraries provides a TurboModuleManagerDelegate
Changelog:
[Internal] [Changed] - Add CompositeReactPackageTurboModuleManagerDelegate
Reviewed By: mdvacca
Differential Revision: D36187694
fbshipit-source-id: 88f1d689342345b4cb7e67186791ad5bd1a6f21b
Summary:
ScrollView's contentOffset prop was assumed to be iOS only, but in reality it is supported on Android as well: https://fburl.com/code/nuxpjpth
Changelog:
[General] - Move ScrollView's contentOffset to common props
Reviewed By: yungsters
Differential Revision: D36219604
fbshipit-source-id: f41679fd2ce7971a30129e0d91ae9f32b9cf756e
Summary:
This Change fixes a possible null exception as the user uses AppCompat 1.4.0
as a dependency in their App and uses a `TextInput` component.
The exception may happen as `mFabricViewStateManager` is accessed during
the constructor of the superclass, and is not yet initialized.
- For reference, commit #e21f8ec34984551f87a306672160cc88e67e4793 fixes the crash which was already happening.
<!-- Explain the **motivation** for making this change. What existing problem does the pull request solve? -->
Possible null exception as `mFabricViewStateManager` is accessed during
the constructor of the superclass, white it is not yet initialized.
This commit #e21f8ec34984551f87a306672160cc88e67e4793 fixes the crash which was already happening, accessing of mFabricViewStateManager before initialization, and left another one of the call of the same nature.
## 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
-->
Fix: accessing `mFabricViewStateManager` before initialization.
[JavaScript] [Fixed] - accessing `mFabricViewStateManager` before initialization.
Pull Request resolved: https://github.com/facebook/react-native/pull/33769
Test Plan: no external tool was used.
Reviewed By: javache
Differential Revision: D36205441
Pulled By: cortinico
fbshipit-source-id: f3fca69224c7794757514f026a5293b213986186
Summary:
I'm updating the versioning schema of `react-native-codegen` to use minor instead of patch versions.
Historically we used to use a version as `0.0.15` and incrementally bump it.
Today, we had to do released a patched version of `react-native-codegen` for React Native 0.68.
Therefore, we're moving to use a versioning scheme as `0.<RN-VERSION>.x` which gives more flexibility and allows us to follow-up on specific version of the codegen for every RN version, should we need to.
`react-native-codegen` 0.70 is essentially a re-publishing of 0.0.16 from `main`
Changelog:
[General] [Changed] - Bump React Native Codegen to 0.70.0
Reviewed By: motiz88
Differential Revision: D36244307
fbshipit-source-id: 475615e5dbc4e6bc850f64110c060a1c87544292
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33792
This Diff exports the `flipper.rb` file in the `package.json` to fix the OSS CI
## Changelog
[iOS][Changed] - Export `flipper.rb` script file
Reviewed By: cortinico
Differential Revision: D36244721
fbshipit-source-id: d8c57ce6525bce6f0acbe722064b79eda0d0a7a8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33776
The implementations of these modules is pretty much identical, and we're already shipping the fbjni version of this anyway.
Changelog: [Internal]
Reviewed By: mhorowitz
Differential Revision: D36200330
fbshipit-source-id: 135ee621e1e4c5eb9616ce7f442fc6d4b946f865
Summary:
Cherry picking https://github.com/facebook/react-native/pull/33707 to main branch
This change is extending the changes made by alespergl to reduce the file paths and command lengths of ndk build commands
Essentially we are shortening the length of the source files by using relative paths instead of absolute paths as enumerated by the wildcard expression
This commit is extending the fix by including all the new modules introduced into RN for the new architecture, including the generated modules.
We are also reverting the ndk bump as ndk23 is crashing frequently when building RN with new arch. The reduced file paths lengths ensures the ndk bump is not required for relatively short application paths.
Fix building RN with new architecture on Windows boxes by using relative paths for C++ sources
## Changelog
Fix building RN with new architecture on Windows boxes by using relative paths for C++ sources
[CATEGORY] [TYPE] - Message
Pull Request resolved: https://github.com/facebook/react-native/pull/33784
Test Plan: Verified building on windows box
Reviewed By: javache
Differential Revision: D36241928
Pulled By: cortinico
fbshipit-source-id: 1ce428a271724cbd3b00a24fe03e7d69253f169b
Summary:
This Diff moves all the Flipper.rb related setup in the cocoapods scripts to a dedicated script.
It also removes the not needed dummy files and add tests for flipper.
## Changelog
[iOS][Internal] - Extract Flipper setup in a separate file and add tests
Reviewed By: cortinico
Differential Revision: D36129808
fbshipit-source-id: 5446203a69b527146c893aa9611e98688e20b778
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33780
Currently this just has a default ThreadPool name, which can be confusing in systraces and crash reports.
Changelog: [Internal]
Reviewed By: ryancat
Differential Revision: D36200090
fbshipit-source-id: 22918993e7c822ed721ccaf79cdcd9d2a972193d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33761
Changelog:
[General][Fixed] - Add 'mkdirp' as a direct dependency to 'react-native' instead of assuming it being a transitive dependency of some other module.
Reviewed By: cortinico, cipolleschi
Differential Revision: D36138320
fbshipit-source-id: b2421aa6b22fca0b813bbb5bb0c7213540ca578d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33779
This diff adds a `store_artifacts` to CircleCI so the Hermes debug symbols are retained and can be used to symbolicate native crashes for Hermes.
Changelog:
[Internal] [Changed] - Store Hermes Debug Symbols inside CircleCI
Reviewed By: cipolleschi
Differential Revision: D36201978
fbshipit-source-id: ef9a71e2953180aef5caea9f5eb0047190ed6198
Summary:
This comment on how to enable/disable Hermes went out of sync with the release of the New Architecture. Got reported on the website here: https://github.com/facebook/react-native-website/issues/3105
I'm fixing it.
Changelog:
[Internal] [Changed] - Fix comments on how to enable/disable Hermes on iOS
Reviewed By: cipolleschi
Differential Revision: D36204189
fbshipit-source-id: 5831a9500477115ebe5fa5cb62176ceefc722839
Summary:
Customize the Hermes version exposed to CocoaPods with one that refers to the facebook/hermes commit sha from which Hermes was built.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D36145140
fbshipit-source-id: 4ff7546d2335ea6642dd9b10f4b7a9aba260d550
Summary:
Use Circle CI caching to avoid re-building Hermes. The cache key will be determined by the Hermes tag specified in sdks/.hermesversion; if the file does not exist (as is the case in builds from main), the commit sha for the latest Hermes commit from facebook/hermes will be used.
This should significantly speed up builds across all workflows: builds from main (commitlies), nightlies, and release builds.
Changelog: [Internal]
Reviewed By: cortinico, cipolleschi
Differential Revision: D36158296
fbshipit-source-id: b80457fdefad0d63e62feeb4d509265e2762f253
Summary:
Updates `yarn.lock` to resolve mixed/mismatched Metro versions between direct dependencies on `0.70.3` and indirect dependencies on `^0.70.1`, so that everything resolves to `0.70.3`.
Changelog: [Internal]
Reviewed By: jacdebug, cortinico
Differential Revision: D36131458
fbshipit-source-id: d1ad72432b664b7191b2431d3c3b95b70f3a81d7
Summary:
Changelog:
[Breaking][General] Remove jest/preprocessor from the react-native package
Using `react-native/jest/preprocessor` outside of the React Native repo has been deprecated since D34820086 (https://github.com/facebook/react-native/commit/c1e9aa9a272aed3cba60c4aeff783eeb8bffce68). Here, we make this file private and stop publishing it to npm.
The supported method of using Jest in React Native projects is using the [Jest preset](https://jestjs.io/docs/tutorial-react-native) shipped as part of the `react-native` package.
NOTE: We could probably make some of the other files under `jest/` private as well, but we should go through a separate deprecation cycle with those, in case they are also being used externally by some projects. I'm leaving that for future followup at the moment.
Reviewed By: GijsWeterings
Differential Revision: D36132939
fbshipit-source-id: 300ffa6cf16232573cd3a79a34c14daaafd7aa43
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33773
I noticed this was a very slow part of my build because each instance of the binary would run its own yarn install. Instead use the yarn_workspace approach to share a single yarn setup.
Changelog: [Internal]
Reviewed By: d16r
Differential Revision: D36164350
fbshipit-source-id: 5290587010fe6021b758bda98bf01995fdf14acd
Summary:
Noticed in D36098912 (https://github.com/facebook/react-native/commit/5de0f145eca36d3263cb8a9928add278cdfffa2b) that the definition of NativeAnimatedModule's OperationQueue.isEmpty was incorrect as it didn't account for `mPeekedOperation`, while `drainQueueIntoList` did.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D36109810
fbshipit-source-id: afd7059975ce6e5c65d1975d168a03f0881bd7c1
Summary:
Adjust logs during `pod install` to warn user about longer install times due to Hermes compilation.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D36143766
fbshipit-source-id: 0facb2e295543438dfbc46d11db1c4dc163acff9
Summary:
The ReactAndroid cmake build assumes that the build directory is ReactAndroid/build, but this is not always the case if gradle is configured with a different build location. Instead of assuming the build location in cmake, pass it from gradle.
## Changelog
[Android] [Fixed] - Pass react build dir to cmake
Pull Request resolved: https://github.com/facebook/react-native/pull/33736
Test Plan:
Tested in an app with a custom build dir that RN now builds properly after this change.
In build.gradle add:
```groovy
allprojects {
buildDir = "${System.getProperty("user.home")}/.gradle/builds/${rootProject.name}/${project.name}"
}
```
Reviewed By: christophpurrer
Differential Revision: D36128556
Pulled By: cortinico
fbshipit-source-id: cdb8283c93ea7c384ec94cd3e24012220965b6dc
Summary:
This change caused some internal regression in release builds, hence reverting it
Changelog:
[Internal] [Changed] - Back out > Add CompositeReactPackageTurboModuleManagerDelegate
Reviewed By: alsun2001
Differential Revision: D36182014
fbshipit-source-id: e49fc897f3b1a2e9d33fcb7687244be74020c5be
Summary:
Changelog:
[General][Breaking] - Remove nonstandard Promise.prototype.done
`Promise.prototype.done` has been deprecated since D34222667 (https://github.com/facebook/react-native/commit/35800962c16a33eb8e9ff1adfd428cf00bb670d3). Here we remove it from React Native's default Promise polyfill. Users should switch to using standard Promise features like `.then()`, or install their own custom polyfills for advanced use cases.
Reviewed By: kodafb
Differential Revision: D36001688
fbshipit-source-id: 37f452000c16279280ef6a50b2ce616776377c4e
Summary:
We are working on making the empty object literal `{}` have the type `{}` - i.e. exact empty object - rather than being unsealed.
Some manual fixes, in particular to React Native code, which is used and can be synced to other repos (e.g. WWW).
With these changes, error diff in Xplat is down to ~1990 errors
Note that after I roll out `exact_empty_objects`, I'll codemod all the `{...null}` (the only way to get an exact empty object currently) back to `{}`
Changelog: [Internal]
Reviewed By: SamChou19815
Differential Revision: D36142838
fbshipit-source-id: 054caf370db230f42a4c5f5706c88979ef246537
Summary:
Assertion failure would lead to a crash, in real world not being able to start an activity shouldn't crash - usually a navigation won't happen as expected, user could try again.
Changelog:
[Android][Changed] - Don't assert on current activity when call startActivityForResult
Reviewed By: cortinico
Differential Revision: D35746652
fbshipit-source-id: 0b77ca5a69b2f3f3b0b969d84980ed8290ac9b1f
Summary:
Remove old deprecated modules that cause annoying warnings. This can be a breaking change for some third-party modules.
## Changelog
[General] [Removed] - Remove deprecated removeListener methods
Pull Request resolved: https://github.com/facebook/react-native/pull/33580
Test Plan: See `flow-check` and `build-arvr-js-flow` succeed in Sandcastle.
Reviewed By: cortinico
Differential Revision: D35549719
Pulled By: yungsters
fbshipit-source-id: 0495e36de19db434362d5de56463d9c1ad6edd73
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33758
This fails to compile in our CircleCI builds
```
/root/react-native/ReactAndroid/src/main/java/com/facebook/react/CompositeReactPackageTurboModuleManagerDelegate.java:52: error: incompatible types: java.util.List<java.lang.Object> cannot be converted to java.util.List<com.facebook.react.ReactPackage>
delegates.add(delegatesBuilder.build(context, Collections.emptyList()));
```
Make the empty collection generic should solve the issue
Changelog:
[Internal] [Changed] - Fix Circle CI for CompositeReactPackageTurboModuleManagerDelegate
Reviewed By: cortinico, dmitryrykun
Differential Revision: D36130573
fbshipit-source-id: 9615311798fbbd7c000838dfbc043f450c2d9e2e
Summary:
Using Fabric with a Swift native module is currently broken. There are currently two issues.
If you try to integrate a native module with Swift code, you will get the following error when running `pod install` with Fabric enabled:
```
[!] The following Swift pods cannot yet be integrated as static libraries:
The Swift pod `MyNativeView` depends upon `React-RCTFabric`, `React-Codegen`, `RCTTypeSafety`, and `ReactCommon`, which do not define modules.
To opt into those targets generating module maps (which is necessary to import them from Swift when building as static libraries),
you may set `use_modular_headers!` globally in your Podfile, or specify `:modular_headers => true` for particular dependencies.
```
To resolve this, I have applied the suggestion from the error (set `:modular_headers => true` for the appropriate modules inside `react_native_pods.rb`.
Afterwards, `pod install` succeeds but I still got `Redefinition of module 'React'` during the build due to the conflict inside the generated modulesmaps `React-Core.modulemap` and `React-RCTFabric.modulemap`. This makes sense since `React-RCTFabric.podspec` has `s.header_dir = "React"` (see [here](https://github.com/facebook/react-native/blob/main/React/React-RCTFabric.podspec#L37)) and the module inherits that. However, we can explicitly specify `module_name` for the podspec which is what I have done. I have named the module `Fabric`, let me know if you think there's a better name.
## 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] - Fix using Swift in a native module with Fabric enabled
Pull Request resolved: https://github.com/facebook/react-native/pull/33743
Test Plan:
1. Clone [this](https://github.com/fortmarek/react-native) repo
2. From `main`, apply changes from [this](https://github.com/fortmarek/react-native/commit/26958fccf4b4ac90d0bf9bb3699f12760a6b2b58) commit (adding Swift file to the `MyNativeView` native module in the RN tester app)
3. Try to run `USE_FABRIC=1 RCT_NEW_ARCH_ENABLED=1 USE_CODEGEN_DISCOVERY=1 USE_HERMES=0 bundle exec pod install` inside the `packages/rn-tester`
4. Observe errors
5. Apply [the commit](https://github.com/facebook/react-native/commit/9772c6209d73257f679b76407e1b5a27ffe03219) from this PR
6. Both pod install and the subsequent build should succeed.
I can also make changes to the current `MyNativeView` module to include Swift as well if it's something that the React Native Core team would be interested in - in case you want the Swift native modules to be always buildable on `main`
Reviewed By: dmitryrykun
Differential Revision: D36097852
Pulled By: cipolleschi
fbshipit-source-id: 2faebcffd1115339f89a406e265a6a040218dc9c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33749
Yet another bump of the Codegen to ship new features for RN 0.69
Changelog:
[Internal] [Changed] - Bump React Native Codegen to 0.0.16
Reviewed By: cipolleschi
Differential Revision: D36096803
fbshipit-source-id: 46e118f633eff2abf636737e69718e8fcb3608ed
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33729
This PR addresses [this comment](https://www.internalfb.com/diff/D35820848?dst_version_fbid=496290878846487&transaction_fbid=355967423221044).
It makes the CodeGen to the `outputDir` as base directory for the codegen.
Finally, it updates the unit tests accordingly.
## Changelog
[iOS][Changed] - use `outputDir` as base directory for the codegen and remove the possibility to customize the intermediate path. The generated code requires specific paths in the `#include` directive.
Reviewed By: cortinico, dmitryrykun
Differential Revision: D35935282
fbshipit-source-id: a9ad4e296efb042cf34b20db5eebb59614beb5f6
Summary:
This Diff splits the `generate-specs-cli.js` script into:
* `generate-specs-cli-executor.js`: which contains the logic to generate the code for iOS.
* `generate-specs-cli.js`: which contains the argument parsing logic and invokes the executor.
Finally it introduces some tests.
## Changelog
[iOS][Changed] - Refactor part of the codegen scripts and add tests.
Reviewed By: cortinico, dmitryrykun
Differential Revision: D35892576
fbshipit-source-id: 6a3205af049bf55aa4ecaf64544ebc4eb7b13f73
Summary:
This Diff splits the `generate-artifacts.js` script into:
* `generate-artifacts-executor.js`: which contains the logic to generate the code for iOS.
* `generate-artifacts.js`: which contains the argument parsing logic and invokes the executor.
Finally, it introduces some tests.
## Changelog
[iOS][Changed] - Refactor part of the codegen scripts and add tests.
Reviewed By: cortinico, dmitryrykun
Differential Revision: D35846674
fbshipit-source-id: 14873c3fe762606e9004a29e4a6b986bf6a8f055
Summary:
This Diff introduces some changes in the CodeGen to properly generate the types in the right folder.
## Issue
The codegen on iOS defines the output folder once, before creating the generated code.
When the code we have to generate is just a TurboModule (TM) or a Fabric Component (FC), this mechanism works properly.
However, if a library has to generate both TM and FC, actually using the library type `all`, all the code is generated using the TurboModules' output folder.
(**Note:** Android only works in this way)
This generates invalid code because all the FC's `#import` directives assumes that the code is generated in the FC output path which, in this case, is not.
## Solution
The adopted solution moves the responsibility to decide where the files has to be generated to the CodeGen step instead of in the preparatory phases.
The two paths are precomputed in the `generate-artifacts.js` script (the entry point for the CodeGen) and they are passed to all the scripts that requires them.
Once they reach the `RNCodegen.js` file, the generators creates the files and save them in the proper paths.
## Changelog
[iOS][Changed] - CodeGen now supports the `"all"` library type.
Reviewed By: cortinico, dmitryrykun
Differential Revision: D35820848
fbshipit-source-id: ce7f5393936e2ae17f8b2c970f6a011d27f641f2
Summary:
This diff adds a CompositeReactPackageTurboModuleManagerDelegate which can be used to combine 1 or more TurboModuleManagerDelegates into a single one.
This is useful when both the app and one or multiple of its libraries provides a TurboModuleManagerDelegate
Changelog:
[Internal] [Changed] - Add CompositeReactPackageTurboModuleManagerDelegate
Reviewed By: cortinico
Differential Revision: D36057036
fbshipit-source-id: bf131fa7315941b3353c0522e4d77d909b82914b
Summary:
We are working on making the empty object literal `{}` have the type `{}` - i.e. exact empty object - rather than being unsealed.
Making this change exposes a variety of errors. We can prevent these errors by annotating what we want the type of the empty object to be.
Reduces Xplat error diff to 2.3k
- Announcement: [post](https://fb.workplace.com/groups/flowlang/posts/903386663600331)
- Support group: [Flow Support](https://fb.workplace.com/groups/flow)
drop-conflicts
Format:
```
arc f
```
Sort imports
```
hg l -n | xargs js1 lint --fix --rule 'fb-tools/sort-requires'
```
Changelog: [Internal]
Reviewed By: samwgoldman
Differential Revision: D36086696
fbshipit-source-id: 90447279f2e6e38f44189b74ec0297719f7adf58
Summary:
With the new architecture, this diagnostic utility will be helpful to ensure stronger validation of various corner cases at runtime, like handling an early JavaScript exception when loading React Native.
If `global.RN$DiagnosticFlags` is set to a string of comma-separated flags, the util functions will be able to perform additional diagnostics. For now, the accepted flags are:
- `early_js_errors`
- `all`
This is still experimental and may change frequently.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D36088407
fbshipit-source-id: 9059d2d081b0f41d049310fb09650416b333ff57
Summary: There's no need to use private feature flag for overflowInset feature. This makes future refactor on feature flags easier.
Reviewed By: javache
Differential Revision: D35866302
fbshipit-source-id: a3fde212ff40cd6d4c68832bb39b34de5a17a8d4
Summary:
Changelog:
[Internal]
Cleans up unnecessary type casts / suppressions throughout the codebase following D35869725.
Reviewed By: javache
Differential Revision: D35870027
fbshipit-source-id: eefcb544b19ba93587011cdfd4046d18dddb246e
Summary:
Changelog:
[General][Fixed] - Improved Flow type inference in Animated `.interpolate()`
Improves the ergonomics of `.interpolate()` by allowing Flow to infer the correct type for `outputRange`. This is achieved by adding a new type parameter `OutputT` to `interpolate()` (and `Animated.Interpolation` and `InterpolationConfigType`), which Flow infers as either `number` or `string` based on usage.
Admittedly, at the call site, this is not that much safer compared to something like `outputRange: $ReadOnlyArray<number | string>`, but it does document the intent of the API a bit better and provide some downstream type safety. For example, we can now express `Animated.Number` (D35869375) more precisely by excluding string-valued interpolation nodes.
Reviewed By: javache
Differential Revision: D35869725
fbshipit-source-id: e03ec22e9b3368ee196b392af011062ac99d8bb9
Summary:
Changelog: [General][Added] - Add `Animated.Numeric` Flow type
Adds a Flow type to represent the various Animated node types that evaluate to numeric values and can be `interpolate()`d.
I'm including `AnimatedInterpolation` as "numeric" here even though it can technically evaluate either to a number or to a string, depending on its config. Note that calling `interpolate()` on a string-valued `AnimatedInterpolation` is a runtime error.
In a future diff, I'm planning to add a type argument to `AnimatedInterpolation` (and its config type), at which point we can refine `Animated.Numeric` to correctly include only `AnimatedInterpolation<number>`.
Reviewed By: javache
Differential Revision: D35869375
fbshipit-source-id: 2ff6754f1a5abc68c9da2c6836872c2022b25676
Summary:
I wrote a test for a vibration feature in a react native app by importing the `Vibration` module and using `jest.spyOn(Vibration, 'vibrate')`.
I had the following error:
```
Invariant Violation: TurboModuleRegistry.getEnforcing(...): 'Vibration' could not be found. Verify that a module by this name is registered in the native binary.
```
That lead me to look for (and not find) a mock for the `Vibration` module in the code.
## 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] - Add Jest mock for Vibration module
Pull Request resolved: https://github.com/facebook/react-native/pull/30643
Test Plan:
I would be glad to provide a test plan for this, but as it is part of testing I don't really know how to do so.
Any suggestion or help is welcome!
Reviewed By: yungsters
Differential Revision: D36097003
Pulled By: cortinico
fbshipit-source-id: 58683120da34f40e142a44c4bef8a5fced04bac2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33747
This Diff connects the ruby tests setup with CircleCI, making sure that we are executing the same script in Sandcastle and CircleCI.
At the moment, the scripts runs somedummy tests to make sure that everything works.
## Changelog
[iOS][Changed] - Add ruby tests to circleci
Reviewed By: dmitryrykun
Differential Revision: D36091716
fbshipit-source-id: c432e5f8b5269754db2b7ec278b159dcedf3b3b9
Summary:
This PR adds a step in the iOS legocastle script to run the ruby tests in the cocoapods folder.
These tests are executed before the pod installation step: this because we would like to fail as fast as possible in case of issues.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D36006781
fbshipit-source-id: 8afbc1ccc751d2dc736bdc23ec382ebd7b5c7f4f
Summary:
This Diff prepares a set of dummy tests to make sure that our infra supports tests in ruby.
It also adds a scripts in the `__tests__` folder which can be invoked to run all the tests. The script performs a discovery of all the tests in the cocoapods folder.
Next steps will configure Sandcastles and CircleCI.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D35968556
fbshipit-source-id: b8bf23d30dc5358ab603e396cce1c6639dd0f567
Summary:
Changelog: [Internal][iOS] Fix AppState in Bridgeless mode by removing guard for bridge, since it doesn't use bridge
AppState doesn't use bridge because RCTAppState subclasses RCTEventEmitter, which calls `_callableJSModules invokeModule` in both Bridge and Bridgeless mode to send events to JS.
Reviewed By: fkgozali
Differential Revision: D35988515
fbshipit-source-id: fb19f0f2df5b270f0ef57637930f94686e39a9a1
Summary:
This PR reestablish the WebSocketTest in CI which is making the `test_ios_unit` fail.
**Note:** the test_ios_unit is actually running integration tests...
## Changelog
[iOS] [Changed] - Fix the test_ios_unit test
Pull Request resolved: https://github.com/facebook/react-native/pull/33721
Test Plan: The CI of this PR is green. 😬
Reviewed By: cortinico
Differential Revision: D36002823
Pulled By: cipolleschi
fbshipit-source-id: 20eeb08bfd02658ad6579085241f81654f74c1af
Summary:
During the release of .69, we (fortmarek and me) discovered a couple of bits that needed
some intervention.
- `sdks/.hermesversion` was gitignored, so we could not commit that.
- `scripts/bump-hermes-version.js` was not executable, so we had to chmod +x to
make it runnable.
Here I'm fixing it.
Changelog:
[Internal] [Changed] - Fix release infrastructure failures discovered during .69 release
Reviewed By: cipolleschi
Differential Revision: D36003808
fbshipit-source-id: c4d82ed5e2c63988699035ac84b0e87ed8894540
2022-04-28 07:48:40 -07:00
5376 changed files with 207902 additions and 132331 deletions
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
description:Please provide a clear and concise description of what the bug is. Include screenshots if needed. Test using the [latest React Native release](https://github.com/facebook/react-native/releases/latest) to make sure your issue has not already been fixed.
validations:
required:true
- type:input
id:version
attributes:
label:Version
description:What react-native version does this appear on?
placeholder:ex. 0.66.0
label:React Native Version
description:What is the latest version of react-native that this issue reproduces on? Please only list the highest version you tested. Bear in mind that only issues on [supported versions](https://github.com/reactwg/react-native-releases#which-versions-are-currently-supported) will be looked into.
placeholder:ex. 0.71.0
validations:
required:true
- type:textarea
@@ -40,8 +40,9 @@ body:
attributes:
label:Snack, code example, screenshot, or link to a repository
description:|
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.
Please provide a Snack (https://snack.expo.dev/), 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
Please note that a reproducer is **mandatory**. Issues without reproducer are more likely to stall and will be closed.
about:Questions and doubts related to technical questions for the New Architecture should be directed to the Working Group. Instructions on how to join are available in the README.
description:Report a reproducible bug or a build issue when using the New Architecture (Fabric & TurboModules) in React Native.
labels:["Needs: Triage :mag:","Type: New Architecture"]
body:
- type:markdown
attributes:
value:|
Please provide all the information requested. Issues that do not follow this format are going to be closed.
This issue report is reserved to bug & build issues for users on the New Architecture. If you're not using
the New Architecture, please don't open issues on this category.
- type:textarea
id:description
attributes:
label:Description
description:|
Please provide a clear and concise description of what the bug or issue is. Include screenshots if needed.
Please make sure you check the New Architecture documentation first, as your issue might
already be answered there - https://reactnative.dev/docs/next/new-architecture-intro
validations:
required:true
- type:input
id:version
attributes:
label:React Native Version
description:What is the latest version of react-native that this issue reproduces on? Please test against the latest stable version, and list only the highest version you tested. Bug reports against older versions are more likely to stall.
placeholder:ex. 0.71.0
validations:
required:true
- type:textarea
id:react-native-info
attributes:
label:Output of `npx react-native info`
description:Run `npx react-native info` in your terminal, copy and paste the results here.
validations:
required:true
- type:textarea
id:reproduction
attributes:
label:Steps to reproduce
description:Provide a detailed list of steps that reproduce the issue.
validations:
required:true
- type:textarea
id:extra
attributes:
label:Snack, code example, screenshot, or link to a repository
description:|
Please provide a Snack (https://snack.expo.dev/), 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
Please note that a reproducer is **mandatory**. Issues without reproducer are more likely to stall and will be closed.
Please use this form to file an issue if you have upgarded or are upgrading to [latest stable release](https://github.com/facebook/react-native/releases/latest) and have experienced a regression (something that used to work in previous version).
Please use this form to file an issue if you have upgraded or are upgrading to [latest stable release](https://github.com/facebook/react-native/releases/latest) and have experienced a regression (something that used to work in previous version).
You can participate in the conversation on the status of this release in the [working group](https://github.com/reactwg/react-native-releases/discussions).
---
To help you upgrade to this version, you can use the [upgrade helper](https://react-native-community.github.io/upgrade-helper/) ⚛️
---
See changes from this release in the [changelog PR](https://github.com/facebook/react-native/labels/%F0%9F%93%9D%20Changelog)
# Configuration for Respond To Issue Based on Label https://github.com/marketplace/actions/respond-to-issue-based-on-label
"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
"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.
* Copyright (c) Meta Platforms, Inc. and affiliates.
*
* This source code is licensed under the MIT license found in the
* LICENSE file in the root directory of this source tree.
*
* @format
*/
module.exports=async(github,context,label)=>{
constcloseIssue=async()=>{
awaitgithub.rest.issues.update({
issue_number:context.issue.number,
owner:context.repo.owner,
repo:context.repo.repo,
state:'closed',
});
};
constaddComment=asynccomment=>{
awaitgithub.rest.issues.createComment({
issue_number:context.issue.number,
owner:context.repo.owner,
repo:context.repo.repo,
body:comment,
});
};
constrequestAuthorFeedback=async()=>{
// Remove the triage label if it exists (ignore the 404 if not; it's not expected to always be there)
try{
awaitgithub.rest.issues.removeLabel({
issue_number:context.issue.number,
owner:context.repo.owner,
repo:context.repo.repo,
name:'Needs: Triage :mag:',
});
}catch{}
awaitgithub.rest.issues.addLabels({
issue_number:context.issue.number,
owner:context.repo.owner,
repo:context.repo.repo,
labels:['Needs: Author Feedback'],
});
};
switch(label){
case'Type: Invalid':
awaitaddComment(
`| :warning: | Issue is Invalid |\n`+
`| --- | --- |\n`+
`| :information_source: | This issue doesn't match any of the expected types for this repository - closing. |`,
);
awaitcloseIssue();
return;
case'Type: Question':
awaitaddComment(
`| :warning: | Issue is a Question |\n`+
`| --- | --- |\n`+
`| :information_source: | 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/). |`,
);
awaitcloseIssue();
return;
case'Type: Docs':
awaitaddComment(
`| :warning: | Documentation Issue |\n`+
`| --- | --- |\n`+
`| :information_source: | Please report documentation issues in the [react-native-website](https://github.com/facebook/react-native-website/issues) repository. |`,
);
awaitcloseIssue();
return;
case'Resolution: For Stack Overflow':
awaitaddComment(
`| :warning: | Issue is a Question |\n`+
`| --- | --- |\n`+
`| :information_source: | 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. |`,
);
awaitcloseIssue();
return;
case'Type: Expo':
awaitaddComment(
`| :warning: | Issue is Related to Expo |\n`+
`| --- | --- |\n`+
`| :information_source: | It looks like your issue is related to Expo and not React Native core. Please open your issue in [Expo's repository](https://github.com/expo/expo/issues/new). If you are able to create a repro that showcases that this issue is also happening in React Native vanilla, we will be happy to re-open. |`,
);
awaitcloseIssue();
return;
case'Needs: Issue Template':
awaitaddComment(
`| :warning: | Missing Required Fields |\n`+
`| --- | --- |\n`+
`| :information_source: | It looks like your issue may be missing some necessary information. GitHub provides an example template whenever a [new issue is created](https://github.com/facebook/react-native/issues/new?template=bug_report.md). 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. |`,
);
awaitrequestAuthorFeedback();
return;
case'Needs: Environment Info':
awaitaddComment(
`| :warning: | Missing Environment Information |\n`+
`| --- | --- |\n`+
`| :information_source: | 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. |`,
);
awaitrequestAuthorFeedback();
return;
case'Needs: Verify on Latest Version':
awaitaddComment(
`| :warning: | Newer Version of React Native is Available! |\n`+
`| --- | --- |\n`+
`| :information_source: | You are on a supported minor version, but it looks like there's a newer patch available. Please [upgrade](https://reactnative.dev/docs/upgrading) to the highest patch for your minor or latest and verify if the issue persists (alternatively, create a new project and repro the issue in it). If it does not repro, 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 most recent releases. |`,
);
return;
case'Needs: Version Info':
awaitaddComment(
`| :warning: | Add or Reformat Version Info |\n`+
`| --- | --- |\n`+
`| :information_source: | We could not find or parse the version number of React Native in your issue report. Please use the template, and report your version including major, minor, and patch numbers - e.g. 0.70.2 |`,
);
awaitrequestAuthorFeedback();
return;
case'Needs: Repro':
awaitaddComment(
`| :warning: | Missing Reproducible Example |\n`+
`| --- | --- |\n`+
`| :information_source: | It looks like your issue is missing a reproducible example. Please provide a [Snack](https://snack.expo.dev) or a repository that demonstrates the issue you are reporting in a [minimal, complete, and reproducible](https://stackoverflow.com/help/minimal-reproducible-example) manner. |`,
);
awaitrequestAuthorFeedback();
return;
case'Type: Unsupported Version':
awaitaddComment(
`| :warning: | Unsupported Version of React Native |\n`+
`| --- | --- |\n`+
`| :information_source: | It looks like your issue or the example you provided uses an [unsupported version of React Native](https://github.com/reactwg/react-native-releases/blob/main/README.md#releases-support-policy). Due to the number of issues we receive, we're currently only accepting new issues against one of the supported versions. Please [upgrade](https://reactnative.dev/docs/upgrading) to latest and verify if the issue persists (alternatively, create a new project and repro the issue in it). If you cannot upgrade, please open your issue on [StackOverflow](https://stackoverflow.com/questions/tagged/react-native) to get further community support. |`,
body: `This pull request was successfully merged by ${authorName} in **${sha}**.\n\n<sup>[When will my fix make it into a release?](https://github.com/facebook/react-native/wiki/Release-FAQ#when-will-my-fix-make-it-into-a-release) | [Upcoming Releases](https://github.com/reactwg/react-native-releases/discussions/categories/releases)</sup>`
stale-pr-message:'This PR is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.'
close-issue-message:'This issue was closed because it has been stalled for 7 days with no activity.'
close-pr-message:'This PR was closed because it has been stalled for 7 days with no activity.'
exempt-issue-labels:Help Wanted :octocat:, Good first issue, Never gets stale
exempt-pr-labels:Help Wanted :octocat:, Good first issue, Never gets stale
stale-asc:
runs-on:ubuntu-latest
if:github.repository == 'facebook/react-native'
permissions:
issues:write
pull-requests:write
steps:
- uses:actions/stale@v5
with:
ascending:true
repo-token:${{ secrets.GITHUB_TOKEN }}
days-before-stale:180
stale-issue-message:'This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.'
stale-pr-message:'This PR is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.'
close-issue-message:'This issue was closed because it has been stalled for 7 days with no activity.'
close-pr-message:'This PR was closed because it has been stalled for 7 days with no activity.'
exempt-issue-labels:Help Wanted :octocat:, Good first issue, Never gets stale
exempt-pr-labels:Help Wanted :octocat:, Good first issue, Never gets stale
stale-needs-author-feedback:
runs-on:ubuntu-latest
if:github.repository == 'facebook/react-native'
permissions:
issues:write
pull-requests:write
steps:
- uses:actions/stale@v5
with:
repo-token:${{ secrets.GITHUB_TOKEN }}
any-of-labels:'Needs:Author Feedback'
days-before-stale:24
stale-issue-message:"This issue is waiting for author's feedback since 24 days. Please provide the requested feedback or this will be closed in 7 days."
stale-pr-message:"This PR is waiting for author's feedback since 24 days. Please provide the requested feedback or this will be closed in 7 days"
close-issue-message:"This issue was closed because the author hasn't provided the requested feedback after 7 days."
close-pr-message:"This PR was closed because the author hasn't provided the requested feedback after 7 days."
exempt-issue-labels:Help Wanted :octocat:, Good first issue, Never gets stale
exempt-pr-labels:Help Wanted :octocat:, Good first issue, Never gets stale
stale-needs-author-feedback-asc:
runs-on:ubuntu-latest
if:github.repository == 'facebook/react-native'
permissions:
issues:write
pull-requests:write
steps:
- uses:actions/stale@v5
with:
ascending:true
repo-token:${{ secrets.GITHUB_TOKEN }}
any-of-labels:'Needs:Author Feedback'
days-before-stale:24
stale-issue-message:"This issue is waiting for author's feedback since 24 days. Please provide the requested feedback or this will be closed in 7 days."
stale-pr-message:"This PR is waiting for author's feedback since 24 days. Please provide the requested feedback or this will be closed in 7 days"
close-issue-message:"This issue was closed because the author hasn't provided the requested feedback after 7 days."
close-pr-message:"This PR was closed because the author hasn't provided the requested feedback after 7 days."
exempt-issue-labels:Help Wanted :octocat:, Good first issue, Never gets stale
exempt-pr-labels:Help Wanted :octocat:, Good first issue, Never gets stale
Thank you for your interest in contributing to React Native! From commenting on and triaging issues, to reviewing and sending Pull Requests, all contributions are welcome. We aim to build a vibrant and inclusive [ecosystem of partners, core contributors, and community](ECOSYSTEM.md) that goes beyond the main React Native GitHub repository.
Thank you for your interest in contributing to React Native! From commenting on and triaging issues, to reviewing and sending Pull Requests, all contributions are welcome.
We aim to build a vibrant and inclusive [ecosystem of partners, core contributors, and community](ECOSYSTEM.md) that goes beyond the main React Native GitHub repository.
The [Open Source Guides](https://opensource.guide/) website has a collection of resources for individuals, communities, and companies who want to learn how to run and contribute to an open source project. Contributors and people new to open source alike will find the following guides especially useful:
* [How to Contribute to Open Source](https://opensource.guide/how-to-contribute/)
### [Code of Conduct](https://github.com/facebook/react-native/blob/HEAD/CODE_OF_CONDUCT.md)
As a reminder, all contributors are expected to adhere to the [Code of Conduct](https://github.com/facebook/react-native/blob/HEAD/CODE_OF_CONDUCT.md).
## Ways to Contribute
If you are eager to start contributing code right away, we have a list of [good first issues](https://github.com/facebook/react-native/labels/good%20first%20issue) that contain bugs which have a relatively limited scope. As you gain more experience and demonstrate a commitment to evolving React Native, you may be granted issue management permissions in the repository.
There are other ways you can contribute without writing a single line of code. Here are a few things you can do to help out:
1.**Replying and handling open issues.** We get a lot of issues every day, and some of them may lack necessary information. You can help out by guiding people through the process of filling out the issue template, asking for clarifying information, or pointing them to existing issues that match their description of the problem. We cover more about this process in the [Issue Triage wiki](https://github.com/facebook/react-native/wiki/Triaging-GitHub-Issues).
2.**Reviewing pull requests for the docs.** Reviewing [documentation updates](https://github.com/facebook/react-native-website/pulls) can be as simple as checking for spelling and grammar. If you encounter situations that can be explained better in the docs, click **Edit** at the top of most docs pages to get started with your own contribution.
3.**Help people write test plans.** Some pull requests sent to the main repository may lack a proper test plan. These help reviewers understand how the change was tested, and can speed up the time it takes for a contribution to be accepted.
Each of these tasks is highly impactful, and maintainers will greatly appreciate your help.
### Our Development Process
We use GitHub issues and pull requests to keep track of bug reports and contributions from the community. All changes from engineers at Facebook will sync to [GitHub](https://github.com/facebook/react-native) through a bridge with Facebook's internal source control. Changes from the community are handled through GitHub pull requests. Once a change made on GitHub is approved, it will first be imported into Facebook's internal source control and tested against Facebook's codebase. Once merged at Facebook, the change will eventually sync back to GitHub as a single commit once it has passed Facebook's internal tests.
You can learn more about the contribution process in the following documents:
We also have a thriving community of contributors who would be happy to help you get set up. You can reach out to us through [@ReactNative](http://twitter.com/reactnative) (the React Native team) and [@ReactNativeComm](http://twitter.com/reactnativecomm) (the React Native Community organization).
### Repositories
The main repository, <https://github.com/facebook/react-native>, contains the React Native framework itself and it is here where we keep track of bug reports and manage pull requests.
There are a few other repositories you might want to familiarize yourself with:
* **React Native website** which contains the source code for the website, including the documentation, located at <https://github.com/facebook/react-native-website>
* **Releases** Conversations for new releases are happening [in this discussion repo](https://github.com/reactwg/react-native-releases/discussions).
* **Changelog** The changelog can be found [here](https://github.com/facebook/react-native/blob/main/CHANGELOG.md).
* **Discussions** about the future of React Native take place in the <https://github.com/react-native-community/discussions-and-proposals> repository.
* **High-quality plugins** for React Native can be found throughout the [React Native Community GitHub Organization](http://github.com/react-native-community/).
Browsing through these repositories should provide some insight into how the React Native open source project is managed.
## GitHub Issues
We use GitHub issues to track bugs exclusively. We have documented our issue handling processes in the [Issues wiki](https://github.com/facebook/react-native/wiki/Triaging-GitHub-Issues).
### Security Bugs
Facebook has a [bounty program](https://www.facebook.com/whitehat/) for the safe disclosure of security bugs. In those cases, please go through the process outlined on that page and do not file a public issue.
## 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://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.
### Contributing to the Blog
The React Native blog is generated [from the Markdown sources for the blog](https://github.com/facebook/react-native-website/tree/HEAD/website/blog).
Please open an issue in the https://github.com/facebook/react-native-website repository or tag us on [@ReactNative on Twitter](http://twitter.com/reactnative) and get the go-ahead from a maintainer before writing an article intended for the React Native blog. In most cases, you might want to share your article on your own blog or writing medium instead. It's worth asking, though, in case we find your article is a good fit for the blog.
We recommend referring to the [CONTRIBUTING](https://github.com/facebook/react-native-website/blob/HEAD/CONTRIBUTING.md) document for the `react-native-website` repository to learn more about contributing to the website in general.
## 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). 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 `main`.
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.
2. If changes are requested and addressed, please [request review](https://docs.github.com/en/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/requesting-a-pull-request-review) to notify reviewers to take another look.
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.
### Step-by-step Guide
Whenever you are ready to contribute code, check out our [step-by-step guide to sending your first pull request](https://github.com/facebook/react-native/wiki/How-to-Open-a-Pull-Request), or read the [How to Contribute Code](https://github.com/facebook/react-native/wiki/How-to-Contribute-Code) wiki for more details.
### Tests
Tests help us prevent regressions from being introduced to the codebase. The GitHub repository is continuously tested using Circle and Appveyor, the results of which are available through the Checks functionality on [commits](https://github.com/facebook/react-native/commits/HEAD) and pull requests. You can learn more about running and writing tests in the [Tests wiki](http://github.com/facebook/react-native/wiki/Tests).
## Community Contributions
Contributions to React Native are not limited to GitHub. You can help others by sharing your experience using React Native, whether that is through blog posts, presenting talks at conferences, or simply sharing your thoughts on Twitter and tagging @ReactNative.
## Where to Get Help
As you work on React Native, it is natural that sooner or later you may require help. In addition to the resources listed in [SUPPORT](.github/SUPPORT.md), people interested in contributing may take advantage of the following:
* **Twitter**. The React Native team at Facebook has its own account at [@reactnative](https://twitter.com/reactnative), and the React Native Community uses [@reactnativecomm](https://twitter.com/reactnativecomm). If you feel stuck, or need help contributing, please do not hesitate to reach out.
* **Proposals Repository**. If you are considering working on a feature large in scope, consider [creating a proposal first](https://github.com/react-native-community/discussions-and-proposals). The community can help you figure out the right approach, and we'd be happy to help.
* **React Native Community Discord**. While we try to hold most discussions in public, sometimes it can be beneficial to have conversations in real time with other contributors. People who have demonstrated a commitment to moving React Native forward through sustained contributions to the project may eventually be invited to join the React Native Community Discord.
To learn more about how to contribute check out the Contributing section on the React Native website:
We aim to build a vibrant and inclusive ecosystem of partners, core contributors, and community that goes beyond the main React Native GitHub repository. This document explains the roles and responsibilities of various stakeholders and provides guidelines for the community organization. The structure outlined in this document has been in place for a while but hadn't been written down before.
We aim to build a vibrant and inclusive ecosystem of partners, core contributors, and community that goes beyond the main React Native GitHub repository. This document explains the roles and responsibilities of various stakeholders and provides guidelines for the community organization. The structure outlined in this document has been in place for a while but had not been written down before.
There are three types of stakeholders:
* **Partners:** Companies that are significantly invested in React Native and have been for years.
* **Partners:** Companies significantly invested in React Native and take responsibility for the React Native vision and community.
* **Core Contributors:** Individual people who contribute to the React Native project.
* **Community Contributors:** Individuals who support projects in the [react-native-community](https://github.com/react-native-community) organization.
## 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. 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 demonstrate ownership. Informed by their use of React Native, they push for improvements of the core and/or the ecosystem around it. Examples of this may include large scale contributions to `react-native` or owning essential tools or libraries.
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:
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.
* **[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
***[Facebook](https://opensource.facebook.com):** Oversees the React Native product and maintains the [React Native core repo](https://reactnative.dev/)
***[Infinite Red](https://infinite.red/):** Maintains the [ignite cli/boilerplate](https://github.com/infinitered/ignite), organizes [Chain React Conf](https://cr.infinite.red/)
* **[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.
Baseline responsibilities of partners include:
*Attending monthly meeting
*Contributing to the release process. Examples include being a [community releaser](https://reactnative.dev/contributing/release-roles-responsibilities#release-role-2-community-releaser), testing new releases, technical support for release issues.
*Engage on the core contributor Discord
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:
Our current partners and other areas of ownership:
***[Coinbase](https://www.coinbase.com/):** Publishes [posts](https://blog.coinbase.com/tagged/react-native) advocating React Native usage. Supports `@react-native-community/datetimepicker` and other community modules to migrate to the new architecture. Supports releases in testing and feedback.
***[Callstack](https://callstack.com/):** Maintains the [React Native CLI](https://github.com/react-native-community/react-native-cli) and [other community libraries](https://github.com/callstack), organizes [React Native EU](https://react-native.eu/) and hosts [The React Native Show podcast](https://www.callstack.com/podcast-react-native-show)
***[Expo](https://expo.dev/):** Builds [Expo Go and SDK](https://github.com/expo/expo), [Snack](https://snack.expo.dev/), and [Expo Application Services](https://expo.dev/eas). Maintains [React Native Directory](https://reactnative.directory/), stewards [React Navigation](https://reactnavigation.org/) along with other partners.
***[Infinite Red](https://infinite.red/):** Maintains the [ignite cli/boilerplate](https://github.com/infinitered/ignite), organizes [Chain React Conf](https://cr.infinite.red/), hosts the [React Native Radio podcast](https://reactnativeradio.com), publishes the [React Native Newsletter](https://reactnativenewsletter.com)
***[Meta](https://opensource.fb.com/):** Oversees the React Native product and maintains the [React Native core repo](https://reactnative.dev/)
***[Microsoft](https://twitter.com/ReactNativeMSFT):** 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; maintains [rnx-kit](https://github.com/microsoft/rnx-kit), [react-native-test-app](https://github.com/microsoft/react-native-test-app) and coordinates cross-companies efforts such as the [bundle working group](https://github.com/microsoft/rnx-kit/discussions/categories/bundle-working-group).
***[Shopify](https://www.shopify.com/):** Maintains React Native open source libraries such as [flash-list](https://github.com/Shopify/flash-list) or [@shopify/react-native-skia](https://github.com/Shopify/react-native-skia) and sponsors Software Mansion.
***[Software Mansion](https://swmansion.com/):** Maintain core infrastructure including JSC, Animated, and other popular third-party plugins and organizes [App.js Conf](https://appjs.co/)
***[Wix.com](https://wix.engineering/open-source):** Maintains a variety of React Native open source projects ([see all](https://github.com/orgs/wix/repositories?q=react-native)), including: [Detox](https://wix.github.io/Detox/) end-to-end testing library for React Native apps, [RN UILib](https://wix.github.io/react-native-ui-lib/), [RN Navigation](https://wix.github.io/react-native-navigation/), [RN Calendars](https://wix.github.io/react-native-calendars/) and [RN Notifications](https://github.com/wix/react-native-notifications).
This list may fluctuate in response to newcomers who meet our partner definition. 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:
## Core Contributors
@@ -38,13 +47,19 @@ Core contributors are individuals who contribute to the React Native project. A
These are behaviors we have observed in our existing core contributors. They aren't strict rules but rather outline their usual responsibilities. We do not expect every core contributor to do all of the above things all the time. Most importantly, we want to create a supportive and friendly environment that fosters collaboration. Above all else, **we are always polite and friendly.**
Core contributor status is attained after consistently contributing and taking on the responsibilities outlined above and granted by other core contributors. Similarly, after a long period of inactivity, a core contributor may be removed.
Core contributor status is attained after consistently contributing and taking on the responsibilities outlined above and granted by other core contributors. Similarly, after a long period of inactivity (~6 months or more), a core contributor may be contacted to understand if they’re still interested in being part of the program.
We aim to make contributing to React Native as easy and transparent as possible. All important topics are handled through a [discussion or RFC process on GitHub](https://github.com/react-native-community/discussions-and-proposals). We are always looking for active, enthusiastic members of the React Native community to become core contributors.
You can use this [form](https://forms.gle/4jpA4QeNUvAUDnNe8) to either:
* Apply yourself to become a Core Contributor. Make sure to include a list of valuable contributions you did to the React Native repository and ecosystem.
* Nominate someone to become a Core Contributor.
As a core contributor, you will have access to the core contributor Discord which is used for light-weight coordination and discussion.
**We aim to make contributing to React Native as easy and transparent as possible.** We have discussion groups dedicated to the [new architecture rollout](https://github.com/reactwg/react-native-new-architecture), [releases](https://github.com/reactwg/react-native-releases), and [general questions and proposals](https://github.com/react-native-community/discussions-and-proposals). We are always looking for active, enthusiastic members of the React Native community to become core contributors.
## Community Contributors
Community contributors are individuals who support projects in the [react-native-community](https://github.com/react-native-community) organization. This organization exists as an incubator for high quality components that extend the capabilities of React Native with functionality that many but not all applications require. Facebook engineers will provide guidance to help build a vibrant community of people and components that make React Native better.
Community contributors are individuals who support projects in the [react-native-community](https://github.com/react-native-community) organization. This organization exists as an incubator for high quality components that extend the capabilities of React Native with functionality that many but not all applications require. Meta engineers will provide guidance to help build a vibrant community of people and components that make React Native better.
'Animated: `useNativeDriver` is not supported because the native '+
'animated module is missing. Falling back to JS-based animation. To '+
'resolve this, add `RCTAnimation` module to this app, or remove '+
'`useNativeDriver`. '+
'Make sure to run `bundle exec pod install` first. Read more about autolinking: https://github.com/react-native-community/cli/blob/master/docs/autolinking.md',
// T88715063: NativeEventEmitter only used this parameter on iOS. Now it uses it on all platforms, so this code was modified automatically to preserve its behavior
// If you want to use the native module on other platforms, please remove this condition and test its behavior
// T88715063: NativeEventEmitter only used this parameter on iOS. Now it uses it on all platforms, so this code was modified automatically to preserve its behavior
// If you want to use the native module on other platforms, please remove this condition and test its behavior
exports[`DatePickerIOS should render DatePicker with the datetime mode if no mode is passed inside the props: should deep render when mocked (please verify output manually) 1`] = `
<View>
<RCTDatePicker
date={1555883690956}
mode="datetime"
onChange={[Function]}
onResponderTerminationRequest={[Function]}
onStartShouldSetResponder={[Function]}
style={
Object {
"height": 216,
}
}
/>
</View>
`;
exports[`DatePickerIOS should render DatePicker with the datetime mode if no mode is passed inside the props: should deep render when not mocked (please verify output manually) 1`] = `
<View>
<RCTDatePicker
date={1555883690956}
mode="datetime"
onChange={[Function]}
onResponderTerminationRequest={[Function]}
onStartShouldSetResponder={[Function]}
style={
Object {
"height": 216,
}
}
/>
</View>
`;
exports[`DatePickerIOS should render DatePicker with the datetime mode if no mode is passed inside the props: should shallow render as <DatePickerIOS /> when mocked 1`] = `
<DatePickerIOS
date={2019-04-21T21:54:50.956Z}
onDateChange={[MockFunction]}
/>
`;
exports[`DatePickerIOS should render DatePicker with the datetime mode if no mode is passed inside the props: should shallow render as <DatePickerIOS /> when not mocked 1`] = `
<DatePickerIOS
date={2019-04-21T21:54:50.956Z}
onDateChange={[MockFunction]}
/>
`;
exports[`DatePickerIOS should render as expected: should deep render when mocked (please verify output manually) 1`] = `
<View>
<RCTDatePicker
date={1555883690956}
mode="date"
onChange={[Function]}
onResponderTerminationRequest={[Function]}
onStartShouldSetResponder={[Function]}
style={
Object {
"height": 216,
}
}
/>
</View>
`;
exports[`DatePickerIOS should render as expected: should deep render when not mocked (please verify output manually) 1`] = `
<View>
<RCTDatePicker
date={1555883690956}
mode="date"
onChange={[Function]}
onResponderTerminationRequest={[Function]}
onStartShouldSetResponder={[Function]}
style={
Object {
"height": 216,
}
}
/>
</View>
`;
exports[`DatePickerIOS should render as expected: should shallow render as <DatePickerIOS /> when mocked 1`] = `
<DatePickerIOS
date={2019-04-21T21:54:50.956Z}
mode="date"
onDateChange={[MockFunction]}
/>
`;
exports[`DatePickerIOS should render as expected: should shallow render as <DatePickerIOS /> when not mocked 1`] = `
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.