Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41096
LazyReactPackage.getReactModuleInfoProviderViaReflection was deprecated in 0.72, I'm just deleting it.
There are no usages internally or externally
changelog: [Android][Breaking] Delete deprecated method LazyReactPackage.getReactModuleInfoProviderViaReflection
Reviewed By: arushikesarwani94
Differential Revision: D50338302
fbshipit-source-id: 02fe91d5da8d6f01b8d3852aced90034a1a5c8e8
Summary:
The goal of this PR is to migrate deprecated `UIMenuController` to `UIEditMenuInteraction`. `UIMenuController` has been deprecated in iOS 16 and for that reason it's not available for VisionOS.
## Recording
https://github.com/facebook/react-native/assets/52801365/fed994be-d444-462a-9ed0-39b50531425d
bypass-github-export-checks
## 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] [CHANGED] - Migrate RCTTextView to UIEditMenuInteraction
Pull Request resolved: https://github.com/facebook/react-native/pull/41125
Test Plan: Launch RNTester and check for "Selectable Text" example and check that it works for iOS 16/17.
Reviewed By: javache
Differential Revision: D50551016
Pulled By: cipolleschi
fbshipit-source-id: 558ecc5a04a5daa9c4360fabddcab28fba72a323
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41219
Bump to the latest Metro release. This includes minor breaking changes to Metro subpackages that should *not* be visible to RN users.
Metro release notes: https://github.com/facebook/metro/releases/tag/v0.80.0
## Moving to unpinned versioning
Metro is a multi-package project, and not pinning to an exact version means multiple versions of `metro*` packages may appear in an RN project.
This isn't unusual in the NPM ecosystem and *shouldn't* be a problem, but historically has caused issues (eg https://github.com/facebook/react-native/issues/34714, https://github.com/facebook/metro/issues/1017). The root cause of all of these issues, as far as we know, was fixed in https://github.com/facebook/metro/commit/6d46078e74ae9a43aa90bed46dbd6610e2696cd0, a bug where Node hierarchical resolution was effectively sidestepped via a relative worker path, resulting in a mismatch between transformer and host process.
In addition, the fact that `react-refresh`, `metro-react-native-babel-transformer` and `metro-react-native-babel-preset` are now fully moved into the `react-native/` scope and versioned with React Native means there are no circular dependencies between React Native and Metro, explicit or implicit, and we're much more clearly decoupled.
So, we're moving to caret versioning to allow React Native users to pick up Metro fixes and features without requiring React Native releases and user upgrades.
Changelog:
[General][Changed] - Update Metro to ^v0.80.0, stop pinning to an exact version
Reviewed By: GijsWeterings
Differential Revision: D50731999
fbshipit-source-id: 57b07bf73c0b31f392c4d36376ca48b48a8bd598
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
## Changelog:
[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
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41049
Similarly to D50319914, simplify the careful logic we have with CallbackWrapper and RCTBlockGuard and instead rely on bridging's `AsyncCallback` so safely handle jsi::Function for us.
The underlying issue causing memory corruption has been addressed in D50286876.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D50319913
fbshipit-source-id: e422518b9a647b7daa0b75eae529a8b04ce1c22b
Summary:
Changelog: [Internal]
in the future, all void native module methods will execute synchronously.
currently, many modules override the methodQueue selector to return the main queue so their async methods will be executed on the main thread by our infra. now that void methods are executing synchronously, this override will be ignored, thus causing unpredictable behavior for those methods that do depend on being run on main thread to behave correctly.
the migration in this stack will prevent bugs caused by this behavioral change by explicitly dispatching execution onto the main thread.
Reviewed By: mdvacca
Differential Revision: D50635827
fbshipit-source-id: 384ee2f0237a49dc4f50e4171092c864f2f55327
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41165
Currently Bridgeless forces lazy view manager loading, each ReactPackage must implement ```ViewManagerOnDemandReactPackage```. This can bring extra hassle for OSS users in migration.
This diff add backward compatibility by falling back to eager view manage loading, after detecting any ReactPackage of current application NOT a subclass of ```ViewManagerOnDemandReactPackage```.
Changelog:
[Android][Changed] - Fall back to eager view manage loading for Bridgeless
Reviewed By: cortinico
Differential Revision: D50556405
fbshipit-source-id: 32357d1934068d0fa0f2b7cb46b54f2f41b3e24f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41175
This will make sure that if you specify a maven local folder with `react.internal.mavenLocalRepo`
you're not attempting to fetch artifacts from Maven Central.
Changelog:
[Internal] [Changed] - Do not attempt to query Maven Central if project has react.internal.mavenLocalRepo
ignored-github-export-checks
bypass-github-export-checks
Reviewed By: mdvacca
Differential Revision: D50600815
fbshipit-source-id: f429c2ae9d7204e4aa2cb29357983c0dc3a1aab6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41197
As part of https://github.com/facebook/react-native/pull/40775 we marked TurboReactPackage as DeprecatedInNewArchitecture introducing the new class BaseReactPackage.
In this diff I'm replacing usages of TurboReactPackage by BaseReactPackage to make sure new usages of BaseReactPackage work as expected.
changelog: [internal] internal
Reviewed By: arushikesarwani94
Differential Revision: D50611382
fbshipit-source-id: 867c5949463cb5537960a346099e687379baeb73
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41195
Changelog: [Internal]
in PR 41183 , i introduced a new method to retrieve the RCTNetworker's execution queue. i missed updating a few of these asserts
Reviewed By: fkgozali
Differential Revision: D50680549
fbshipit-source-id: ac88382e13ade4434abbb7d6cbca168117df492e
Summary:
As stated here https://github.com/react-native-community/discussions-and-proposals/issues/671 React Native 0.73 will depend on Android Gradle Plugin (AGP) 8.x which requires all libraries to specify a namespace in their build.gradle file, even though this issue was raised many months ago, lots of libraries have not been updated and don't specify a `namespace` inside their build.gradle files
## Changelog:
[ANDROID] [CHANGED] - Ensure namespace is specified for all the 3rd party libraries
Pull Request resolved: https://github.com/facebook/react-native/pull/41085
Test Plan:
Run RNGP tests and test building rn-tester after doing the following procedure
1. Remove `namespace "com.facebook.react"` from react-native/packages/react-native/ReactAndroid/build.gradle
2. Add `package="com.facebook.react"` to react-native/packages/react-native/ReactAndroid/src/main/AndroidManifest.xml
3. Build rn-tester
Also tested this using [BareExpo](https://github.com/expo/expo/tree/main/apps/bare-expo) with AGP 8.1.1 and all libraries that were missing the `namespace` compiled correctly
Reviewed By: cipolleschi
Differential Revision: D50556667
Pulled By: cortinico
fbshipit-source-id: 3d75ec0a8b82427ff0ede89aa7bc58b28b288945
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41192
We currently don't have visibility on what the native module thread is doing when it's busy (on Android). This adds Systrace blocks to at least know the native module and the method we're running there.
Changelog: [internal]
Reviewed By: ryancat
Differential Revision: D50645557
fbshipit-source-id: 5cb6a7f1166bfd50c28f0aba634552c35a34c941
Summary:
This PR removes some unused RNTester assets that were left during removal of slider and removal of Bookmarks feature in RNTester.
## 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] [REMOVED] - Removed unused images from RNTester
Pull Request resolved: https://github.com/facebook/react-native/pull/41186
Test Plan: Not needed
Reviewed By: shwanton
Differential Revision: D50649244
Pulled By: cortinico
fbshipit-source-id: 5203b446108c04619c8cc57ec56f2d5e8455df2b
Summary:
Bumping Fresco to the latest version (3.1.3)
## Changelog:
[ANDROID] [FIXED] - Bump Fresco to 3.1.3
Pull Request resolved: https://github.com/facebook/react-native/pull/41190
Test Plan: CI Should be green
Reviewed By: lunaleaps
Differential Revision: D50650250
Pulled By: cortinico
fbshipit-source-id: ab8151e882300849ef27ec14c4adc77fdf8503e6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41191
In dev mode, display a Redbox for the first fatal error during RN initialization. So if the first fatal error is Metro not connected that will be displayed via Redbox.
Changelog:
[Android][Changed] - Fix RNTester not showing Redbox when Metro is not connected
Reviewed By: cortinico
Differential Revision: D50600631
fbshipit-source-id: f269091c1745a76b49e72d9051c4836a39fded12
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41183
Changelog: [Internal]
in my quest to get rid of all synthesized methodQueues, we have RCTNetworking which uses it internally as well as exposes its underlying execution queue. in this diff, i add a config that replaces that queue with one that is managed by the module itself instead of the one generated by the infra.
this is the last one!
Reviewed By: cipolleschi
Differential Revision: D50588308
fbshipit-source-id: 98fa54a2b5851898a4514b1fb7feaf586cfdbb0c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41182
Changelog: [Internal]
in my quest to get rid of all synthesized methodQueues, we have RCTBlobManager which exposes its underlying execution queue. in this diff, i add a config that replaces that queue with one that is managed by the module itself instead of the one generated by the infra.
Reviewed By: cipolleschi
Differential Revision: D50587693
fbshipit-source-id: 993a13c617afe48c3989d8cd5ad5fbda050603f4
Summary:
We don't need to get oldChildShadowView when we handle the insert mount. So we can remove it.
## Changelog:
[IOS] [CHANGED] - Fabric: clean up oldChildShadowView when handling Insert mount
Pull Request resolved: https://github.com/facebook/react-native/pull/41155
Test Plan: None.
Reviewed By: sammy-SC
Differential Revision: D50554037
Pulled By: javache
fbshipit-source-id: 3250b6bbe119d800f05f39f790dc6949357d4f27
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41181
The goal of this refactor is to ensure that LazyTurboModuleManagerDelegate doesn't hold references to TurboModules.
EveryTime that LazyTurboModuleManagerDelegate.getModule is called, it will create a new TurboModule. This 'should' be fine because the references to already created TurboModules are held on
TurboModuleManager.mModuleHolders.
As part of this diff I'm also throwing an exception when the method LazyTurboModuleManagerDelegate.unstable_isModuleRegistered is called. This should be fine because I ensured that
"LazyTurboModuleManagerDelegate.unstable_isModuleRegistered' is not called for this experiment.
changelog: [internal] internal
Reviewed By: RSNara
Differential Revision: D50610163
fbshipit-source-id: 8d9d808b9b637c8e9bc3fd9c2502793161cac42c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41178
Changelog: [Internal]
in my quest to get rid of all synthesized `methodQueue`s, we have `RCTImageStoreManager` which uses this throughout. in this diff, i add a config that uses a queue that is managed by the module itself instead of the one generated by the infra.
Reviewed By: cipolleschi
Differential Revision: D50585904
fbshipit-source-id: a33f8a4844fe3ef861bf1c3a7b87a9ed4b24d13f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41157
This is internal until we're ready to test this outside of Meta.
Changelog: [internal]
## Context
In the new architecture, every time we commit a new tree in React we send a transaction to the host platform to make all the necessary mutations in the underlying native views.
This can be bad for user experience, because the user might see quick changes to the UI in succession for related changes. It also breaks the semantics of things like layout effects and ref callbacks, which are core to the React programming model and should work across all platforms.
The main semantic that this behavior breaks in React Native is that layout effects are supposed to be blocking for paint. That means that any state updates (or UI mutations) done in layout effects should be applied to the UI atomically with the original changes that triggered them, so users see a single update where the final state is applied. This doesn't work in React Native as none of the commits coming from React are blocked waiting for effects, and instead they're all mounted/applied as they come.
This isn't only a problem for React, but also for future Web-like APIs that rely on microtasks. Those are also assumed to block paint in browsers, and we don't support that behavior either.
## Changes
Now that we're adding support for a well-defined event loop in React Native, we can add a new step to notify UI changes to the host platform in specific points in time, after macrotasks and microtasks are done (the "Update the rendering" step defined on the [Web specification](https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model)).
This implements that step in the new `RuntimeScheduler`. This works by batching all the notifications from the `UIManager` to `MountingCoordinator` and calling all those methods from `RuntimeScheduler` at the right time.
There will be cases where the notifications will be to mount the same tree multiple times, but the mounting coordinator already handles this correctly (would mount the last version of the tree for each surface ID the first time, and be a no-op the other times).
This change will reduce the amount of mount operations we do on the main thread, which means that we could potentially remove the push model from Android if performance is acceptable with this.
NOTE: This only works with the modern runtime scheduler, and only makes sense when used with microtasks enabled too and background executor disabled.
Reviewed By: javache
Differential Revision: D49536327
fbshipit-source-id: fabcbd6a6fb89a851f4c2b4ebefbb330a6ad3a18
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41168
This API is just used to send callbacks from C++ to Java and is completely internal.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D50226596
fbshipit-source-id: f521ae1f35cc31e8e8aeab66b41fd3e95d9467cb
Summary:
Currently `autoscrollToTopThreshold` does not work correctly, it will scroll to top even when the scroll position is past the `autoscrollToTopThreshold` value.
The value of x/y is taken before we adjust the scroll position so we do not need to subtract the delta.
Note that this was already fixed when I ported this code to fabric, so this fix is only needed in the old arch code.
bypass-github-export-checks
## Changelog:
[IOS] [FIXED] - Fix autoscrollToTopThreshold on iOS old arch
Pull Request resolved: https://github.com/facebook/react-native/pull/38245
Test Plan:
In RNTester example, threshold is set to 10, so it should not scroll to top if we are further than 10px from the top of the list.
Before:
https://github.com/facebook/react-native/assets/2677334/13723787-1bc4-4263-9bcb-91ddf7454de3
After:
https://github.com/facebook/react-native/assets/2677334/a8cfdaac-59fc-40de-970a-ff992366e25f
Reviewed By: rshest
Differential Revision: D50447644
Pulled By: cipolleschi
fbshipit-source-id: b21f1836db293120a7a795c8f8f6dd54887495a7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41148
changelog: [internal]
RN moved away from using folly::hash. These are a few places missed during the migration.
Reviewed By: cipolleschi
Differential Revision: D50540176
fbshipit-source-id: 497c13032c23c5b2dfab9e3d6f226f596b90761e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41101
The goal of this diff is to move NativeMethod out of NativeModule, in this case I'm moving it to JavaModuleWrapper.
We could also do a bigger refactor and just remove it, but since the usages of NativeMethod are not part of public API and these classes will dissapear in the new architecture, I opted for reducing risk a do a minor refactor.
Why I'm doing this: because I'm migrating NativeModule to kotlin and don't want to expose NativeMethod in the kotlin public API
This is not a breakage of compatibility because NativeMethod has package visibility.
bypass-github-export-checks
changelog: [internal] internal
Reviewed By: luluwu2032
Differential Revision: D50294833
fbshipit-source-id: 1c7933e666c24df662649a01e1251c74414b5345
Summary:
X-link: https://github.com/facebook/yoga/pull/1434
Pull Request resolved: https://github.com/facebook/react-native/pull/41130
I will use this errata to gate my changes that actually make position: static behave like the web. We have future plans to make position: relative the default again but users could still have declared certain nodes as position: static, so I think this is needed regardless.
Reviewed By: NickGerleman
Differential Revision: D50506915
fbshipit-source-id: b0d9e6883167de6ff002352c9288053324464cb9
Summary:
I wanted to add a new iOS prop, but noticed this, got distracted, fixed it up, and here we are 😅
There are a few Android/iOS specific props that have been added to `ViewProps` instead of `ViewPropsAndroid` or `ViewPropsIOS`. Let's just move around some props to clean that up, in both Flow and TypeScript.Specifically:
- Moved `needsOffscreenAlphaCompositing` to shared as it's implemented on both iOS and Android
- Moved `accessibilityLiveRegion` / `aria-live` / `accesbilityLabelledBy` / `aria-labelledBy` to Android
- While at it, I also updated the comment definition so that `accessibilityLabelledBy` and `aria-labelledBy` because it just maps to the same thing in native code.
- Moved `accessibilityLanguage` to iOS only
## Changelog:
[GENERAL] [FIXED] - Move iOS/Android specific prop types appropriate types
Pull Request resolved: https://github.com/facebook/react-native/pull/40978
Test Plan: CI should pass
Reviewed By: NickGerleman
Differential Revision: D50372564
Pulled By: vincentriemer
fbshipit-source-id: ba947c15ffdd4d84d3424b4274afdcbf130adad4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41162
"The C++ standard forbids containers of const elements because allocator<const T> is ill-formed."
We have a few other callsites for std::vector<const ...>, but the const values are always const pointers, which I guess are okay?
Suffice to say, this doesn't compile with Microsoft STL headers unless you remove const.
## Changelog
[Internal]
Reviewed By: javache
Differential Revision: D50563174
fbshipit-source-id: 96053baedc41237d8d27a1e01ac94ce5abd6c768
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41136
Changelog: [iOS][Breaking] You cannot call methodQueue on RCTHTTPRequestHandler
the `synthesize methodQueue` API is confusing, it looks like an API only for use within native module implementation, but it's actually needed to create a selector that corresponds to the property declared in the `RCTBridgeModule` public protocol.
no one is using the `methodQueue` on `RCTHTTPRequestHandler`, so let's get rid of the public access to it.
Reviewed By: javache, cipolleschi
Differential Revision: D50525900
fbshipit-source-id: f83738491d0eadc71a6dc3194ee16fe7c8748263
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41090
This propagates to enable the use of microtasks in the React reconciler, Runtime Scheduler and Hermes.
Changelog: [internal]
Reviewed By: sammy-SC
Differential Revision: D50177355
fbshipit-source-id: 6cf23cf72b63d19f50453d3e4cc4ac1b056dbd92
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41084
Adds support for executing microtasks in `RuntimeScheduler`, the same way we did in `JSIExecutor` before (removed in D49536251 / https://github.com/facebook/react-native/pull/40870) but now after each actual task in the scheduler.
When we use microtasks in the scheduler, we ignore calls to execute expired tasks (which was used to call "React Native microtasks" that we had before). Those should now be regular microtasks in the runtime.
This is gated behind a feature flag until we've tested this broadly.
This is going to be tested in Hermes but we need to add support for microtasks in JSC (which has a no-op in its JSI interface).
Changelog: [internal]
Reviewed By: sammy-SC
Differential Revision: D49536262
fbshipit-source-id: 8f7ce54c266d1f25312a641abc4ef073d019281f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41082
We're testing a method to access `ReactNativeConfig` without a dependency on native modules, so we can access it before that infra is initialized in places like Hermes or RuntimeScheduler.
When we're in that variant, this passes the configuration to Hermes so we can use it to set flags in the runtime (like enabling microtasks in D50177355).
Changelog: [internal]
Reviewed By: sammy-SC
Differential Revision: D50450488
fbshipit-source-id: 77f0369f93bb7175c569d51b0569669552a13acf
Summary:
When creating the react root for Logbox, we do not pass the concurrentRoot option leading to a warning because it is using Fabric.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D50558855
fbshipit-source-id: ed4399293ca4001bf4e0e059a0eb73481bcf4832
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41158
This feature flag was just a killswitch for OSS. As we don't need it anymore, I'm removing it.
I've also discussed with Expo so they remove any usages of this in their codebase.
Changelog:
[Internal] [Changed] - Remove unnecessary unstable_useRuntimeSchedulerAlways Feature Flag
Reviewed By: rubennorte
Differential Revision: D50554334
fbshipit-source-id: b2346654ad543c1350f2f2cae078900abf39d41c
David Vacca
Oskar Kwaśniewski
Rob Hogan
Krystof Woldrich
Riccardo Cipolleschi
Pieter De Baets
Isabel Chai
Phillip Pan
Lulu Wu
Nicola Corti
Gabriel Donadel
Rubén Norte
zhongwuzw
Kevin Gozali
Janic Duplessis
Samuel Susla
Joe Vilches
Saad Najmi
Arushi Kesarwani
Eric Rozell
Gijs Weterings