Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50967
In some cases we may want to check this only if the prop exists
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D73793783
fbshipit-source-id: b498f82414edf63d8644b90bb3932298eb37b43c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50941
Without doing this, using Animated.event to update a value with an offset causes the value to revert to not having an offset because the native side doesn't even know about the offset if it hasn't been synced.
Don't think there's a better place to sync this for the cases where an animation is kicked off entirely from the native side
Changelog: [Android][Fixed] - Ensure latest offset value is synced to native
Reviewed By: javache
Differential Revision: D73622302
fbshipit-source-id: 7e67a7f41d900cc225af410af94ccdfd33c170c8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50850
This prop will be used to enable screen reader focusability without allowing keyboard focus. Mostly a quality of life prop for product engineers and maps 1:1 to Android
Changelog: [Android][Added] - Expose Android's screenReaderFocusable prop
Reviewed By: javache
Differential Revision: D73382051
fbshipit-source-id: 8171b9d24a735dd42d54abe4537fb487bdd011b7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50962
OSS is affected by https://github.com/facebook/react-native/issues/49694 and it is endangering the migration of multiple apps to the New Architecture.
We fixed the issue but it is hidden behind feature flag while we are experimenting with it internally, to make sure it does not causes regressions.
However, the fix has been verified for the reproducer code and the OSS will be beneficial for the community.
We are overriding the featureFlag, enabling it for OSS.
## Changelog:
[Internal] - Enable `updateRuntimeShadowNodeReferencesOnCommit` for OSS
Reviewed By: lenaic, cortinico
Differential Revision: D73771648
fbshipit-source-id: 4394a2370d9edd9699c8e03293868defd465853c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50909
Enables and maps the `types_generated/` directory for `react-native` and `react-native/virtualized-lists` — exposing the new Strict TypeScript API entry points to React Native.
**New `"exports"` conditions**
- `"react-native-strict-api"` — The Strict TypeScript API opt in, exposing the `index.d.ts` entry point only.
- `"react-native-strict-api-UNSAFE-ALLOW-SUBPATHS"` — Opts into the new from-source generated types, but allows accessing subpaths (unsafe).
- We intend for this unsafe condition to be an escape hatch for Frameworks only (i.e. Expo).
Note: In the case of `virtualized-lists`, we simply use the `"types"` condition — since this package did not expose any TypeScript API previously.
NOTE: Should we need to roll back JS Stable API phase 1, **this is the single diff to revert**.
Changelog:
[General][Added] - Configure the "react-native-strict-api" opt in for our next-gen TypeScript API
Reviewed By: cipolleschi
Differential Revision: D71969602
fbshipit-source-id: 291182cc826db8b33f21fc79698e6096876d17ef
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50964
Address/supress ESLint warnings across the codebase, currently flagged on every PR via GitHub's "Unchanged files with check annotations" check.
{F1977480883}
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D73778510
fbshipit-source-id: 91bed86877eae74fa3b9ebea71e26cdcaeee1761
Summary:
Rewrite of the Inspector class from Java to Kotlin in scope of https://github.com/facebook/react-native/issues/50513
## Changelog:
[ANDROID] [CHANGED] - Migrated Inspector to Kotlin
Pull Request resolved: https://github.com/facebook/react-native/pull/50947
Test Plan: Tested using RNTester app, on both old and new arch, and tested by navigating to multiple pages
Reviewed By: cortinico
Differential Revision: D73767386
Pulled By: javache
fbshipit-source-id: e0098568aa0ed9863503e206a88d3b171c8f9966
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50958
In rn-tester package there are many react-native deep imports which will be deprecated in the future. It is a starter for migrating rn-tester to using root imports instead. Only deep imports that are already root exported are changed. This diff avoids using `CodegenTypes` as it causes build errors and will be resolved in next stages.
Besides import changes, `PointerEvent` type is now also exported from the root.
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D73656526
fbshipit-source-id: 5814a3d9c6a04b1236581dbbe291cd109e2c71c0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50957
Changelog: [internal]
Now we can use the higher level API for event dispatching in this test.
Reviewed By: javache
Differential Revision: D73663626
fbshipit-source-id: 961af26f62128f093c71ad14f457ac8544348415
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50903
For now we do not change the way this module is exported to prevent breaking changes (due to high usage in external packages). It is a tentative mitigation - this case requires more discussion and what could be sufficient. The `no-deep-imports` rule and plugin shouldn't emit a warning when encountered.
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D73590627
fbshipit-source-id: 6f85c52373ee6c7c538c632b55cd9e0b9357f2a3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50932
Add a warning for LegacyArch users that are providing a ViewManager with a corresponding shadow node that implements the `YogaMeasureFunction`.
For those users, we know that the ViewManager is most likely not working on the NewArch (unless they have a backward compat ViewManager with a C++ shadow node implementation).
Changelog:
[Android] [Added] - Warn Legacy Arch users if they use a Component with a ShadowNode with `YogaMeasureFunction.measure()` function. That Component will stop working on NewArch.
Reviewed By: javache
Differential Revision: D73654273
fbshipit-source-id: 70d232434f94bc2a6970379d566b276f73850fce
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50939
Redesigns React Native's `NewAppScreen` component, and moves it into a new `react-native/new-app-screen` package with a single component export. Deletes the old New App Screen under `'react-native/Libraries/NewAppScreen/'`.
{F1977434404}
**Motivation**
- **Reduces our public API** (see https://github.com/react-native-community/discussions-and-proposals/pull/894)
- Separates this screen from the main `react-native` package, where it was a number of subpath exports.
- Reduces the size of the main `react-native` package, including image assets — which are redundant for consumers like Expo.
- **Updated visual treatment**
- Replace outdated logo, update to a responsive tablet/windowed layout.
- Removes outdated guidance (e.g. "use cmd+R to reload"), and generally simplifies the layout (with the aim of reducing future maintenance).
- **Simplifies template boilerplate**
- `NewAppScreen` is now a fully encapsulated screen layout, avoiding the cruft of the previous modular design.
**Integration plan**
When we cut the `0.80-stable` branch, we'll update [the template](https://github.com/react-native-community/template/blob/main/template/App.tsx) to import and use `<NewAppScreen />`.
- This will cause an extra runtime dependency in the template `package.json`, which will require user cleanup. We are happy with this tradeoff, given the self-evident package name, reduction of template boilerplate, and size reduction on the main `react-native` package.
Changelog:
[General][Breaking] - The `NewAppScreen` component is redesigned and moved to the `react-native/new-app-screen` package
Reviewed By: cipolleschi
Differential Revision: D73657878
fbshipit-source-id: 9ca07afa9fbdd6f32015eafa2f27d52ed182918e
Summary:
This PR makes sure that monitor-new-issues runs only in the main repo. It was failing on my fork and spamming notifications.
## Changelog:
[INTERNAL] [FIXED] - run monitor-new-issues only in the main repo
Pull Request resolved: https://github.com/facebook/react-native/pull/50951
Test Plan: CI Green
Reviewed By: cipolleschi
Differential Revision: D73763006
Pulled By: cortinico
fbshipit-source-id: cbb22f8804448b41de970d3d11930110b353994f
Summary:
For real this time, the change was lost due to some merge conflict
Changelog: [Internal]
Reviewed By: Abbondanzo
Differential Revision: D73726167
fbshipit-source-id: 1e0cef75f59a166d795922266365b2b7b060472e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50872
NOTE: Resubmission of D71968187.
Define `"exports"` field on the main `react-native` package.
**Notes**
Module resolution should be equivalent to the previous implicit `"main"` field (backwards compatible).
- Exports all module subpaths to JavaScript (Flow) source files, with and without `.js` suffix (unchanged ✅)
- These are restricted to the `flow/` and `Libraries/` subdirectories (ℹ️ this should be unchanged, matching any JS imports apps may have today)
- Still includes 3P integration scripts such as `./jest-preset.js` and `./rn-get-polyfills.js` (unchanged ✅)
- Exports `./package.json` (unchanged ✅)
- TypeScript should:
- fall back to the `"types"` field (unchanged ✅)
- OR to `"."`,`"./*"` when Package Exports support is enabled via `compilerOptions`, and use the *adjacent `.d.ts` file* (unchanged ✅)
Changelog:
[General][Breaking] - The `react-native` package now defines package.json `"exports"`.
- While these expose existing JavaScript and TypeScript modules, this change may affect deep imports of non-JS files via Node in third party tools.
- Jest mocks to a `react-native` subpath will need to be updated to match the import path used in your code.
- Imports from `src/` and `src/private/` directories are disallowed.
Reviewed By: robhogan
Differential Revision: D72228547
fbshipit-source-id: d50d6e556d32a9cf2f90855a562e61549853acb9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50855
This diff addresses a crash caused by view duplication in React Native Android. The issue occurred when a view was not already clipped and was laid out again, resulting in duplicated views.
This problem was particularly noticeable when using nested FlatLists, which triggered a custom focus search with an incomplete and buggy duplicated FlatList container view.
The fix involves preventing the duplication of views by checking if a view is clipped already before laying it out again. Additionally, this diff includes two other improvements:
- Preventing clipping issues: When a view is nested within a non-ReactClippingViewGroup ancestor, focus searching would fail due to the needUpdateClippingRecursive logic only running on instances of ReactClippingViewGroup. By excluding these ancestors, we ensure that the next focusable view can be properly excluded from being clipped.
- Minor fix: A minor fix was made to prevent potential issues in deeply nested cases.
- Add a Kill switch with a feature flag and mobile config combo.
Reviewed By: joevilches
Differential Revision: D73471780
fbshipit-source-id: efbb968600f21b24ab1fa32222d555f346fb336e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50936
D63141469 introduced an option to use HSR Core's trace macros for profiling react. I believe this was to enable Tracy support. However, the consequence of this is that hsr core is statically linked twice into Worlds, once in libclient_server_android.so and once into libxplat_js_react-native-github_packages_react-native_ReactCxxPlatform_react_profiling_profiling.so.
It isn't obvious that this causes any problems, but it does result in some weirdness with regard to symbol interposition between the two shared libraries. Some tracing categories are registered twice in hz_tracing, for example.
Since the HSR Core macros call directly through to hz_tracing, this change simply replaces the HSR Core dependency with an equivalent hz_tracing dependency.
Reviewed By: javache
Differential Revision: D73532803
fbshipit-source-id: 56d4b62873aabcbf0a92cebd7a0f720fed616158
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50908
This diff removes the usages of ShadowNodes in the new architecture by fully releasing disableShadowNodeOnNewArchitectureAndroid() feature flag.
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D73519567
fbshipit-source-id: e222e3b4fab371c8bc5480950da005d2a12a8619
Summary:
We landed a PR that was importing a file available only in the New Architecture also when the app was running in the old architecture.
This was creating a corrupted bundle for rntester.
This PR fixes the issue
bypass-github-export-checks
## Changelog:
[Internal] - Fix RNTester on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/50940
Test Plan: Tested locally by setting `newArchEnabled` to false in the gradle.properties file
Reviewed By: javache, cortinico
Differential Revision: D73663049
Pulled By: cipolleschi
fbshipit-source-id: c8d6e4190adee7388e51901360a811b0007ee3a5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50938
Changelog: [internal]
No more `maybeNode`s. Using ref objects makes the tests cleaner and the JSX easier to read than injecting lambdas.
This speaks for itself:
* 617 lines added
* 1393 lines removed
{F1977434870}
Reviewed By: lenaic
Differential Revision: D73659018
fbshipit-source-id: d1c23e6457bb1d351ce02b9f6fa8778b06ee0e55
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50935
Those classes are internal and deprecated since a while.
It should now be safe to fully remove them.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D73655877
fbshipit-source-id: cdca8f032fe865f9a08c40e4a0145945c7e25a85
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50931
This removes all the `OSS_LEGACY_WARNINGS_ENABLED` infrastructure from LegacyArchitectureLogger. We'll instead pivot to use ad-hoc functions for scenarios that don't work in LegacyArch + Interop Layers (see D73654273).
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D73654272
fbshipit-source-id: d10eac2ded92f2c0191503e64f0c1d9db688d6e9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50930
Due to D73591315, we don't need to specify the `legacyWarningsEnabled` for RNTester anymore as it's effectively ignored.
Changelog:
[Internal] [Changed] -
Reviewed By: rshest, cipolleschi
Differential Revision: D73654270
fbshipit-source-id: 9428634fb8374024940e4041de60d679b6f352a2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50929
We decided to change the warning model for LegacyArch/NewArch.
I'm currently removing the infra to read the `legacyWarningsEnabled` Gradle property if provided.
Warnings will be enabled by default for all Legacy Arch users in the new model.
This change was never shipped in a numbered version, so that's not breaking.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D73591315
fbshipit-source-id: a46fade91b46fcc9b81984577161c046dc0939b6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50928
This broke in D72979663, since we relied on the object identify of `native` changing to correctly reset the native state back to the controlled JS state.
Changelog: [General][Fixed] Fixed switches correctly reverting to controlled state
Reviewed By: vzaidman
Differential Revision: D73653323
fbshipit-source-id: d6ca8a31d9f08a339c7acf6bba264137690dd794
Summary:
Rewrite of JSBundleLoader from Java to Kotlin in scope of https://github.com/facebook/react-native/issues/50513
## Changelog:
[ANDROID] [CHANGED] - Migrated JSBundleLoader to Kotlin
<!-- 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/50911
Test Plan: Tested using RNTester app, on both old and new arch, and tested by navigating to multiple pages
Reviewed By: cortinico
Differential Revision: D73649145
Pulled By: javache
fbshipit-source-id: 7ef1fc1ea1c53a8b914ae1aada1966e64b4c3d80
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50899
changelog: [internal]
making things clearer in the docs for Fantom.
Reviewed By: rubennorte
Differential Revision: D73580305
fbshipit-source-id: 0e5edaa3baf57fc54f7a0c454fe4d2fa81627f66
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50906
Annotation to mark classes or functions that are part of the interop APIs that provide support for legacy architecture APIs in the new architecture of React Native .
changelog: [internal] internal
Reviewed By: shwanton
Differential Revision: D73407613
fbshipit-source-id: 887a14ca4dea891b50e7df01e0ffff5064cd43ea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50888
This is shared between platforms using a very strange pattern. Let's just extract this into its own function. Not considering breaking, since TextLayoutManager is internal interface.
Changelog: [internal]
Reviewed By: rshest
Differential Revision: D73555465
fbshipit-source-id: ea99fbebd9db44efd1dc56c2cad68b5b56e77ad1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50890
With Facsimile, we are introducing some new concept of `PreparedText`, where platform TextLayoutManager which implement, can lead to additional optimizations.
`#ifdef ANDROID` is not a workable pattern for this. Apart from react-native-cxx getting hooked into it, and all of the existing bugs there, it is bad for editor environment, and hard to reason about.
This splits up `ParagraphState`, so that we can control platform specific bits more easily. We do not split `ParagraphShadowNode`, which will use concepts (e.g. `TextLayoutManagerWithPreparedText`) to control which paths it takes, based on platform capaibilities.
Changelog: [internal]
Reviewed By: rshest
Differential Revision: D73555441
fbshipit-source-id: fd585eb99d26b0b6966efb1867d03fbd5cc7e7e2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50923
This implements the view manager for `PreparedLayoutTextView`, originating by taking the view managers composing `ReactTextView`, converting to Kotlin, and removing everything no longer needed.
In Facsimile, anything influencing text appearance is applied earlier, when creating the Fabric layout, so there are many less setters here. Most visual attributes are instead present in the state we are presenting.
We have tasks for some of these, that need to be reimplemented, as they do not currently influence the Spannable being measured. That includes e.g. `ReactTextViewManagerCallback`, used for injection, and `dataDetectorType` for linkifying Spannable.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D73287706
fbshipit-source-id: 938b57d4e443f6b8bb127e17b47cc371f31a416d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/50922
This forms the basis for a replacement of `TextView`.
This started off with Litho's [`RCTextView`](https://github.com/facebook/litho/blob/master/litho-rendercore-text/src/main/java/com/facebook/rendercore/text/RCTextView.java), which is a simple view, for rendering a text layout, and providing some built-in keyboard navigation and a11y support. Many changes were made to it, including:
1. Removing many parts not relevant to RN, or which will be replaced by other RN infra. E.g. we will reuse existing a11y delegates, have existing ways of creating Spannables and text layouts, inline views, etc
2. Converting to Kotlin
3. Adding back in some changes required for RN's drawing, and expected view manager APIs (e.g. overflow/clipping customization)
4. Making it target a ViewGroup instead of a View, for correct inline view support down the line
Because we rely on drawing text layout, with the same Spannable as before, most things "just work", because they are part of the layout we are drawing, generated by TextLayoutManager on the Fabric side. We don't offer much customization to what can be drawn, forcing it to have happened in the layout we are showing already.
There are quite a few bits not implemented yet. Some of these are cases, like `textAlignVertical`, were previously incorrectly implemented just at the ReactTextView layer, so Fabric layout was unaware of them. Another similar class to this is any non-default fonts which we must load. `adjustsFontSizeToFit` (stubbed out in later diff) will also need some tweaking with the new assumption we don’t want to mutate Spans/layouts set in State.
Fine grained selection support is the largest tbd.
Changelog: [Internal]
Reviewed By: Abbondanzo
Differential Revision: D73282649
fbshipit-source-id: abe3a30461095d2d0ddbc6c939704f3982f44771
