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
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39480
Changelog:
[Internal] - Separate the time series data and renderer logic from performance monitor overlay so that it can be swapped later to C++ for cross-platform support.
Reviewed By: rshest
Differential Revision: D49321748
fbshipit-source-id: fbb781ef710b134130bfd80dada00748e73d5f24
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41087
CoreModulesPackage is not being used outside of its package (neither in OSS or at Meta), I'm reducing its visibiity to package.
If you are using this class, please contact us and we will consider increasing visibiity again.
bypass-github-export-checks
changelog: [Android][Breaking] Reduce visibility of CoreModulesPackage class
Reviewed By: christophpurrer
Differential Revision: D50338546
fbshipit-source-id: 3f0ce4dd22ddfa6743760ad378e7c6e45ab58127
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41088
This was probably caused by a copy paste, I'm fixing the log message to describe the proper class.
bypass-github-export-checks
changelog: [internal] internal
Reviewed By: RSNara
Differential Revision: D50338296
fbshipit-source-id: 28657009ae7f9467d29eecd9b68c1f9541696350
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41014
DebugCorePackage is only used from com.facebook.react, there are no interesting usages internally at Meta or in OSS, so I'm reducing the visibility to package.
bypass-github-export-checks
changelog: [Android][Breaking] Reducing visibility of DebugCorePackage
Reviewed By: christophpurrer
Differential Revision: D50338294
fbshipit-source-id: db9b3be3b1899733a2f9d5f1cbeb314c2d350b57
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41072
As part of the new architecture rollout, we want to simplify our set of supported configurations. Right now it is possible to use Fabric / new architecture without using concurrent root, which prevents us from bringing the new concurrent capabilities to these applications and holds back React renderer code.
Changelog: [Deprecated] Using the new architecture without concurrent root will soon not be supported.
Reviewed By: rubennorte, sammy-SC
Differential Revision: D50425540
fbshipit-source-id: 1ec4c8202074e6ea98178f1a07311fda35b1951b
Summary:
In one of the latests commits on main, Hermes failed somehow to build dSYMs in some slices.
However, the slices were cached (so the cache is poisoned) and the overall process failed.
With this change, we aim to make the slice's build process fail if the dSYM or the actual framework is not built properly, before caching, so they are not poisoned
## Changelog:
[Internal] - Fail the build if dSYM or hermes.frameworks are not built
Pull Request resolved: https://github.com/facebook/react-native/pull/41076
Test Plan: CircleCI is green
Reviewed By: huntie
Differential Revision: D50453598
Pulled By: cipolleschi
fbshipit-source-id: 06bf16ef1472bd9bc9825977b817445272477a10
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41048
Reapplies D49792717
AsyncCallback and SyncCallbacks are better primitives for jsi::Function handling. The code is simpler and requires less manual argument passing. See in D49684248 how the API was extended to support more use-cases.
The underlying issue causing memory corruption has been addressed in D50286876.
Changelog: [Deprecated] AsyncCallback replaces RAIICallbackWrapperDestroyer as a safer way to manage jsi::Function memory ownership.
Reviewed By: rshest
Differential Revision: D50319914
fbshipit-source-id: e038813cad85c47be1f004bc2ea1fdaf0eee9094
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41061
changelog: [internal]
Method `dispatchCommandMountItem` only calls `addViewCommandMountItem` without adding anything on top of it. The name is inaccurate because it doesn't dispatch mount item, it queues it.
Let's remove one of them to simplify the API.
Reviewed By: javache
Differential Revision: D50408576
fbshipit-source-id: 3a4871c38e7b081a5e27aba211d61254075e76cd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41060
changelog: [internal]
The return value is never consumed, let's remove it.
Reviewed By: rubennorte
Differential Revision: D50407732
fbshipit-source-id: 8a363d874b4e1eb7852a9fefb3b511f66d3fdbe9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39943
When the user attaches a debugger, and the app moves to the background the debugging session persists. This
sends a CDP console.info so the debugging user is aware of the app's state. It is an easy state to get into
when debugging on multiple emulators.
Changelog: [iOS][Added] - Add console.log notification in DevTools if app transitions between back/foreground.
Reviewed By: dmytrorykun
Differential Revision: D49956535
fbshipit-source-id: 29e1aba9c4eaeba072fe04f2b932a3e04c96d081
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41055
This should fix the issue highlighted in [this comment](https://github.com/reactwg/react-native-releases/discussions/64#discussioncomment-7271155).
Basically, before the fix, we were not supporting flavours correctly, as we assumed that only Debug and Release were available.
With this change, we infer whether we have to fetch Hermes for Debug or Release based on the actual flags that are passed. In this way, the users can customize their app's flavors more freely.
## Changelog:
[Internal] - Support multiple flavors when downloading Hermes
Reviewed By: huntie
Differential Revision: D50408381
fbshipit-source-id: 6990218b286b4dd823323bc63de90279efc9e74e
Summary:
X-link: https://github.com/facebook/yoga/pull/1431
Pull Request resolved: https://github.com/facebook/react-native/pull/41041
The last of the row-reverse issues hurray!
The position insets were broken with row-reverse since we were using the main-start/main-end edges to inset from and NOT the inline-start/inline-end edges as we should. This made it so that inset in left and right were swapped and same with top and bottom (with column-reverse). The solution here is the same as the previous ones were we are migrating to using inline-start/end as the leading/trailing edge now.
Reviewed By: NickGerleman
Differential Revision: D50390543
fbshipit-source-id: b714deab8489fbe11f7f6db21e4aad3b3aa314b3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41044
The reference Clang/GCC build has a pretty strict set of warnings enabled. The reference MSVC build has less strict warnings, which can be a problem for MSVC users building at higher warning levels (e.g. React Native for Windows in OSS uses `/W4` as its baseline warning level).
This bumps up the MSVC warning level to `/W4`, since we are nearly clean already.
There are some limitations. E.g. we don't test binary with MSVC (some issues I didn't work out), and only test building statically linked. But but we do have a minimal C benchmark we compile with MSVC.
X-link: https://github.com/facebook/yoga/pull/1432
Test Plan: GitHub Actions running benchmark MSVC build.
Reviewed By: yungsters
Differential Revision: D50398443
Pulled By: NickGerleman
fbshipit-source-id: 6616034d79b1a308b32d5d3387bae70f40b7b5ab
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41067
Bump `hermes-parser` packages to the latest released version.
Changelog: https://github.com/facebook/hermes/blob/main/tools/hermes-parser/js/CHANGELOG.md
Notable changes:
- Added parsing support for `as` expressions as well as `renders*` and renders?`.
- Updated internal prettier version to `3.0.3`.
Changelog: [Internal]
Reviewed By: SamChou19815
Differential Revision: D50395762
fbshipit-source-id: 8a9131ea1b0683e79c7bc74b4df9deafac7450f9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41056
As the title says,
I accidentally included this as the diff on top of it that would have made this flag toggleable was abandoned.
Changelog:
[Internal] [Changed] - Revert accidental bridgelessEnabled=true for RN Tester
Reviewed By: luluwu2032
Differential Revision: D50409804
fbshipit-source-id: 0e17883094f90e397544b2be0daee5f6cacd8756
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41058
Glog has a piece of code which looks like this:
```
namespace google {
// They need the definitions of integer types.
#include "glog/log_severity.h"
#include "glog/vlog_is_on.h"
```
This fragment is:
- Always valid when the pod does not define a module
- Valid for Xcode >= 14.3, when the pod do define a module
- Invalid for Xcode < 14.3, when the pod do define a module
Modules are required to support Swift, so, in the long run, we want to have `DEFINES_MODULE` set to `YES` for `Glog`.
This is a temporary workaround to keep supporting older versions of Xcode while Apple keeps allowing to use Xcode 14.1 to submit apps to the store.
Historically, Apple pushes the minimum version of Xcode every April, so we expect to be able to remove this workaround in April 2024.
## Changelog:
[Internal] - Make Glog work with older versions of Xcode
Reviewed By: cortinico
Differential Revision: D50410487
fbshipit-source-id: 96145cdf9ba1bc75622403d3c06454d6d4bfd967
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40948
## Changelog:
[iOS][Breaking] alertAction is deprecated in PushNotificationIOS. getScheduledLocalNotifications now uses new iOS APIs which do not expose this property.
Reviewed By: cipolleschi
Differential Revision: D50275541
fbshipit-source-id: e4ecad858cd06350c749e7f5a837f36316656183
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41063
Some tests for RuntimeScheduler broke because we used uninitialized values incorrectly (they're initialized with 0 on Android but with something like `0101010101...` on iOS).
This fixes the tests by assigning the right initial value.
Changelog: [internal]
Reviewed By: sammy-SC
Differential Revision: D50413220
fbshipit-source-id: e1fc223e795e2ae01d6e3ba3bc32bd052c8fc2f3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41052
When we animate an Animated.Value that has multiple components (eg Animated.Color, AnimatedXY), we have no guarantee that the animation callbacks will be processed in a single React commit. Previously, we attempted to work around this by ignoring these updates in `__findAnimatedPropsNodes`, but that leads to other issues.
Instead, force all animation completions that happen in a single frame to be processed together by emitting them as a single event (Note: this only works when using the singleOpBatching flag for Animated which hasn't been rolled out)
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D50366676
fbshipit-source-id: 613920056113b6515792e80e06254b92061bc335
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40999
Fast refresh banner for Android was introduced for Bridge-only (D42286425), in this diff we enable it for Bridgeless as well.
Changelog:
[Android][Changed] - Enable fast refresh banner for Bridgeless
Reviewed By: cortinico
Differential Revision: D50318991
fbshipit-source-id: 08e3cda5e4cc6e9b7319db57627c1e6bf7fcc67b
Summary:
We've been using SocketRocket 0.7.0 (to pick up a few bug fixes) without issue in React Native macOS. Might as well bump it upstream before 0.73 if we can.
## Changelog:
[IOS] [CHANGED] - Update SocketRocket to 0.7.0
Pull Request resolved: https://github.com/facebook/react-native/pull/39571
Test Plan: CI should pass
Reviewed By: cortinico
Differential Revision: D50411361
Pulled By: cipolleschi
fbshipit-source-id: 93ab571dcfd23e699f1c066bf7aaf737e1f2d18b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41028
This removes misleading `const` modifiers from some methods in `RuntimeScheduler` that shouldn't really use it, and removes the `mutable` modifiers that were only necessary because of that.
Changelog: [internal]
Reviewed By: sammy-SC
Differential Revision: D50364626
fbshipit-source-id: 28ed9fa923f8e787166f702ccaecd41a635d3b3a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40945
This adds some temporary logic to configure the use of the modern version of RuntimeScheduler based on values coming from the app configuration.
This logic is centralized in `ReactInstance` so from that point the code is completely cross-platform.
This doesn't use `ReactNativeConfig`/`CoreFeatures` because they're initialized after the point where we need to access them for this use case. This way is a bit uglier but this isn't intended to live for long (only until we verify this doesn't have regressions in a complex app).
Changelog: [internal]
---
Reviewed By: sammy-SC
Differential Revision: D50171297
fbshipit-source-id: 8d96e228550cc6112ffe2abec4d531514b052f82
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40944
## Summary
This creates a new version of `RuntimeScheduler` that's intended to be backwards compatible but with a few notable changes:
1. `scheduleTask` is now thread-safe.
2. `scheduleWork` is now just an alias of `scheduleTask` with immediate priority (to preserve the yielding semantics it had over other tasks).
3. Yielding mechanism has changed, to make lower priority tasks to yield to higher priority tasks, instead of just yielding to `scheduleWork` and `executeNowOnTheSameThread`.
We don't expect this to have any impact in performance or user perceivable behavior, so we consider it a short-lived refactor. When we validate this assumptions in a complex application we'll delete the old version and only keep the fork.
## Motivation
The main motivation for this refactor is to reduce the amount of unnecessary interruptions of running tasks (via `shouldYield`) that are only used to schedule asynchronous tasks from native.
The `scheduleWork` method is the only available mechanism exposed to native APIs to schedule work in the JS thread (as the existing version of `scheduleTask` is only meant to be called from JS). This mechanism **always** asks for any running tasks in the scheduler to yield, so these tasks are always considered to have the highest priority. This makes sense for discrete user events, but not for many other use cases coming from native (e.g.: notifying network responses could be UserBlocking, Normal or Low depending on the use case).
We need a way to schedule tasks from native with other kinds of priorities, so we don't always have to interrupt what's currently executing if it has a higher priority than what we're scheduling.
## Changes
**General APIs:**
This centralizes scheduling in only 2 APIs in `RuntimeScheduler` (which already exist in the legacy version):
* `scheduleTask`, which is non-blocking for the caller and can be used from any thread. This always uses the task queue in the scheduler and a new yielding mechanism.
* `executeNowOnTheSameThread`, which is blocking for the caller and asks any task executing in the scheduler to yield. These tasks don't go through the task queue and instead queue through the existing synchronization mechanism in `RuntimeExecutor`. The yielding mechanism for these tasks is preserved.
`scheduleWork` will be deprecated and it's just an alias for `scheduleTask` with an immediate priority (to preserve a similar behavior).
**Yielding behavior:**
Before, tasks would only yield to tasks scheduled via `scheduleWork` and `executeNowOnTheSameThread` (those tasks didn't go through the task queue).
With this implementation, tasks would now yield to any task that has a higher position in the task queue. That means we reuse the existing mechanism to avoid lower priority tasks to never execute because higher priority tasks never stop coming.
All tasks would yield to requests for synchronous access (via `executeNowOnTheSameThread`) as did the current implementation.
Changelog: [internal]
Reviewed By: javache, sammy-SC
Differential Revision: D49316881
fbshipit-source-id: 046afc8b6f510a8608ef3da6e27b2663d861f1b8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40875
This introduces a proxy for RuntimeScheduler so we can select between 2 different implementations at runtime (current implementation vs. new implementation, done in D49316881).
Changelog: [internal]
Reviewed By: javache, sammy-SC
Differential Revision: D49316880
fbshipit-source-id: 4035ed6ba641a2316f2efb7cf4a0a86270d6ae23
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40870
This removes an old experiment to implement microtasks in React Native (which is incorrect now that the runtime scheduler executes multiple tasks per runtime executor "task"). `drainMicrotasks` is a no-op at the moment in Hermes because the flag isn't set, so this code is essentially dead.
We'll add the new iteration of microtasks in a following PR.
Changelog: [internal]
Reviewed By: christophpurrer
Differential Revision: D49536251
fbshipit-source-id: b8efba2d0310b9e33e65b79c60ad2db1c8109def
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41054
changelog: [internal]
Avoid going into a while loop if there are no preMountItems.
Reviewed By: javache
Differential Revision: D50407034
fbshipit-source-id: 5c163e02303c331b8fff46fb9a955f88f72a529c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41051
Strictifies flow to flow strict-local in files where doing that doesn't cause new flow errors.
Changelog: Internal
Reviewed By: yungsters
Differential Revision: D50369011
fbshipit-source-id: b4a5a26b839b7327a3178e6f5b35246dea365a38
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41047
Array events are currently broken in the sample for RN Tester. This is because the event name is not registered correctly.
I'm updating the event registration to be correct.
Changelog:
[Internal] [Changed] - Make IntArray events work on Bridgeless for RN-Tester
Reviewed By: cipolleschi
Differential Revision: D50266485
fbshipit-source-id: 13bbce91a41281383d4857048e573b6d9cc5387b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41020
This adds Fabric and Paper bindings to support `alignContent: "space-evenly"` as implemented in https://github.com/facebook/yoga/pull/1422
Changelog:
[General][Added] - Bindings for `alignContent: "space-evenly"`
Reviewed By: yungsters
Differential Revision: D50347978
fbshipit-source-id: 44df3b8ddc7171cddf56957c11ac7d975f706f9d
Samuel Susla
Jane Li
Phillip Pan
David Vacca
Eric Rozell
Ingrid Wang
Alex Hunt
Moti Zilberman
Xin Chen
Dimitar Nestorov
Pieter De Baets
Riccardo Cipolleschi
Blake Friedman
Riccardo Cipolleschi
Sam Zhou
Joe Vilches
Nick Gerleman
Pieter Vanderwerff
Alex Taylor (alta)
Thomas Nardone
Nicola Corti
Rubén Norte
Lulu Wu
Saad Najmi
Gijs Weterings