Summary:
This PR implements `RCTRootViewFactory` a utility class (suggested by cipolleschi) that returns proper RCTRootView based on the current environment state (new arch/old arch/bridgeless). This class aims to preserve background compatibility by implementing a configuration class forwarding necessary class to RCTAppDelegate.
### Brownfield use case
This PR leverages the `RCTRootViewFactory` in `RCTAppDelegate` for the default initialization of React Native (greenfield).
Here is an example of creating a Brownfield integration (without RCTAppDelegate) using this class (can be later added to docs):
1. Store reference to `rootViewFactory` and to `UIWindow`
`AppDelegate.h`:
```objc
interface AppDelegate : UIResponder <UIApplicationDelegate>
property(nonatomic, strong) UIWindow* window;
property(nonatomic, strong) RCTRootViewFactory* rootViewFactory;
end
```
2. Create an initial configuration using `RCTRootViewFactoryConfiguration` and initialize `RCTRootViewFactory` using it. Then you can use the factory to create a new `RCTRootView` without worrying about old arch/new arch/bridgeless.
`AppDelegate.mm`
```objc
implementation AppDelegate
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary<UIApplicationLaunchOptionsKey,id> *)launchOptions {
// Create configuration
RCTRootViewFactoryConfiguration *configuration = [[RCTRootViewFactoryConfiguration alloc] initWithBundleURL:self.bundleURL
newArchEnabled:self.fabricEnabled
turboModuleEnabled:self.turboModuleEnabled
bridgelessEnabled:self.bridgelessEnabled];
// Initialize RCTRootViewFactory
self.rootViewFactory = [[RCTRootViewFactory alloc] initWithConfiguration:configuration];
// Create main root view
UIView *rootView = [self.rootViewFactory viewWithModuleName:@"RNTesterApp" initialProperties:@{} launchOptions:launchOptions];
// Set main window as you prefer for your Brownfield integration.
self.window = [[UIWindow alloc] initWithFrame:[UIScreen mainScreen].bounds];
UIViewController *rootViewController = [UIViewController new];
rootViewController.view = rootView;
self.window.rootViewController = rootViewController;
[self.window makeKeyAndVisible];
// Later in the codebase you can initialize more rootView's using rootViewFactory.
return YES;
}
end
```
bypass-github-export-checks
## Changelog:
[INTERNAL] [ADDED] - Implement RCTRootViewFactory
Pull Request resolved: https://github.com/facebook/react-native/pull/42263
Test Plan: Check if root view is properly created on app initialization
Reviewed By: dmytrorykun
Differential Revision: D53179625
Pulled By: cipolleschi
fbshipit-source-id: 9bc850965ba30d84ad3e67d91dd888f0547c2136
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43305
changelog: [internal]
Originally when I built setNativeProps, I assumed a node is either controlled by handled directly or it is controlled by React. But we can't make sure that's the case, users can do both and control one prop with setNativeProps and the others with React. Additionally, Suspense uses display: none to hide a subtree.
Therefore, React controlled props must not be copied into `ShadowNodeFamily::nativeProps_DEPRECATED`
Reviewed By: javache
Differential Revision: D54453820
fbshipit-source-id: 5b4038f0dd366621d26a92f668d33f27ce60f4b4
Summary:
Changelog: [internal]
Now that `jsi::Runtime::queueMicrotask` is available, we can use it instead of calling an internal Hermes API in `RuntimeSchedulerTest`.
Reviewed By: christophpurrer
Differential Revision: D54416245
fbshipit-source-id: c9cbd3783d9dc1c3df499a7fec7acb6c229ec571
Summary:
Changelog: [internal]
## Context
We want to enable the new React Native event loop by default for all users on the new RN architecture (on the bridgeless initialization path more concretely), which requires support for microtasks in all the JS engines that the support (Hermes already has it, JSC doesn't).
## Changes
This adds initial support for microtasks in JSC, so we can schedule and execute microtasks in this runtime.
One limitation about this approach is that, AFAIK, the public API for JSC doesn't allow us to customize its internal microtask queue or specify the method to be used by its built-in `Promise` or native `async function`, so we're forced to continue using a polyfill in that case (which uses `setImmediate` that will be mapped to `queueMicrotask`).
Reviewed By: NickGerleman
Differential Revision: D54302534
fbshipit-source-id: 47f71620344a81bc6624917f77452106ffbf55a3
Summary:
Changelog: [internal]
## Context
Microtasks are an important aspect of JavaScript and they will become increasingly important in the hosts where we're currently using JSI.
For example, React Native is going to adopt an event loop processing model similar to the one on the Web, which means it would need the ability to schedule and execute microtasks in every iteration of the loop. See https://github.com/react-native-community/discussions-and-proposals/pull/744 for details.
JSI already has a method to execute all pending microtasks (`drainMicrotasks`) but without a method to schedule microtasks this is incomplete.
We're currently testing microtasks with Hermes using an internal method to schedule microtasks (`HermesInternal.enqueueJob`) but we need a method in JSI so this also works in other runtimes like JSC and V8.
## Changes
This adds the `queueMicrotask` to the Runtime API in JSI so we have symmetric API for microtasks and we can implement the necessary functionality.
The expectation for JSI implementations is to queue microtasks from this method and from built-ins like Promises and async functions in the same queue, and not drain that queue until explicitly done via `drainMicrotasks` in JSI.
This also modifies Hermes and JSC to provide stubs for those methods, and the actual implementation will be done in following diffs.
Reviewed By: neildhar
Differential Revision: D54302536
fbshipit-source-id: 25f52f91d7ef1a51687c431d2c7562c373dc72a5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43287
Move react-native-community/cli clean into core per RFC-0759. Provides:
- android
- metro
- npm
- bun
- watchman
- yarn
- cocoapods
These tasks are used to clear up caching artefacts in React Native projects. This is going to be called by the `react-native-community/cli` once we publish these in an npm package.
Changelog:
[General][Added] RFC-0759 Move cli clean into core
Reviewed By: cipolleschi
Differential Revision: D53997878
fbshipit-source-id: 56907be714184abecc8e3ef677ffc83e9ee7b54d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43293
Was debugging this, and found that this exception was being thrown due to `DefaultBindingsInstaller`, which was an invalid hybrid object. The ReactInstance initializer fully supports this being null, so let's use that as default.
Changelog: [Android][Fixed] NullPointerException is no longer ignored in MessageQueueThreadHandler
Reviewed By: sammy-SC
Differential Revision: D54434417
fbshipit-source-id: 52417b390061eface0f0578e32796d3a85303e03
Summary:
The `rrc_textinput` was not exposed via prefab. I'm adding it to make possible for react-native-live-markdown to integrate on top of React Native via prefab. Based on https://github.com/facebook/react-native/issues/36166.
## 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] [CHANGED] - Expose `rrc_textinput` via prefab.
Pull Request resolved: https://github.com/facebook/react-native/pull/43274
Reviewed By: cipolleschi
Differential Revision: D54482657
Pulled By: cortinico
fbshipit-source-id: ca7f4127f1808f841d88925238666e837de75bd0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43268
We previously restricted all copies and moves of SyncCallback, but that led to unsafe calling paths being added instead to AsyncCallback. Instead, allowing moving of SyncCallback, and document the need for the caller to invoke it safely, so can we remove the unsafe path from AsyncCallback.
Changelog: [General][Changed] Allow moving SyncCallback for advanced use-cases
Reviewed By: christophpurrer
Differential Revision: D54381734
fbshipit-source-id: 5fd797cd4541e507aa68f1e4e76a1be5cae20fbe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43294
These are gated by `ReactFeatureFlags.enableBridgelessArchitecture` and are missing support. They should be evaluated for backwards compatibility
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D54422143
fbshipit-source-id: b35b60f17d68d412a354b20e02fb6bbf591c40b0
Summary:
X-link: https://github.com/facebook/litho/pull/976
X-link: https://github.com/facebook/yoga/pull/1586
Pull Request resolved: https://github.com/facebook/react-native/pull/43299
Add the React Clang Tidy config to Yoga, run the auto fixes, and make some manual mechanical tweaks.
Notably, the automatic changes to the infra for generating a Yoga tree from JSON capture make it 70% faster.
Before:
{F1463947076}
After:
{F1463946802}
This also cleans up all the no-op shallow const parameters in headers.
{F1463943386}
Not all checks are available in all environments, but that is okay, as Clang Tidy will gracefully skip them.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D54461054
fbshipit-source-id: dbd2d9ce51afd3174d1f2c6d439fa7d08baff46f
Summary:
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
bypass-github-export-checks
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D54027179
fbshipit-source-id: 4840becb8374ddbf8091be1e5e593289d18c78e0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43296
Fix CI by adding explicit visibility modifier to the newly added `BridgelessCatalystInstance` class. In Kotlin, in explicit API mode, which is usually the default mode for Kotlin, we must explicitly specify one of the modifiers for every declaration to make it clear and explicit.
Changelog:
[Internal] internal
Reviewed By: makovkastar
Differential Revision: D54442485
fbshipit-source-id: 4409ff810a09cc4fadcd2ccf21f7fbac3015f413
Summary:
Inspired by some new C++ code in `RKJSModules` where Clang Tidy could have caught some C++ quirks and shown them in Phabricator, this enables Fabric's Clang Tidy checks in more places, and enables more checks.
1. Hoist the renderer `.clang-tidy` to `xplat/js`, and duplicate to `xplat/ReactNative`
2. Remove all the scattered `.clang-tidy` files in RN which are less aggressive
3. Sort the list of checks
4. Add the following new checks:
1. `bugprone-incorrect-enable-if`
1. `bugprone-infinite-loop`
1. `bugprone-optional-value-conversion`
1. `bugprone-redundant-branch-condition`
1. `bugprone-shared-ptr-array-mismatch`
1. `bugprone-signed-char-misuse`
1. `bugprone-too-small-loop-variable`
1. `bugprone-unique-ptr-array-mismatch`
1. `bugprone-unsafe-functions`
1. `bugprone-unused-raii`
1. `cppcoreguidelines-avoid-const-or-ref-data-members`
1. `cppcoreguidelines-avoid-non-const-global-variables`
1. `cppcoreguidelines-init-variables`
1. `cppcoreguidelines-interfaces-global-init`
1. `cppcoreguidelines-missing-std-forward`
1. `cppcoreguidelines-prefer-member-initializer`
1. `facebook-hte-BadEnum`
1. `facebook-hte-MissingStatic`
1. `misc-header-include-cycle`
1. `misc-misplaced-const`
1. `modernize-use-constraints`
1. `modernize-use-designated-initializers`
1. `modernize-use-starts-ends-with`
I did not auto apply fixes, since even the existing set can sometimes (rarely) generate invalid code.
Changelog: [Internal]
Reviewed By: ksheedlo
Differential Revision: D54411398
fbshipit-source-id: 4958d880969ae07a03fa4f62ba68ee44790487ca
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43165
Fixes component stacks without source info, and duplication in the error message string.
## Before
No component stacks, and error message duplication:
{F1459400803}
## After
Back to normal, albeit without the component source location:
{F1459401148}
Changelog:
[General][Fixed] - Support component stacks without source info.
Reviewed By: yungsters
Differential Revision: D53981672
fbshipit-source-id: c83455673ce327ed1a4c6cfeb3247e97da9b6a2e
Summary:
Small tweak to #43069 - trim the message to avoid ending with a newline.
Changelog:
[General][Changed] - Trim invalid blob response error message
Reviewed By: christophpurrer
Differential Revision: D54422284
fbshipit-source-id: 53a4e963f8aba36c55e16ad7539b2f2d98c781f8
Summary:
When used with expo, JS code content type is `application/javascript; charset=UTF-8` instead of just `application/javascript`, We have a really large bundle and the application shows stuck at "Bundling 100%" and does not show "Downloading 1..100%".
Here we improve the check for the content type to correctly show the progress.
## Changelog:
[IOS] [FIXED] - Fixed headers content type check for iOS bundle download
<!-- 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/43262
Reviewed By: huntie
Differential Revision: D54412657
Pulled By: robhogan
fbshipit-source-id: f12e260f1bda36495eb5e6ecd0f66c86f26d4747
Summary:
The RemoveDeleteTree operation assumes it can safely call getChildAt with indices that are out of bounds to find all the children. `getChildAtWithSubviewClippingEnabled` was unnecessarily stricter than `getChildAt` and would crash in such cases.
Changelog: [Android][Fixed] - Fix crash in `getChildAtWithSubviewClippingEnabled`
Reviewed By: NickGerleman
Differential Revision: D54380975
fbshipit-source-id: 17e93c685cd07b02dc20efa2fae89090d6e38457
Summary:
The `scrollEventThrottle` prop is missing in the ViewConfig for ScrollView for the Android platform. Because of that it was ignored by native in the New Architecture.
This diff fixes that.
Changelog: [Android][Fixed] - Add support for scrollEventThrottle for ScrollView on the New Architecture.
Reviewed By: fkgozali
Differential Revision: D54303157
fbshipit-source-id: 824f32c2f9fb3958271b094bbfc770992a4335e1
Summary:
Changelog: [General][Fixed] Re-enable listing Hermes debugger targets in chrome://inspect, broken in 0.74 RC
Fixes https://github.com/facebook/react-native/issues/43259.
Reverts D52958725 and fixes the original `Content-Length` Unicode bug using a different approach.
Reviewed By: fabriziocucci
Differential Revision: D54409847
fbshipit-source-id: ed5bb464ab67f37535947646b124814d8bbf797c
Summary:
In order to make the legacy APIs of Catalyst Instance backwards compatible, introducing a regular class that implements CatalystInstance so as to make these APIs available for folks in Bridgeless mode as well.
Changelog:
[Internal] internal
Reviewed By: RSNara
Differential Revision: D54093013
fbshipit-source-id: f494c05e79f570883f9b5374cd177862970304c0
Summary:
Changelog: [General][Breaking] Native modules using the codegen now throw an error when called with `null` for optional but not nullable arguments.
## Context
Right now, if you have a native module using the codegen with a method like this:
```
someMethod(value?: number): void;
```
And you call it like this:
```
NativeModule.someMethod(null);
```
The app doesn't throw an error, but it should because this method shouldn't accept `null` according to its type definition.
## Changes
This modifies the codegen to only check for `undefined` in those cases, otherwise trying to cast the value to the expected type and failing if it's `null`.
NOTE: this is technically a breaking change, but if people are using Flow or TypeScript in their projects they're very unlikely to hit this case, because they would've complained if you tried to pass `null` in these cases.
Reviewed By: cipolleschi
Differential Revision: D54206289
fbshipit-source-id: 58f2f2f3009d203b96189d3c66d1ae98a9e4fb36
Summary:
Changelog: [internal]
This modifies the method to run microtasks in `RuntimeScheduler_Modern` to align a bit better with the spec. In this case, we'll check if we're already running microtasks when we call that method, and skip if that's the case.
We're not currently calling this method recursively so this shouldn't really be a change with the current logic.
Reviewed By: javache
Differential Revision: D54302537
fbshipit-source-id: ef5e12e68e0c7f8c9258929609c050ef78e4cde5
Summary:
After discussing with mdvacca, we prefer to undo the change of `TurboModule` package to `.internal` as this is a quite aggressive breaking change for the ecosystem.
Moreover: users should not invoke `TurboModule.class.isAssignableFrom` because `TurboModule` is `.internal`. Therefore I'm exposing another API to check if a class is a TurboModule as a static field of `ReactModuleInfo`.
## Changelog:
[INTERNAL] - Do not use TurboModule.class.isAssignableFrom
Pull Request resolved: https://github.com/facebook/react-native/pull/43219
Test Plan: Tests are attached
Reviewed By: mdvacca, cipolleschi
Differential Revision: D54280882
Pulled By: cortinico
fbshipit-source-id: 9443c8aa23cf70dd5cfe574fe573d83313134358
Summary:
Changelog: [internal]
This fixes a crashes during logout on Android and iOS caused by trying to unregister the inspector from instances that were not previously registered. This is because I removed a check in D51459050 that was necessary when the inspector was disabled via the flag (and we call the `unregisterFromInspector` method unconditionally).
This also gates the registration/unregistration on Android properly.
Reviewed By: huntie
Differential Revision: D54357554
fbshipit-source-id: 945288acdabdface324884bee1e832870ec8806f
Summary:
This change moves the prepack script of react-native in a separate script, so we can make sure we execute all the preprocessing we need before packing and publishing React Native to OSS.
## Changelog:
[General][Changed] - Moved the tasks of prepack in a separate node script
Reviewed By: huntie
Differential Revision: D54308411
fbshipit-source-id: 989c2b8c6cf88a1e9d87cf34e43351b5c0e7ea73
Summary:
Added a check to avoid the regeneration of RNCore components in case they have been generated already.
In order to maintain backward compatibility and to make sure not to break internal use cases, I think we should still keep the possibility to generate these components at `pod install` time.
Internal users of RNTester, for example, will not run `yarn prepack` before building react-native using OSS technology.
Notice that, in this specific case, the Codegen generates the file in a path that is not `node_modules`.
## Changelog:
[General][Added] - Skip generation of RNCore if the files have been already generated
Reviewed By: dmytrorykun
Differential Revision: D54308832
fbshipit-source-id: 0b5822a367eb0b191c42bc92f8bff20d541c5b29
Summary:
This change extracts the function to create RNCore components in a separate reusable unit.
RNCore is now generate in the `node_modules` folder when the app runs pod install, which is a problem because there are use cases where it's not possible to modify the `node_modules` folder or the generated files might be lost.
The goal is to:
- extract this function
- execute this function before packing react-native during the release. (see D54308411)
In this way, we are going to generate the RNCore files in the react-native path that will be packaged and then released.
Users of react-native will have the generated code directly in the node_modules with no need to generate it.
## Changelog:
[General][Added] - Add function to only generate RNCore components
Reviewed By: huntie
Differential Revision: D54308713
fbshipit-source-id: 0fa9ab4ba7b66c577663f0c736742c4d5583f617
Summary:
This change factor out in a variable the `libraryName` to avoid verbosity.
## Changelog:
[Internal] - factor out libraryName
Reviewed By: dmytrorykun
Differential Revision: D54308601
fbshipit-source-id: 1a64a6b960cc86a1cff059e3ba6a45c33bf3150e
Summary:
This change refactor the RNCORE_CONFIGS in a separate variable to simplify reuse.
## Changelog:
[Internal] - Refactor code
Reviewed By: dmytrorykun
Differential Revision: D54308346
fbshipit-source-id: b9d7c8e0a9b4042f2ab1adeb7aae875264d22499
Summary:
In OSS we have reports like [this one](https://github.com/facebook/react-native/issues/43241) where env variables from different settings might clash together, making react native apps fail to build hermes.
For example, a team might have defined a BUILD_FROM_SOURCE env variable to build their specific project from source and that will clash with how react native apps installs Hermes.
This change disambiguate the BUILD_FROM_SOURCE flag we have internally, moving to a less likely to clash RCT_BUILD_HERMES_FROM_SOURCE.
## Changelog:
[iOS][Breaking] - Rename BUILD_FROM_SOURCE to RCT_BUILD_HERMES_FROM_SOURCE
Reviewed By: huntie
Differential Revision: D54356337
fbshipit-source-id: 1115e3c22cbcf1d64b7edae30da614d52423123b
Summary:
The current behavior for `maintainVisibleContentPosition` on ScrollView is to pick the first fully visible item as the scroll anchor. This has a number of disadvantages:
* It causes problems for lists with loading indicators and large items. The loading glimmer can be picked as the anchor and pull the scroll down too quickly. This is the case for Marketplace.
* It's inconsistent with the [CSS Scroll Anchoring](https://www.w3.org/TR/css-scroll-anchoring-1/) behavior, which is to pick the first partially visible view.
This change will switch to picking the first partially visible view as the anchor, to align with the CSS implementation.
Discussed the change with yungsters, NickGerleman, and cipolleschi and agreed about the change in behavior.
This also enables `maintainVisibleContentPosition` for Android. After adding it to `validAttributes` for Android it appears to be working well. Previously it was not functional at all on Android, as the property change from React was not passed to ReactScrollViewManager.java.
## Changelog:
[General] [Changed] - maintainVisibleContentPosition property on ScrollView now selects the first partially visible view as the anchor, rather than the first fully visible view.
Reviewed By: NickGerleman
Differential Revision: D54223244
fbshipit-source-id: 05ddfc0bbf16d61f9599b9d8066c0bd21b086301
Summary:
Changelog: [Internal]
Fixes a bug detected by LeakSanitizer: `HostAgent`'s destructor writes to session state, but when the containing `HostTargetSession` is being torn down, the `SessionState` object currently gets destroyed first, resulting in a dangling reference. Reordering the members of `HostTargetSession` results in the correct destruction order.
bypass-github-export-checks
Reviewed By: robhogan
Differential Revision: D54305545
fbshipit-source-id: e91a6f3de5eed327b811524548d01565e26234fa
Summary:
Changelog: [Internal]
This implements the integration of `ReactInstance` with the modern CDP backend.
This is the last missing piece to complete the integration of bridgeless with the modern CDP backend, and now we can test it end to end.
Reviewed By: huntie
Differential Revision: D51459050
fbshipit-source-id: 54e8972ee199cbcc8e5e73d7215a34f008feeaa3
Summary:
Changelog: [Internal]
This implements the integration of `ReactHost` with the modern CDP backend. It handles the registration of pages in CDP when we create new instances of `ReactHost` (which is the equivalent concept in React Native).
The next PR will handle the registration of `ReactInstance` to complete the integration on bridgeless.
Reviewed By: huntie
Differential Revision: D51459049
fbshipit-source-id: 9576c8d8e38ca925035d90f2871bcd7aa534f725
Summary:
Changelog: [internal]
This adds a new type of executor in AndroidExecutors to execute runnables on the UI thread.
If the caller is already on the UI thread it'd call the runnable immediately. Otherwise it'd be scheduled in the UI thread to execute asynchronously.
Reviewed By: huntie
Differential Revision: D53941120
fbshipit-source-id: b68c7a4540be2a12df930e4e52eeb7b7a1aa91d8
Summary:
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
bypass-github-export-checks
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D54027184
fbshipit-source-id: 722a7e398849f5d935894f321aa0177167eebaef
Summary:
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
bypass-github-export-checks
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D54027180
fbshipit-source-id: bf8875c06c8990172e6b449e12902691131b9cef
Summary:
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
bypass-github-export-checks
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D54027186
fbshipit-source-id: 2cee2b598c3ef15641222018703a7d6a467ba30c