Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53936
Align with other mount items and make it easier to identify in memory traces.
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D83241794
fbshipit-source-id: 9df1523e265e560c15f93bad8cd91a651bc5a4e2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53923
Motivated by feedback on D83070252. This prevents us from including decodable information about debug targets in these values.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D83139401
fbshipit-source-id: 01b01d23e4dfb06e400729b8cedf1fe2e098b209
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53921
Changelog: [Internal] `devMiddleware` removed the unused option `projectRoot`
This option was used only in a dead branch of the code inside `InspectorProxy`.
The scenario where it appeared was enabling resolving script sources (`Debugger.getScriptSource`) starting with `file://` which were coming from the file system. However, we don't seem to ever point scripts at the filesystem this way.
Reviewed By: huntie
Differential Revision: D82739662
fbshipit-source-id: 9a130eaa83cb94ae0e36a5a1102c56ff8a36cffc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53914
Pulls hysteresis window computation out of for loop. Simplify the remaining code.
Changelog: [Internal] - Same as general summary.
Reviewed By: lunaleaps
Differential Revision: D83005735
fbshipit-source-id: 824863c649406a750d44b31ac92878505ab61596
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53900
# Changelog:
[Internal] -
There is a crash reported, which looks like it may be potentially caused by some scenarios when we are trying to execute a scheduled task after the TaskDispatchThread instance had been quit.
This adds a missing extra check in the corresponding code to avoid such scenarios.
Reviewed By: christophpurrer, lenaic
Differential Revision: D83050169
fbshipit-source-id: 0ee0fa5848b070c2dc3dd92dbad4e6d5996734b3
Summary:
Since the view recycling is optional on iOS [since 0.74](https://github.com/facebook/react-native/commit/613a5a75977d84333df7cbd5701e01a7ab5a3385) when a view (with disabled view recycling) is unmounted / destroyed there is no lifecycle callback for a component view to notify it of such event. Currently we (`react-native-screens`) are forced to scan mutation list of every mounting transaction in every of ours container components. Components with view recycling turned on, get `prepareForRecycle` callback on Fabric & on old architecture, there was `invalidate` message sent (`RCTInvalidating` protocol). It would be nice & useful to have something like this for components with view recycling disabled, or enabled but not recycled due to pool being full.
In particular in `react-native-screens` we need an information that the component is being destroyed to release retained resources (view controllers & others).
I have concern regarding naming of this method, as it could collide / be mistaken with `invalidate` method of `RCTInvalidating` protocol, but naming is hard & I don't see a name that fits better 😄 Open for suggestions!
## 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
-->
[IOS] [ADDED] - Add invalidation callback for non-recycled component instances
Pull Request resolved: https://github.com/facebook/react-native/pull/53708
Test Plan:
Apply this patch to `RNTMyNativeViewComponentView.mm`:
```objective-c
diff --git a/packages/rn-tester/NativeComponentExample/ios/RNTMyNativeViewComponentView.mm b/packages/rn-tester/NativeComponentExample/ios/RNTMyNativeViewComponentView.mm
index 2eb7bff28e..8464da603b 100644
--- a/packages/rn-tester/NativeComponentExample/ios/RNTMyNativeViewComponentView.mm
+++ b/packages/rn-tester/NativeComponentExample/ios/RNTMyNativeViewComponentView.mm
@@ -123,6 +123,16 @@ using namespace facebook::react;
[_view removeOverlays];
}
+- (void)invalidate
+{
+ NSLog(@"RCTComponentViewProtocol invalidate called");
+}
+
++ (BOOL)shouldBeRecycled
+{
+ return NO;
+}
+
- (void)fireLagacyStyleEvent
{
RNTMyNativeViewEventEmitter::OnLegacyStyleEvent value = {"Legacy Style Event Fired."};
```
& render `MyNativeView` in any of the RNTester screens / examples. Unmount the view & observe the log in XCode.
https://github.com/user-attachments/assets/be3f67bb-73e0-4af2-9ca1-f2eb9f3347bb
(called twice, because there are two components rendered at a time)
Reviewed By: javache
Differential Revision: D83139361
Pulled By: cipolleschi
fbshipit-source-id: 17ef964648ac44b583503b6b00fc5dd457887061
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53911
This change mimics what we implemented on Android to crash the app.
This is in general never going t be triggered. It will be triggered only if users are actually going through the old way to initialize React Native, i.e. by using the RCTRootView class which creates thebridge, or if they are creating the bridge themselves.
## Changelog:
[iOS][Added] - Crash the app if they force the legacy architecture.
Reviewed By: RSNara, cortinico
Differential Revision: D83066377
fbshipit-source-id: 0907effceb9a3655ec8d6bde8e0986f50f1ab663
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53878
Changelog: [Internal]
Adds the `prebuiltBinaryPath` option to `unstable_spawnDebuggerShellWithArgs` and `unstable_prepareDebuggerShell`, for advanced integrations that need to change how the React Native DevTools prebuilt binary is distributed.
Reviewed By: huntie
Differential Revision: D82956699
fbshipit-source-id: 30f9c461c7d8f22a553f278bbe42b86742c98da7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53890
Changelog: [Internal] - Adds support for VirtualView v2 in Android HorizontalScrollView native component by implementing VirtualViewContainer interface. Only on Android because iOS equivalent native components are already set up to support virtualview v2 on horizontal scrollviews.
## Changes in Detail
Adds necessary changes to Android `HorizontalScrollView` native component to support the experimental version of VirtualView.
Reviewed By: lunaleaps
Differential Revision: D82783403
fbshipit-source-id: 1e55eb054ab098af5ca8dd526b27c574025943c4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53829
Forwards along focus and blur calls to their respective native commands, leaving the TextInput path intact for now.
There are a few ways places to implement this, all with different trade offs. I decided to leave TextInputState.js intact and instead only go down the original path if the focused/blurred element is a TextInput by using the registered inputs in TextInputState. This revealed a subtle issue where the TextInputs aren't registered in time for the ref callback, meaning you can't focus them there if you rely on the registered list.
Changelog: [Internal]
Reviewed By: shwanton
Differential Revision: D82676628
fbshipit-source-id: d39c92dfc99ec4b5e100203bb43c8a4f9c80a649
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53912
Changelog: [Internal]
Add new fantom flag `fantom_disable_coverage` to be used in tests that are sensitive to things like memory allocation.
Also disable coverage for any benchmark test.
Reviewed By: arushikesarwani94
Differential Revision: D83070065
fbshipit-source-id: a885e79e3d0c88cfb7adef30cb60ab46a617edac
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53904
Adds more transparency to the background of the perf overlay, we got some feedback about it visually obscuring elements behind it.
{F1982191377}
{F1982191388}
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D83037721
fbshipit-source-id: e70c799ea7942c6aea886e9a3580e324c4238048
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53905
Updates `PerfMonitorOverlayManager` so that it is minimally and correctly integrated in the `DevSupportManagerBase` reload cycle — attempting to fix a bug where the background profiling state on startup / subsequent packager connections would be out of sync.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D83058519
fbshipit-source-id: 9a9bb32d3215ccf722aa39ca0ca943449f7ae62e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53885
Changelog: [General][Added] DevServer banners can now be closed on tap. On iOS, don't close them after 15s anymore.
Banners, on iOS, but not Android, are currently closed after 15s since {D47478373} where it was introduced to deal with the banner telling users they need to connect to Metro stuck forever.
Instead of closing it after 15 seconds, allow the users on both Android and iOS to close it via a touch.
Reviewed By: huntie
Differential Revision: D82727997
fbshipit-source-id: 5aa2af78a4dbcd95b69423d52421900d4ab35244
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53784
LayoutAnimation is part of legacy architecture, I'm deleting the code used from its non supported public APIs
changelog: [internal] internal
Reviewed By: shwanton
Differential Revision: D82235545
fbshipit-source-id: 9665c57b68eba9d958d3f8b9dd4224558cc8e9f6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53884
Changelog: [Internal]
Now that there's a clear display for when HMR is disconnected, we don't want to show messages regardless devices connection and disconnection to the DevServer because they are too partial.
Reviewed By: huntie
Differential Revision: D82727105
fbshipit-source-id: 32dd077f85d2044f89ae2d8d60a37c0ec6cccbbf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53883
Changelog: [General][Added] - new banner added to indicate that Fast Refresh has lost connection, and that the app needs to be restarted to reconnect
When HMR were getting disconnected, we were not giving any indication for the user.
This lead to situations were the connection is re-established, but HMR is still disconnected, which is unexpected for users.
Instead, raise a banner hinting the user to reload the app to reconnect.
Reviewed By: huntie
Differential Revision: D82726853
fbshipit-source-id: d5f264547b2af89e9dc2a9046d063efe1145d690
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53846
Changelog: [Android][Added] - hot reload banner is now displayed in blue background like on iOS
iOS has a colorful "Refreshing..." banner:
{F1982086204}
While android doesn't respect the color HMR asks it to set up for the banner:
{F1982086218}
Reviewed By: cortinico
Differential Revision: D82726743
fbshipit-source-id: 4042851f5a8fd7d4f238f25e2d83f77144742de9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53881
Changelog: [Internal]
To make sure that coverage is insertect correctly when run in different metro setup where patterns do not match perfectly, we need to add glob prefix
Reviewed By: sammy-SC
Differential Revision: D82968565
fbshipit-source-id: c2676ef4c774411938039fc5b98a3b953f6ec916
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53642
## Context
One of the quirk of SwiftPM is that the packages has to have access to the headers they need. Usually this is solved by properly setting the header_search_path. However, in SwiftPM, we are not allowed to use headers search path that escape the package itself (basically, header search path can't start with `../`).
To work around this limitation we are recreating the correct Header structure by using hardlinks to the actual headers.
## Changed
In this change we are adding a function that is used to orchestrate the helpers function defined in previous changes.
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D81778457
fbshipit-source-id: b4ab8c902d6d7e6ca4b89ccbab75c1b5d84ce00a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53640
## Context
One of the quirk of SwiftPM is that the packages has to have access to the headers they need. Usually this is solved by properly setting the header_search_path. However, in SwiftPM, we are not allowed to use headers search path that escape the package itself (basically, header search path can't start with `../`).
To work around this limitation we are recreating the correct Header structure by using hardlinks to the actual headers.
## Changed
In this change we are adding an helper function to create hard links to Codegen Headers so that other libraries can access them.
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D81778450
fbshipit-source-id: e9f62f1c81ce8a635cc880007f495de342342a25
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53638
## Context
One of the quirk of SwiftPM is that the packages has to have access to the headers they need. Usually this is solved by properly setting the header_search_path. However, in SwiftPM, we are not allowed to use headers search path that escape the package itself (basically, header search path can't start with `../`).
To work around this limitation we are recreating the correct Header structure by using hardlinks to the actual headers.
## Changed
In this change we are adding an helper function that creates links for the ThirdPartyDependencies that React native and libraries might need to access.
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D81778459
fbshipit-source-id: b8f9f207a0fbe2265e2861bf508516946905b472
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53635
## Context
One of the quirk of SwiftPM is that the packages has to have access to the headers they need. Usually this is solved by properly setting the header_search_path. However, in SwiftPM, we are not allowed to use headers search path that escape the package itself (basically, header search path can't start with `../`).
To work around this limitation we are recreating the correct Header structure by using hardlinks to the actual headers.
## Changed
In this change we did two things:
1. we move the helper functions to a headers-utils.js file (and the tests to the `headers-utils-test.js` file)
2. we added a function that coordinates the creation of the header links *and added tests for it)
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D81778464
fbshipit-source-id: fd8eb5a7af55db0a08c4d299c5470058d5424768
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53631
## Context
One of the quirk of SwiftPM is that the packages has to have access to the headers they need. Usually this is solved by properly setting the header_search_path. However, in SwiftPM, we are not allowed to use headers search path that escape the package itself (basically, header search path can't start with `../`).
To work around this limitation we are recreating the correct Header structure by using hardlinks to the actual headers.
## Changed
In this change we are adding an helper function that creates links for the ReactCommon folder that has a complex structure and complex mapping requirements
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D81778470
fbshipit-source-id: e0f4001048fcde0e988fc3a05b53efb1de70460b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53629
## Context
One of the quirk of SwiftPM is that the packages has to have access to the headers they need. Usually this is solved by properly setting the header_search_path. However, in SwiftPM, we are not allowed to use headers search path that escape the package itself (basically, header search path can't start with `../`).
To work around this limitation we are recreating the correct Header structure by using hardlinks to the actual headers.
## Changed
In this change we are adding a function to properly create the header structure for the headers in ReactApple that requires a special case.
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D81778471
fbshipit-source-id: 095d901dce139cf8221251f952f474be943a5ab3