Summary:
[Codegen 131] This PR add a function `emitUnionProp` to the parser-primitives, as requested on https://github.com/facebook/react-native/issues/34872
## Changelog:
[INTERNAL] [ADDED] - Add `emitUnionProp` function to parser-primitives
Pull Request resolved: https://github.com/facebook/react-native/pull/38705
Test Plan: `yarn test react-native-codegen`
Reviewed By: christophpurrer
Differential Revision: D47921708
Pulled By: rshest
fbshipit-source-id: c2c081c6317928e5eb8b0c1d0640c7b7f40a4b0b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38680
Upgrades to the recently published versions of `deprecated-react-native-listview` and `deprecated-react-native-prop-types`.
Changelog:
[Internal]
Reviewed By: NickGerleman
Differential Revision: D47893357
fbshipit-source-id: 430cbb51086cfd1c346a6a5c15b2e90358ab6565
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38648https://github.com/facebook/react-native/pull/38475 made this code no longer no-op on Android, which caused regressions documented in https://github.com/facebook/react-native/issues/38470#issuecomment-1639620459 due to VirtualizedList having more out-of-date information.
We are already coalescing scroll events on both Android and iOS, which will ensure we are not flooded with events. VirtualizedList also already inserts an artificial 50ms delay to new renders by default when high priority work is not happening (see `updateCellsBatchingPeriod`). This limits the heavy work done by VirtualizedList (no new renders or expensive math on scroll events), while letting the list still have the most recent events.
We can eventually remove this once VirtualizedList is able to use OffScreen universally.
Changelog:
[General][Changed] - Remove default 50ms Scroll Event Throttling in VirtualizedList
Reviewed By: ryancat
Differential Revision: D47823772
fbshipit-source-id: 55d22a1074235ccc1b2cf167f6b1758640c79edb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38703
This change consolidates the pattern for setting up out-of-tree platform options for core classes like ViewProps and ViewEventEmitter. A similar pattern was used for Touch.h. As we move towards documenting how to build an out-of-tree platform, it would be nice to specify a set of HostPlatformX classes that need to be implemented and made resolvable from specific header paths.
At this point, there is:
- HostPlatformViewProps
- HostPlatformViewEventEmitter
- HostPlatformViewTraitsInitializer
- HostPlatformTouch
- HostPlatformColor
The other benefit of this pattern is to DRY helper aliases like SharedViewEventEmitter and SharedViewProps.
## Changelog:
[General] [Added] - Use more consistent pattern for out-of-tree platform Fabric C++ class extensions
Reviewed By: christophpurrer
Differential Revision: D47917598
fbshipit-source-id: 58ee9677eefd34eb0bc2d321103314642c457cd8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38681
Desktop platforms send additional information with onTouch(Start|Move|End|Cancel) events, including modifier keys and mouse button information.
This information has not historically been available for mobile platforms, so rather than blindly adding the fields, this change adds a hook for out-of-tree platforms to extend the data in nativeEvent payload for Fabric Touch events.
## Changelog:
[General] [Added] - Support customization of underlying Touch event representation in out-of-tree platforms
Reviewed By: christophpurrer
Differential Revision: D47896016
fbshipit-source-id: 02e3fce854302412381b0bd9254474c6bb5c63ac
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:
The `package_and_publish_release_dryrun` workflow does the same steps that we are actually already doing in the `tests` workflow.
Both workflows are triggered when `run_nightly_workflow == false && run_release_workflow == false` so the triggering condition **is the same**
The following table highlights and compares the steps performed by the two workflows:
| Package_and_publish_release_dryrun | Tests |
| --- | --- |
| `prepare_package_for_release(version: ‘’, latest: false, dryrun: true)` | |
| `prepare_hermes_workspace` | `prepare_hermes_workspace` |
| `build_hermesc_linux` | `build_hermesc_linux` |
| `build_hermes_macos(flavor: Debug | Release)` | `build_hermes_macos(flavor: Debug | Release)` |
| `build_hermesc_windows` | `build_hermesc_windows` |
| `build_npm_package (release_type: dry-run)` | `build_npm_package(release_type: dry-run)` |
The only missing job in `tests` workflow is `prepare_package_for_release`. This job has the following features:
1. It invokes the `prepare-package-for-release.js` scripts, actually testing it.
2. It doesn’t cache anything,
3. it doesn’t attach any workspace
Due to 2 and 3, it means that it does not influence any job that follow it in the pipeline as they won't access any of the results from this job.
So, we are adding this job in the Test pipeline, so we exercise the `prepare-package-for-release.js` making sure that it works, and remove
the whole `package_and_publish_release_dryrun` wroflow as it will now be completely duplicated
## Changelog:
[Internal] - Remove the `package_and_publish_release_dryrun` workflow
Pull Request resolved: https://github.com/facebook/react-native/pull/38533
Test Plan: CircleCI stays green
Reviewed By: cortinico
Differential Revision: D47633526
Pulled By: cipolleschi
fbshipit-source-id: 28ea9c5944931b992ad07fdeecf08e1d1a86b775
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:
Adds changelog for the new 0.70.13 patch.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - Add 0.70.13 changelog
Pull Request resolved: https://github.com/facebook/react-native/pull/38662
Test Plan: N/A
Reviewed By: cortinico
Differential Revision: D47865844
Pulled By: rshest
fbshipit-source-id: d9a8633baec0a9e08c63d458d4d3b601bfd997fd
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
Dmitry Rykun
Phillip Pan
Alex Hunt
Denis
szymonrybczak
Cao Doan
Tim Yung
Nick Gerleman
Eric Rozell
Siddarth Kumar
William Bell
David Vacca
Riccardo Cipolleschi
Intl Scheduler
Davyd Narbutovich
Ed Voas
Hanno J. Gödecke
Fabrizio Bertoglio
kacperkapusciak
fortmarek
Josh Leibsly
Jesse Watts-Russell