Summary:
## Changelog:
[Internal] -
This replaces object literal return types in `getConstants()` for core RN native modules with type aliases.
This is a valid change from the point of view of binary compatibility between native/JS, and provides a couple of benefits, such as clearer code in general, but also ability to employ C++ codegen for the corresponding types and their marshalling.
bypass-github-export-checks
Reviewed By: christophpurrer
Differential Revision: D48685992
fbshipit-source-id: f21358b12448d30a7b5e25e81f62ef77964d1fcd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38872
## Changelog:
[iOS][Breaking] - RCTTurboModuleRegistry is unavailable in RCTRootView and RCTSurfaceHostingProxyRootView
now after all the diffs in this stack, we can finally decouple the root views from the module registry, and remove the dependency from fabric root views on bridge.
for what i'm breaking, i only found this module library: https://github.com/flyskywhy/react-native-blob-util/blob/3d5155e11426fa458a9e2dbf7fe691cf9863ff01/ios/ReactNativeBlobUtil/ReactNativeBlobUtil.mm#L45. they can replace this with synthesize moduleRegistry API to get access.
for eventDispatcher, i didn't see anyone using this.
Reviewed By: mdvacca, cipolleschi
Differential Revision: D48179428
fbshipit-source-id: d08fbd0adf6177d56e32a0ce4b21b6acb0682a2d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39113
This diff makes Xcode build fail if `Build JS Bundle` script phase fails. Before that the script phase could fail silently resulting in subltle breakages. E.g. we could get seemingly working app that doesn't have proper jsbundle or source maps.
Changelog: [IOS][Fixed] - Fail Xcode build if Build JS Bundle script phase fails.
Reviewed By: motiz88
Differential Revision: D48562229
fbshipit-source-id: 247e271b1ce28061418bb7a8277dcabf3dcf99aa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39128
`HERMES_ENABLED` was supposed to indicate wether hermes-engine pod is present in the project. It was initialized by grepping `hermes-engine` from `Podfile.lock`.
This is redundant because Hermes is enabled by default and it is sufficient to check that `$USE_HERMES != false` for cases that are Hermes specific.
Changelog: [Internal] - Remove usage of HERMES_ENABLED from react-native-xcode.sh
Reviewed By: cipolleschi
Differential Revision: D48600174
fbshipit-source-id: 522d4edb89517fd432cc159624a41219c9e00124
Summary:
- if an existing iOS project specifies `EXCLUDED_ARCHS`, these settings are overwritten by the `react_native_post_install` step as part of the Cocoapods install
- this can break the build of existing iOS apps that want to include React Native
- a previous PR (https://github.com/facebook/react-native/pull/38132) updated the Cocoapods utils to that we only update `EXCLUDED_ARCHS` when using Hermes
- this worked around the issue for apps that opted to use JSC
- however if you _do_ want to use Hermes (the default) this problem persists
### Existing Behaviour
- one of the functions called as part of the `react_native_post_install` step is `exclude_i386_architecture_while_using_hermes`
- see [/packages/react-native/scripts/cocoapods/utils.rb](https://github.com/facebook/react-native/blob/v0.72.1/packages/react-native/scripts/cocoapods/utils.rb#L56-L69)
```
def self.exclude_i386_architecture_while_using_hermes(installer)
projects = self.extract_projects(installer)
# Hermes does not support `i386` architecture
excluded_archs_default = self.has_pod(installer, 'hermes-engine') ? "i386" : ""
projects.each do |project|
project.build_configurations.each do |config|
config.build_settings["EXCLUDED_ARCHS[sdk=iphonesimulator*]"] = excluded_archs_default
end
project.save()
end
end
```
🐛 **However** 🐛
- this means existing projects that have `EXCLUDED_ARCHS` set, the existing value will be overwritten either to `"i386"` or a blank string
### Changed Behaviour
- appends `"i386"` to existing string if set, or just sets the value to `"i386"` if there is no existing value
## 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
-->
[IOS] [FIXED] don't override `EXCLUDED_ARCHS` when installing Hermes
Pull Request resolved: https://github.com/facebook/react-native/pull/39060
Reviewed By: dmytrorykun
Differential Revision: D48515441
Pulled By: cipolleschi
fbshipit-source-id: 8cb3c8b680d92272da0b106553179af051d0f84e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39148
This change adds another `DEFINES_MODULE` to React-ImageManager which is required to integrate with Swift.
## Changelog:
[Internal] - Add Defines modules for React-ImageManager.
## Facebook:
This work is required to collaborate with Expo on ExpoModules
Reviewed By: dmytrorykun
Differential Revision: D48648153
fbshipit-source-id: b06f049be2aedc9fb1ca4744fde0dda88cb74ece
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39185
Changelog: [Internal] - Fix incorrect pointer coordinates caching
In D48472486 I moved the updating of "previous" fields into the `handleHitStateDivergence` method which made sense considering that it's run on every event regardless but what I didn't take into account was the updating of the `mLastEventCoordinatesByPointerId` field. On `ACTION_HOVER_MOVE` events there's a filter that ensures that only move events that have a large enough distance are emitted (something that isn't done on iOS, hence why I didn't think of it), but after my changes in D48472486 it was updating `mLastEventCoordinatesByPointerId` **before** that hover move check, making the distance always 0 and never firing move events.
This diff fixes this by moving the updating of `mLastEventCoordinatesByPointerId` and `mLastButtonState` back to the end of `handleMotionEvent`.
Reviewed By: lunaleaps
Differential Revision: D48756372
fbshipit-source-id: 6f2e40366986ce8d1c6128e49bf3abd44137196d
Summary:
This PR is another one made with the intent to reduce the number of diffs between React Native and React Native macOS.
In https://github.com/facebook/react-native/commit/f7219ec02d71d2f0f6c71af4d5c3d4850a898fd8#diff-d091f6636e07dc62dd7d892489355707c43923ac15056fd2eb59d9a297d576a6 , we introduced `kRCTPlatformName`, which had already been in React Native macOS for a while (since we ifdef to either "ios" or "macos" in a number of places). This change moves the string up to a common header (dropping the "k" prefix) so we can refactor other strings that currently have a hardcoded "platform=ios" inside them.
## Changelog:
[IOS] [CHANGED] - Add RCTPlatformName to RCTConstants.h
Pull Request resolved: https://github.com/facebook/react-native/pull/39141
Test Plan: CI should pass
Reviewed By: NickGerleman
Differential Revision: D48656197
Pulled By: lunaleaps
fbshipit-source-id: b9ff08e2591d7553a1a452795f36d4405ddaa5b1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39184
Previously, when `props.accessibilityValue` was enabled and other props were enabled, like `props.accessibilityRole`, that are used in the accessibilityValue for iOS, the value from `props.accessibilityValue` wasn't announced.
This is a problem for cases like radio button, which also needs to announce the placement of the radio button within a group, e.g. "[label], radio button, checked, 1 out of 3".
This diff fixes this problem by including the value from `props.acessibilityValue` within the method that builds the `accessibiityValue` for VoiceOver.
Reviewed By: cipolleschi
Differential Revision: D48534155
fbshipit-source-id: 176ba76ff772741a5cdc7d2a56c6cdfb92674477
Summary:
- when using the `useWindowDimensions()` hook in a component, it's possible for the hook to report incorrect sizes and not update as frequently as it should
- this is most applicable to apps built for iPad and macOS
- closes https://github.com/facebook/react-native/issues/36118
### Existing Behavior - https://youtu.be/NcV6kEDg20E
- either when resizing a React Native app to a different [Size Class](https://developer.apple.com/design/human-interface-guidelines/layout#Device-size-classes) or changing the Appearance, we dispatch an `RCTUserInterfaceStyleDidChangeNotification` notification
- these are then handled in the `interfaceFrameDidChange` method of `RCTDeviceInfo`
- this results in a `didUpdateDimensions` Device Event, which in turn updates the results of `useWindowDimensions()`
- see [RCTDeviceInfo.mm#L217-L232](https://github.com/facebook/react-native/blob/v0.72.0-rc.4/packages/react-native/React/CoreModules/RCTDeviceInfo.mm#L217-L232)
- and [Dimensions.js#L119-L124](https://github.com/facebook/react-native/blob/v0.72.0-rc.4/packages/react-native/Libraries/Utilities/Dimensions.js#L119-L124)
🐛 **However** 🐛
- if you are resizing without triggering a `UITraitCollection` change, the Dimensions reported by `useWindowDimensions()` can become stale, until you either:-
- hit a certain width that is considered a different Size Class
- change the Appearance
- background then resume the app
- make the app full-screen
### Changed Behavior - https://youtu.be/w9BevpZ2y08
- added a new `RCTRootViewFrameDidChangeNotification` notification
- the thinking here is to avoid additional overhead by re-using the same `RCTUserInterfaceStyleDidChangeNotification`
- maybe it's overkill?
- the new notifications are sent from an override of `setFrame` on `RCTRootView`
- the new notifications call the same `interfaceFrameDidChange` method of `RCTDeviceInfo`
- Dimensions are now reported correctly when resizing; even within the same Size Class
## 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
-->
[IOS] [FIXED] - Dimensions could be reported incorrectly when resizing iPad or macOS apps
Pull Request resolved: https://github.com/facebook/react-native/pull/37649
Test Plan:
**Reproduction: https://github.com/jpdriver/Dimensions**
or to recreate it yourself:-
- Generate a new project
- Change App.tsx
```
import * as React from 'react';
import {View, Text, useWindowDimensions} from 'react-native';
export default function App() {
const {width, height} = useWindowDimensions();
return (
<View style={{flex: 1, justifyContent: 'center', alignItems: 'center'}}>
<Text>Width: {width}</Text>
<Text>Height: {height}</Text>
</View>
);
}
```
- Open the iOS project in Xcode and enable iPad support
- Enable the iPad app to be used in any orientation
- Run the app
- Enable Stage Manager
- Drag one of the corners to resize the app
Reviewed By: javache
Differential Revision: D46335537
Pulled By: NickGerleman
fbshipit-source-id: 1533f511cf3805fdc9629a2ee115cc00e204d82c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39144
## Changelog:
[Internal] -
This adds more information into internal shadow tree consistency check error reporting, as well as some minor code refactorings.
Note that the code is run only in debug, and normally you don't trigger such issues, unless you look into a new platform implementation (which I did).
Reviewed By: javache
Differential Revision: D48643602
fbshipit-source-id: a6475f2f577c7b461622472af1c6855072ae319e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39149
Props structs are allowed to references RawValue keys multiple times, however this didn't work correctly if the key was formed out of a different combination of prefix/name/suffix, as the duplicate key entry would've been removed from the `RawPropsKeyMap`. Log an error in such scenarios to help identify these types of problems.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D48641819
fbshipit-source-id: 8cf71366cbf8ae6bee418a6c9d030ebd38784d52
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39155
[Changelog]: [Android][Fixed] Fix crash in CompositeTurboModuleManagerDelegate
CompositeTurboModuleManagerDelegate.cpp crashes as we pass in one or multiple
```
jni::alias_ref<TurboModuleManagerDelegate::javaobject> delegate
```
but don't retain a global reference to them. Fix use:
```
jni::make_global(delegate)
```
Differential Revision: D48670217
fbshipit-source-id: e805f28919918b2a867589dbb6e2a70d67dcd8c3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39153
`FlatList`'s restriction on not changing the `onViewableItemsChanged` prop forces developers to violate the rules of React, risking bugs and blocking the rollout of other improvements such as React Forget.
This diff relaxes the validation specifically for the seemingly common case in which a developer passes just a onViewableItemsChanged prop instead of viewabilityConfigCallbackPairs. We use an anonymous closure to create a stable identity that will be passed down to the underlying VirtualizedList, where the closure calls the current `props.onViewableItemsChanged`. The intent of this diff is to alleviate the worst impacts of the current restriction with a correct if not ideal solution, giving us time to fix the API more holistically.
Feedback welcome!
## Changelog:
[Changed] - Allow passing different values to `FlatList.onViewableItemsChanged`
## Facebook
See https://fburl.com/workplace/9svfrytw for more context.
Reviewed By: NickGerleman
Differential Revision: D48656586
fbshipit-source-id: 5b0926deada25637786c4cf3b329607d9f515528
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39140
TurboReactPackage.getModule is nullable, although the internals of ReactNative requires this method to be non null (otherwise there will a NPEs)
I'm making TurboReactPackage.getModule no nullable, this is important to simplify API and future migration to kotlin
changelog: [internal] internal/
Reviewed By: cortinico
Differential Revision: D48588375
fbshipit-source-id: e510f76ea0271ff33ab2ebe6c76382c4781e1787
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39137
getNativeModuleIterator is not required to be public, reducing visibillity to package only
changelog: [internal] intenral
Reviewed By: philIip, rshest
Differential Revision: D48588376
fbshipit-source-id: 6cbff90a4c51d2af4b0693b84c1a674ea24b94d1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39135
## Changelog:
[Internal] -
Expose constants type from DeviceInfo native module - this makes codegen generate the corresponding data structure, making the native module implementation shorter (in C++ in particular).
Reviewed By: christophpurrer
Differential Revision: D48620784
fbshipit-source-id: 40ae83ebec92e0a470c20ef1ad16f8392e2bf8b0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38967
Changelog: [IOS][Added] - Now it is possible to build Hermes form local source directory. Just set REACT_NATIVE_OVERRIDE_HERMES_DIR to the path to that directory.
Known shortcoming: changes made to the Hermes source will not be reflected in the RN project. You should manually delete `Pods/hermes-engine` and rerun `pod install`.
Reviewed By: cipolleschi
Differential Revision: D48121314
fbshipit-source-id: 0389662396921bdf120d390de36a586c52eb47f1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38963
This diff refactors `hermes-utils.rb` in the following way:
- Explicitly define all the scenarios how `hermes-engine.podspec` can consume its source.
- Try to be explicit and verbose about when those scenarios take place.
- Split `compute_hermes_source` into two functions:
- `hermes_source_type` that determines the podspec source type.
- `podspec_source` that builds the podspec source based on the source type provided.
Also `hermes-engine.podspec` now uses source type returned by `hermes_source_type` instead of derived values `:git` and `:http`, which were not descriptive and granular enough.
This refactoring should make adding new cases and altering existing ones easier. Conditions, precedence and how to act for each scenario is much more explicit.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D48161239
fbshipit-source-id: 3d3d24aa1e05458e1f877153e43ebc2b437352e9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38326
This diff adds the iOS side of changes that the platform would notify `ReactMarker` in C++ for selected list of events. This helps us collect and send startup performance timing values via the `performance.reactNativeStartupTiming` API.
Changelog:
[iOS][Internal] - Notify ReactMarker in C++ from iOS platform for startup perf API
Reviewed By: rshest
Differential Revision: D43931719
fbshipit-source-id: 480ad8d53e541be6200cf8f7336f698a11d9600e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38870
## Changelog:
[iOS][Breaking] - hasBridge is removed from RCTRootView and RCTSurfaceHostingProxyRootView
i'm looking to limit callsites to the bridge in new architecture. in GH search i didn't see anyone using this method.
Reviewed By: cipolleschi
Differential Revision: D48175886
fbshipit-source-id: 367bfd549f658a64c5f9defac6eb66b92e681216
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38865
Changelog: [Internal] - Add basic active pointer tracking to the pointer event processor
This diff lays the groundwork for keeping track of all the "active" pointers. The ActivePointer struct right now only contains a copy of the PointerEvent data but in future diffs this will be extended to include additional stateful metadata.
It's important to note that the code as written in this diff only "tracks" pointers when they are down and won't track pointers that are only hovering. I do want to include this in future diffs but I couldn't include that handling here as it requires changes to the iOS native pointer handling to stop deriving its own hover events which ends up snowballing even more changes. I will be making this change in (hopefully) the next diff where I refactor the hover event derivation to the fabric C++ layer.
Reviewed By: rozele
Differential Revision: D48167438
fbshipit-source-id: d1c7146e7b8d46b2f8defd4785618ee1cd54f155
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39106
## Changelog:
[Internal] -
`ReactNativeFeatureFlags` are not guaranteed to be initialized before everything else, and one case popped up with this being a problem, in particular when creating `GlobalPerformanceLogger` instance (which may be created quite early on).
If the order of initialization of `ReactNativeFeatureFlags` and reading a value from there is flipped, then we'd just get a default value, without using any `MobileConfig` backing or anything.
This diff works this around for the particular case of `GlobalPerformanceLogger` initialization by making the corresponding flag tri-state (unititalized/true/false) and making sure that its value is only really taken into account after its initialized.
Reviewed By: ryancat
Differential Revision: D48559981
fbshipit-source-id: 7fa842d3b845866e15f89731c7e5c9036b83fb24
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39084
The current behaviour of `jsi::ArrayBuffer::size` with Hermes is to
return the value of the `byteLength` property. While this is
superficially more consistent with the behaviour for `Array`, which
reads the length property, it is a problem in practice since the
`byteLength` property is easily overridden in JS, making it unsafe
to use when indexing into the backing storage.
While this is a behaviour change, it should be fine because:
1. This is already the behaviour with JSC (the newly added test also
runs against the JSC implementation) and also seems to be the behaviour
of Microsoft's [V8 implementation](https://github.com/microsoft/v8-jsi/blob/db1ca30d6e5d39ee3a88a9f81b258c3825735917/src/V8JsiRuntime.cpp#L1239C48-L1239C58).
2. The current behaviour is counterintuitive and likely to lead to
bugs.
Changelog: [Internal]
Reviewed By: tmikov
Differential Revision: D48226661
fbshipit-source-id: 043d60deeb9dc189705594415f4f262f7de1095a
Summary:
Removed deprecated function removeSubscription from the type of NativeEventEmitter, so that it lines up with its implementation. This is a fix for https://github.com/facebook/react-native/issues/39111 .
## 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
-->
[General] [Fixed] - Fix a type issue of NativeEventEmitter
Pull Request resolved: https://github.com/facebook/react-native/pull/39115
Test Plan: Not applicable
Reviewed By: NickGerleman
Differential Revision: D48573676
Pulled By: lunaleaps
fbshipit-source-id: e70c951e230e0d236e0bf0a1ba02b450bdc98ac5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39116
This changes updates the Glog pod to defines module.
This makes it easier to work with Glog using Swift and to work on React Native Modules
## Changelog:
[Internal] - Make Glog define modules
Reviewed By: dmytrorykun
Differential Revision: D48564026
fbshipit-source-id: 83bb45fa6387321d089528107517ffbf0874c70d
Summary:
During investigation of impact of PR https://github.com/facebook/react-native/pull/38706 on `reanimated` I found out that when:
- state reconciliation is turned on
- `progressState` in `ShadowTree::tryCommit` quite often returns a new pointer to updated shadow tree
- above happened due to `newState->getMostRecentStateIfObsolete()` returning precisely the same ptr as `newState` in `progressState`
- this is caused by calling `ShadowNodeFamily::setMostRecentState` with the same state as currently held and marking those states as obsolete
This PR adds additional check whether `ShadowNodeFamily::setMostRecentState` is called with the same `state` as currently set and skips setting obsolete flag if that happens.
## Changelog:
[INTERNAL][FIXED] Setting the same most recent state for ShadowNodeFamily, doesn't mark it as obsolete
Pull Request resolved: https://github.com/facebook/react-native/pull/39095
Test Plan: None
Reviewed By: cipolleschi
Differential Revision: D48526395
Pulled By: sammy-SC
fbshipit-source-id: f77cea2364611a42a3363285b4732f33aae8a0a7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39059
## Context
RFC: Decoupling Flipper from React Native core: https://github.com/react-native-community/discussions-and-proposals/pull/641
## Changes
This change:
- Links the new `react-native/dev-middleware` endpoints into the recently migrated `react-native start` command.
- Adds `react-native/community-cli-plugin` (the migrated [`cli-plugin-metro`](https://github.com/react-native-community/cli/tree/main/packages/cli-plugin-metro)) as a dependency of `react-native`, and hooks in these versions of the `start`, `bundle`, and `ram-bundle` commands via `react-native.config.js`.
Functionally, this means that the new `/open-debugger` endpoint is available on the dev server started by `react-native start` (not yet linked into any UI).
After this PR is merged, the new `community-cli-plugin` package is "linked" and we can remove `cli-plugin-metro` from `react-native-community/cli`: https://github.com/react-native-community/cli/pull/2055.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D47226421
fbshipit-source-id: 123039961f93bd8183a32a2d3f30c447f7c0f132
Ruslan Shestopalyuk
Phillip Pan
Dmitry Rykun
JP
Riccardo Cipolleschi
Vincent Riemer
Arushi Kesarwani
Saad Najmi
Carmen Krol
Intl Scheduler
Pieter De Baets
Ergul Azizler
Christoph Purrer
Joe Savona
David Vacca
Andrew Wang
Sam Zhou
Xin Chen
Neil Dhar
Yupeng Li
Alex Hunt
Samuel Susla
Michał Mąka