Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38668
On other platforms (e.g., react-native-windows), it's possible that platform colors may not be efficiently represented as int32_t values. In the case of react-native-windows, Color can either be an ARGB value or a list of fallback strings for platform colors.
This change should decouple how platforms represent color values, allowing them to manage how they are used at the point they are used.
## Changelog:
[General] [Added] - Support customization of underlying Color representation in out-of-tree platforms
Reviewed By: NickGerleman
Differential Revision: D47873465
fbshipit-source-id: 1dbb36be409c04ce87b356d75503ec0cf88f1c5b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38582
Some out of tree platforms may have extra events (e.g., events for different input modalities) that don't exist on other platforms.
For example, react-native-windows and react-native-macos have `onKeyUp` and `onKeyDown` that can be emitted from any native component.
This change provides a hook for out of platforms to customize which events can be emitted from all native components.
## Changelog:
[General] [Added] - Support additional View events in out of tree platform Fabric implementations
Reviewed By: christophpurrer
Differential Revision: D47721603
fbshipit-source-id: 5ae2ff0f6c1b1dfd72b0a310c1309a85e6b170b1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38580
We already have a differential between Android and iOS View props that force view flattening (or unflattening) behaviors. Other out-of-tree platforms may have a need to customize view flattening behaviors.
This change adds a ViewTraitsInitializer header that out of tree platforms can inject to include platform-specific ViewProps fields when considering view flattening behaviors.
## Changelog:
[General] [Added] - Support customization of View traits for flattening in out of tree platform Fabric implementations
Reviewed By: christophpurrer
Differential Revision: D47721377
fbshipit-source-id: b7d6dda2f20e153a0277861d04709090756c96ce
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38549
Out of tree platforms may need different implementations of ViewProps. In fact, Android does already with props like `needsOffscreenAlphaCompositing` and `focusable`. This diff is not opinionated on whether these props should actually be shared on all platforms. Props like `focusable` may be a good candidate for generalizing to all platforms. However, there will always be a need for one platform to experiment with a new prop while it's not available yet on another, especially when considering out of tree platforms.
This diff moves the existing ViewProps class to BaseViewProps, aliases ViewProps as BaseViewProps for iOS for now, and moves Android-specific view props to it's own header and implementation.
## Changelog:
[General] [Added] - Support additional View props in out of tree platform Fabric implementations
Reviewed By: christophpurrer
Differential Revision: D47492635
fbshipit-source-id: 5739174a2b1d28ba84f4398ccc1cc0b846ebea79
Summary:
[Codegen 135] This PR introduces `getPaperTopLevelNameDeprecated` to parser base class and abstracts the logic out of typescript and parser events as requested on https://github.com/facebook/react-native/issues/34872
## Changelog:
[Internal] [Changed] - Add `getPaperTopLevelNameDeprecated` to parser base class and update usages.
Pull Request resolved: https://github.com/facebook/react-native/pull/38683
Test Plan:
Run `yarn jest react-native-codegen` locally and ensure CI is green
## Screenshot of test passing locally:
<img width="1060" alt="Screenshot 2023-07-30 at 10 04 24 AM" src="https://github.com/facebook/react-native/assets/64726664/3f61377b-9f44-45e8-bece-d4fd6bcc4567">
Reviewed By: cipolleschi
Differential Revision: D47902816
Pulled By: rshest
fbshipit-source-id: 6fab53e02cfc3f0aaa3ffd795c3fe1d2f723e060
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38690
Bridgeless mode needs static view configs support. Let's not not enable it until this support is shipped to OSS.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D47913713
fbshipit-source-id: 207be574295455cc215f907803b596bf48dca88b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38540
Changelog: [Internal]
this is never set to yes, clean it up
we need to decide if this is actually part of our feature set
Reviewed By: cipolleschi
Differential Revision: D47620233
fbshipit-source-id: 6f530015da0645d721bef7ff7c5d512113273b1a
Summary:
[Codegen 130] This PR add a `getLiteralValue` function to the Parser interface, which returns the literal value of an union represented, given an option. as requested on https://github.com/facebook/react-native/issues/34872
## Changelog:
[INTERNAL] [ADDED] - Add `getLiteralValue` function to codegen Parser
Pull Request resolved: https://github.com/facebook/react-native/pull/38651
Test Plan: Run `yarn jest react-native-codegen` and ensure CI is green
Reviewed By: cipolleschi
Differential Revision: D47912960
Pulled By: rshest
fbshipit-source-id: d9426fef4c0f92c5244d5c4c72202ec29099b76e
Summary:
This added React-ImageManager to the use_frameworks! - a lot of rpm modules podspec need this.
bypass-github-export-checks
## Changelog:
[iOS] [FIXED] - Add React-ImageManager path to work with use_frameworks!
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/38247
Test Plan: Should not be breaking - it will add to the header_search_paths React-ImageManager
Reviewed By: dmytrorykun
Differential Revision: D47593749
Pulled By: cipolleschi
fbshipit-source-id: a66e90707e5fa73573deab1f04e8d8693869a90c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38686
In this diff I'm introducing the FrameworkAPI annotation to document APIs that are provided ONLY for frameworks
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D47839411
fbshipit-source-id: 254a1f6cd42279478fba0ddb3f3736bb2b675bae
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38592
ContextBasedJavaModule is not used, neither internally or externdally. We are just deleting it
changelog: [internal] intenral
Reviewed By: christophpurrer, cortinico
Differential Revision: D47450518
fbshipit-source-id: b431adbe30c72491723b8821b3c59e0e8e7030f1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38320
In this diff I'm extracting the loading of turbomodulejsijni into its own function. This could have perf implications as we are trying to load multimple times the same soLoader
changelog: [intenral] internal
Reviewed By: luluwu2032
Differential Revision: D47409162
fbshipit-source-id: 007e89e99ec0e7fa494d811f9c830b1363acec19
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38644
It's likely that some components consuming react/renderer/graphics headers are consuming the wrong PlatformColorParser header, since the implementation under platform/android is quite different from the implementation under platform/cxx.
This change should hoist the correct headers to react/renderer/graphics when building Fabric in OSS.
## Changelog:
[General] [Fixed] - Fix headers for react/renderer/graphics for Fabric Android
Reviewed By: cortinico, NickGerleman
Differential Revision: D47821848
fbshipit-source-id: a2f2b057aa73c1c6b4a00e2c3e508cebb6e6facf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38655https://github.com/facebook/react-native/pull/35993 added logic in VirtualizedList to support `maintainVisibleContentPosition`. This logic makes sure that a previously visible cell being used as an anchor remains rendered after new content is added.
The strategy here is to calculate the difference in previous and new positions of the anchor, and move the render window to its new location during item change. `minIndexForVisible` is used as this anchor.
When an item change moves the anchor to a position below `minIndexForVisible`, shifting the render window may result in a window which starts before zero. This fixes up `_constrainToItemCount()` to handle this.
Changelog:
[General][Fixed] - Fix invariant violation when `maintainVisibleContentPosition` adjustment moves window before list start
Reviewed By: yungsters
Differential Revision: D47846165
fbshipit-source-id: 8a36f66fdad321acb255745dad85618d28c54dba
Summary:
This PR is a result of this PR, which got merged but then reverted:
- https://github.com/facebook/react-native/pull/37913
We are trying to implement a workaround for https://github.com/facebook/react-native/issues/35350, so react-native users on android API 33+ can use `<FlatList inverted={true} />` without running into ANRs.
As explained in the issue, starting from android API 33 there are severe performance issues when using scaleY: -1 on a view, and its child view, which is what we are doing when inverting the ScrollView component (e.g. in FlatList).
This PR adds a workaround. The workaround is to also scale on the X-Axis which causes a different transform matrix to be created, that doesn't cause the ANR (see the issue for details).
However, when doing that the vertical scroll bar will be on the wrong side, thus we switch the position in the native code once we detect that the list is inverted, using the newly added `isInvertedVirtualizedList` prop.
This is a follow up PR to:
- https://github.com/facebook/react-native/pull/38071⚠️ **Note:** [38071](https://github.com/facebook/react-native/pull/38071) needs to be merged and shipped first! Only then we can merge this PR.
## 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
-->
[ANDROID] [FIXED] - ANR when having an inverted FlatList on android API 33+
Pull Request resolved: https://github.com/facebook/react-native/pull/38073
Test Plan:
- Check the RN tester app and see that scrollview is still working as expected
- Add the `internalAndroidApplyInvertedFix` prop as test to a scrollview and see how the scrollbar will change position.
Reviewed By: cortinico
Differential Revision: D47848063
Pulled By: NickGerleman
fbshipit-source-id: 4a6948a8b89f0b39f01b7a2d44dba740c53fabb3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38654
Changelog:
[Internal][Added] - Created mechanism to add other properties in OCSceneTracker then subsequently refine them when consuming the current scene.
Reviewed By: rubennorte
Differential Revision: D47810741
fbshipit-source-id: d24e4f4d1d25fac2f3bed2e98e7a7b4642f26319
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:
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
Eric Rozell
Siddarth Kumar
Dmitry Rykun
Phillip Pan
Denis
William Bell
David Vacca
Intl Scheduler
Davyd Narbutovich
Ed Voas
Nick Gerleman
Hanno J. Gödecke
Fabrizio Bertoglio
Josh Leibsly
Jesse Watts-Russell
Xin Chen
evanbacon
Nicola Corti
Ruslan Lesiutin
Lorenzo Sciandra
Louie Colgan
Riccardo Cipolleschi
Luna Wei