Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41036
Changelog:
[Added] - Shipping the new event dispatching pipeline that immediately moves events over to the C++ queue. This should unblock useDeferredValue + useTransition interruptibility on Android.
Reviewed By: javache
Differential Revision: D50365981
fbshipit-source-id: ecf60e5bc29fb4568463568a6ede4330e0294fd3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39671
Since minsdk version was increased to 23, we are deleting code using Android APIs < 23 for class ReactEditText
changelog: [Android][Breaking] Remove support for Android API < 23 in ReactEditText
Reviewed By: NickGerleman
Differential Revision: D48545507
fbshipit-source-id: 98be52ba36248962864e99e80ff648bbb351ff61
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41499
After D48152876 we consume JSI from `ReactCommon/jsi`, and ignore JSI that is distributed with `hermes-engine`.
This diff removes `include/jsi` from `source_files` of `hermes-engine` so we don't get two sets of JSI headers - one from `ReactCommon`, and the other one from `hermes-engine`.
This diff also fixes accidental breakage of ODR violation. We will no longer compile JSI into `react-native` when linking against `hermes-engine`, which already has JSI in it.
Changelog: [iOS][Fixed] - Exclude JSI headers when using hermes-engine prebuilt.
Reviewed By: cipolleschi
Differential Revision: D51347562
fbshipit-source-id: 6e4b9940c43d74d227a05999926b8752d7685670
Summary:
Recently, both `metro-inspector-proxy`(https://github.com/facebook/react-native/pull/39045) and `react-native-community/cli-plugin-metro`(https://github.com/facebook/react-native/pull/38795) were moved to this repo and in the process of moving these packages, the `exports` field inside package.json was added, only exporting the `index.js` file.
The problem is that Expo CLI (and possibly other community packages) rely on functions and classes that are not exported in the `index.js` file, e.g. Importing the InspectorProxy class from `react-native/dev-middleware/dist/inspector-proxy/InspectorProxy`. Normally this wouldn't be a problem and we would just import from `dist/` but due to the `exports` field, attempting to import from any other file not specified on this field will result in a `ERR_PACKAGE_PATH_NOT_EXPORTED` error.
As a short-term fix, we should create `unstable_`-prefixed exports of individual features Expo currently depends on.
## Changelog:
[INTERNAL] [CHANGED] - Expose unstable_InspectorProxy and unstable_Device from `react-native/dev-middleware`
Pull Request resolved: https://github.com/facebook/react-native/pull/41370
Test Plan: N / A
Reviewed By: robhogan
Differential Revision: D51163134
Pulled By: blakef
fbshipit-source-id: e67adaedc4fc64131e4c9dd8383c9877b8202283
Summary:
There is a problem in the way that we check if Fabric is enabled inside `react_native_post_install`.
https://github.com/facebook/react-native/blob/899e7cdb55197fc17a96a93af4f8bcc7519553c2/packages/react-native/scripts/react_native_pods.rb#L239
We're determining if fabric is enabled by checking if the `React-Fabric pod `is present, but since we always call `setup_fabric!(:react_native_path => prefix)` (https://github.com/facebook/react-native/pull/39057) inside `use_react_native` the `React-Fabric` pod is always present causing the `-DRN_FABRIC_ENABLED` flag to always be added to `project.pbxproj` even if the new arch is disabled.
[IOS] [FIXED] - Fix ios pod post_install logic for detecting if fabric is enabled
Pull Request resolved: https://github.com/facebook/react-native/pull/41284
Test Plan: Run `use_react_native!(fabric => false)` should not add the `-DRN_FABRIC_ENABLED` flag to `project.pbxproj`
Reviewed By: fkgozali
Differential Revision: D50896487
Pulled By: cipolleschi
fbshipit-source-id: 78154407ce52b09fd3a317b7dc64bd4bba56363e
Summary:
This should fix
https://github.com/facebook/react-native/issues/37905#issuecomment-1774851214
When working on react-native-fast-image, we realized that the interop layer does not work for components where the exported name is different from the iOS class.
To fix this, we can use the Bridge to retrieve the actual view manager, given the component name.
This solution should be much more robust than making assumptions on the ViewManager name, given the ComponentName.
On top of that, we realized tha the interop layer was not calling `didSetProps` after setting the props, so we are invoking that.
bypass-github-export-checks
[iOS][Fixed] - Add support for Components with custom names in the interop layer.
Pull Request resolved: https://github.com/facebook/react-native/pull/41207
Test Plan: Tested locally on an app created in 0.72 and 0.73 in Bridge and Bridgeless mode.
Reviewed By: cortinico
Differential Revision: D50698172
Pulled By: cipolleschi
fbshipit-source-id: 49aee905418515b0204febbbe6a67c0114f37029
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40869
Bumps DRNPT to v5 - the significant change is that this one depends on `react-native/normalize-color: ^0.73.0`, instead of `*`, so is protected from future breaking changes to that package.
NOTE: We can't safely include `react-native/normalize-color: ^0.74.0` in the dependency range of DRNPT because `0.74.0` isn't a semver-compliant release (0.74 isn't cut yet), so this will pull 0.73.2 from NPM, which is fine. We may need to publish DRNPT@6 if 0.74 final turns out to contain breaking changes (eg, a Node 20 bump).
Changelog:
[General][Fixed] Update `deprecated-react-native-prop-types` to remove fragile transitive `*` dependencies.
Reviewed By: huntie
Differential Revision: D50228564
fbshipit-source-id: 01aafafad40d9a93d00de2b5f45d2796620b9b5d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41270
`scheduleCellsToRenderUpdate()` is called in response to new measurements, or component changes. It has logic to decide whether to immediately calculate new state, or to defer it until a later batched period.
It will not immediately update state if we don't yet have measurements for cells, but this condition is after another which calculates priority, relying on these measurements. These are garbage if we don't yet have measurements, and trigger an invariant violation in horizontal RTL.
This switches around the conditions, to avoid offset resolution if we don't yet have valid measurements.
I suspect some "hiPri" renders where cells shift are bugged right now when we update state in response to content size change, before we have new corresponding cell layouts.
Changelog:
[General][Fixed] - Bail on hiPri render on missing layout data before checking priority
Reviewed By: yungsters
Differential Revision: D50791506
fbshipit-source-id: 8dbffc37edd2a42f7842c0090d344dcd6f3e3c6d
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:
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/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:
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/40941
Events are currently not working for Fabric Interop on Bridgeless. That's because the `BridgelessReactContext` is not checking for interop modules on `getJsModule` calls, so the `InteropEventEmitter` is never returned.
This extends `BridgelessReactContext` so that `InteropEventEmitter` is returned if the Interop Layer is turned on.
Changelog:
[Internal] [Changed] - Make events work for Fabric Interop on Bridgeless
Reviewed By: cipolleschi
Differential Revision: D50266484
fbshipit-source-id: 0188d71bdc7acc8c188d886d45f0258914ad7af7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40929
This diff reduces the footprint that bridgeless is imposing on the new app template. Specifically:
- I've created a `.toReactHost` method that converts a DefaultReactNativeHost to a DefaultReactHost
- I've updated RN Tester to use the same setup as the New App template which reduces code duplication.
I also had to remove a couple of `UnstableReactNativeAPI` as those were bleeding in the new app template.
I don't think we should ask users to opt-in in `UnstableReactNativeAPI` in the New App template itself as
this means that all the apps will get this opt-in.
Instead we should keep it only for specific APIs that we want the users to opt into.
Changelog:
[Internal] [Changed] - Simplify new app template for bridgeless
Reviewed By: cipolleschi, luluwu2032
Differential Revision: D50227693
fbshipit-source-id: e86c54d5156cc27f1f898b43ca89c57d5cf148b8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40942
The Fabric Interop example for Android is broken. This is due to the Kotlin conversion which moved the `Color.colorToHSV(color, hsv)` statement *after* the HSV array is read so the array is always [0,0,0].
I'm fixing it here.
Changelog:
[Internal] [Changed] - Fix broken Fabric Interop example
Reviewed By: cipolleschi
Differential Revision: D50264766
fbshipit-source-id: 27ae5289408c7c23c667d6d7112437fa7ebe36d5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40940
Currently the `onIntArrayChanged` event is invoked
only once inside RN Tester. I'm changing the logic to make sure it fires whenever we click "Set Opacity"
Changelog:
[Internal] [Changed] - Make sure onIntArrayChanged is invoked on RN Tester
Reviewed By: mdvacca, dmytrorykun
Differential Revision: D50264765
fbshipit-source-id: 93a60fd1b657c3d8b8182cab6bb7cd4368ac9a42
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40767
Fix the following issue:
```Invariant Violation: TurboModuleRegistry.getEnforcing(...):
'ExceptionsManager' could not be found. Verify that a module by this name is registered in the native
binary.Bridgeless mode: true. TurboModule interop: true. Modules loaded: {"NativeModules":[],"TurboModules":
["PlatformConstants","AppState","SourceCode","BlobModule","WebSocketModule","DevSettings","DevToolsSettingsManager","LogBox","Networking","Appearance","DevLoadingView","DeviceInfo","DeviceEventManager",
"SoundManager","ImageLoader","DialogManagerAndroid","NativeAnimatedModule","I18nManager","AccessibilityInfo","StatusBarManager","StatusBarManager","IntentAndroid","ToastAndroid","ShareModule","Vibration"],
"NotFound":["NativePerformanceCxx","NativePerformanceObserverCxx","RedBox","BugReporting","HeadlessJsTaskSupport","FrameRateLogger","KeyboardObserver",
"AccessibilityManager","ModalManager","LinkingManager","ActionSheetManager","ExceptionsManager"]}
```
Changelog:
[Android][Changed] - Add Add ExceptionsManagerModule to CoreReactPackage
Reviewed By: cortinico
Differential Revision: D50017783
fbshipit-source-id: 8642bb23bdae50a1e702f5e0586b0ede80007bb1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39810
Two issues will be fixed:
- Bridgeless has lazy view manager loading by default so the React Package that provides view managers must implement ViewManagerOnDemandReactPackage, we might could refactor the design of package classes later
- ThemedReactContext should **NOT** be used directly to call function ```getJSModule```, since it doesn't overrides ```getJSModule``` for Bridgeless, we can use it's internal variable ```meactApplicationContext``` which should be an instance of BridgelessReactContext
Reviewed By: cortinico
Differential Revision: D49912656
fbshipit-source-id: a0bdd717612398e8d7a6f36d36dba241a3b06bd7
Summary:
We don't need this if-than-else because the initializeFlipper already checks if we're on bridgeless or not
Changelog:
[Internal] [Changed] - Do not guard initializeFlipper for bridgeless for RN Tester
Reviewed By: NickGerleman
Differential Revision: D49881903
fbshipit-source-id: e6bfc941b43382580bd418a5f27ad9426d300c69
Summary:
Rewrite `RNTesterApplication` to Kotlin as per [Help us Kotlin-ify React Native tests - Round 2](https://github.com/facebook/react-native/issues/38825)
## Changelog:
[ANDROID] [CHANGED] - Rewrite RNTesterApplication to Kotlin, add AnnotationTarget property.
Pull Request resolved: https://github.com/facebook/react-native/pull/39557
Test Plan:
`yarn && yarn android` ✅
The only thing I'm kinda unsure of is whether `AnnotationTarget.PROPERTY` should be added, but it didn't let me annotate `reactHostInterface` without that and didn't compile.
<img width="637" alt="image" src="https://github.com/facebook/react-native/assets/33528752/8bc84870-f3f2-4a46-b076-6ee7e38bd735">
cortinico mdvacca
Reviewed By: cortinico
Differential Revision: D49598401
Pulled By: mdvacca
fbshipit-source-id: 105ae0c13c93dae0eeb2b6fa9040f03f42d2736a
Summary:
Commit 8b88883071 broke the Cache for RNTester because the cached version of the pods does not know about the exitence of SocketRocket 6.1.0
Bumping the keys should force a redownload of the cocoapods specs repo
## Changelog:
[Internal] - Bump RNTester cache keys
Pull Request resolved: https://github.com/facebook/react-native/pull/40789
Test Plan: CircleCI is green
Reviewed By: GijsWeterings
Differential Revision: D50169281
Pulled By: cipolleschi
fbshipit-source-id: 83e251495bfa43d62384470efe97c5505d76684f
# Conflicts:
# packages/rn-tester/Podfile.lock
Summary:
The SocketRocket version was upgraded to 0.6.1 on the 0.72-stable branch but for some reason it was not updated in main, causing a downgrade when running `pod install` with 0.73.0 RC1
Original commit bumping SocketRocket -> https://github.com/facebook/react-native/commit/8ce471e2fa802cc50ff2d6ab346627cb5f6d79b4
## Changelog:
[IOS] [CHANGED] - Bump SocketRocket to 0.6.1
Pull Request resolved: https://github.com/facebook/react-native/pull/40774
Test Plan: Run rntester locally
Reviewed By: cipolleschi
Differential Revision: D50137261
Pulled By: arushikesarwani94
fbshipit-source-id: dfc2760f5d5611881126ad114d8f6ada23630a29
# Conflicts:
# packages/react-native/React-Core.podspec
# packages/react-native/React/CoreModules/React-CoreModules.podspec
# packages/rn-tester/Podfile.lock
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41050
This change aligns all the podspecs to 13.4, including 3rd party libraries. This should fix https://github.com/facebook/react-native/issues/39826
## Changelog
[iOS][Changed] - Align all pods to 13.4
Reviewed By: huntie
Differential Revision: D50405114
fbshipit-source-id: 2d1b50ed8433e8cdc2214eb17e15be6ea81107a1
# Conflicts:
# packages/react-native/scripts/cocoapods/utils.rb
Summary:
For a very long time when a promise rejects without an attached catch we get this warning screen without a correct stack trace, only some internal calls to the RN internals.
<img src="https://github.com/facebook/react-native/assets/1634213/75aa7615-ee3e-4229-80d6-1744130de6e5" width="200" />
I created [an issue for discussion](https://github.com/react-native-community/discussions-and-proposals/discussions/718) in the react-native-community repo and we figured out it was only a matter of symbolication. While it cannot be done on release without external packages and source maps, at least while developing we can provide a symbolicated stack-trace so developers can better debug the source of rejected promise.
I got the stack trace symbolicated and the correct code frame. I'm missing some help trying to display it in the warning view but at the very least I can now correctly show the line of the error and log the codeframe to the console.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[GENERAL] [FIXED] - Show correct stack frame on unhandled promise rejections on development mode.
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/40914
Test Plan:
I simply created a throwing function on a dummy app, and checked the output of the console and the warning view:
```ts
import React from 'react';
import {SafeAreaView, Text} from 'react-native';
async function throwme() {
throw new Error('UNHANDLED');
}
function App(): JSX.Element {
throwme();
return (
<SafeAreaView>
<Text>Throw test</Text>
</SafeAreaView>
);
}
export default App;
```
Here is the output
<img src="https://github.com/facebook/react-native/assets/1634213/2c100e4d-618e-4143-8d64-4095e8370f4f" width="200" />
Edit: I got the warning window working properly:
<img src="https://github.com/facebook/react-native/assets/1634213/f02a2568-da3e-4daa-8132-e05cbe591737" width="200" />
Reviewed By: yungsters
Differential Revision: D50324344
Pulled By: javache
fbshipit-source-id: 66850312d444cf1ae5333b493222ae0868d47056
Luna Wei
Jesse Watts-Russell
David Vacca
Dmitry Rykun
Gabriel Donadel
Kacper Kafara
Riccardo Cipolleschi
Riccardo Cipolleschi
Distiller
Rob Hogan
Nick Gerleman
tarunrajput
Nicola Corti
Rob Hogan
Moti Zilberman
Distiller
Alex Hunt
Lulu Wu
Christoph Purrer
Oleksii
Oscar Franco