Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42817
## Context
We're introducing the concept of **capability flags** to provide granular control of behaviours in the Inspector Proxy, to replace the recently added `type: 'Legacy' | 'Modern'` target switch.
A capability flag disables a specific feature/hack in the Inspector Proxy layer by indicating that the target supports one or more modern CDP features.
## This diff
- Implements capability flags in `InspectorProxy`, via an optional `"capabilities"` key returned by a device's CDP server.
- Wires up an initial flag, `nativePageReloads`, to disable the legacy "React Native Experimental (Improved Chrome Reloads)" page and emulated page reload behaviour.
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D53352244
fbshipit-source-id: 622fc6028174919b9bf776e3ac52724d97ca2734
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42758
Changelog: [iOS][Added] - introduce native api to access RuntimeExecutor
The goal of this API is to provide a safe way to access the `jsi::runtime` in bridgeless mode. The decision to limit access to the runtime in bridgeless was a conscious one - the runtime pointer is not thread-safe and its lifecycle must be managed correctly by owners.
However, interacting with the runtime is an advanced use case we would want to support. Our recommended ways to access the runtime in bridgeless mode is either 1) via the RuntimeExecutor, or 2) via a C++ TurboModule.
This diff introduces the API that would allow for 1). The integration consists of these parts:
- wrapper object for RuntimeExecutor access, `RCTRuntimeExecutor`. The NSObject wrapper is necessary so we can make it the property of a swift module
- new protocol API,`RCTRuntimeExecutionModule`, for modules to access the RuntimeExecutor block
- integration within the bridgeless infrastructure
Reviewed By: javache
Differential Revision: D53256188
fbshipit-source-id: 8fadbe8f760cdb8928bbf3f7e4829e27b7617b9d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42860
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D53393473
fbshipit-source-id: 93e6be94cee4f852c85464ce151670b1c8f1f913
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42857
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
Reviewed By: rshest
Differential Revision: D53393472
fbshipit-source-id: 717507391623d67d03d83bf344475a4a830504a7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42861
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
Reviewed By: rshest
Differential Revision: D53393474
fbshipit-source-id: 4bbdf72729d3a84ad90a3071d8abcedefbe89878
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42856
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D53393476
fbshipit-source-id: b2278befdbfa45209acf36c8c73b276bb897ac8f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42853
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D53393135
fbshipit-source-id: 74a7f710eb7bf5a2e2b39e07ee4b026a425f521c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42855
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D53393136
fbshipit-source-id: 29884933200a5f9251954fc3488828767a4013fa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42854
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D53393141
fbshipit-source-id: a83840a904ba06f4dfbded2480c19d1457566f4c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42852
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D53393137
fbshipit-source-id: 9ed2d2b28d3ad6ecb644eeb494ac2511e3b2397e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42848
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D53393140
fbshipit-source-id: 90e64c746a1d72cfd91876082bdc9642c72fd896
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42825
This makes overrides for feature flags more predictable by only allowing a single point of overrides per app.
The previous behavior was:
* Common flags: the last override would win.
* JS flags: overrides would be combined and the last definition for each flag would win.
The new behavior, both for common flags and for JS flags, is to only have a single override.
Changelog: [internal]
Reviewed By: mdvacca
Differential Revision: D53360609
fbshipit-source-id: 7e299d74fada188beb1bf17eb7e25ff97015781e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42820
The feature flag system generates a significant amount of files. This reduces that number to remove noise from diffs/PRs by eliminating a file that could be defined privately within another one.
Changelog: [internal]
Reviewed By: huntie
Differential Revision: D53352391
fbshipit-source-id: 51fccb3c1bb09ef3503cd34334d28c1021bd1b25
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42815
Feature flags were originally defined in a JSON file for easier interoperability but we're only using the definitions in JS anyway, so having the definitions in a JS file is more flexible (e.g.: adding comments).
Changelog: [internal]
Reviewed By: huntie
Differential Revision: D53351483
fbshipit-source-id: 23fe0a3898b4facf2f2cf9645f78c45d78937f31
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42871
Minor improvements:
* Removed unused imports
* No longer need to use `static const *` because now we don't rely on pointer equality (we specify the index of the array where to write now).
Changelog: [internal]
Reviewed By: javache
Differential Revision: D53416934
fbshipit-source-id: 9ea12b8398688666e6b76768d3f8fb4e1aad5d1c
Summary:
`react-native/community-cli-plugin` is unable to resolve out-of-tree platforms in monorepos because the package may not be hoisted to the same location. For example, if `react-native/community-cli-plugin` was hoisted:
```
/~/node_modules/react-native/community-cli-plugin/dist/utils
```
It may never find `react-native-macos` if it wasn't hoisted:
```
/~/packages/my-app/node_modules/react-native-macos
```
## Changelog:
[GENERAL] [FIXED] - Fix `react-native/community-cli-plugin` is unable to resolve out-of-tree platforms in monorepos
Pull Request resolved: https://github.com/facebook/react-native/pull/42875
Test Plan: Tested in an internal project.
Reviewed By: cipolleschi
Differential Revision: D53426607
Pulled By: robhogan
fbshipit-source-id: 29b9fe92d5773d0160bba375d2e92ec688652e3e
Summary:
Original commit changeset: 32898e1ba30b
Original Phabricator Diff: D52998256
[General][Removed] - Back out: Gradle plugin for resolving node_modules packages.
Backing this (my own diff) out as it breaks CI - I'm not sure why it landed.
Reviewed By: cipolleschi
Differential Revision: D53427912
fbshipit-source-id: baec254a463e3f7827d6a8675499aab34069ddd1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42823
This is a tiny new Gradle plugin intended to be published to the Gradle Plugin Portal independently of React Native. It's only function is to resolve `node_modules` package roots using a sufficient subset of the Node JS resolution algorithm - e.g, we can use it to find `react-native` itself from a user's project, whatever package manager or workspace setup they're using, in a Gradle-friendly, cacheable manner.
The plugin is both a `Settings` plugin and a `Project` plugin, so that it may be used from both `settings.gradle` (where we need it to resolve `react-native`) and `app/build.gradle` (which currently applies from `cli-platform-android`).
The setup is mostly `gradle init` with a few modifications (eg, Kotlin JVM version) to stay close to the setup for `react-native-gradle-plugin`. I think it's easier to reason about this currently as an entirely separate Gradle project, but we may be able to merge the two and reduce some duplication once it's proven.
Changelog:
[General][Added] - Gradle plugin for resolving node_modules packages.
Reviewed By: cortinico
Differential Revision: D52998256
fbshipit-source-id: 32898e1ba30bccabca11b623f03959a51898afe8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42870
This refactors `ReactNativeFeatureFlagsAccessor` in C++ to improve its thread-safety:
* It makes all cached feature flags atomic to prevent data corruption when writing them concurrently.
* It refactors the list of accessed feature flags to be an array of atomic character pointers instead of a vector.
Performance-wise, this is lock-free so it would still be fast enough for our use cases.
Semantic-wise, this implementation could lead to feature flags being initialized more than once (if 2 threads happen to access the same feature flag before it has been initialized), but that's ok. The only consequence of this would be accessing the provider twice, but the end state of the accessor is the same (the same value would be cached and the flag would still be marked as accessed).
Changelog: [internal]
Reviewed By: javache
Differential Revision: D53406924
fbshipit-source-id: 1023673c40f9da43a51c5f96354d4c458c9d14d4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42869
`DefaultReactNativeHost` builds a `ViewManagerRegistry` based on a list of ViewManagers, which is inefficient, as we have to allocate them all ahead of time (defeating the purpose of `ViewManagerOnDemandReactPackage`). Instead provide a `ViewManagerResolver`which lazily resolves them.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D53406841
fbshipit-source-id: be8437e2127fb6741d1948cecbcf5c3d9f8de268
Summary:
This PR fixes a specific case pointed out by dmytrorykun, where there might be no platform or `deployment_target` specified at all and in that case we assume that this library supports every platform (same as Cocoapods).
## Changelog:
[IOS] [FIXED] - Don't add compiler conditionals when no platforms are specified
Pull Request resolved: https://github.com/facebook/react-native/pull/42867
Test Plan:
Test running codegen when library doesn't specify a `platform`:
```
require 'json'
package = JSON.parse(File.read(File.join(__dir__, 'package.json')))
Pod::Spec.new do |s|
s.name = 'OSSLibraryExample'
s.version = package['version']
s.summary = package['description']
s.description = package['description']
s.homepage = package['homepage']
s.license = package['license']
s.author = 'Meta Platforms, Inc. and its affiliates'
s.source = { :git => package['repository'], :tag => '#{s.version}' }
s.source_files = 'ios/**/*.{h,m,mm,cpp}'
install_modules_dependencies(s)
end
```
Check generated `RCTThirdPartyFabricComponentsProvider`
Reviewed By: cortinico
Differential Revision: D53405625
Pulled By: dmytrorykun
fbshipit-source-id: 0f6917c56b84f0fa29807f516acdbd8d15aa5b46
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42822
The conversion to string was introduced in D45043929. It was supposed to fix command execution for `MyLegacyNativeComponent` in RNTester on Android/Old Architecture.
At the same time it introduced a regression on iOS, since we have [different code path](https://www.internalfb.com/code/fbsource/[ffee789cab9514c0a15b8a63869cbfdf4e534a56]/xplat/js/react-native-github/packages/react-native/React/Modules/RCTUIManager.m?lines=1088-1092) for string commands in iOS, where we expect command name, and not command number converted to string.
I tried to remove that conversion, did local tests, and saw no issues with executing commands on Android.
Looks like the underlying issue has been fixed in some other way.
So let's just remove those conversions.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D53123956
fbshipit-source-id: 968e35277e01215bd6fc1282c78f04666453317d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42811
changelog: [internal]
Attempt to fixing a crash in ReactViewGroup when removeClippedSubviews is enabled.
The implementation of removeClippedSubviews in ReactViewGroup is stateful and must be in sync between children of view and [member variables in ReactViewGroup](https://fburl.com/code/l22wewzc) that keep reference to all children. When it gets out of sync, it manifests itself as `java.lang.IndexOutOfBoundsException` crash.
The mounting layer counts on the fact that view hierarchy will never be directly mutated and all mutations will go through [ReactClippingViewManager](https://fburl.com/code/esl3vqhh). ReactClippingViewManager, if clipping is enabled, calls appropriate methods on ReactViewGroup to make sure member variables to manage clipping are in sync with view hierarchy.
This is true, except for a retry mechanism in SurfaceMountingManager. The retry mechanism tries to manually reconciliation the state with android view hierarchy. It bypasses ReactClippingViewManager in the process.
Reviewed By: javache, mdvacca
Differential Revision: D53348831
fbshipit-source-id: b6b190781a7c85ee4dfd7cb9bc74fd3a55466e45
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42688
X-link: https://github.com/facebook/yoga/pull/1567
We are planning on overhauling NodeToString to output JSON instead of HTML for the purposes of better benchmarking and capturing trees in JSON format to benchmark later. This gives us a bit of a headache as we have to revise several build files to ensure this new library works, ensure that it is only included in certain debug builds, and deal with the benchmark <-> internal cross boundary that arises as the benchmark code (which is a separate binary) tries to interact with it.
On top of it all this is really not used at all.
The plan is to rip out this functionality and just put it in a separate binary that one can include if they really want to debug. That means that it cannot exist in the public API, so I am removing it here.
Private internals come next
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D53137544
fbshipit-source-id: 7571d243b914cd9bf09ac2418d9a1b86d1bee64a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42828
Updates to toJSON:
- return object tree instead of formatted snapshot string. Applying the `'react.test.json'` symbol lets Jest do the formatting work for us
- Source props from `pendingProps` on `instanceHandle`. This adds props such as `pointerEvents` and `style` which were present on RTR's snapshots but don't get included in the node's `props` collection
- Render text node as text value, instead of RCTRawText like `<RCTRawText text="Hello" />`
Changelog: [internal]
Reviewed By: kassens
Differential Revision: D53321821
fbshipit-source-id: 033637b9152441c318c9c797aa9223ff15768873
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42827
This is a simple snapshot test using ReactTestRender's toJSON. We have almost the same functionality in RNTR already, so let's see if we can support tests like this.
Merging the new setup and environment with the existing configuration (https://fburl.com/code/s85sma77) still causes issues so here we add unmocking and new setup inline. Added task T177114228 to track following up on this
Note that some formatting is changed and props are dropped on the snapshot. This is resolved with refactor in next diff
Changelog: [internal]
Reviewed By: yungsters
Differential Revision: D53321823
fbshipit-source-id: a20f77c29fefb9172f8a8189bd821dd202b2ff02
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42826
yungsters debugged the failing test library import and found that we don't yet support package exports. Switching this to main with an index file allows us to import the library in other places.
Changelog: [internal]
Reviewed By: yungsters
Differential Revision: D53240712
fbshipit-source-id: 046a7d1678cbca181e4a4de607a9c0e7490ef047
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42790
A tiny bit of refactoring to unify the setup
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D53313332
fbshipit-source-id: 4642f7d1dee8adf821b06c2ed25be09fd5dce098
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42747
Changelog: [Internal]
Implements a `RuntimeAgent` (D51231326) for Hermes for the modern CDP backend, based on the `CDPHandler` API that Hermes exposes currently.
## A note on `console`
We unfortunately have to disable `console` interception (D51234334 / equivalently D52971652) because `CDPHandler`'s current implementation is not aligned with the Agent concept:
* Agents are only created once a session has started, but the `console` interceptor needs to be injected at VM startup.
* Agents should not clobber each other's shared state (nor consume excessive resources per Agent), but each `CDPHandler` would install its own independent `console` interceptor if enabled.
We will enable CDP `console` support in the modern backend in future work. This will require either some additional plumbing in RN (e.g. to safely access JSI from an Agent/Target) or some additional work in Hermes.
## Conditional compilation based on `HERMES_ENABLE_DEBUGGER`
`HermesRuntimeAgent.cpp` compiles both with and without `-DHERMES_ENABLE_DEBUGGER`, which is the flag Hermes uses to control the availability of `CDPHandler` (and its containing Buck library).
If the debugger is not enabled, `HermesRuntimeAgent` reduces to a `FallbackRuntimeAgent`. In either case, no Hermes debugger headers leak into `HermesRuntimeAgent.h`, so callers don't need to check `#ifdef HERMES_ENABLE_DEBUGGER`, and the overall CDP backend infra is not gated on whether the Hermes debugger is compiled in.
Reviewed By: huntie
Differential Revision: D51234333
fbshipit-source-id: ccbca443560308c5edba4b9689501d01059fdd94
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42725
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
Reviewed By: NickGerleman
Differential Revision: D53200097
fbshipit-source-id: dad54f5bf03967b5d4126757ab0d5424534af888
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42723
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
Reviewed By: NickGerleman
Differential Revision: D53200099
fbshipit-source-id: a5b244da401fb23c9579728c7261312ab200d623
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42724
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
Reviewed By: NickGerleman
Differential Revision: D53200100
fbshipit-source-id: e6355af332c601e0d61e698d2fa0506c6a293989
Summary:
This PR removes the TypeScript entry for `UIManager.takeSnapshot()`. This function does not appear to be implemented anywhere, and calling it throws `TypeError: _reactNative.UIManager.takeSnapshot is not a function (it is undefined)`.
I think this functionality is still supported by [react-native-view-shot](https://github.com/gre/react-native-view-shot) for anyone who needs 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
-->
[General] [Removed] - Removed type definition `UIManager.takeSnapshot()`
Pull Request resolved: https://github.com/facebook/react-native/pull/42779
Test Plan: Ran TypeScript checks.
Reviewed By: cipolleschi
Differential Revision: D53307137
Pulled By: NickGerleman
fbshipit-source-id: 2e65c58c77bcde4f36f5065295d15757c519239d
Alex Hunt
Phillip Pan
Fabrizio Cucci
George Zahariev
David Vacca
Rubén Norte
Tommy Nguyen
Rob Hogan
Samuel Susla
Pieter De Baets
Oskar Kwaśniewski
Dmitry Rykun
Ramanpreet Nara
Joe Vilches
Alex Taylor (alta)
Jack Pope
Christoph Purrer
Moti Zilberman
Fabrizio Bertoglio
Pieter De Baets
Max Phillips
