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:
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/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:
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
Alex Hunt
Fabrizio Cucci
Moti Zilberman
Samuel Susla
Riccardo Cipolleschi
Oskar Kwaśniewski
Nicola Corti
Jane Li
Phillip Pan
David Vacca
Eric Rozell
Ingrid Wang
Xin Chen
Dimitar Nestorov
Pieter De Baets
Blake Friedman
Riccardo Cipolleschi
Joe Vilches
Nick Gerleman
Pieter Vanderwerff
Thomas Nardone
Rubén Norte
Lulu Wu
Saad Najmi