Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52427
Adds and wires up a minimal implementation of `PerformanceResourceTiming` on the JS side. This materialises D74245441 in user space.
When all feature flags are enabled, network requests can now be observed from JS via `PerformanceObserver`.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D75062713
fbshipit-source-id: 06523e70f57feaaa53432ef21fa92676d1e90360
Summary:
reverting Refactor ViewManagerInterfaces codegen to generate kotlin classes because of warning in OSS, we will reland after 0.81 cut
Changelog: [Android][Breaking] - Revert of Migrate ViewManagerInterfaces to kotlin. Some types in code generated ViewManagerInterfaces might differ. e.g. this will start enforcing nullability in parameters of viewManagerInterface methods (e.g. String commands parameters are not nullable, view params are not nullable in any method, etc)
Reviewed By: lenaic, mlord93
Differential Revision: D77759777
fbshipit-source-id: c24b216b231cdc53296d8c9fca8d789d80daa596
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52393
## Changelog:
[General][Deprecated] - ShadowNode::Shared is now deprecated. Use `std::shared_ptr<const ShadowNode>` instead.
- Mark ShadowNode::Shared as deprecated in ShadowNode.h
- Replace all uses of ShadowNode::Shared with std::shared_ptr<const ShadowNode>.
This continues the systematic effort to remove ShadowNode type aliases in favor of explicit standard library types for improved code clarity and maintainability.
Reviewed By: christophpurrer
Differential Revision: D77650696
fbshipit-source-id: b4769e2a1e39f49d14d5927be105487ecf69fa3f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52405
This field has been deprecated since RN 0.77, we can safely remove it ahead of the branch cut.
Changelog:
[Android] [Removed] - Remove deprecated `isStartSamplingProfilerOnInit` from `DeveloperSettings`
Reviewed By: mdvacca, javache
Differential Revision: D77734913
fbshipit-source-id: 231ecb360921d48ec941a3a214e73b4b89446c13
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52395
This method was exposed as `public` but there is no need for us to expose it in OSS.
So I'm marking it as internal.
Changelog:
[Internal] [Changed] - Make loadWithFeatureFlags correctly internal
Reviewed By: mlord93, mdvacca, javache
Differential Revision: D77734270
fbshipit-source-id: 34e1d7aaa4a5bf3563c78aad570e2310592bcc77
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52382
Changelog: [Internal]
In C++, both `virtual ~CallInvoker() {}` and `virtual ~CallInvoker() = default` can be used to define a virtual destructor. However, they have slightly different implications:
1. `virtual ~CallInvoker() {}`:
* This is the traditional way of defining a virtual destructor.
* It provides an empty implementation for the destructor, which does nothing.
* The compiler will not generate a default implementation, as you've provided one explicitly.
2. `virtual ~CallInvoker() = default`:
* This is a more modern way of defining a virtual destructor (introduced in C++11).
* It tells the compiler to generate a default implementation for the destructor.
* The default implementation will perform the necessary cleanup operations, such as calling the destructors of base classes and member variables.
In general, `= default` is considered better because it:
* Avoids unnecessary code duplication: By letting the compiler generate the default implementation, you avoid duplicating code that's already generated by the compiler.
* Improves maintainability: If the class has member variables or base classes with non-trivial destructors, using `= default` ensures that the correct cleanup operations are performed without requiring manual updates.
* Conveys intent: Using `= default` clearly indicates that the destructor should perform its default behavior, making the code easier to understand.
So, unless you have a specific reason to provide a custom implementation, `virtual ~CallInvoker() = default` is generally the better choice.
Reviewed By: rshest
Differential Revision: D77685932
fbshipit-source-id: 78c81f8e400069ad38d8d7405dafeb0b6db8e67b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52347
We can build an accessibility tree for Talkback by overriding addChildrenForAccessibility of ViewGroup.
With this we just manually build a tree that contains the elements we care about in the order we want.
We also try to keep most of the tree intact so that coopting works properly
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D77258926
fbshipit-source-id: 767ebc880a2efbf7934b9e7dee3013dd7822e5ad
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52297
Doing virtual views is the only way of making it possible to add the host view into the order. This however is too complex for very little gain, we are opting to go for a cleaner solution with the trade off of not being able to add the host view.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D77278752
fbshipit-source-id: 709b995f51a9a03f6d07f2e24f8aea21d62d95c4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51735
This diff refactors the ViewManagerInterfaces codegen to generate kotlin classes,
As a consequence of this change, there are some ViewManagerInterfaces that have changed their APIs
## Changelog: [Android][Breaking] - Migrate ViewManagerInterfaces to kotlin. Some types in code generated ViewManagerInterfaces might differ. e.g. this will start enforcing nullability in parameters of viewManagerInterface methods (e.g. String commands parameters are not nullable, view params are not nullable in any method, etc)
Reviewed By: javache
Differential Revision: D75719542
fbshipit-source-id: 7e9aa7ccc24e827bd7b6df72b3302e852932e731
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52400
`react-stack-bottom-frame` -> `react_stack_bottom_frame`.
This survives `babel/plugin-transform-function-name`, but now frames
will be displayed as `at Object.react_stack_bottom_frame (...)` in V8.
Checks that were relying on exact function name match were updated to
use either `.indexOf()` or `.includes()`
For backwards compatibility, both React DevTools and Flight Client will
look for both options. I am not so sure about the latter and if React
version is locked.
DiffTrain build for [91d097b2c588a0977a7a10ed12512dc8a34e3a5b](https://github.com/facebook/react/commit/91d097b2c588a0977a7a10ed12512dc8a34e3a5b)
Reviewed By: jackpope
Differential Revision: D77601866
fbshipit-source-id: 24ed8713af4bebbaeb7a612333cd79c51b696565
Summary:
This PR (initially created for edge-to-edge opt-in support, rebased multiple times) fixes the `Dimensions` API `window` values on Android < 15, when edge-to-edge is enabled.
Currently the window height doesn't include the status and navigation bar heights (but it does on Android >= 15):
<img width="300" alt="Screenshot 2025-06-27 at 16 23 02" src="https://github.com/user-attachments/assets/c7d11334-9298-4f7f-a75c-590df8cc2d8a" />
Using `WindowMetricsCalculator` from AndroidX:
<img width="300" alt="Screenshot 2025-06-27 at 16 34 01" src="https://github.com/user-attachments/assets/7a4e3dc7-a83b-421b-8f6d-fd1344f5fe81" />
Fixes https://github.com/facebook/react-native/issues/47080
## Changelog:
[Android] [Fixed] Fix `Dimensions` `window` values on Android < 15 when edge-to-edge is enabled
Pull Request resolved: https://github.com/facebook/react-native/pull/47554
Test Plan:
Run the example app on an Android < 15 device.
Rollback Plan:
Reviewed By: cortinico
Differential Revision: D77547628
Pulled By: alanleedev
fbshipit-source-id: 9d841f642d5b7ef3294dfbf3868137087a672ad6
Summary:
We need to upgrade the targetSdk to 36, which requires ensuring compatibility with the latest Android APIs and addressing any deprecations or behavior changes introduced in this version.
## Changelog:
[Android] [Changed] - Updated targetSdk to 36 in Android.
Pull Request resolved: https://github.com/facebook/react-native/pull/52355
Test Plan:
- Verified that the app builds and runs successfully with targetSdkVersion 36.
- Ran the full suite of unit and instrumentation tests: all tests passed.
- Manually tested key user flows (login, navigation, data sync) on devices running Android 14 (API 34) and emulator with API 36
- Confirmed that there are no runtime crashes or warnings related to `targetSDK` upgrade.
Behavioral guide for migration: https://developer.android.com/about/versions/16/behavior-changes-16
Reviewed By: fabriziocucci
Differential Revision: D77728391
Pulled By: cortinico
fbshipit-source-id: 3f714f900bbeecc56c0cf46c54b4e42c532c8384
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52335
Adds support for `Network.requestWillBeSentExtraInfo` and `Network.dataReceived` CDP events in jsinspector-modern and wires up for iOS.
In particular, `Network.requestWillBeSentExtraInfo` is necessary to populate request headers in the UI.
**End of base Network implementation for iOS**
After this diff, we are spec-complete on all CDP Network methods for our V1, on iOS.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D77489476
fbshipit-source-id: 84aa4da9d9fcbdc61eff236fc6bd2136496910a5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52334
Adds support for `Network.loadingFailed` in jsinspector-modern and wires up for iOS.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D77489477
fbshipit-source-id: dc8156979fe49583819019fa4b88b6eb99dea734
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52331
Updates the iOS inputs to `NetworkReporter` to support incremental string data HTTP responses (`Transfer-Encoding: chunked`).
This means that incremental responses, such as Metro bundle requests, can be displayed as previews in React Native DevTools.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D77457109
fbshipit-source-id: 00a622dbac97c38e07c67b5ee3661c8d586f6fe1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52332
Adds support for the [`Network.getResponseBody`](https://chromedevtools.github.io/devtools-protocol/tot/Network/#method-getResponseBody) CDP event in `jsinspector-modern` and configures this for iOS. This enables us to populate the "Preview" and "Response" tabs in the React Native DevTools Network panel.
This is integrated with `RCTNetworking.mm` to support synchronously received `text` or `blob` data types, with incremental response support added next in D77457109.
**Implementation notes**
- Adds a new `BoundedRequestBuffer` construct to safely buffer response previews at a max memory size.
- `RCTNetworking` will always call `maybeStoreResponseBody` (when feature flag enabled), but is unaware whether there is an active CDP debugging session with network support or not.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D74319394
fbshipit-source-id: c9dbb44551c15d1b1a7cce56b35bf829f8a99dc7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52380
Apps that rely support focus in FlatList rendered items are missing out on a FlatList optimization that defers rendering for offscreen content updates.
For example, on Android, if you focus and smooth scroll an item into view, the onScroll event will fire first. For most sufficiently large virtualization windows, the next render will be delayed by the render batch timeout as most materialization of virtualized views is not treated as a high pri render.
However, this batch / timeout mechanism isn't being used for cell render updates that occur as a result of a focus change.
This change adds the same timeout mechanism used for scroll events. In most cases, the view that is focused is in the viewport, and the extra rendering needed is already scheduled (or executed with high priority if needed) when the onScroll event is processed.
In cases where the focus change occurs outside the viewport, most platforms will want to do some kind of "bring into view" anyway, and the same applies - onScroll will take care of scheduling the cell rendering priority.
## Changelog
[Internal]
Reviewed By: NickGerleman
Differential Revision: D77681274
fbshipit-source-id: 1ade377e513eca21338a380ff9299dd410606aec
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52358
Another class going from Java to Kotlin.
This is quite involved due to the amount of Raw generics we were using so I'd appreaciate a couple of further eyes here.
Changelog:
[Android] [Changed] - Convert UIManagerModuleConstantsHelper to Kotlin
Reviewed By: mdvacca, javache
Differential Revision: D77589975
fbshipit-source-id: 477c1e2a8dfd31db60047fd1252f6d47c177f5c7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52378
This adds a Gradle property called `exclusiveEnterpriseRepository`
that users can set in their `android/gradle.properties` as such:
```diff
# Use this property to enable or disable the Hermes JS engine.
# If set to false, you will be using JSC instead.
hermesEnabled=true
+exclusiveEnterpriseRepository=https://my.internal.proxy.net/
```
This will remove all the existing Maven repositories and only use the internal mirror they have.
Changelog:
[Android] [Added] - RNGP - Add support for `exclusiveEnterpriseRepository` to specify an internal Maven mirror.
Reviewed By: mdvacca
Differential Revision: D77667573
fbshipit-source-id: 835004d2ae7aa4e250b6f7a88a41918b573f5bd5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52387
I would like to grab this in a subclass but unfortunately can't. It is kinda jank since this is a val obtained via reflection, but I figure this is better than copy and paste. I think that I could also expose a function that uses this scroller the way I want it to. Let me know if there are strong objections here
Changelog: [Internal]
Reviewed By: rozele
Differential Revision: D77684599
fbshipit-source-id: 6f02c1da5135c1cf34fa1483542e06bf8f0be75e
Summary:
This change fixes an issue on iOS where gradients that fade to a transparent color-stop appear dark or "muddy." The fix ensures that the color's hue is preserved during the transition, matching the behavior on Android and web.
### The Problem
When creating a gradient on iOS (e.g., linear-gradient(red, transparent)), the transparent keyword is treated as transparent black (rgba(0,0,0,0)). The `CAGradientLayer` on iOS then interpolates all color channels linearly, causing the red, green, and blue components of the start color to fade to 0. This transition through black results in an undesirable dark or "muddy" appearance in the middle of the gradient.
## Changelog:
[IOS][FIXED] - Gradient interpolation for transparent colors
<!-- 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/52249
Test Plan:
Checkout `LinearGradient` example in RNTester, checkout the newly added transparent color transition example, it should render same on android and iOS.
| Before | After |
| --- | --- |
| <img src="https://github.com/user-attachments/assets/c0bb54ad-ed0e-4a80-b37f-0458af0f1f77" width="300"> | <img src="https://github.com/user-attachments/assets/02da921a-bd0e-45c1-881c-cf6460d5ed43" width="300"> |
| `linear-gradient(to right, red, transparent)` transitions to black on iOS, creating a dark effect. | The gradient correctly fades the red color's alpha channel to zero |
Reviewed By: javache
Differential Revision: D77312194
Pulled By: NickGerleman
fbshipit-source-id: 053df8e44f52cd22a3f28fd01f583f7d03c66af5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52386
Enum `values()` function makes a copy of an underlying array on each call. This happens in a hot path, and seems to show up during profiling. Let's cache it.
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D77623705
fbshipit-source-id: 5a33425822f477f63fe104ca9e5ed474385a2022
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52385
This replaces `buildSpannableFromFragmentsOptimized()` with a more optimized version. There are a couple main changes.
1. We don't need a complicated structure around ordering, and span priority, that made its way from the Java ShadowNode logic. AttributedString already ensures there are no overlapping attributes per fragment.
2. `SpannableStringBuilder` is a complicated text-editor style data structure, optimized to allow text content to be modified, and spans re-applied. We can use a much lighter `SpannableString`, on top of the ahead-of-time known text content, which is faster, and saves around 500 bytes per string (and prepared layout). If we assign this to an `EditText`, which later gets edited, Android will copy it to a `SpannableStringBuilder`.
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D77622848
fbshipit-source-id: 69bbac86e1f0fd4a15dab6bc279cca305f2a53ae
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52372
This is just a follow-up on top D77025333 to make sure that the links in the blog posts and the GitHub releases keep working.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D77654056
fbshipit-source-id: a1c6df44ebee058dd5b59e5b6a60c7c1e060e52c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52370
This is just a patch bump of Gradle ahead of the 0.81 branch cut.
Changelog:
[Android] [Changed] - Bump Gradle to 8.14.2
Reviewed By: fabriziocucci
Differential Revision: D77601121
fbshipit-source-id: b2fdc8b022f2ab43997f412c77e0c924c01f1a5d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52369
Tiny fix where the system status bar elements were no longer visible under Android edge-to-edge.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D77653633
fbshipit-source-id: 1275a0de6665a6ef4599166fb205865cd581bb41
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52359
This is needed ahead of the 81 branch cut.
Changelog:
[Internal] - Bump all packages to 0.81.0-main
Reviewed By: huntie
Differential Revision: D77602196
fbshipit-source-id: 1b52a7d1577783d72aba8d20f98032f29ffcc7df
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52357
Changelog: [Internal]
Adds a hyper-minimal build script using `electron/packager` that produces custom binaries for the experimental React Native DevTools standalone shell. The main user-facing benefit of this is replacing the Electron name and icon with our own branding.
NOTE: `electron/packager` is designed to include the application code in the resulting binary. This is arguably overkill for us - the current launch model of `electron src/electron/index.js` is actually wholly sufficient for what we need - but I decided to go with the grain of the available tooling for simplicity.
Icon design courtesy of huntie. 🙏
Reviewed By: huntie
Differential Revision: D77591742
fbshipit-source-id: a968465df4f54fba54c874b6300788e151600ed7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52365
Adds type imports autofix support and pass `fb_internal` paths in react native deep imports eslint rule. The rule fixes imports with all matched types with static API mapping to prevent splits.
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D77445445
fbshipit-source-id: cd5b75b4b3b53792117b8297352dddc4d63dbf70
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52345
changelog: [internal]
I would like to measure impact of D76597973 to get a better understanding of UIKit's rendering.
Reviewed By: yungsters
Differential Revision: D77542666
fbshipit-source-id: 4c2de4f36d2b374d83df934dd3a98d01b24f487f
Summary:
This PR connects breaking change detection with a danger bot. The action takes snapshot from main branch and from the PR as inputs to`diff-api-snapshot` (saved in runner temp directory).
## Changelog:
[Internal]
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/52045
Reviewed By: huntie
Differential Revision: D76735630
Pulled By: coado
fbshipit-source-id: 9208117340c1e0bf10d58b67892727717d22e62f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52353
This diff aligns breaking change detection script with new snapshot format. It compares hashes to determine if the API changed for each specifier.
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D77377762
fbshipit-source-id: e1c69692ace389fb08ae9470b9f9631e53834206
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52342
This diff deletes `public-api-test` for detecting changes in public API. It is replaced with public API snapshot validation (in D76340729) for better detection and understanding of changes that influence external interfaces.
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D77531763
fbshipit-source-id: a8ef2b6f52fa6efb5b312598ea3e4746fc51e4ec
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52352
This diff adds excution of `yarn build-types --validate` to run RN JS API snapshot validation on CI.
### Motivation
Detect react-native public API changes before they land.
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D76340729
fbshipit-source-id: 10c465418e0ba4eb05cf557a16119f9756843d9e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52343
This diff commits our V2 JavaScript API snapshot for React Native.
This is a new format and workflow that replaces the previous `public-api-test` Jest test.
Please look at the file header for up-to-date instructions on updating the API snapshot.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D77532617
fbshipit-source-id: d5faae815aa5071b0f472fcb02318b73772b11cf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52268
Ships the feature flag introduced in https://github.com/facebook/react-native/pull/51719 to fix crahes that result from shadowed animated style values.
Changelog:
[General][Changed] - Animated now always flattens `props.style`, which fixes an error that results from `props.style` objects in which `AnimatedNode` instances are shadowed (i.e. flattened to not exist in the resulting `props.style` object).
Reviewed By: javache
Differential Revision: D77314904
fbshipit-source-id: b442d0256aee7a8925e28c7e87aee5e0a3f39425
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52354
These should no longer be needed as `ReactNativeFeatureFlags` handles the missing native module gracefully.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D77365271
fbshipit-source-id: 92c6789b2175f24c79838118f681107a43c9ff0a
Summary:
X-link: https://github.com/facebook/yoga/pull/1823
Pull Request resolved: https://github.com/facebook/react-native/pull/52348
Fixes https://github.com/facebook/yoga/issues/1819
Yoga has a fast path when measuring a node, if it thinks it knows its dimensions ahead of time.
This path has some eroneous logic, to set both axis to owner size, if *either* will evaluate to zero, while having an `YGMeasureModeAtMost`/`FitContent` constraint. This means that if a node is given a zero width, and Yoga later measures with with `FitContent`, its height will become the maximum allowable height, even if it shouldn't be that large.
We can fix this, by only allowing if both axis are this fixed case, instead of just one.
This bug has existed for about a decade (going back to at least D3312496).
Changelog:
[General][Fixed] - Fix possible invalid measurements with width or height is zero pixels
Reviewed By: yungsters
Differential Revision: D76851589
fbshipit-source-id: 6f5a0e6beccc51f591726c9e83e9b90f3350ed0f
Summary:
Static code analysis reports several weak warnings, many of which seem to be leftovers after Kotlin migration. This PR addresses quite a few:
- [Accessor call that can be replaced with property access syntax](https://www.jetbrains.com/help/inspectopedia/UsePropertyAccessSyntax.html)
## Changelog:
[INTERNAL] - Kotlin: fix static code analysis weak warnings (6/n)
Pull Request resolved: https://github.com/facebook/react-native/pull/52338
Test Plan:
```sh
yarn android
yarn test-android
```
Reviewed By: NickGerleman
Differential Revision: D77504913
Pulled By: cortinico
fbshipit-source-id: 62661ba6adafb7893ce27811357020966d5ea4c1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52346
This is bypassing the mutex, and potentially not thread-safe.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D77541041
fbshipit-source-id: f97415d066786864806836768dbce2d5e68487ef
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52341
The setter for `createNewDialog` is now wrong (after D76834213).
If the `createNewDialog` has been set to `true` by any other field, we should respect it and not set it to true/false regardless
(only considering the `isEdgeToEdgeFeatureFlagOn`) property.
This fixes it.
Changelog:
[Internal] [Changed] -
Reviewed By: javache
Differential Revision: D77539533
fbshipit-source-id: a1deaf1f1b856895304e8b73fa5d0c0367e677af
Summary:
There is an issue with keyboard navigation if some scroll view sets `snapToAlignment`. In this case, we are unable to find potential focus candidates if clipping is enabled since this prop will make it so that certain views in the hierarchy under the scroll view form a native view without any traits being set. The fix we have in place currently relies on `FormsStackingContext` to be set to discover potential candidates so it will break in this case. To fix this, we just return the entire ancestor list, since native will know how to deal with the cases that are not actual views, and in general has the official knowledge of what can be in the hierarchy or not.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D77467933
fbshipit-source-id: 35daaba06347c738cf7a85eef86adb7944a9cb26
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52308
Experimentation shows, that we very heavily rely on the global text cache for performance (not sure how much of this is invalidation, vs repeated text, or revisiting previous surfaces).
This adds a global LRU cache, of prepared layouts, given a specific AttributedString and constraints. This is similar to the existing cache, with the caveat, that we need to have separate entries for any display states, instead of just those that effect metrics.
I sized it at 200 elements for now, since an Android `Layout` is much heavier than a `Size` (in practice, each seem to weight 1-3KB (though this will be significantly reduced with future change to move from `SpannableStringBuilder` to `SpannableString` and also contributes to the global JNI ref table, but set this up to be customizable via flag, so we can experiment, on perf impact, vs memory.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D77341994
fbshipit-source-id: b453250dc475f6a281a3260b876bf80f301dd5dd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52323
Original commit changeset: b144ca6db6f7
Original Phabricator Diff: D77388413
Reverting the revert since it did not fix our javascript crash problem for v270 https://fburl.com/scuba/errorreporting_system_vros_javascripterrors/mtexik9e
Original diff stack: D76908041
Revert diff stack: D77388940
Changelog[Internal]:
Puting back the Kotlin Migration for ReactDelegate file
Reviewed By: cortinico
Differential Revision: D77448293
fbshipit-source-id: ed40836c3ecb4ca551b23cb64de2c34cfda0dea1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52322
Original commit changeset: 4a366205ea9c
Original Phabricator Diff: D77388940
Reverting the revert since it did not fix our javascript crash problem for v270 https://fburl.com/scuba/errorreporting_system_vros_javascripterrors/mtexik9e
Original diff stack: D76908041
Revert diff stack: D77388940
Changelog[Internal]:
Puting back the Kotlin Migration for ReactDelegate file
Reviewed By: cortinico
Differential Revision: D77448238
fbshipit-source-id: f41faa19f6761b7ed644e804019f5ec4738326a7
Summary:
This follows https://github.com/facebook/react-native/pull/47554
Compared to the initial proposal, I had to remove the `edgeToEdgeEnabled` property from the root `gradle.properties` and put it in the app `gradle.properties` instead (explaining the `AgpConfiguratorUtils.kt` / `GenerateEntryPointTask.kt` / `ProjectUtils.kt` / `PropertyUtils.kt` changes)
This PR:
- Enable edge-to-edge for `MainActivity` (when `edgeToEdgeEnabled` is set to `true`)
- Disable `StatusBar` `backgroundColor` and `translucent` (when `edgeToEdgeEnabled` is set to `true`)
- Enforce `statusBarTranslucent` and `navigationBarTranslucent` on `Modal` when edge-to-edge is enabled
- Add an `isEdgeToEdge` constant to `DeviceInfoModule` for [`react-native-is-edge-to-edge`](https://github.com/zoontek/react-native-edge-to-edge/tree/main/react-native-is-edge-to-edge) detection
## 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] [Added] - Add edge-to-edge opt-in support
Pull Request resolved: https://github.com/facebook/react-native/pull/52088
Test Plan:
- Update `enableEdgeToEdge` value in `packages/rn-tester/android/app/gradle.properties`
- Recompile
https://github.com/user-attachments/assets/4c6beb98-fa88-427c-b62d-a42ffe5330f0
Rollback Plan:
Reviewed By: cortinico
Differential Revision: D76834213
Pulled By: alanleedev
fbshipit-source-id: c39b2cff1a5e94e31306e3b35651aa2de83d2fe6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52309
This is another class going from Java to Kotlin.
Thish should have no breaking changes, but I'll keep an eye to see if this is disruptive for users in the ecosystem.
I also haven't removed any of the Deprecated method, which can be cleaned up afterwards.
Changelog:
[Android] [Changed] - Migrate ThemedReactContext to Kotlin
Reviewed By: javache
Differential Revision: D77374236
fbshipit-source-id: d1787b21897b01c45bbf841fdda00972e0be58db
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52296
## Changelog:
[Internal] [Changed] - Fewer calls to direct manipulation callback
`NativeAnimatedNodesManager::onRender` is supposed to run each frame for c++ animation, from the callstack sample trace, the vast majority of time is spent on `updateNodes` (run update on all AnimatedNodes) and `commitProps` (where either Fabric ShadowTree commit or direct manipulation is called). Change in this PR is supposed to reduce time spent in `commitProps`
{F1979788964}
Reviewed By: sammy-SC
Differential Revision: D77380842
fbshipit-source-id: 2f25ca1fba4171a7b3e485298738379d0daff3ad
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52306
The RCTPushNotificationManager is deprecated and not part of the prebuilds as it is optional.
We mistakenly added it to the umbrella header and nightlies do not work with prebuilds.
This change removes the header ad should fix the build.
## Changelog:
[Internal] -
Reviewed By: philIip
Differential Revision: D77395754
fbshipit-source-id: 66371650dc56f5be16a00319d9e4a1078a7b68bd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52276
The line metrics reported do not process the Spannable, meaning their layout results may disagree with those used for measurement and display.
Changelog:
[Android][Fixed] - Fix onTextLayout metrics not incorporating ReactTextViewManagerCallback
Reviewed By: lenaic
Differential Revision: D77261839
fbshipit-source-id: 87bdc86ce16a2ae9fa69532c5721c19567a53595
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52222
Changelog: [Internal]
Introduce environment option to force usage of OSS fantom test runner.
If env is not set - check for BUCK file in tester which is checked in for FB but not for OSS.
Reviewed By: rubennorte
Differential Revision: D77160761
fbshipit-source-id: 1701ff140ff2be1bbeacfb4305e9f89089cacb42
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52294
changelog: [internal]
Views that are hidden provide couple perf benefits:
- The layer is skipped during hit-testing, so the view no longer receives touches.
- Compositing work for the layer is skipped, so nothing is uploaded to the GPU for that view.
Note, VirtualView still occupies space in memory and because this is infinite list and its numbers will grow unbounded.
In this diff, hidden = YES is only set when VirtualView does not participate in accessibility features.
Reviewed By: yungsters
Differential Revision: D76597973
fbshipit-source-id: 10eb36fccabba9e37cc6322ed5969b8502193a5f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52295
The current setup for several of our podspecs abuses the `**` globbing mechanism, forcing us to specify some excluded folders.
By excplicitly mention the folders that we want to use on iOS, we can avoid the usage of the `exclude_files` property.
This should make the setup more reliable and it will also avoid to leak to OSS the presence of some folders we only use internally like `platform/macos` and `platform/windows`
## Changelog:
[Internal] -
Reviewed By: huntie
Differential Revision: D77381512
fbshipit-source-id: 4cb9118bf9f0ecd253d7d871341f733564d84c83
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52300
Targeted improvement to `versionExportedApis` (D77303917) to reduce noise.
This eliminates the false positive from a rename to a local (unexported) type, that does not structurally change the shape of exported types.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D77314292
fbshipit-source-id: 4de90f5b5f1b622225762b2a73e386538000d54a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52299
Correctness improvement to the `versionExportedApis` transform (D77303917). Now handles namespaced references (e.g. `Animated.Value`) by redirecting to the locally defined type name.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D77314293
fbshipit-source-id: 6442d3ab0a3c8bebf6593455b1c2fb74266e657f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52298
Exposes the ability to output inline debug annotations for the `versionExportedApis` transform (D77303917) as a formalised `--debug-version-annotations` CLI flag.
This is helpful for debugging and future maintenance, and will be used to show the effect of the next diffs.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D77373723
fbshipit-source-id: 91c91abcb657ab88ee2f8209efccb4024602acc7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52292
Adds a new transform that annotates all exported symbols in our V2 JS API snapshot with a version hash based on the shape of all input types.
This intends to be a reliable mechanism to indicate how changes to local types will ultimately affect exported types.
**Advantages** (over our alternative type inlining prototype)
- More intuitive to developers — in that source type changes are preserved closer to their original source code shapes.
- Enables useful Git blaming of individual exported APIs — hash for each export line will change every time a type is affected, and relevant commits can be looked up based on this.
- Handles recursive types.
- Can be **best-effort** with minimal structural effect over time. We are okay with false positives that over-match input type changes (these are refined later in the stack).
- Similar to this, is **lower risk** in terms of requiring future updates that may pollute the diff of the body of the API snapshot structurally.
**Example change**
Example type change with multiple references: D77378010
{F1979784798}
✅ 8 char hash based on input type shapes printed next to each root-exported identifier
✅ For a source change to the `AccessibilityProps` type, 33 dependent exported types are updated with a new hash
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D77303917
fbshipit-source-id: 9d43a617697418218eb4951e8e9858d125e222b3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52293
# Changelog:
[Internal] -
Adds a helper method to the `IMountingManager` API in order to get the platform specific image loader implementation, if available.
Reviewed By: christophpurrer
Differential Revision: D77379053
fbshipit-source-id: b7595d78c83e9270ec1818daf2d0f1d342661e52
Summary:
To make sure we are exposing the same public API to swift as without prebuilt, this commit changes the follow:
- ModuleMap / Umbrella file is generated from template, not dynamically to align with non-prebuilt (cocoapods). This is temporary, we are already working toward a solution to generate them dynamically.
- Headers are extracted by reading from podspec files and expanding their globs. This is now easy since we can use the podspec_sources function to look for file globs.
## Changelog:
[Internal] - refactored header/umbrella/modulemap generation for prebuild
Pull Request resolved: https://github.com/facebook/react-native/pull/52286
Test Plan:
- Run RN-tester with/without prebuilts
- Create new RN app based on nightly, build with/without prebuiltsTo make sure we expose all the swift features that we should, we expose and declare a variable from React_RCTAppDelegate
Rollback Plan:
Reviewed By: cortinico
Differential Revision: D77368255
Pulled By: cipolleschi
fbshipit-source-id: 88e2c9d1622753895c8667a9b5aeae4a0d332cc4
Summary:
# Changelog: [Internal]
Adds support for experimental non-standardized `console.timeStamp` API for capturing performance entries on a timeline. The main idea of the API is to be highly performant. More details in the corresponding RCP [1].
NOTE: Because of the `jsinspector-modern` stack gating logic, this won't be installed in production builds. `console.timeStamp` will be polyfilled with a stub - D76987507.
Reviewed By: rubennorte
Differential Revision: D77374707
fbshipit-source-id: cb66b9fda06168f4b13af764afe95a63a0a8d5a0
Summary:
Changelog: [Internal]
A minimal tweak to a legacy code path for React DevTools in React Native (**NOT** Fusebox!) that enables it to work / not crash when encountering an IPv6 dev server address. See doc comment for more.
Reviewed By: hoxyq
Differential Revision: D77150288
fbshipit-source-id: c11c742aad7b83861a1242dd13c5ed2753fbdf29
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52091
# Changelog: [Internal]
Adds support for experimental non-standardized `console.timeStamp` API for capturing performance entries on a timeline. The main idea of the API is to be highly performant. More details in the corresponding RCP [1].
NOTE: Because of the `jsinspector-modern` stack gating logic, this won't be installed in production builds. `console.timeStamp` will be polyfilled with a stub - D76987507.
Reviewed By: rubennorte
Differential Revision: D76284119
fbshipit-source-id: c87c6645fe32f56d84f5915ff57865cfd9723a47
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52168
# Changelog: [Internal]
The main reason for the stub is to make sure this method is always installed. The actual implementation will be part of the `jsinspector-modern` stack, which is fully initialized in production builds.
Once there is a gurantee that RuntimeTarget globals are always installed in any environments, we can remove polyfills altogether.
Reviewed By: rubennorte, GijsWeterings
Differential Revision: D76987507
fbshipit-source-id: 2602af28f9e4359cf58dfafdf84802c0bf92372d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52289
The old `devtools://devtools/...` URL is **unsupported** with our modern debugger backend.
This reference was something we'd been intentionally leaving in place to preserve the old experience in Flipper — we can now remove.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D77368319
fbshipit-source-id: 400183e9bc477a887d66d79b412277971cf425e5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52280
Changelog: [Internal]
Adds a type-simplifyng transform for the API snapshot, with the goal of resolving some built-in TS types during build time. Most notably, it's able to simplify `Omit` structures emitted by the `flow-api-translator` when translating Flow's type spread operator.
It builds upon a simplified type inlining transform from the previous approach. The type inlining transform is able to handle inlining type references and resolution of built-in TS types on literal types:
- `Omit`
- `Readonly`
- `Partial`
- `keyof`
Reference inlining is performed top-down and built-in type resolution is performed bottom-up, which makes it possible for the second step to assume working on type literals.
Type simplifying transform uses the type inlining to reduce type references encountered inside `Omits` to their literal shapes, which makes possible to determine whether `Omit` is neccessary case-by-case. If `Omit` is redundant, it can be safely removed. If it's not, the omitted keys can be reduced to represent a subset of keys existing in the target type.
It also keeps the ability to resolve `Partial` and `Readonly` types on type literals, simplifying the snapshot further.
An example diff the transform can handle:
Before:
```
export declare type AccessibilityProps = Readonly<
Omit<
AccessibilityPropsAndroid,
| keyof {
accessibilityActions?: ReadonlyArray<AccessibilityActionInfo>
accessibilityHint?: string
accessibilityLabel?: string
accessibilityRole?: AccessibilityRole
accessibilityState?: AccessibilityState
accessibilityValue?: AccessibilityValue
accessible?: boolean
"aria-busy"?: boolean
"aria-checked"?: "mixed" | (boolean | undefined)
"aria-disabled"?: boolean
"aria-expanded"?: boolean
"aria-hidden"?: boolean
"aria-label"?: string
"aria-selected"?: boolean
"aria-valuemax"?: AccessibilityValue["max"]
"aria-valuemin"?: AccessibilityValue["min"]
"aria-valuenow"?: AccessibilityValue["now"]
"aria-valuetext"?: AccessibilityValue["text"]
role?: Role
}
| keyof AccessibilityPropsIOS
> &
Omit<
AccessibilityPropsIOS,
keyof {
accessibilityActions?: ReadonlyArray<AccessibilityActionInfo>
accessibilityHint?: string
accessibilityLabel?: string
accessibilityRole?: AccessibilityRole
accessibilityState?: AccessibilityState
accessibilityValue?: AccessibilityValue
accessible?: boolean
"aria-busy"?: boolean
"aria-checked"?: "mixed" | (boolean | undefined)
"aria-disabled"?: boolean
"aria-expanded"?: boolean
"aria-hidden"?: boolean
"aria-label"?: string
"aria-selected"?: boolean
"aria-valuemax"?: AccessibilityValue["max"]
"aria-valuemin"?: AccessibilityValue["min"]
"aria-valuenow"?: AccessibilityValue["now"]
"aria-valuetext"?: AccessibilityValue["text"]
role?: Role
}
> & {
accessibilityActions?: ReadonlyArray<AccessibilityActionInfo>
accessibilityHint?: string
accessibilityLabel?: string
accessibilityRole?: AccessibilityRole
accessibilityState?: AccessibilityState
accessibilityValue?: AccessibilityValue
accessible?: boolean
"aria-busy"?: boolean
"aria-checked"?: "mixed" | (boolean | undefined)
"aria-disabled"?: boolean
"aria-expanded"?: boolean
"aria-hidden"?: boolean
"aria-label"?: string
"aria-selected"?: boolean
"aria-valuemax"?: AccessibilityValue["max"]
"aria-valuemin"?: AccessibilityValue["min"]
"aria-valuenow"?: AccessibilityValue["now"]
"aria-valuetext"?: AccessibilityValue["text"]
role?: Role
}
>
```
After:
```
export declare type AccessibilityProps = Readonly<
AccessibilityPropsAndroid &
AccessibilityPropsIOS & {
accessibilityActions?: ReadonlyArray<AccessibilityActionInfo>
accessibilityHint?: string
accessibilityLabel?: string
accessibilityRole?: AccessibilityRole
accessibilityState?: AccessibilityState
accessibilityValue?: AccessibilityValue
accessible?: boolean
"aria-busy"?: boolean
"aria-checked"?: "mixed" | (boolean | undefined)
"aria-disabled"?: boolean
"aria-expanded"?: boolean
"aria-hidden"?: boolean
"aria-label"?: string
"aria-selected"?: boolean
"aria-valuemax"?: AccessibilityValue["max"]
"aria-valuemin"?: AccessibilityValue["min"]
"aria-valuenow"?: AccessibilityValue["now"]
"aria-valuetext"?: AccessibilityValue["text"]
role?: Role
}
>
```
Reviewed By: huntie
Differential Revision: D77295302
fbshipit-source-id: 213aef46035bde4f9783353b5344a6986a418399
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52246
This diff adds the required override to codegen props to make the `FabricMountingManager` aware of the availability of a prop diffing implementation for native components using codegen props.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D77234066
fbshipit-source-id: 8e95628348f491c5ee08609bc7d7b3d30bc7151b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52266
Native components may use `MixedType` properties in rare cases to hold untyped data. This diff adds support for serializing and prop diffing these types of props so that all of the props and object fields would be included in prop diffing results.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D77307169
fbshipit-source-id: ae6b00207ef857c9cfa4bdf9c235972915410a29
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52244
The ArrayType props converts to std::vector. This prompted the need for `toDynamic(const T&)` conversion functions as this breaks to potential reliance on all type instances having a `toDynamic()` function available. This includes:
- array of arrays types
- array of objects types
- object with arrays
The ArrayType conversion uses the availability of the `toDynamic` conversion methods for all supported types to convert the values stored by the `std::vector` to `folly::dynamic` values to be stored on a `folly::dynamic::array`.
The diff removes unnecessary conversion methods implemented previously for the core components prop diffing. These are now handled by the generic `toDynamic(const std::vector<T>&)` conversion method.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D77234065
fbshipit-source-id: 97a3b175ff07fe4a6de3adb14ee6cb42db1a2cfe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52243
Building on the availability of `toDynamic` conversion methods for all supported property types, this diff adds support for diffing of `ObjectType` props.
The template adds the generation of a default comparator for the generated C++ struct. The struct also gains a `toDynamic` conversion method that will convert each property of the object type to a `folly::dynamic` value.
Primitive types make use of the implicit conversion supported by `folly::dynamic`, all other types are converted using `toDynamic`.
The `toDynamic` logic is implemented as a method defined on the struct to avoid increased binary size when required multiple times by the prop diffing implementation.
The external `toDynamic` conversion function calls the struct method directly. This enables support for converting object types using object types within their props.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D77234064
fbshipit-source-id: 21deb3104303aa374fb65b969af57a6aca6db38c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52242
Codegen supports `DimensionType` props which represents a YGValue. This diff adds a conversion to `folly::dynamic` supporting all the existing value types `YGValue` can represent.
This completes codegen support for all allowed `ReservedPropTypeAnnotation` prop types.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D77234061
fbshipit-source-id: 6c3aef5e3ab0459d8a68ebd8efaccfecb83b0b08
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52241
Add support for converting string and int32 enum types to `folly::dynamic` and generating the correct property diffing for it conditionally adding the prop value to the prop diff result.
This diff updates the template to convert the enum back to the original string representation provided from the JS side based on the current generated C++ enum value.
The string enum re-uses the existing `toString` conversion. The number enum generates the switch-case mapping required to map back the C++ enum value to the original value assigned to it.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D77234070
fbshipit-source-id: 8c669d5b2e21bd6022c6ba36149465495e4d4bf3
Summary:
Changelog: [Internal]
Fixes a thread safety bug in the C++ platform's `InspectorPackagerConnectionDelegate::WebSocket` implementation. Since D60520747 `IWebSocketDelegate` event calls have been required to be made on the inspector thread, but the C++ platform was making them on the platform's WebSocket thread instead.
Reviewed By: christophpurrer
Differential Revision: D77150289
fbshipit-source-id: f57de05eaccbbe9db674076fc9e60f8d0dd243c5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52271
In my haste I messed up a few of these. Either type in the text, or giving them props they should not have.
Changelog: [Internal]
Reviewed By: jorge-cab
Differential Revision: D77310876
fbshipit-source-id: 9c5a28285d4bb3673fe99630fa7ed97033b17904
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52263
Changelog: [Internal]
Adds a bare-bones API to set the dev server host and port at the time of creating a `ReactInstance` in the C++ platform.
Reviewed By: rshest
Differential Revision: D77050457
fbshipit-source-id: 642dc96d3cb486a2e7faa177adcbf8a15b8fb668
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52256
## Summary
ReactNativeAttributePayloadFabric was synced to react-native in
https://github.com/facebook/react-native/commit/0e42d33cbcfadcf5d787108da785d56a83d07a9f.
We should now consume these methods from the
ReactNativePrivateInterface.
Moving these methods to the React Native repo gives us more flexibility
to experiment with new techniques for bridging and diffing props
payloads.
I did have to leave some stub implementations for existing unit tests,
but moved all detailed tests to the React Native repo.
## How did you test this change?
* `yarn prettier`
* `yarn test ReactFabric-test`
DiffTrain build for [7a3ffef70339c10f8d65a27b88cd73bfbe13eb8a](https://github.com/facebook/react/commit/7a3ffef70339c10f8d65a27b88cd73bfbe13eb8a)
Reviewed By: rubennorte
Differential Revision: D77296286
fbshipit-source-id: a26aa0fe0f7f1c8a42407d759351734a4c85f970
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52050
Uncaught errors are currently raising a custom error to `console.error`:
* With somewhat unclear messaging.
* Only the **component stack** is reported.
* The top-most stack leads to the component where the throw occurred and not to the actual error being thrown.
* The actual error being thrown is never logged
After this change:
* We print the actual error thrown
* The *Owner stack* is attached
(see test plan for examples)
## Changelog:
[General][Breaking] Improve messaging and add error stack trace in console errors generated on throws from components.
----
This is a breaking change because someone might be monkey-patching console.errors, or just listens to them.
Reviewed By: rickhanlonii
Differential Revision: D75080385
fbshipit-source-id: 824f30a804a3bb836ea1be7257784e56c00077c1
Summary:
After switching to the new backwards compatible cocoapods structure with prebuilts, we no longer need any change in the ReactCodegen template.
This commit fixes this.
## Changelog:
[IOS] [FIXED] - revert changes in ReactCodegen template
Pull Request resolved: https://github.com/facebook/react-native/pull/52257
Test Plan: Build RN-tester with prebuilt
Reviewed By: cortinico
Differential Revision: D77303429
Pulled By: cipolleschi
fbshipit-source-id: d251d7d67b1c902082891ba705db5158c558e842
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52234
Changelog: [Internal]
Use raw regex instead of micromatch as it depends on node imports.
Reviewed By: christophpurrer
Differential Revision: D77241819
fbshipit-source-id: c579b42f064f67c2e44e15e40ab6262f45a90797
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52220
# Changelog: [Internal]
Mainly, 2 changes:
1. `PerformanceTracer::serializeTraceEvent(const TraceEvent& event)` -> `PerformanceTracer::serializeTraceEvent(TraceEvent&& event)` for less copies, actually move strings from the `TraceEvent` into the serialized `folly:object`.
2. When collecting events from the buffer, only lock when accessing buffer, not when serializing.
Reviewed By: rubennorte
Differential Revision: D77164969
fbshipit-source-id: c7dd84dd3c94dae22b89ffd4b229974e6d8084de
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52196
# Changelog: [Internal]
Probably been overlooked for quite some time, but shouldn't be a bottleneck.
Reviewed By: motiz88
Differential Revision: D77148271
fbshipit-source-id: e8eb32137086d6c280aab2ec5903be03f96175ad
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52188
# Changelog: [Internal]
`buffer_.push_back` -> `buffer_.emplace_back`
I didn't measure if there were any runtime wins from this, because I don't expect there would be. Let's avoid potential copies, if possible.
Reviewed By: rubennorte
Differential Revision: D77053032
fbshipit-source-id: 80a0d3759bf95b1945ebe560806712bfa6a4f924
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52187
# Changelog: [Internal]
- `bool tracing_` -> `std::atomic<bool> tracingAtomic_`.
- More doc-comments to explain the usage of mutex and atomics.
- `PerformanceTracer::isTracing()` -> `inline PerformanceTracer::isTracing()`.
- `uint64_t processId_` -> `const uint64_t processId_`.
The main change is that the boolean flag that controls "if we are tracing" is now atomic, which should eliminate potential data races. To avoid "logic" races, we are still going to lock mutex, and then check again. The use of `std::atomic` allows us to perform cheaper check first to avoid potentially unnecessary serializations from other systems that report events into `PerformanceTracer`.
Reviewed By: rubennorte
Differential Revision: D77053030
fbshipit-source-id: 82966055db0d75f828e7b95ad4c6cd7f18902265
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52254
changelog: [internal]
View culling would generate incorrect mounting instructions because view culling context is checked before it is changed by a view.
Reviewed By: javache
Differential Revision: D77298889
fbshipit-source-id: 2f98dc4de90f34673ff6f627b597942d80fda865
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52239
Add `toDynamic` conversion function for `EdgeInset` which allowed for removing the custom conversion implemented for the `ViewProps`.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D77234069
fbshipit-source-id: 3aecad8a6d78468f0056167fa1523ccdfb68f369
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52238
Add prop diffing codegen for `PointPrimitive` prop type by adding a `toDynamic` conversion for the struct and the prop diffing conditional result update.
The addition of the `toDynamic` function will allow for converting the type when used in array and object types.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D77234062
fbshipit-source-id: d0f52e8fd78ac7712925ea2a47cdd0fe3392d5b0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52237
For array props conversion following later in this stack, each type should have a toDynamic conversion available that can be called upon to convert all supported types to a `folly::dynamic` result.
This diff adds the toDynamic conversion function for `ImageSource`
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D77234063
fbshipit-source-id: 392cbaf172595936f7f66faa824900dadd58bdcf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52252
Instead of declaring two different sets of Pods for prebuilt and build from source, this commit now keeps the pod structure the same for both modes so that consuming libraries can expect to have the same pods and header files available - without this, libraries would have to be updated to take advantage of the prebuilds.
This PR does:
- Added React-Core-prebuilt as a pod in React-Core if prebuilt is enabled
- Simplified react_native_pods to keep pods structure and add React-Core-prebuilt pod if prebuilts are enabled
- Added function for selecting source sets based on prebuilt/build from source
To be able to function both in prebuilt and in regular build from source mode, all podspecs are now using the switch function podspec_sources so that they only include header files if we are in prebuild mode.
Also added React-Core-prebuilt as dependency on React-Core if we are in prebuilt mode so that we install the React.XCFramework.
## Changelog:
[IOS] [FIXED] - Added backwards compatible use of prebuild through cocoapods
Pull Request resolved: https://github.com/facebook/react-native/pull/52223
Test Plan:
Tested in RN-Tester both with and without prebuild.
Rollback Plan:
Reviewed By: cortinico
Differential Revision: D77296047
Pulled By: cipolleschi
fbshipit-source-id: f3eb4d56b2a78bfc8e10ad852746be1ceaf828b2
Summary:
`Package.swift` was missing the `RCTVibration` target. This commit adds this target.
## Changelog:
[Internal] - Added RCTVibration to SwiftPM
Pull Request resolved: https://github.com/facebook/react-native/pull/52223
Test Plan: Tested in RN-Tester both with and without prebuild.
Reviewed By: cortinico
Differential Revision: D77257066
Pulled By: cipolleschi
fbshipit-source-id: 13c918387a2ed4a8e3941ddce8b7ba11c24eaab5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52235
Adds `organizeDeclarations` transform, replacing `sortTypeDefinitions`.
All `export declare ...` statements are now collected and represented at the end of the snapshot in a single `export {}` block — significantly improving readability and diffing.
Changelog: [Internal]
Reviewed By: j-piasecki
Differential Revision: D77150017
fbshipit-source-id: 1bd451c0e2a18fd6fc0504970b10a5d2502ac872
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52245
Changes `VirtualView` to avoid dispatching redundant mode change events by reading the last committed `renderState` to determine whether the desired render state is already in effect.
This enables `VirtualView` to avoid dispatching synchronous `Visible` mode change events when a previous `Prerender` mode change event has already been committed.
Changelog:
[Internal]
Reviewed By: lunaleaps
Differential Revision: D77271865
fbshipit-source-id: 75418aec1416995737f308a1beff407f2cedb940
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52240
Changes `VirtualView` to detect when its window is not in a focused window (e.g. scroll position or layout changes when it is blurred) and to instead dispatch an async `Prerender` event instead of a sync `Visible` event.
This minimizes unnecessary main thread synchronous work that is needed for a view that is not important to the user experience.
Changelog:
[Internal]
Reviewed By: mdvacca
Differential Revision: D77261958
fbshipit-source-id: 32acef9bc938005a0d73c5166f1741aebadf23bb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52236
Enable experimental Flow 'match' syntax for `react-native-github/packages/react-native/src/private/components/virtualview/` and adopt in one case to see if there are any issues.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D77250963
fbshipit-source-id: 0b2a5817a05f3332031f0c0590fe956eaa74ddd3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52212
Correcting some C++ imports that show up when build with Xcode 26:
- Missing `<string>` imports.
- `<tgmath.h>` is a deprecated C++ header file, which in this case can be substituted with `<cmath>`.
## Changelog: [Internal]
[iOS][Fixed] - Fix deprecated C++ imports
Reviewed By: zhenma
Differential Revision: D77192276
fbshipit-source-id: 30c836947cb3eb54f6e7ac42b87fd2493334a4f4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52231
Not calling `super.onInitializeAccessibilityNodeInfo` on the host view with accessibilityOrder prevents setting proper dimensions for the node that backs the view which leads TalkBack to trigger scrolling when under a ScrollVIew.
We still need the host's node to not be accessible so we still set it to not be focusable and not have a content description since this should be handled by the virtual views
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D77180494
fbshipit-source-id: fe8794cf421cdc9548cf3e18a62d4bb3e8c26b09
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52066
Before, to disable views that were excluded from the order we were setting them to be not important for accessibility. This however breaks coopting behavior of parent views, because parent views will not announce content descriptions of children that are not important for accessibility.
Instead of disabling by setting `important for accessibility = no` now we just set `isFocusable = false` which disables focusing but still allows parent views to coopt
We also add functionality to restore view focusability when enabling disabling screen readers since `isFocusable` changes keyboard focusability and when screen readers are disabled we don't want to change it.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D76745057
fbshipit-source-id: cc237c5f8a4b894a7caa3e34207080777de440ac
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52228
To avoid unexpected behaviour, apply all Babel transforms within `build-types` sequentially, so that each transform plugin has an accurate starting AST.
Changelog: [Internal]
Reviewed By: j-piasecki
Differential Revision: D77148444
fbshipit-source-id: f86beac12b7a08ef800e28db1ff88755970cf64e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52194
Changelog: [Internal]
Introducing a way to include sources and deps via function that react_native_android_dep.
This will help with Fantom OSS build.
Reviewed By: cortinico
Differential Revision: D77146189
fbshipit-source-id: 06b09d433741506bc1f58fbf1f9e6add9a9cff91
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52221
It is currently not possible to use prebuilds, because we are missing the `React-Core-prebuilt.podspec` from the npm package we publish.
This change should fix it.
## Changelog:
[iOS][Added] - Ship the `React-Core-prebuilt.podspec` in the package.json
Reviewed By: cortinico
Differential Revision: D77223271
fbshipit-source-id: ab068e1711fdd86f3f0069dc9aa3c0a591fcd26b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52215
We were not handling the download of the XML properly. Using `Net::HTTP.get` will directly return the body and that won't let us check on the status code of the response.
## Changelog:
[Internal] - use get_response instead of get when downloading the maven metadata
Reviewed By: cortinico
Differential Revision: D77216121
fbshipit-source-id: 4da0abff1624c687977a7b77db8a15f19e6b887d
Summary:
This PR replaces Core Graphics implementation with Core Animation for radial gradients. I found that `endPoints` for radial gradient type works differently than linear gradient type. The `endPoint.x` accounts for horizontal length and `endPoint.y` accounts for vertical. This makes it possible to draw ellipse gradients. So we don't need the core graphics API anymore.
## Changelog:
[IOS] [CHANGED] - Optimised Radial Gradients.
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/52117
Test Plan: Non breaking change. Test Radial gradient example from RNTester. Compare results with web, android and iOS. Each platform should render the gradients identically.
Reviewed By: rshest
Differential Revision: D77140709
Pulled By: javache
fbshipit-source-id: 6e3ad9fcf8e819d340ccf5f5946beb140e616cb0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52122
Would love to have a place with all the edge cases we can come back to when we try and tweak things.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D76942595
fbshipit-source-id: ce6e293e2c068383e54404af71a29a0586dbc04e
Summary:
### The Problem
When trying to measure the location of a `View` within a `ScrollView` (ie. for scrolling to the view), the current recommended method is to use `measureLayout` on the nested view to determine its location inside the containing scroll view:
```tsx
const MyComponent = () => {
const scrollViewRef = useRef<ScrollView>(null);
const nestedViewRef = useRef<View>(null);
const scrollToNestedView = () => {
if (!scrollViewRef.current || !nestedViewRef.current) {
return;
}
nestedViewRef.current.measureLayout(
scrollViewRef.current.getInnerViewNode(),
(x, y) => { scrollViewRef.current.scrollTo({ y, animated: true }); },
);
}
return (
<ScrollView ref={scrollViewRef}>
<View ref={nestedViewRef}>
{ /* content */ }
</View>
</ScrollView>
);
}
```
This is valid in the Typescript types layer. However, the only two methods on `ScrollView` to use in this scenario that are [available in the type definitions](https://github.com/facebook/react-native/blob/main/packages/react-native/Libraries/Components/ScrollView/ScrollView.d.ts#L830) are `getScrollableNode` and `getInnerViewNode` – both of these methods [return a `number`](https://github.com/facebook/react-native/blob/main/packages/react-native/Libraries/Components/ScrollView/ScrollView.js#L139-L140). The issue is that a `number` not a valid value to use with `measureLayout` because [its source returns early for that type](https://github.com/facebook/react-native/blob/main/packages/react-native/Libraries/ReactNative/ReactFabricPublicInstance/ReactFabricHostComponent.js#L91-L102).
(Note, you can also use `findNodeHandle` with the scroll view ref, but this also returns a `number`.)
### The Solution
The long-term solution would be to update the types for both `measureLayout` and `ScrollView`. However, that would constitute a breaking change and require some fairly expansive updates. Instead, I am proposing an additive solution.
`ScrollView` has [a public method called `getNativeScrollRef`](https://github.com/facebook/react-native/blob/e69f0726cd2616fb112d2e4fabfeaafc8cada5d7/packages/react-native/Libraries/Components/ScrollView/ScrollView.js#L142) which returns the underlying `HostInstance`. This method correctly works in the runtime layer, but is not supported in the types layer. This PR exposes the public method in the type definition so that we can properly access the underlying instance without using `ts-ignore`.
## Changelog:[GENERAL] [FIXED] - Expose `ScrollView.getNativeScrollRef` on the type definition to allow accessing the underlying `HostInstance`.
Pull Request resolved: https://github.com/facebook/react-native/pull/52203
Test Plan: None needed. This is only a type update exposing existing functionality.
Reviewed By: cortinico
Differential Revision: D77153959
Pulled By: rshest
fbshipit-source-id: 5880695da85406ed9fe49a1b736b5754db0e6382
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52095
This diff removes `shelljs` from `run-ci-javascript-tests.js` and replaces `echo, exec, and exit` methods.
### Motivation
Decrease number of references to `shelljs` across the react-native-github.
Changelog:
[Internal]
Reviewed By: NickGerleman
Differential Revision: D76512374
fbshipit-source-id: 6e02901b570cf9a36bd13a075106a7066a85a2d9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52192
Changelog: [internal]
When we shipped the event loop we removed the need to run only expired tasks in `RuntimeScheduler_Modern`, but we never cleaned up the code properly. This does it.
Reviewed By: javache
Differential Revision: D77142978
fbshipit-source-id: f808edf80a134f487723fa36ab7a3593e4efe2d3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52191
Changelog: [internal]
Some time ago we added logging for the timer ID in Systrace/Perfetto so we could see where timers were scheduled vs. executed.
This diff adds support for the same functionality for tasks in the runtime scheduler.
Reviewed By: javache
Differential Revision: D77039038
fbshipit-source-id: 792d2fe29b44fb209f9129f46f9d661dad7ebdff
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52190
Changelog: [internal]
This adds some tracing metadata to IntersectionObserver to contextualize the performance of certain operations (logging how many observers it's processing).
Reviewed By: javache
Differential Revision: D77039037
fbshipit-source-id: 9cee79ac0509f57e4658a16142f3fe2d10d71fdf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52189
Changelog: [internal]
This creates a benchmark to measure the changes in performance in RuntimeScheduler.
Reviewed By: javache
Differential Revision: D77142979
fbshipit-source-id: 1a6e6824f4c6fdb8d2c5cbad77fb4b8ba406ef29
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52138
Integrate React Core prebuilds with apps
## Context
This PR introduces the first working version of building React Native apps on iOS using prebuilt RNCore and cocoapods.
- Added React-Core-prebuilt.podspec for installing/consuming XCFrameworks
- Added logic in react_native_pods.rb for switching between build from source and using prebuilts
- Added rncore.rb - utilities for the ReactCore prebuilts
- Updated rndependencies with some extra error handling modelled after rncode.rb
- Added support for hard linking headers and modules in each inner framework in the XCFramework in xcframework.js
## Swift:
To enable support for the objective-c types from swift, the swift compiler uses a module map to gather exports from the framework (module.modulemap). This file basically points to an umbrella header file that exports the valid objective-c types (non c++) to Swift. In addition these files are read from the DerivedData and not the project source - so it is a bit hard to control everyting.
I was initially not able to use cocoapods own module definitions (module_name, module_file props) to use a custom module map. I finally found that these files are expected in the deriveddata (build folder) where only the active inner framework is copied - so then I had to hard link both module map and header files for each arch.
## Changelog:
[IOS] [ADDED] - Added support for using prebuilt RNCore with Cocoapods
Pull Request resolved: https://github.com/facebook/react-native/pull/52109
Test Plan:
Run with RN Tester. We need to remove all extra pods from RNTester pod file since none of them are yet compatible with prebuilt (they reference non-prebuilt pods)
Rollback Plan:
Reviewed By: cortinico
Differential Revision: D76980286
Pulled By: cipolleschi
fbshipit-source-id: 0ef34599cf7a60e54f799708bce93bcf6fb9d950
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52134
Update RNDependencies podspec to fail fast if framework is missing
## Context
This PR introduces the first working version of building React Native apps on iOS using prebuilt RNCore and cocoapods.
- Added React-Core-prebuilt.podspec for installing/consuming XCFrameworks
- Added logic in react_native_pods.rb for switching between build from source and using prebuilts
- Added rncore.rb - utilities for the ReactCore prebuilts
- Updated rndependencies with some extra error handling modelled after rncode.rb
- Added support for hard linking headers and modules in each inner framework in the XCFramework in xcframework.js
## Swift:
To enable support for the objective-c types from swift, the swift compiler uses a module map to gather exports from the framework (module.modulemap). This file basically points to an umbrella header file that exports the valid objective-c types (non c++) to Swift. In addition these files are read from the DerivedData and not the project source - so it is a bit hard to control everyting.
I was initially not able to use cocoapods own module definitions (module_name, module_file props) to use a custom module map. I finally found that these files are expected in the deriveddata (build folder) where only the active inner framework is copied - so then I had to hard link both module map and header files for each arch.
## Changelog:
[IOS] [CHANGED] - Fail fast when pod install i f using prebuild if frameworks are not present in the disk.
Pull Request resolved: https://github.com/facebook/react-native/pull/52109
Test Plan:
Run with RN Tester. We need to remove all extra pods from RNTester pod file since none of them are yet compatible with prebuilt (they reference non-prebuilt pods)
Rollback Plan:
Reviewed By: cortinico
Differential Revision: D76980282
Pulled By: cipolleschi
fbshipit-source-id: 6ab029d0cb06e2f0a3d99ea9fc7b375865e7a966
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52135
Update the xcframework.js script to support Swift
## Context
This PR introduces the first working version of building React Native apps on iOS using prebuilt RNCore and cocoapods.
- Added React-Core-prebuilt.podspec for installing/consuming XCFrameworks
- Added logic in react_native_pods.rb for switching between build from source and using prebuilts
- Added rncore.rb - utilities for the ReactCore prebuilts
- Updated rndependencies with some extra error handling modelled after rncode.rb
- Added support for hard linking headers and modules in each inner framework in the XCFramework in xcframework.js
## Swift:
To enable support for the objective-c types from swift, the swift compiler uses a module map to gather exports from the framework (module.modulemap). This file basically points to an umbrella header file that exports the valid objective-c types (non c++) to Swift. In addition these files are read from the DerivedData and not the project source - so it is a bit hard to control everyting.
I was initially not able to use cocoapods own module definitions (module_name, module_file props) to use a custom module map. I finally found that these files are expected in the deriveddata (build folder) where only the active inner framework is copied - so then I had to hard link both module map and header files for each arch.
## Changelog:
[INTERNAL] - Update the xcframework.js script to support Swift
Pull Request resolved: https://github.com/facebook/react-native/pull/52109
Test Plan:
Run with RN Tester. We need to remove all extra pods from RNTester pod file since none of them are yet compatible with prebuilt (they reference non-prebuilt pods)
Rollback Plan:
Reviewed By: cortinico
Differential Revision: D76980285
Pulled By: cipolleschi
fbshipit-source-id: 4e5486b79c406ba4b375e2ada24cbe5450e2346f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52137
Update ReactCodegen to support Core prebuilds
## Context
This PR introduces the first working version of building React Native apps on iOS using prebuilt RNCore and cocoapods.
- Added React-Core-prebuilt.podspec for installing/consuming XCFrameworks
- Added logic in react_native_pods.rb for switching between build from source and using prebuilts
- Added rncore.rb - utilities for the ReactCore prebuilts
- Updated rndependencies with some extra error handling modelled after rncode.rb
- Added support for hard linking headers and modules in each inner framework in the XCFramework in xcframework.js
## Swift:
To enable support for the objective-c types from swift, the swift compiler uses a module map to gather exports from the framework (module.modulemap). This file basically points to an umbrella header file that exports the valid objective-c types (non c++) to Swift. In addition these files are read from the DerivedData and not the project source - so it is a bit hard to control everyting.
I was initially not able to use cocoapods own module definitions (module_name, module_file props) to use a custom module map. I finally found that these files are expected in the deriveddata (build folder) where only the active inner framework is copied - so then I had to hard link both module map and header files for each arch.
## Changelog:
[IOS] [CHANGED] - Update ReactCodegen to support Core prebuilds
Pull Request resolved: https://github.com/facebook/react-native/pull/52109
Test Plan:
Run with RN Tester. We need to remove all extra pods from RNTester pod file since none of them are yet compatible with prebuilt (they reference non-prebuilt pods)
Rollback Plan:
Reviewed By: cortinico
Differential Revision: D76980283
Pulled By: cipolleschi
fbshipit-source-id: 4b120203e9e1628a63580b0b3b2e882837c0b818
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52136
Update rndependencies.rb to use the same logic of rncore.rb
## Context
This PR introduces the first working version of building React Native apps on iOS using prebuilt RNCore and cocoapods.
- Added React-Core-prebuilt.podspec for installing/consuming XCFrameworks
- Added logic in react_native_pods.rb for switching between build from source and using prebuilts
- Added rncore.rb - utilities for the ReactCore prebuilts
- Updated rndependencies with some extra error handling modelled after rncode.rb
- Added support for hard linking headers and modules in each inner framework in the XCFramework in xcframework.js
## Swift:
To enable support for the objective-c types from swift, the swift compiler uses a module map to gather exports from the framework (module.modulemap). This file basically points to an umbrella header file that exports the valid objective-c types (non c++) to Swift. In addition these files are read from the DerivedData and not the project source - so it is a bit hard to control everyting.
I was initially not able to use cocoapods own module definitions (module_name, module_file props) to use a custom module map. I finally found that these files are expected in the deriveddata (build folder) where only the active inner framework is copied - so then I had to hard link both module map and header files for each arch.
## Changelog:
[INTERNAL] - Update rndependencies.rb to use the same logic of rncore.rb
Pull Request resolved: https://github.com/facebook/react-native/pull/52109
Test Plan:
Run with RN Tester. We need to remove all extra pods from RNTester pod file since none of them are yet compatible with prebuilt (they reference non-prebuilt pods)
Rollback Plan:
Reviewed By: cortinico
Differential Revision: D76980284
Pulled By: cipolleschi
fbshipit-source-id: a7f09d931c66e2fdf468a09da4be1d40847f472b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52133
Add React-Core-prebuild.podspec to integrate React native core prebuilds using cocoapods
## Context
This PR introduces the first working version of building React Native apps on iOS using prebuilt RNCore and cocoapods.
- Added React-Core-prebuilt.podspec for installing/consuming XCFrameworks
- Added logic in react_native_pods.rb for switching between build from source and using prebuilts
- Added rncore.rb - utilities for the ReactCore prebuilts
- Updated rndependencies with some extra error handling modelled after rncode.rb
- Added support for hard linking headers and modules in each inner framework in the XCFramework in xcframework.js
## Swift:
To enable support for the objective-c types from swift, the swift compiler uses a module map to gather exports from the framework (module.modulemap). This file basically points to an umbrella header file that exports the valid objective-c types (non c++) to Swift. In addition these files are read from the DerivedData and not the project source - so it is a bit hard to control everyting.
I was initially not able to use cocoapods own module definitions (module_name, module_file props) to use a custom module map. I finally found that these files are expected in the deriveddata (build folder) where only the active inner framework is copied - so then I had to hard link both module map and header files for each arch.
## Changelog:
[IOS] [ADDED] - Add `React-Core-prebuild.podspec` to integrate React native core prebuilds using cocoapods
Pull Request resolved: https://github.com/facebook/react-native/pull/52109
Test Plan:
Run with RN Tester. We need to remove all extra pods from RNTester pod file since none of them are yet compatible with prebuilt (they reference non-prebuilt pods)
Rollback Plan:
Reviewed By: cortinico
Differential Revision: D76980281
Pulled By: cipolleschi
fbshipit-source-id: ce102837d6df6ab0fa2e55862cc0c954125bd362
Summary:
Introduce rncore.rb to manage the prebuilds of RNCore.
## Context
This PR introduces the first working version of building React Native apps on iOS using prebuilt RNCore and cocoapods.
- Added React-Core-prebuilt.podspec for installing/consuming XCFrameworks
- Added logic in react_native_pods.rb for switching between build from source and using prebuilts
- Added rncore.rb - utilities for the ReactCore prebuilts
- Updated rndependencies with some extra error handling modelled after rncode.rb
- Added support for hard linking headers and modules in each inner framework in the XCFramework in xcframework.js
## Swift:
To enable support for the objective-c types from swift, the swift compiler uses a module map to gather exports from the framework (module.modulemap). This file basically points to an umbrella header file that exports the valid objective-c types (non c++) to Swift. In addition these files are read from the DerivedData and not the project source - so it is a bit hard to control everyting.
I was initially not able to use cocoapods own module definitions (module_name, module_file props) to use a custom module map. I finally found that these files are expected in the deriveddata (build folder) where only the active inner framework is copied - so then I had to hard link both module map and header files for each arch.
bypass-github-export-checks
## Changelog:
[INTERNAL] - Added script to handle React Core prebuilds
Pull Request resolved: https://github.com/facebook/react-native/pull/52109
Test Plan:
Run with RN Tester. We need to remove all extra pods from RNTester pod file since none of them are yet compatible with prebuilt (they reference non-prebuilt pods)
Rollback Plan:
Reviewed By: cortinico, rshest
Differential Revision: D76979549
Pulled By: cipolleschi
fbshipit-source-id: 7a2b1809bf58b600293cc33ca2dcff0060f3fab0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52198
# Changelog:
[Internal] -
This provides an implementation of what was the RnCxx ImageLoaderModule stub inside ReactCxxPlatform, allowing the clients use dependency injection to provide the actual platform specific image loading functionality.
Reviewed By: javache
Differential Revision: D77015269
fbshipit-source-id: 7355dd75692c1f564de8c3daffd6c8a79182dc09
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52154
I wasn't able to find any meaningful usage of `EventDispatcherImpl` in OSS, therefore I'm making this class internal.
Changelog:
[Internal] [Changed] -
Reviewed By: javache
Differential Revision: D77024759
fbshipit-source-id: e1ff3329cedf96a8c75edb9b9ccc1ce21adfab11
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52150
This is another class moving from Java to Kotlin.
Changelog:
[Internal] [Changed] -
Reviewed By: javache
Differential Revision: D77021952
fbshipit-source-id: 0b04a10bcbe65b7dc14ddd2821f80d90a43f8610
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52195
RNTester is currently instacrashing on release due to use minifying the `ReactModalHostView`.
In that class there is a static method that is accessed by JNI so we should annotated this class
as `DoNotStrip` as otherwise we won't be able to access it.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D77148010
fbshipit-source-id: c5b2758fa2919bc1f5885433202a45b4c3f8ff99
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52185
It seems like one of the activity on the stack is not properly implementing `DefaultHardwareBackBtnHandler`.
This will make the crash more clear as it will be clear which activity is the one responsible for the crash.
Changelog:
[Internal] [Changed] -
Reviewed By: javache
Differential Revision: D77142320
fbshipit-source-id: 1913976d1ad5d3ceafcfc0569f3b74dad9e919ae
Summary:
Splitting the CHANGELOG as it's getting too big to handle.
Changelog:
[Internal] [Changed] -
bypass-github-export-checks
Reviewed By: cipolleschi
Differential Revision: D77025333
fbshipit-source-id: cf2d54f2096f9c8c6a3fadb354d0c3065370440d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52156
Changelog: [Internal]
Fix devtoolsruntimesettings lib as it needs to be OBJECT library as it has source code included.
Reviewed By: christophpurrer
Differential Revision: D77035122
fbshipit-source-id: 27ad7fe637512afc79f3dcc6b0846dcfd4f22504
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52155
Changelog: [Internal]
Gating RN_SERIALIZABLE_STATE behind ANDROID flag so we can build ReactCommon with cmake when targeting different platforms.
This will help build reac-native-fantom for OSS.
Reviewed By: christophpurrer
Differential Revision: D77034689
fbshipit-source-id: 15f9192c90693f4743f31fcf72f593802b622c47
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52110
## Changelog:
[General] [Internal] - Add Fantom test for layout props
With this test it turns out `layoutStyleUpdated_` on PropsAnimatedNode actually can change after animation update, because its connected StyleAnimatedNodes might be changing. This bug was introduced since D74602321
Reviewed By: rshest
Differential Revision: D76753864
fbshipit-source-id: 5bebb11340086390df20c89adf80abaa63cadc90
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52143
Noticed that some of the `IndexOutOfBoundsException` crashes we've been tracking we're not being reported as soft errors because they were not running wrapped by the RN ExceptionHandler
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D77017423
fbshipit-source-id: 760297a0c5ee3d58577931829a31d312dacffdf1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52111
Changelog: [Internal]
JSRuntime integration with executor on messagequeue.
Inching closer to full integration with the rest of RN.
Reviewed By: rshest
Differential Revision: D76752667
fbshipit-source-id: 0ef8fe0c615dc1eb45355f7502e01663772ebf13
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52112
Adding `shouldForwardToReactInstance` check in Bridgeless since it was missed in https://github.com/facebook/react-native/pull/43351
**Changelog:**
[ANDROID][FIXED] - Adding `shouldForwardToReactInstance` check in ReactDelegate for Bridgeless
Reviewed By: cortinico, javache
Differential Revision: D76908041
fbshipit-source-id: 20b8fce248d8e560ab862cf325b6f8b15be870e3
Summary:
this PR makes the stale bot messages a bit clearer and fixes a grammatical issue.
# Changelog:
[INTERNAL] [FIXED] Tweak stale bot messages
Pull Request resolved: https://github.com/facebook/react-native/pull/52124
Test Plan: N/A
Reviewed By: andrewdacenko
Differential Revision: D76969503
Pulled By: cortinico
fbshipit-source-id: d030a0488b44521f61447e252bae5ded10826dbb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52130
After D73948178, Modals now need to access JNI to get the dimension of the
screen to properly position the modal on first rendering.
Before my change, the Modal was positioned in 0,0 (which is the default
behavior for CXX).
I'm suppressing this test for Android, as it will keep on running with the
previous behavior for CXX.
Changelog:
[Internal] [Changed] -
Reviewed By: javache
Differential Revision: D76979787
fbshipit-source-id: 78675712f97baee29036f943b2a8bcd23047e4ed
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52131
This class is not used in OSS and can be made internal.
Changelog:
[Internal] [Changed] -
Reviewed By: javache
Differential Revision: D76979122
fbshipit-source-id: 2d81e3605e6c51336b3bdb2671dd9faf8f25639b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52132
This is yet another class that is getting converted from Java to Kotlin.
Changelog:
[Internal] [Changed] -
Reviewed By: javache
Differential Revision: D76979123
fbshipit-source-id: d1fc54e61d64b78a56cf0198ae5fe588702a8698
Summary:
This PR replaces Core Graphics implementation with Core Animation for linear gradients. I came across a great [solution](https://stackoverflow.com/questions/38821631/cagradientlayer-diagonal-gradient/43176174#43176174) that makes the `CAGradientLayer`'s start and end point behaviour CSS spec compliant. This will make gradients much more performant.
## Changelog:
[IOS] [CHANGED] - Optimised Linear Gradients.
<!-- 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/52096
Test Plan:
Non breaking change. Test Linear gradient example from RNTester. Compare results with web, android and iOS. Each platform should render the gradients identically.
## Note:
I will be doing a PR to use `CAGradientLayer` for radial gradients as well. The next properties that I have locally working are `background-size`, `background-position` and `background-repeat`. These will be addressed in small PRs.
Reviewed By: NickGerleman
Differential Revision: D76905215
Pulled By: javache
fbshipit-source-id: 0094bdf70869d619272d491dd496983316b0dbf0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52129
This remove all the usages of SafeAreaView from RNTester.
The problem is that we introduced a warning that SafEAreaView is deprecated and, therefore, we had a warning in debug mode.
This was causing a yellow bubble to appear and the OSS E2E test started failing.
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D76978227
fbshipit-source-id: c45a31bae1602bc307e4fbbd71e7987a8ed78858
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51048
Fixes https://github.com/facebook/react-native/issues/50442
Closes https://github.com/facebook/react-native/pull/50704
Users reported that Modals on Android are first renderer anchored in 0,0.
That results in them being on the top left corner of the screen for some seconds.
This is happening because the native state of the Modal on Android as width/height set at 0,0 - which we then update in a subsequent callback.
I'm fixing this by making sure we render the Modal the first time with the right screen size - the status bar size
Changelog:
[Android] [Fixed] - Fix Modal first frame being rendered on top-left corner
Reviewed By: javache
Differential Revision: D73948178
fbshipit-source-id: 055c12aa62d70acc1e4c5a2a5c4ea0c5608e22c7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52127
Currently using `react.internal.useHermesNightly` is broken locally because we try to search for versions such as 0.0.0.+ while the nightlies version are of the form 0.81.0-...
This fixes it.
Changelog:
[Internal] [Changed] -
Reviewed By: NickGerleman
Differential Revision: D76901197
fbshipit-source-id: 51f7b2e7ec936aace67d4d62a8019554800347fc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52102
Changelog: [internal]
This ships the variant of IntersectionObserver that integrates directly with the Event Loop, avoiding dispatching notifications during observation and waiting for the end of the Event Loop tick instead. Also cleans up all the associated feature flags.
Reviewed By: lenaic
Differential Revision: D76892649
fbshipit-source-id: 9364b43a4d60b75c25b9a2d6ced7937b03376b04
Summary:
Static code analysis reports 18 warnings for incorrect usages of the `VisibleForTesting` annotation as some of the classes/functions/properties that are annotated are not used only in tests but also in other non-test files across the codebase. This PR cleans that up to fix those warnings.
## Changelog:
[INTERNAL] - Clean up incorrect VisibleForTesting annotation usages
Pull Request resolved: https://github.com/facebook/react-native/pull/52025
Test Plan:
```sh
yarn test-android
yarn android
```
Reviewed By: rshest
Differential Revision: D76745241
Pulled By: sbuggay
fbshipit-source-id: 4702a7258002916cc95c178dc8931c8bb471f7bc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52120
It is pretty jarring for semantically different labels to be read all at once, let's comma separate them - which VoiceOver will pause at. Android does this by default with its coopting implementation
Changelog: [Internal]
Reviewed By: jorge-cab
Differential Revision: D76921000
fbshipit-source-id: afe1f93e38babde918137576d0693c1579101ef7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52093
This change updates the `BaseViewManager` implementation to drop and restore the original focus listener when a view instance has its `onDropViewInstance` method called. This is necessary to support view recycling, since the `addEventEmitters` method is called each time a recycled view is popped out of the stack. This would result in N+1 `onFocus`/`onBlur` calls for each time the view is recycled.
Changelog: [Android][Fixed] - Remove focus change listener when dropping/recycling view instances
Reviewed By: NickGerleman
Differential Revision: D76852137
fbshipit-source-id: 9e980e7a1850a952baf04724bc251ff32186c6fa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52106
Changelog: [internal]
This slightly improves the formatting of the output produced by benchmarks, so we can just copy&paste the result to share it as valid Markdown.
Reviewed By: christophpurrer
Differential Revision: D76898244
fbshipit-source-id: dc1040ee3787c7f0dcb747c9fba8eb14086a0087
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52105
Changelog: [internal]
I just learnt there's a Hermes variant that we don't support (staging) so this adds support for it.
Reviewed By: christophpurrer
Differential Revision: D76897715
fbshipit-source-id: 3113edde3c785d71ad4a57dd435f16e13ab46976
2025-06-18 09:36:36 -07:00
726 changed files with 33615 additions and 22498 deletions
stale-issue-message:'This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.'
stale-pr-message:'This PR is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.'
stale-issue-message:'This issue is stale because it has been open for 180 days with no activity. It will be closed in 7 days unless you comment on it or remove the "Stale" label.'
stale-pr-message:'This PR is stale because it has been open for 180 days with no activity. It will be closed in 7 days unless you comment on it or remove the "Stale" label.'
close-issue-message:'This issue was closed because it has been stalled for 7 days with no activity.'
close-pr-message:'This PR was closed because it has been stalled for 7 days with no activity.'
exempt-issue-labels:'Help Wanted :octocat:, Good first issue, Never gets stale, Issue:Author Provided Repro'
"description":"Package that includes native module exapmle, native component example, targets both the old and the new architecture. It should serve as an example of a real-world OSS library.",
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
