Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53840
After this diff, successful network events are displayed as fully hydrated timespans in the Performance panel network track, with all metadata needed to usefully populate the UI.
**Changes**
Adds:
- `"ResourceFinish"`: `encodedDataLength`, `decodedBodyLength`
- `"ResourceReceiveResponse"`: Populates `data.timing` members, which enables *"Request sent and waiting"* to be rendered correctly in the timeline.
Removes:
- `"ResourceWillSendRequest"` events — very rarely emitted by Chrome and are extraneous for our use case.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D82636798
fbshipit-source-id: a4b0f0671b97aaadc279ac56d39fee0c95d4ddc7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53817
What is currently happening, is that the various commits on the release branches like `0.82-stable` are resetting the version of native artifacts to `1000.0.0-<SHA>`.
The reason is that during the `test-all` workflow, we pass the `dry-run` as release type.
That's to prevent the various tools from calling `npm publish` and so on.
The problem is that on the releases branches, the version was already set at branch cut time.
Therefore, we see the version 1000.0.0 reappearing during Android E2E test in the emulator. Similary this is also affecting iOS prebuilds so I'm attempting to fix it here.
Changelog:
[Internal] [Changed] -
Reviewed By: huntie
Differential Revision: D82553599
fbshipit-source-id: 31a52e7df036e700663b3d3dd677973a7a210a30
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53842
Changelog: [Internal]
There is a conflict between dotslash in node_modules and in OD it does not invoke buck2
Reviewed By: javache
Differential Revision: D82724326
fbshipit-source-id: c90cab58818e0245f8763b729c7e5432735eb05e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53838
The FPS listener is being assigned to all scroll view instances by the scroll view manager. This listener should not be reset when the view is being recycled and should stay assigned at all times.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D82720151
fbshipit-source-id: a2a37bad93efaa6e435725adf16c9ad1b4207ba0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53794
Basically what the title says. This is needed by Expo for experimetation.
Changelog:
[Internal] [Changed] -
Reviewed By: joevilches
Differential Revision: D82530292
fbshipit-source-id: 82ce8b1e8fc8d954cc04ec456ad80f769aedafe7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53795
I've published another docker image that should now work and unblock `run_fantom_tests`
so we don't need to pin the version to `v18.0` anymore:
https://github.com/react-native-community/docker-android
Changelog:
[Internal] [Changed] -
Reviewed By: huntie
Differential Revision: D82532516
fbshipit-source-id: 980c2feb053f9d096e70f37bb690e18cc8b87dc0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53776
Refactor and improve how we emit CDP trace events for network requests.
Key changes:
- Split up `PerformanceTracer` methods into discrete trace events.
- Move event calls out of `PerformanceEntryReporter` (upwards) into `NetworkReporter`. This now:
- Aligns better with the matching source `NetworkReporter` events.
- Removes metadata pieces from `PerformanceEntryReporter` that weren't part of the Web `PerformanceResourceTiming` API.
- Populate additional fields on `ResourceReceiveResponse`.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D82433225
fbshipit-source-id: 4fce219f0c86a7257b8df250ef9f2b4ec8bd8de3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53807
We need to read the values off feature flags before checking them.
## Changelog
[Internal]
Reviewed By: javache
Differential Revision: D82572898
fbshipit-source-id: 09fbc09570c78b41d9c25fb03c5557e390da7cae
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53780
This is a commit we're going to pick in 0.82 as we want to make sure users cannot invoke `load()`
from `DefaultNewArchitectureEntryPoint` with flags that are not true,true,true.
Changelog:
[Android] [Changed] - Runtime check that NewArchitecture is enabled in DefaultNewArchitectureEntryPoint
Reviewed By: mdvacca
Differential Revision: D82456975
fbshipit-source-id: 749996a3491913cfe400173608218077c3ffbc10
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53735
This class should have been marked as LegacyArchitecture back then but was forgotten.
I'm doing it now.
Changelog:
[Internal] -
Reviewed By: javache
Differential Revision: D82219780
fbshipit-source-id: 5119b7469733d5d2d4b16e976b09231ad5f71f5f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53775
A refactor to align our C++ code style within `jsinpector-modern`.
We prefer `std::string` and `const std::string&` everywhere (see [C++ Core Guidelines F.15](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rf-conventional)), except for when we are handing potentially very large strings — in which case we must use `string_view` all the way down.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D82446939
fbshipit-source-id: 4b1c43068d1339f4b4a4c7eb06b392d0b0f624e1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53788
Fix thread safety issue due to member variable in `NetworkHandler` singleton without mutex.
Also intend to un-singleton this class in the imminent future.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D82460574
fbshipit-source-id: c0c614f8f1bb5ffba22872ae5717fbd2ca01f2e9
Summary:
The `--otp` flag is completely unused now, therefore it can be removed.
We don't pass the `NPM_CONFIG_OTP` env variable either as this was done back in the days of CircleCI so I'm cleaning this up.
## Changelog:
[INTERNAL] - Remove unused --otp property from release infrastructure
Pull Request resolved: https://github.com/facebook/react-native/pull/53779
Test Plan: CI
Reviewed By: lunaleaps
Differential Revision: D82453539
Pulled By: cortinico
fbshipit-source-id: 84a6b82a037c754165c21e17976dc534d9a7ba4c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53793
## Changelog:
[Android] [Deprecated] - Clean up batchingControlledByJS in NativeAnimated kotlin
`start/finishOperationBatch` will no longer be called on kotlin NativeAnimated since D78005971 (https://github.com/facebook/react-native/pull/52521), so `batchingControlledByJS` will remain false. Cleaning up some logic and TODO comments there
this feature was added in D23010844
Reviewed By: christophpurrer
Differential Revision: D82461457
fbshipit-source-id: a1208720b83e614c2a5f994ec1a5005189c5f197
Summary:
As per the discussion on the previous [PR thread](https://github.com/facebook/react-native/pull/52028#issuecomment-2979481948), this PR uses `SwiftUI` to implement blur filter on iOS.
## Approach:
To implement blur filter on iOS, we have two options:
1. Use `CAFilter` (private API, app can get rejected/API can break). Earlier [PR](https://github.com/facebook/react-native/pull/52028) was using that approach. Thanks to Nick for suggesting SwiftUI API.
2. Use `SwiftUI`. Wrap the view in a SwiftUI view and apply [blur](https://developer.apple.com/documentation/swiftui/view/blur(radius:opaque:)). This PR builds on top of that approach. This also enables a way to add `SwiftUI` only features like this one. Additional filters (grayscale, saturate, contrast, hueRotate) can also be added.
There are a few ways we can implement the SwiftUI approach:
1. Create a new `RCTSwiftUIComponentView` -> do style flattening in View -> check if `filter` is present and conditionally render the `RCTSwiftUIComponentView` on iOS, wrap children with a `SwiftUI` view. Tradeoff with this approach is that it adds `StyleSheet.flatten` overhead on JS side.
2. Add a `SwiftUI` container view inside of `RCTViewComponentView`. Tradeoff with this approach is that it complicates `RCTViewComponentView` a bit.
I decided to go with **2** to avoid the flattening tradeoff and try to minimize complicating `RCTViewComponentView`. it only adds the wrapper if it's required and removes if not (in this PR, blur filter style will add the wrapper, it will get removed if blur filter styling gets removed). It uses the existing container view pattern.
## Changelog:
[IOS][ADDED] - Filter blur
<!-- 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/52495
Test Plan:
Test filter blur example on iOS. SwiftUI view should be added to the hierarchy.
<img src="https://github.com/user-attachments/assets/742539f4-a96d-45f4-94ba-5eb588d0ad5a" width="300px" />
## Aside:
- This PR also adds a new swift podspec. Creating a new podspec felt the right approach as adding swift in existing ones were adding some complexity. But open for changes here. Also, need some eyes on the podspec configs. cc - chrfalch 🙏 this might also affect the SPM migration.
- Unrelated: Existing brightness filter has some inconsistency compared to android and web, it uses [self.layer.opacity](https://github.com/facebook/react-native/blob/6892dde36373bbef2d0afe535ae818b1a7164f08/packages/react-native/React/Fabric/Mounting/ComponentViews/View/RCTViewComponentView.mm#L1008) so transparent background color do not blend well unless the view has an opacity. One solution would be to calculate true background color by using brightness or else use the `SwiftUI`'s [brightness](https://developer.apple.com/documentation/swiftui/view/brightness(_:)), which would be cleaner imo (tested and it works).
Reviewed By: cipolleschi
Differential Revision: D79666764
Pulled By: joevilches
fbshipit-source-id: 05e43d75ce7b6f25b67b4eed632524a559ea1c2e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53771
# Changelog: [Internal]
Instead of opening DevTools every time we emit a background trace, we are going to check if there is an active session with Fusebox client and will send it to the first one registered.
Reviewed By: huntie
Differential Revision: D82321146
fbshipit-source-id: 46b4d090ae9a6f8b4fc98181b303ff552c561eb8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53760
# Changelog: [Internal]
This is a different approach from the one that I've introduced initially in [1].
This saves us from the scenario, where any local session could snatch the stashed trace recording. For example, if some session was created for a Runtime binding right after we've stashed the trace and before initializing real CDP session with the Frontend.
Reviewed By: huntie
Differential Revision: D82316584
fbshipit-source-id: 806a0f6dbdb4e4e928ce33af228cae86d43772e9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53755
Changelog: [iOS][Fixed] Make `RCTSetDefaultFontHandler` compatible with the new arch, and add a more powerful version as `RCTSetDefaultFontResolver`
Reviewed By: fkgozali
Differential Revision: D82207676
fbshipit-source-id: eeeaf708491de9156ef4f1e045864e4322213902
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53777
Expose `unstable_NativeText` and `unstable_NativeView` components as root exports of the `react-native` package.
These are exposed as `unstable_` APIs which have no semver guarantee.
**Motivation**
There is significant community interest / dependance on the currently private `TextNativeComponent` and `ViewNativeComponent` deep imports, to access the faster-performing inner versions of these UI components.
Using `<Text>` and `<View>`, while recommended and stable, has led to measurable performance overhead in some apps when compared with these `<Native*>` counterparts.
Notably, these APIs are also referenced by low-level libraries such as React Strict DOM.
I am proposing this change in order to:
- Unblock libraries which safely use these.
- Meet users where they are at.
- Unblock us from enabling the Strict TypeScript API (no deep imports).
References:
- https://github.com/react-native-community/discussions-and-proposals/discussions/893#discussioncomment-13452047
- https://javascript.plainenglish.io/optimizing-text-component-rendering-in-react-native-b9d3565659d9
- https://github.com/search?type=code&q=react-native%2FLibraries%2FText%2FTextNativeComponent
**Ideal future state**
We are exposing these as unstable APIs because they should not be part of React Native's final API. The ideal end state is we improve the regular `<Text>` and `<View>` components to eliminate performance overhead and the need to access any lower level API.
Changelog:
[General][Added] - `unstable_NativeText` and `unstable_NativeView` are now exported from the `react-native` package
Reviewed By: javache
Differential Revision: D81588145
fbshipit-source-id: 2ea9b7f822286de85f49607944c6a484d1fcf242
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53761
Updates `NetworkReporter` and `PerformanceEntryReporter` to populate (minimal) `"ResourceSendRequest"` and `"ResourceFinished"` events when a CDP performance trace is active. This allows the Chrome DevTools Performance panel to display the "Network" track.
**Notes**
- The trace events that Chrome requires need extra fields which aren't present on `PerformanceResourceTiming`, hence the new + optional `devtoolsRequestId`, `requestMethod`, `resourceType` params. We only populate these in debug builds.
**Limitations**
- We emit a *complete trace event set* within `reportResourceTiming`, implementing basic initial support in the Performance panel Network track. This means 1/ either all/no events are sent for a given request (rather than incrementally), 2/ we aren't yet handling failed/cancelled requests in this pipeline.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D82212362
fbshipit-source-id: 4c6d5d2510cc98ddc819a2778222b835411295c8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53746
ScreenshotTestsManagerModule and ReactAppScreenshotTestActivity are not in use anymore, let's delete them
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D82249453
fbshipit-source-id: 73b0f2ef2e9a5370057c07c3bee03f9c0793d61a
