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
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39540
This simplifies the use of Codegen when creating dev builds of `rn-tester` in the monorepo. It now runs from source for this internal scenario, and this package is now built using the shared monorepo build setup.
Changes:
- Migrate `packages/react-native-codegen` to the shared `yarn build` setup.
- Update package to use `"exports"` field and wrap entry point modules with `babel-register` (NOTE: This is only required for each entry point internally used in the monorepo).
- Fixup small Flow syntax quirks that fail under `hermes-parser`.
- Remove `BuildCodegenCLITask` task from Android build.
- Remove Codegen `build.sh` call from iOS build, use `require.resolve` for `combine-js-to-schema-cli.js` entry point.
Externally significant FYIs:
- `react-native/codegen` is converted to use the `"exports"` field — it should export all `.js` files, as before.
- `codegenPath` is now ignored and marked as deprecated on `ReactExtensions.kt`.
NOTE: TypeScript auto-generation is not yet enabled on this package, since it uses CommonJS `module.exports` syntax (unsupported by `flow-api-translator`).
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D49370200
fbshipit-source-id: 992913155169912ea1a3cb24cb26efbd3f783058
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41159
Changelog: [Internal]
Cleanup from D48966244. The deprecated `jsinspector` files are no longer used by any code in either fbsource or `react-native`.
Reviewed By: hoxyq
Differential Revision: D50530796
fbshipit-source-id: b539b097cb6caf6c50a482fa93bf5d7886e76e52
Summary:
E2E tests in OSS are expensive and flaky.
They already prevented some broken changes to land on main, but as of today:
- they are always green, so they are not bloking
- nobody is looking at the reporting job
- the reporting job takes a lot of time to run and prevent other useful signals to be available soon
- it is expensive
So we decide to disable them for the time being, while we iterate on those with Callstack and MSFT.
## Changelog:
[Internal] - Disable E2E tests
Pull Request resolved: https://github.com/facebook/react-native/pull/41153
Test Plan: CircleCI stays green
Reviewed By: cortinico
Differential Revision: D50552818
Pulled By: cipolleschi
fbshipit-source-id: 7160a8074492c3c9a55485d8a17a6883eb4b35b5
Summary:
This is a small fix to update line number pointing to `fabric_enabled` line number
## Changelog
[Internal] [Fixed] - Update line number in RNTester README
Pull Request resolved: https://github.com/facebook/react-native/pull/41145
Test Plan: Not needed
Reviewed By: rshest
Differential Revision: D50551044
Pulled By: cipolleschi
fbshipit-source-id: bed88c54f3b2718ca4cdb08e66fed2d7e4cac7ab
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41081
It turns out that Bridgeless for RN-Tester release is still broken.
This fixes it by making sure we actually `DoNotStrip` the missing constructor
Changelog:
[Android] [Fixed] - Fix crash with `java.lang.NoSuchMethodError` for Bridgeless
Reviewed By: RSNara
Differential Revision: D50455967
fbshipit-source-id: eae971fceeb863d8a400e9de1d2467637d59d2b0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41152
Building on byCedric's approach in https://github.com/facebook/metro/pull/991, and on D49954920, this diff passes stable, unique *logical device IDs* to the debugger connection infrastructure from Android and iOS.
See D49954920 for the precise stability and uniqueness requirements that these IDs meet.
Changelog:
[Changed][General] - Automatically reconnect to an existing debugger session on relaunching the app
Reviewed By: huntie
Differential Revision: D49954919
fbshipit-source-id: d4d918f0cbfd9df426e888845817e00410efb9d3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41154
Pull Request resolved: https://github.com/facebook/react-native/pull/41080
Building on byCedric's approach in https://github.com/facebook/metro/pull/991, adds support for passing a `device=...` argument to `/open-debugger` for more precise targeting.
Changelog: [Internal]
---
## Note on what "device" means in this context
In `dev-middleware` / `inspector-proxy`, "device" is something of a misnomer. It refers to a *logical device* containing one or more *pages*. In React Native, each app process forms its own logical device in which individual VMs register themselves as pages. An instance of `inspector-proxy` connects one or more *debuggers* (frontends) to one or more logical devices (one frontend to one page on one device).
The intent of the logical device ID is to help with target discovery and especially *re*discovery - to reduce the number of times users need to explicitly close and restart the debugger frontend (e.g. after an app crash).
If provided, the logical device ID:
1. SHOULD be stable for the current combination of physical device (or emulator instance) and app.
2. SHOULD be stable across installs/launches of the same app on the same device (or emulator instance), though it MAY be user-resettable (so as to not require any special privacy permissions).
3. MUST be unique across different apps on the same physical device (or emulator).
4. MUST be unique across physical devices (or emulators).
5. MUST be unique for each concurrent *instance* of the same app on the same physical device (or emulator).
NOTE: The uniqueness requirements are stronger (MUST) than the stability requirements (SHOULD). In particular, on platforms that allow multiple instances of the same app to run concurrently, requirements 1 and/or 2 MAY be violated in order to meet requirement 5. This will be relevant, for example, on desktop platforms.
In an upcoming diff, we will pass device IDs meeting these criteria from both iOS and Android.
Reviewed By: huntie, blakef
Differential Revision: D49954920
fbshipit-source-id: 45f2b50765dece34cbb93fa32abcdf3b0522391c
Summary:
App can be submitted to the app store by using Xcode 14.1 as min Xcode version.
Right now we are testing everything against the latests Xcode, but it would be good to have some tests to check that we don't break the flow for people stuck on older Xcodes.
We already had issues like these in the past, unfortunately.
Plus, we are making some changes using C++20 which we don't know whether they are properly supported by older versions of Xcode.
This change should give us confidence on those changes too.
## Changelog:
[Internal] - Use Xcode 14.1 for some tests
Pull Request resolved: https://github.com/facebook/react-native/pull/39602
Test Plan: CircleCI is green
Reviewed By: NickGerleman
Differential Revision: D49540292
Pulled By: cipolleschi
fbshipit-source-id: 71c07293598fd5b1f73f6d7d9425f385aa12fc4e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41113
changelog: [internal]
We must prevent VirtualizedList._onContentSizeChange from being triggered by a conflicting bubbling onContentSizeChange event.
For TextInput, we change the event onContentSizeChange from bubbling to direct (https://github.com/facebook/react-native/commit/744fb4a0d23d15a40cd591e31f6c0f6cb3a7f06b). To make this safer, we need to filter out any `onContentSizeChange` event since we can't control 3rd party components from dispatching onContentSizeChange as bubbling event.
Reviewed By: NickGerleman
Differential Revision: D50451232
fbshipit-source-id: b7a446e4efc9c45024d37f35cb53f2fcbb28799f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41114
changelog: [internal]
MountItemDispatcher integrates with FabricUIManager in a non-obvious ways. This diff documents some of that.
Reviewed By: NickGerleman
Differential Revision: D50494929
fbshipit-source-id: ed3c1748765ca4590035be20f045ecfb14af86c2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41043
Changelog: [Internal]
in this change, we create an config pipeline to set `_enableSharedModuleQueue` in TMM
Reviewed By: cipolleschi
Differential Revision: D50398636
fbshipit-source-id: cd8c210ad2ae4774ceb10130a8b80e500d17986a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41042
Changelog: [Internal]
currently, each native module creates a new module queue if `methodQueue` is not overridden in the native module.
we want to see if we can use a single execution queue for a few reasons:
- parity with android's queue model
- performance: creating so many queues... for what? the overhead of this feels like it exceeds any potential benefit
- set us up to remove the assocs from the module to the method queue, which will allow us to deprecate `synthesize methodQueue` and `-(dispatch_queue_t)moduleQueue` API.
in this QE, we just start with replacing the KVO assoc'd queue with the shared module queue.
Reviewed By: cipolleschi
Differential Revision: D50398635
fbshipit-source-id: 0b194a5ae5269e843c7c537a973ee1d345ce1df4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41086
In this diff I'm fixing the lookup of ReactModuleInfoProvider instance for CoreReactPackage. It is searching for the wrong class.
changelog: [internal] internal
Reviewed By: RSNara
Differential Revision: D50338304
fbshipit-source-id: 840d1d018cc0f9df8a64fd09a851d8a87f5a1f15
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41083
All callsites for `useImperativeHandle` have been removed, so we can also remove the import from react.
## Changelog
[General][Internal]
Reviewed By: mogers
Differential Revision: D50457268
fbshipit-source-id: befa08cf7173a8d02800fa2447dbcd8a9ce874de
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41039
## Changelog:
[iOS][Breaking] - repeatInterval is deprecated in PushNotificationIOS. Use fireDate and the new fireIntervalSeconds.
Reviewed By: philIip
Differential Revision: D50277316
fbshipit-source-id: ddcc2d2fc9d89d2bacac296848109e98c95c0107
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41118
Updates the release process and guidance for `debugger-frontend`, now that the source [facebookexperimental/rn-chrome-devtools-frontend](https://github.com/facebookexperimental/rn-chrome-devtools-frontend) repo is published.
The `sync-and-build` script now requires a `--branch` argument, allowing us to match release branches across repos for hotfixes (e.g. `0.73-stable`).
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D50496327
fbshipit-source-id: 671fd1581e23032eec0a419a6e50dac6c76feeb0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39163
Changelog: [Internal]
Flow knows about `util.parseArgs` now and has [really nice types for it](https://github.com/facebook/flow/commit/dc5c06a7cbf4b326bd1582b91c5cd0ed65a705bb), so let's update the type definitions for the `pkgjs/parseargs` shim to use those. The updated types use conditional and mapped types to generate a more precise return type for `parseArgs`, based directly on the provided config object.
Reviewed By: huntie
Differential Revision: D48683091
fbshipit-source-id: c0c8fe655a595e6f2f5cf1d4fc1ff0163ed3635f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41126
Long term, we'll want to flow check React Native desktop code, but in the near term, we can side step flow issues entirely by denylisting the desktop forked files in .flowconfig [ignore]. In fact, we don't do any flow checks on react-native desktop today 😬.
For the most part, the .macos.js and .windows.js forked files will be trivial changes to existing modules from react-native-github, and they will be kept in sync in an automated way, so there's an argument that the value of flow checks on these files is pretty limited.
However, at least until flow supports sub-directory multi-platform extensions and interface type hierarchies, we'll need to have entirely separate .flowconfigs for mobile and desktop (as desktop adds APIs to react-native mobile for things like keyboard input and navigation on arbitrary views).
These desktop .flowconfigs will come in a later diff.
## Changelog
[General][Internal]
Reviewed By: shwanton
Differential Revision: D50426512
fbshipit-source-id: f174268468056d510be0993ef619469c9cee3b4e
Phillip Pan
Gabriel Donadel Dall'Agnol
zhongwuzw
Kevin Gozali
David Vacca
Rubén Norte
Sam Zhou
Pieter De Baets
Janic Duplessis
Samuel Susla
Joe Vilches
Saad Najmi
Arushi Kesarwani
Eric Rozell
Gijs Weterings
Nicola Corti
Alex Hunt
Fabrizio Cucci
Moti Zilberman
Riccardo Cipolleschi
Oskar Kwaśniewski
Jane Li
Ingrid Wang
Xin Chen