Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38529
VirtualizedList internally represents metrics along the scrolling axis using `offset` (x, y), and `length` (width, height). This one dimensional representation allows the list to be generic to being horizontal or vertical.
Right now offset conversion directly takes the `x` or `y` axis value, but this is not correct when we are using a horizontal FlatList in RTL.
This change converts most VirtualizedList code handling `offset,length` coordinates consistently flow from start to end, including in horizontal RTL and in inverted FlatList.
This is paired with a fix to Android native code in D47627115. With these together, basic Horizontal FlatList scenarios should work correctly when laid out in RTL.
Changelog:
[General][Fixed] - Fix virtualization logic with horizontal RTL lists
Reviewed By: vincentriemer
Differential Revision: D46586420
fbshipit-source-id: 79594e197d21871bb493399999e91fc0d6c7b050
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38526
This changes the logic we use to correct scroll position on RTL ScrollView content change, to a new more generalized strategy of keeping a constant right-edge offset on layout change. This includes first layout, so that the initial scroll position is correct.
Changelog:
[Android][Fixed] - Generalize RTL Scroll Correction Logic
Reviewed By: yungsters
Differential Revision: D47627115
fbshipit-source-id: 33b2aae0cb603b7f7f2e2e6c127622fd531230e8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38328
This diff adds the two extra markers `initializeRuntimeStart` and `initializeRuntimeEnd` to the startup performance API. The runtime start time matches the existing android marker `GET_REACT_INSTANCE_MANAGER_START`, which is the first marker we have on the RN android app.
Changelog:
[Android][Added] - Add `performance.reactNativeStartupTiming.initializeRuntimeStart` and` `performance.reactNativeStartupTiming.initializeRuntimeEnd` API
Reviewed By: mdvacca
Differential Revision: D43863974
fbshipit-source-id: 277d35e14dbb5e3def8d440b717b3cf0215b4f47
Summary:
X-link: https://github.com/facebook/metro/pull/1024
Pull Request resolved: https://github.com/facebook/react-native/pull/38228
Changelog: [General][Changed] - Move react-native-babel-transformer and react-native-babel-preset from Metro to React Native repo.
Metro Changelog: **[Breaking]** - Remove `metro-react-native-babel-transformer` and `metro-react-native-babel-preset`, to be published as `react-native/metro-babel-transformer` and `react-native/babel-preset` instead.
This diff does the following:
- Move `metro/packages/metro-react-native-babel-preset` to `react-native/packages/react-native-babel-preset`.
- Rename `metro-react-native-babel-preset` package to `react-native/babel-preset`.
- Move `metro/packages/metro-react-native-babel-transformer` to `react-native/packages/react-native-babel-transformer`.
- Rename `metro-react-native-babel-transformer` package to `react-native/metro-babel-transformer`.
- Upadate dependencies.
Reviewed By: robhogan
Differential Revision: D46977466
fbshipit-source-id: 32478f63a0442b61a1804f12ef814c8b29d7f8bb
Summary:
The React Native community almost exclusively adds `mjs` support with something like: `config.resolver.sourceExts.push("mjs");` which causes `js` to be resolved before `mjs`. Mainstream bundlers will do the opposite, resolving `mjs` then `js`, unless bundling for Node.js environments.
`event-target-shim` has a `.js` and `.mjs` entry, when we [attempt to implement _community-standard_ resolution in Metro](https://github.com/expo/expo/pull/23528) the app fails to open on iOS––providing no indication of what failed. The issue here is that the `mjs` exports for `event-target-shim` don't support `module.exports = function() {}`, so we need to update some of the imports in `react-native` (note that one of the imports to `event-target-shim` already uses `import/export`).
### Discovery
For future readers––to discover this bug, I wrote a custom Metro resolver which printed a list of any `mjs` file that was resolved. In a basic app we observe the following:
```
/node_modules/react-native/Libraries/Core/setUpXHR.js > /node_modules/abort-controller/dist/abort-controller.mjs
/node_modules/react-native/Libraries/Network/XMLHttpRequest.js > /node_modules/event-target-shim/dist/event-target-shim.mjs
/node_modules/react-native/Libraries/WebSocket/WebSocket.js > /node_modules/event-target-shim/dist/event-target-shim.mjs
/node_modules/react-native/Libraries/Blob/FileReader.js > /node_modules/event-target-shim/dist/event-target-shim.mjs
/node_modules/abort-controller/dist/abort-controller.mjs > /node_modules/event-target-shim/dist/event-target-shim.mjs
```
In all cases the mjs files are resolved via `react-native` importing third-party packages, specifically `abort-controller` and `event-target-shim`. I modified the custom Metro resolver to ignore mjs resolution in different files until I found the problematic imports. This revealed that the exports were changing in `event-target-shim` between mjs and js.
Further, this was difficult to discover because the code that attempts to invoke an object as a function (error) is happening during the React Native networking setup. Ideally this JS code would be isolated from the user's bundler configuration and therefore impossible to break.
## Changelog:
[GENERAL] [FIXED] - Update `event-target-shim` import to support Metro resolving `mjs` modules before `js`.
<!-- 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
Pull Request resolved: https://github.com/facebook/react-native/pull/38628
Test Plan:
- If you add `mjs` support to the `metro.config.js` file **before** js (`config.resolver.sourceExts.unshift("mjs");`), the project should be capable of starting.
- Usage with the default `metro.config.js` setup works as well.
- https://github.com/expo/expo/pull/23528 works.
Reviewed By: NickGerleman
Differential Revision: D47816854
Pulled By: TheSavior
fbshipit-source-id: ebaf2e7a3ec02ae61effa004058589053601b766
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38637
ComponentDescriptor and ConcreteComponentDescriptor expose a virtual method to interpolate props for LayoutAnimation. The implementation of this virtual method in ConcreteComponentDescriptor calls ViewPropsInterpolation, creating a circular dependency between react/renderer/core and react/renderer/components/view.
To break this circular dependency, this change lifts the props interpolation functionality out of ComponentDescriptor into LayoutAnimationKeyFrameManager.
Please note, while this is technically a "breaking" change, as component descriptors for 3p components may have overridden this method, it's not supported because LayoutAnimation only works on View props.
## Changelog:
[General] [Breaking] - Remove interpolateProps functionality from ComponentDescriptor to fix circular dependency between react/renderer/core and react/renderer/components/view
Reviewed By: christophpurrer
Differential Revision: D47797967
fbshipit-source-id: 5285da7cc9de29f21ce14c96b850a3c58c579e94
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38642
isHighlighted is only used for iOS. Even macOS disables it (see https://github.com/microsoft/react-native-macos/pull/1346).
This change ensures that the isHighlighted prop is only updated for iOS.
## Changelog:
[General] [Fixed] - Avoids re-renders during text selection on desktop platforms by limiting native-only `isHighlighted` prop to iOS
Reviewed By: lenaic, sammy-SC
Differential Revision: D47800845
fbshipit-source-id: af109be17027b2fbc9408e2ec9e1b841c709fe35
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38638
A new stable version of Android Gradle Plugin has just been released which I'm bumping over here, and applying all the required changes.
Changelog:
[Internal] [Changed] - Bump AGP to 8.1.0
Reviewed By: cipolleschi
Differential Revision: D47798273
fbshipit-source-id: 57672b10444ffb6079aa5881ff09d033d2a5e895
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38634
To reduce the noise of the `check-for-reproducer` bot, this restricts the event
that trigger the bot to only the issue creation.
Changelog:
[Internal] [Changed] - Let check-for-reproducer run only on newly created issues
Reviewed By: cipolleschi
Differential Revision: D47792374
fbshipit-source-id: 738a9342899e234022029e94f43b0dccebc21819
Summary:
The `Request` interface provided by `types/react-native` doesn't have a `signal` property when it should as this is something that is accessible on the `Request` object.

For example, running the following:
#### Without providing a `signal`
```ts
console.log(new Request('https://www.facebook.com'));
```
will result in the following:
```ts
{"_bodyInit": undefined, "_bodyText": "", "bodyUsed": false, "credentials": "same-origin", "headers": {"map": {}}, "method": "GET", "mode": null, "referrer": null, "signal": {}, "url": "https://www.facebook.com"}
```
## Changelog:
[GENERAL] [FIXED] - Fixed missing property `signal` for the `Request` interface
## Reproduce
1. Add `new Request('https://www.facebook.com').signal` to a typescript file
2. TS will error `Property 'signal' does not exist on type 'Request'`
Pull Request resolved: https://github.com/facebook/react-native/pull/38536
Test Plan:
Adding to `global.d.ts` in a file will resolve the problem, demonstrating that this works.
```ts
interface Request {
readonly signal: AbortSignal | undefined
}
```
Reviewed By: NickGerleman
Differential Revision: D47660506
Pulled By: jacdebug
fbshipit-source-id: ef1459fbaca5d8f31bf8539bd61ac5e447111fec
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38613
The `value` string of the ReactAccessibilityDelegate's `fromValue` method is marked as `Nullable`, however the `null` case is not handled.
This change handle the `null` case setting the accesssibility role to NONE.
## Changelog:
[Android][Fixed] - Set the accessibility role to `NONE` when a `null` string is passed to `fromValue`
Reviewed By: cortinico
Differential Revision: D47752098
fbshipit-source-id: e8a44bdd8874e996d8127cb2ee29e5135210b196
Summary:
The bot message is split in a wrong way:
https://github.com/facebook/react-native/issues/38603#issuecomment-1648749441
I'm updating it to use `<br/><br/>` instead which renders correctly inside tables.
Changelog:
[Internal] [Changed] - Properly split the "Too Old Version of React Native" message
Reviewed By: NickGerleman
Differential Revision: D47764363
fbshipit-source-id: 7a80f03b4228a3f0c69d718b8eb60ecd4ac60a2b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38515
Regenerate `babel/traverse` and `babel/types` Flow library definitions from the runtime code at the current lockfile versions, using Metro's `yarn update-babel-flow-lib-defs`.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D47588687
fbshipit-source-id: 065a741ce4a9d765427455a26d23892ea6401f9a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38611
For Ruby tests, we are already testing the least recent (2.6.10) and the most recent version (3.2.0).
Testig on 2.7.7 (a minor greater than 2.6.10) was an over-cautious measure we can safely remove now after few months where we saw that no changes broke this specific version of ruby.
## Changelog:
[Internal] - Remove tests on Ruby 2.7.7
Reviewed By: cortinico
Differential Revision: D47715594
fbshipit-source-id: 854b5e0369f390d8801b72f1231fe6ce30069e09
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38551
I think we can safely remove the StaticFrameworks tests: the DynamicFrameworks are stricter than the static, so if something works in a dynamic frameworks setup, it will work also in the static framework one.
we can safely delete the following tests
- test_ios_template-NewArch-Debug-WithoutFlipper-Hermes-StaticFrameworks
- test_ios_template-NewArch-Debug-WithoutFlipper-JSC-StaticFrameworks
- test_ios_template-NewArch-Release-WithoutFlipper-Hermes-StaticFrameworks
- test_ios_template-NewArch-Release-WithoutFlipper-JSC-StaticFrameworks
- test_ios_template-OldArch-Debug-WithoutFlipper-Hermes-StaticFrameworks
- test_ios_template-OldArch-Debug-WithoutFlipper-JSC-StaticFrameworks
- test_ios_template-OldArch-Release-WithoutFlipper-Hermes-StaticFrameworks
- test_ios_template-OldArch-Release-WithoutFlipper-JSC-StaticFrameworks
- test_ios_rntester-NewArch-Hermes-StaticFrameworks
- test_ios_rntester-NewArch-JSC-StaticFrameworks
- test_ios_rntester-OldArch-Hermes-StaticFrameworks
- test_ios_rntester-OldArch-JSC-StaticFrameworks
## Changelog
[Internal] - Remove static frameworks tests in CircleCI
Reviewed By: dmytrorykun
Differential Revision: D47669902
fbshipit-source-id: 4888bbf88bb23284e410936910e5f71c969408d0
Summary:
Currently, `metro-config` does not have `hermes-parser` enabled by default. This is because `hermes-parser` does not yet support parsing all of TypeScript's syntax nodes.
However, this also means we cannot yet utilize any Flow langauge features that require the use of `hermes-parser` (and are unsupported by Babel). Mapped types falls into this category, so we cannot use them.
This backs out a recent change that tried to adopt Flow mapped types in `EventEmitter`, for now. We can revisit after making the necessary changes to `metro-config`.
Changelog:
[Internal]
Reviewed By: pieterv
Differential Revision: D47729818
fbshipit-source-id: ec90b38e113a9c3ad952f33777fabbd82519cffb
Summary:
Migrates `EventEmitter` in React Native to use the newly introduced mapped types in Flow, instead of `$ObjMap`.
Changelog:
[Internal]
Reviewed By: jbrown215
Differential Revision: D47296240
fbshipit-source-id: 435d0a19242dcd13a4a6c7824daf0e894445cfa7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38554
@public
Upgrades React Native, Relay, and Metro to use `hermes-parser@0.14.0`.
This also changes the repository's Jest configuration to now use `hermes-parser`.
Changelog:
[Internal]
Reviewed By: SamChou19815
Differential Revision: D47522140
fbshipit-source-id: 207ccd0c4e4489d486731d0c847d8089abc1cc72
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38322
As title, so that we can keep the format
```#import <ReactCommon/RCTHost.h>```
Changelog:
[iOS][Changed] - ] Re-orgnize BridgelessApple files to keep proper header file include structure
Reviewed By: cipolleschi, dmytrorykun
Differential Revision: D47421732
fbshipit-source-id: af14807d20676e8732c66fa7f792580819c33f33
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38107
This change makes bridgeless build with JSC and with all the frameworks settings.
## Changelog:
[iOS][Added] Support bridgeless with JSC and frameworks
Reviewed By: philIip
Differential Revision: D47025704
fbshipit-source-id: 5779d3ffd9ed037e6f6dee6c64cc65835f370a5b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38547
Before this change, when a turbomodule was registered using the `RCT_EXPORT_MODULE()` function using a custom name, the TM was not found in the registry.
With this change, we are adding a fallback that looks in the list of registered TM, asking for the name used by the user to register it.
This fallback is executed only if no other method was successful before as it is more expensive.
## CHANGELOG
[iOS][Fixed] - Honor the custom name choosen by the user to register the module.
Reviewed By: philIip
Differential Revision: D47666848
fbshipit-source-id: 545855de1c398726b9449a0d77af7f1756cca233
Summary:
There was a typo in App.test.tsx, that I noticed when tried to upgrade from 0.71 to 0.72
## Changelog:
Fixed small typo from *shiped* to *shipped*
Pick one each for the category and type tags:
[GENERAL] [FIXED]
Pull Request resolved: https://github.com/facebook/react-native/pull/38524
Reviewed By: cortinico
Differential Revision: D47695088
Pulled By: NickGerleman
fbshipit-source-id: 9f74c7f891927be6c0c0f522f0cd51b022fb54f1
Summary:
The change in D47554161 is breaking builds for iOS 17 as the `addEntriesFromDictionary` method returns void and the code tries to assign the returned value to another dictionary.
## Changelog:
[iOS][Fixed] - Use `addEntriesFromDictionary` properly in RCTBaseTextInputView.
Reviewed By: sammy-SC
Differential Revision: D47696854
fbshipit-source-id: 49e01fdc63b3f0478762994d5cafdceb16830c74