Summary:
Changelog: [Internal]
With the Hermes fix in D55250610, we're able to make stronger assertions in `CDPAgentReentrancyRegressionTest`, which is an integration test covering a class of related bugs.
bypass-github-export-checks
Reviewed By: mattbfb
Differential Revision: D55962593
fbshipit-source-id: 09d03effc51d6f1904842f1c7c2f7e4407fefc63
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44022
changelog: [internal]
move the new state reconciliation algorithm to the unified feature flag system.
Reviewed By: rubennorte
Differential Revision: D55965530
fbshipit-source-id: 3edde0858a670e86dc2d1cb561f03f584ff21896
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44021
changelog: [internal]
This is an evolution of cloneless state progression, introduced in D49012353.
# Problem
## When React clones the wrong node revision
Whenever React wants to commit a new change, it first needs to clone shadow nodes. React sometimes clones from the wrong revision. This has mostly been fine, Fabric does state reconciliation to pass newest state forward. State reconciliation is needed, as we need to keep native state in the shadow tree.
However, when React clones a node that has never been through layout step, it will clone a node without any layout information and its yoga node is dirtied. Even though there might be a subsequent revision of the node with layout information already calculated. As a result, Yoga needs to traverse bigger parts of the tree, even though layout has been calculated before. It is just cached on a different revision that was used as a source.
There are two main sources (there is more but they don't help to paint the picture) when this can happen. Background Executor and State Progression. Let's start with the simpler one but less severe: Background Executor.
Background Executor moves layout from JavaScript thread. React can start cloning nodes right away, even though they might not have layout information calculated yet. This is a race condition and depending on when the node is cloned, we can see different results. In this case, React eventually clones node from the correct revision with the layout cache. It will be in a correct state in the end. This case is not as bad as far as I can tell but I included it here because it better illustrates what is going on.
State Progression is where things get worse. In this scenario, React will never clone from the correct revision and will never recover from this. Anytime React clones node with a state that needs to be progressed, it will get cloned one more time during commit but React will hold the wrong revision. Depending on where this node is located in the view hierarchy, it may lead to expensive layout calculations.
Example:
Let's use notation A/r1 as node of family A revision 1.
- React calls create node. Node A/r1 is created and React holds reference to this. It will later use it to clone it.
Node A has native state that was updated. New revision A/r2 is created. Now React and RN do not observe the same node anymore (this is sometimes necessary).
- React now clones node A to create A/r3. This revision may have the wrong yoga cache. Now this might sound like one off but let's explore what happens next.
- During commit, Fabric must do state progression to give node A/r3 state from A/r2. This requires cloning and new revision A/r4 is created. React has again a wrong node that does not have Yoga cache and can't recover from this state.
The blast radius of this varies depending on where in the tree the node is.
# Solution - State Alignment Mechanism
The main principle for new state progression is to make sure React references the correct shadow node after commit to avoid layout cache miss on subsequent commit.
Agenda for the diagrams below:
- Black colour: node was not cloned.
- Blue colour: node was cloned by React.
- Orange colour: node was cloned by host platform.
- Blue and Orange colour: node was cloned by both React and host platform.
## Simple cases
### Base case
{F1483309510}
### React Cloned
{F1483308354}
### React and host platform clone the same node
{F1483309324}
## Medium difficulty
### React clones a different branch than host platform
{F1483349393}
### React deletes a branch that was cloned by host platform
{F1483349259}
### React changes structure of the tree, node cloned by host platform remains
{F1483349758}
### React reorders nodes that were cloned by host platform
{F1483350283}
Reviewed By: rubennorte
Differential Revision: D53405702
fbshipit-source-id: c7d4b0772c144c86d72e39965e9626a2daefa6fd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44020
changelog: [internal]
This diff only adds more tests for state reconciliation to cover more cases.
Thanks to this, I discovered bugs in my previous implementation of cloneless state progression.
Reviewed By: rubennorte
Differential Revision: D55926491
fbshipit-source-id: 5945ba9bc1d6fed111fbca07e19589cbef50712d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44019
changelog: [internal]
use size_t instead of int32_t so that caller of `ShadowNode::replaceChild` does not need to cast.
Reviewed By: rubennorte
Differential Revision: D55923333
fbshipit-source-id: 8f8062708d9aaddedb600aa7dac419a177e2ab24
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44018
changelog: [internal]
New trait ClonedByNativeStateUpdate is used to mark the path that was cloned by native state update.
This is a pre-requisite for new state reconciliation algorithm. It will mark part of shadow tree that was affected by native state update.
Reviewed By: rubennorte
Differential Revision: D55922776
fbshipit-source-id: 6d4515460346c341af3ee6117d570b3201328bc9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44017
changelog: [internal]
Add an option to mark all nodes clone indirectly by `ShadowNode::cloneTree`.
This is a pre-requisite for new state reconciliation algorithm. It will be used to mark part of shadow tree that was affected by native state update.
Reviewed By: rubennorte
Differential Revision: D55745323
fbshipit-source-id: 5e2a2e8a572cc5077d907608f83992a43625d58e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44016
changelog: [internal]
Add option to set traits when node is created or cloned via ShadowNodeFragment.
This is a pre-requisite for new state reconciliation algorithm.
Reviewed By: rubennorte
Differential Revision: D55691094
fbshipit-source-id: 0bdf024c3c9b28304969ddc9b9c63b0f0b924bb0
Summary:
IOS builds started failing due to Xcode version checks falsely claiming newer versions are not installed
TODO affecting Xcode version checking reads: Remove this code after April 2024, when Apple will push the lower version of Xcode required to upload apps to the Store.
## Changelog:
remove deprecated Xcode version check
Pick one each for the category and type tags:
[IOS] [REMOVED] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/43949
Test Plan: Should run as before, only the deprecated version check has been removed.
Reviewed By: dmytrorykun
Differential Revision: D56056701
Pulled By: cipolleschi
fbshipit-source-id: 47288e04bd1cfc989cf05994cb47421fd2379af0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44026
Changelog: [Android][Removed] Delete ReactContext.initializeWithInstance(). ReactContext now no longer contains legacy react instance methods. Please use BridgeReactInstance instead.
Yet another attempt to land this (last one was D55505416).
Copy-pasting below the amazing summary from RSNara.
## Context
Prior, ReactContext used to implement bridge logic.
For bridgeless mode, we created BridgelessReactContext < ReactContext
## Problem
This could lead to failures: we could call bridge methods in bridgeless mode.
## Changes
Primary change:
- Make all the react instance methods inside ReactContext abstract.
Secondary changes: Implement react instance methods in concrete subclasses:
- **New:** BridgeReactContext: By delegating to CatalystInstance
- **New:** ThemedReactContext: By delegating to inner ReactContext
- **Unchanged:** BridgelessReactContext: By delegating to ReactHost
## Auxiliary changes
This fixes ThemedReactContext in bridgeless mode.
**Problem:** Prior, ThemedReactContext's react instance methods did not work in bridgeless mode: ThemedReactContext wasn't initialized in bridgeless mode, so all those methods had undefined behaviour.
**Solution:** ThemedReactContext now implements all react instance methods, by just forwarding to the initialized ReactContext it decorates (which has an instance).
NOTE: Intentionally not converting `BridgeReactContext` to Kotlin to minimize the risk of these changes.
Reviewed By: RSNara
Differential Revision: D55964787
fbshipit-source-id: b404efe0c7095894fa815165cc8682f78dccfa17
Summary:
X-link: https://github.com/facebook/react-fbsource-import/pull/5
Pull Request resolved: https://github.com/facebook/react-native/pull/44046
changelog: [internal]
`passthroughAnimatedPropExplicitValues` from sticky header were removed in D46703731 with assumption that native animations trigger on complete callback and it can be used as a synchronisation point for Fabric.
On complete callback is triggered for native animations do trigger on complete callback with one exception: when the native animation is driven by scroll view's content offset.
As a result, synchronisation between React and Fabric doesn't happen and Pressability stops working if there is a pressable element in the sticky header.
Reviewed By: rubennorte
Differential Revision: D56005408
fbshipit-source-id: daead3a566e157593aa3f1b3ae3553ec1094b6da
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43418
Changelog: [Internal]
This diff adds a script, which will be later imported from `InitializeCore` to setup a required global for communication between React Native runtime (RDT Backend in it) and Chrome DevTools Frontend (RDT Frontend in it).
See README for the architecture overview and how bidirectional communication is established.
Corresponding PR in Chrome DevTools frontend - https://github.com/facebookexperimental/rn-chrome-devtools-frontend/pull/15
Reviewed By: motiz88
Differential Revision: D54770207
fbshipit-source-id: 0f0f04a338b5c7eab817c843a99b07cca95e57fd
Summary:
If you check the source of truth `packages/react-native/Libraries/Components/Touchable/TouchableHighlight.js` I'll find that `TouchableHighlight` is a result of `React.forwardRef(...)` :
https://github.com/facebook/react-native/blob/44d59ea6f9a1705487314e33de52f7056651ba25/packages/react-native/Libraries/Components/Touchable/TouchableHighlight.js#L382-L391
So the TS type isn't correct : (
```tsx
<TouchableHighlight ref={ref => { }} />
// ^^^ ref should be a `View` (but now it's `TouchableHighlight`)
```
---
**Breaking changes**
As `TouchableHighlight` isn't class anymore it can't be used as value & type
```tsx
import {TouchableHighlight} from 'react-native';
const ref = useRef<TouchableHighlight>();
// ^^^ TS2749: TouchableHighlight refers to a value, but is being used as a type here.
// Did you mean typeof TouchableHighlight?
```
**Recommend solution:** use build-in react type `React.ElementRef`
```diff
-const ref = useRef<TouchableHighlight>();
+const ref = useRef<React.ElementRef<typeof TouchableHighlight>>();
```
Also, it possible to use `View` as type:
```diff
-const ref = useRef<TouchableHighlight>();
+const ref = useRef<View>();
```
## Changelog:
[GENERAL] [BREAKING] - [Typescript] Transform TouchableHighlight from JS class to ForwardRef component
Pull Request resolved: https://github.com/facebook/react-native/pull/44038
Test Plan: See: `packages/react-native/types/__typetests__/index.tsx`
Reviewed By: NickGerleman
Differential Revision: D56015309
Pulled By: dmytrorykun
fbshipit-source-id: fee346536787a5921626ed69a4c01da2b599dc2f
Summary:
If you check the source of truth `packages/react-native/Libraries/Components/Touchable/TouchableOpacity.js` I'll find that `TouchableOpacity` is a result of `React.forwardRef(...)` :
https://github.com/facebook/react-native/blob/f7eaf63881b23216c06ab3c81ea94d0312cd6a7b/packages/react-native/Libraries/Components/Touchable/TouchableOpacity.js#L326-L335
So the TS type isn't correct : (
```tsx
<TouchableOpacity ref={ref => { }} />
// ^^^ ref should be a `View` (but now it's `TouchableOpacity`)
```
---
**Breaking changes**
As `TouchableOpacity` isn't class anymore it can't be used as value & type
```tsx
import {TouchableOpacity} from 'react-native';
const ref = useRef<TouchableOpacity>();
// ^^^ TS2749: TouchableOpacity refers to a value, but is being used as a type here.
// Did you mean typeof TouchableOpacity?
```
**Recommend solution:** use build-in react type `React.ElementRef`
```diff
-const ref = useRef<TouchableOpacity>();
+const ref = useRef<React.ElementRef<typeof TouchableOpacity>>();
```
Also, it possible to use `View` as type:
```diff
-const ref = useRef<TouchableOpacity>();
+const ref = useRef<View>();
```
## Changelog:
[GENERAL] [BREAKING] - [Typescript] Transform `TouchableOpacity` from JS `class` to `ForwardRef` component
Pull Request resolved: https://github.com/facebook/react-native/pull/44030
Test Plan: See: `packages/react-native/types/__typetests__/index.tsx`
Reviewed By: NickGerleman
Differential Revision: D56017133
Pulled By: dmytrorykun
fbshipit-source-id: 58f4c1a14c9b3bd2407ea6c825a90b355acb16bb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44005
When using frameworks on iOS, there is a possibility that modules import the Spec.h file twice and this might end up in a Redefinition of some symbols and duplication of symbols which ends up in build errors, as reported here: https://github.com/facebook/react-native/issues/42670.
This change adds some [`#include guards`](https://en.wikipedia.org/wiki/Include_guard) in codegen to avoid the redefinition of those symbols if the header is imported/included multiple times.
Note: I also experimented with `#pragma once`, but it looks like Apple is not happy with that directive. [It seems](https://forums.developer.apple.com/forums/thread/739964) that it started working flakely from Xcode 15.
## Changelog:
[General][Fixed] - Make sure that we can't include Codegen symbols multiple times
Reviewed By: cortinico
Differential Revision: D55925605
fbshipit-source-id: 15ca076aace2ffbd03ab8fa8a68a3d8ce0d1ea65
Summary:
this PR cleans up an outdated compatibility function in AndroidExecutors. the function in question was checking whether the code was running on Gingerbread or later - this is no longer needed, as RN requires Marshmallow or later.
## Changelog:
[INTERNAL] [FIXED] - Clean up outdated compatibility function
Pull Request resolved: https://github.com/facebook/react-native/pull/43958
Test Plan: this should work as normal.
Reviewed By: cortinico
Differential Revision: D55877661
Pulled By: dmytrorykun
fbshipit-source-id: 02eac50b0898d683f6abf731bf8e438ae4219a41
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43979
changelog: [internal]
using `availableSize` instead of `measurement` to avoid dependency on calling `textLayoutManager_->measure` before dispatching `onTextLayout` event.
This is important in subsequent optimisation.
Reviewed By: javache
Differential Revision: D55796594
fbshipit-source-id: 06b516e2afaf668c6359ad86b570229824933bae
Summary:
## 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
-->
Changelog: [Internal] Generated changelog
Pull Request resolved: https://github.com/facebook/react-native/pull/44008
Reviewed By: christophpurrer
Differential Revision: D56017161
Pulled By: dmytrorykun
fbshipit-source-id: 512c576a055a17b37a1f9fd5e328a1ff5165b398
Summary:
Using version information previously housed in react-native-communtiy/cli
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D55960009
fbshipit-source-id: 38f8b2310942a9337a7b64b51a87ae629d9bbbaf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44039
Changelog: [Internal]
Get label color from theme to fix dark mode.
Reviewed By: NickGerleman
Differential Revision: D56011777
fbshipit-source-id: 3ef14d6437c51118f0c0db3950b24f7e71d33fb3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43914
changelog: [internal]
This QE with caching text measurement and NSTextStorage did not deliver the desired results. Let's remove the code to simplify the text measure infra.
Reviewed By: javache
Differential Revision: D55753670
fbshipit-source-id: b194c4ca1eded70b0d00da748716628c264a47b9
Summary:
Capturing the correct attribution in the licenses as well as adding some documentation.
I think the code will have changed significantly enough across the files that once we change to flow, we can drop the attribution in the files but leave the mention in the README.
Changelog: [Internal]
bypass-github-export-checks
Reviewed By: huntie
Differential Revision: D55752899
fbshipit-source-id: b436d745d5ad439661d2af840b2cc8df4bff0038
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44041
changelog: [internal]
Building rn-tester left artifacts that would be picked up by mercurial.
```
❯ hg s
? rn-tester.xcodeproj.local/Project Settings.plist
? rn-tester.xcodeproj.local/Project Settings.plist.lock
```
To mitigate this, add `rn-tester.xcodeproj.local` introduce .gitignore for rn-tester.
Reviewed By: fabriziocucci
Differential Revision: D56006193
fbshipit-source-id: 5701f1adf395e98f84ca59574dbd8747cf7e85db
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44010
X-link: https://github.com/facebook/yoga/pull/1641
Yoga has quirk where newly constructed nodes are clean, which isn't really correct. Normally never shows in in real code because setting a style or children will dirty. Fabric doesn't use the public APIs that do this dirtying, so it ends up getting creative instead.
We should fix so that newly constructed nodes are dirty. Copy-constructed Nodes (also only a Fabric thing, will retain original dirty flag.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D55855328
fbshipit-source-id: be49efaf8ac29351f8e5ec509bd9912546944332
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44028
Changelog: [Internal]
While testing something completely unrelated (i.e. D55964787), I've noticed that [test_android](https://github.com/facebook/react-native/actions/runs/8635097933/job/23673157303?pr=44026) actually failed on Github with this error:
> Task :packages:react-native:ReactAndroid:compileDebugUnitTestKotlin
e: file:///__w/react-native/react-native/packages/react-native/ReactAndroid/src/test/java/com/facebook/react/views/image/ReactImagePropertyTest.kt:62:38 Smart cast to 'CatalystInstance' is impossible, because 'catalystInstanceMock' is a mutable property that could have been changed by this time
Reviewed By: RSNara
Differential Revision: D55982797
fbshipit-source-id: a49e766ae95e22603293326da93007d78250da6a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43998
Another library with an empty JNI_OnLoad method.
Moving it to `INTERFACE` so it exposes only the Header it has declared.
This removes the `libreactperfloggerjni.so` from the final APK.
Changelog:
[Internal] [Changed] - Move reactperfloggerjni to INTERFACE library
Reviewed By: javache
Differential Revision: D55919228
fbshipit-source-id: 634f4f6013825b0de8827b3143a012e6c880509d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44015
Changelog: [internal]
## Context
When we introduced synchronous state updates in Fabric, we saw some crashes on coming from the mounting layer on Android.
It seems some of these crashes are caused by nested mount operations. When we're mounting some views, like [scroll views](https://github.com/facebook/react-native/blob/881c0bc8970b9e402df6b4f87e1759b238b24735/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/views/scroll/ReactHorizontalScrollView.java#L383), we dispatch state updates that end up doing more mutations. When we were doing these state updates asynchronously, all the original mutations were processed before these updates, but now that we do them synchronously, the mutations are interleaved causing errors.
## Changes
This introduces a new flag that will force all the mutations going through `MountItemExecutor` in `FabricUIManager` to be batched instead of executed synchronously. This fixes the issues I saw locally and I'm expecting this will unblock synchronous state updates in production.
Potentially, this might fix other crashes we've been seeing with a low frequency.
Reviewed By: sammy-SC
Differential Revision: D55942125
fbshipit-source-id: b8d9c145ec307de7318dbbed14880bc9a84fdb2a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43992
# Changelog:
[Internal] -
While looking into implementing native DevLoadingView on non-Android/iOS platform, I realized that the current code inside `LoadingView.android.js`/`LoadingView.ios.js` is functionally identical, and can be transformed into each other with simple code transformations.
This diff:
* Renames `LoadingView` into `DevLoadingView` (as it's arguably more fitting name, given that it also relies on `NativeDevLoadingView` native module implementation)
* Merges the iOS/Android specific JS files into one
* Factors usage of the colors out of the actual logic, to better separate presentation from the business logic
From the perspective of public APIs there should be no changes.
Reviewed By: christophpurrer
Differential Revision: D55914787
fbshipit-source-id: 656311db80e5ee03f60ee7ffcf5f405ca99a9ce5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43068
This diff adds `react-native-test-library` package.
It contains native module and native component example, and targets both the new and the old architecture. It has structure similar to many OSS React Native libraries, and is supposed to be used to test the integration with third-party libraries.
It is integrated with RNTester as the **OSS Library Example** screen.
{F1457510909}
**Change Background** tests native commands.
**Set Opacity** tests native props.
**Get Random Number** tests native module.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D50793835
fbshipit-source-id: ff6daefab10e6e9f13049e3013f8f63cfa8a929e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43995
With a previous change, we started taking snapshots of the Modal every time a Fabric mounting event was happening. this might cause perf regression when a modal is presented, and there is no need to take a snapshot that often.
This change moves the snapshotting code right before the dismissal of the Modal.
## Changelog
[iOS][Changed] - Move the snapshotting code before the dismissal.
## Facebook
This should fix T179288585, T184520225
Differential Revision: D55914776
fbshipit-source-id: 6679babf7f72aef7254113497116d5482640e789
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43999
Currently NewArch-BridgeMode is partially broken when creating views via `ReactDelegate`.
That's because we're using the ctor that doesn't account for `Boolean: fabricEnabled`.
That means that the `RootView` that it will be created are all having setIsFabric(FALSE).
This is causing problems like whitescreens on several reload + multiple warnings such as:
```
E com.facebook.react.bridge.ReactNoCrashSoftException: Cannot get UIManager because the context doesn't contain an active CatalystInstance.
```
Fixes#43692
See for more context on this issues: https://github.com/facebook/react-native/issues/43692
Changelog:
[Android] [Fixed] - Fix bridge mode by constructing ReactDelegate correctly
Reviewed By: cipolleschi
Differential Revision: D55921078
fbshipit-source-id: 2c21d089a49538402d546177bcdb26c8d7d5fbc1
Summary:
This current consists of a bunch of TypeScript code, which will be ported to Flow in the stack.
Changelog: [Internal]
bypass-github-export-checks
Reviewed By: huntie
Differential Revision: D55741526
fbshipit-source-id: 1dc30d2ab63e0526dd6fed17ccf7cce9f57bdbee
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43994
We received [this issue](https://github.com/facebook/react-native/issues/43764) from OSS where an app can't connect to Metro on reloads in the following scenario:
* Start the App when metro does not run.
* Observe the error screen
* Start Metro
* Press Reload
* Observe the error message again
While the desired behavior should be to connect to Metro now that this is running.
The root cause of the problem is that the RCTHost is initialized with a value of the `bundleURL` that is `nil`. Upon reload, the RCTHost is **not** recreated: the instance is restarted, but with the previous `bundleURL`, which is still `nil`.
The solution is to initialize the `RCTHost` with a closure that re-evaluate the `bundleURL` whenever it is invoked and to evaluate it only on `start`, to keep the initialization path light.
This way, when the app is started with Metro not running, the `bundleURL` is `nil`. But when it is reloaded with Metro starting, the `bundleURL` is properly initialized.
Note that the changes in this diff are not breaking as I reimplemented (and deprecated) the old initializer so that they should work in the same way.
## Changelog:
[iOS][Fixed] - Let RCTHost be initialized with a function to provide the `bundleURL` so that it can connect to metro on Reload when the url changes.
Reviewed By: dmytrorykun
Differential Revision: D55916135
fbshipit-source-id: 6927b2154870245f28f42d26bd0209b28c9518f2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43963
changelog: [internal]
This experiment did work out. Let's clean it up
Reviewed By: cortinico
Differential Revision: D55797519
fbshipit-source-id: a5da97a7d31b9395b25bfd37db567054721599b0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43971
It turns out that we forgot to add a listener for the orientation change event in Bridgeless.
We used to have `UIApplicationDidChangeStatusBarOrientationNotification` but this is slightly unreliable because there might be use cases where the status bar has been hidden and, therefore, the event is not triggered.
This should fix an issue reported by OSS.
## Changelog:
[iOS][Fixed] - Make sure that the New Architecture listens to orientation change events.
Reviewed By: cortinico
Differential Revision: D55871599
fbshipit-source-id: c9b0634ec2126aa7a6488c2c56c87a9610fa1adf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43852
Changelog: [internal]
Just a small refactor so we rely less on shared pointers within `RuntimeSCheduler_Modern`.
Reviewed By: javache
Differential Revision: D55646389
fbshipit-source-id: d01dcba7b1551d349d21717ba585828ed7fb3259
Moti Zilberman
Samuel Susla
Max Hoffmann
Fabrizio Cucci
Ruslan Lesiutin
Sam Zhou
D N
Riccardo Cipolleschi
Sophie L
hurali97
Blake Friedman
Andrew Datsenko
Mohamed Moussa
Nick Gerleman
Biki-das
Alan Lee
Nicola Corti
Rubén Norte
Soe Lynn
Ruslan Shestopalyuk
Dmitry Rykun
Christoph Purrer