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:
Adds extra printouts when running `npx react-native start`:
- The current React Native version.
- "Dev server ready" on `dep_graph_loaded` event (indicating that the server is ready to receive bundle requests from devices).
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D48778254
fbshipit-source-id: ebc0672d6b6791882fe0df2d9795eaf7c5a396d6
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/39175
Just `tee`-ing the e2e tests command into a log is not enough to make the command non-failing.
I'm wrapping it into a single command and `or`-int to true to ensure that it never fails.
## Changelog:
[Internal] - Make e2e tests not failing in CI
Reviewed By: rshest
Differential Revision: D48720827
fbshipit-source-id: cb1ed9a15c7761371ae48e7edca90f032688daa1
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:
Pull Request resolved: https://github.com/facebook/react-native/pull/39158
.flowconfig.android is the same as .flowconfig now. The check is meaningless. This diff removes it and the flowconfig.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D48629137
fbshipit-source-id: bc1bee9426eed7bc41dc7a1efe75333e1191e066
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:
Expose a `unstable_browserLauncher` option to `createDevMiddleware()`. This allows integrators to provide a custom implementation for opening URLs in a web browser, initially a `launchDebuggerAppWindow` method.
Customising the browser launcher implementation can be useful in cases where the dev server is running remotely and not on the developer's local machine.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D48647750
fbshipit-source-id: ebf34106ad27899024396b13b22ec4536aad05b9
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:
Given that the e2e tests are quite flaky, we want to reduce the flakyness making them non land blocking.
The idea is to:
1. always have them green in CircleCI
2. store the test logs in CircleCI artifacts, so we can explore them if needed.
3. use danger to read the artifacts from CircleCI and post a message to inform the user whether the Test ends up successfully or not.
## Changelog:
[Internal] - Make e2e tests non land-blocking. Use Danger to report the status of the E2E jobs
Pull Request resolved: https://github.com/facebook/react-native/pull/39129
Test Plan: CircleCI stays green, logs are uploaded as artifacts.
Reviewed By: rshest
Differential Revision: D48642955
Pulled By: cipolleschi
fbshipit-source-id: 185862f46c47d59f949743a9b893162b2bb3a651
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/39146
Adds Microsoft Edge fallback for the `/open-debugger` endpoint when no Chrome installation is found.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D48563386
fbshipit-source-id: 74baba7c03a062bd769b2f9ac0cc35bac0b2ae65
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39136
## Changelog:
[Internal] -
`getConstants()` method for TM was enforced to only use object literals for the return type specs.
This limits flexibility, in particular those data structures can't be consequently exported and picked up by codegen (not even mentioning the potential need for copypasting those obejct literals around).
This relaxes this restriction.
Note that I've been digging into the development history in order to find out whether there was any particular historical reason for such a limitation, but couldn't find any, so I assume it was rather incidental.
Reviewed By: christophpurrer
Differential Revision: D48620652
fbshipit-source-id: 92d6ba531fc99fb9b25b4957ae123e7832f44ee4
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
Ruslan Shestopalyuk
Phillip Pan
Alex Hunt
Dmitry Rykun
JP
Riccardo Cipolleschi
Vincent Riemer
Arushi Kesarwani
Saad Najmi
Carmen Krol
Intl Scheduler
Sam Zhou
Pieter De Baets
Riccardo Cipolleschi
Ergul Azizler
Christoph Purrer
Joe Savona
David Vacca
Andrew Wang
Xin Chen
FabianSolheim
Gijs Weterings