Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43129
## Changelog:
[Internal] -
C++ side expects "source" property to be an up to date, correctly resolved Image source inside `ImageProps`.
Incidentally, it wasn't the case when:
* we build for an Android platform
* the asset is a "packager asset", i.e. bundled by Metro and included in APK
It hasn't been an issue in the case of "pure" Android platform, as it instead uses "src" prop, instead of source on the Java implementation side, ignoring "source" completely, so the fact that "source" wasn't propagated correctly to C++ in some cases didn't affect Android.
However, there are some new use cases where we'd like to have correct "source" value in C++ as well (and ultimately align this between all the platforms, so it's "source" everywhere, but this is a matter of a separate discussion).
Differential Revision: D54000899
fbshipit-source-id: 9bfb9e7c157cf19ddf396c141b03b75f3b2022e8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43118
While debugging issues with precompiled_headers in Instagram, it became apparent that these RN files don't correctly import the necessary files to make them build on their own. Fix that!
Changelog: [iOS][Fixed] Fixed missing header imports
Reviewed By: fkgozali
Differential Revision: D53963676
fbshipit-source-id: 74e9758153f6176133475e45d27f7644d1a6dece
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43023
Unused mobile config, and is not consistently used across all the many places we can initialize a Hermes instance.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D53761942
fbshipit-source-id: a3e1adae87e41142c337a27b33750f82774cf92c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43114
Changelog: [iOS][Breaking]
PR#42628 introduced new behavior on how the react native infra tracks local notifications that start the app. in this PR, we are officially deleting the old implementation.
Reviewed By: ingridwang
Differential Revision: D52931617
fbshipit-source-id: 3b77479b0aacf239e45cfcc7d7c4b20e82e0b786
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43113
Changelog: [Internal]
Renames the "Page" concept in the modern CDP backend to "Host". Now all the Target types we have are named consistently after React Native concepts (ReactHost, ReactInstance, JSI Runtime) rather than CDP/browser concepts (Page).
Reviewed By: robhogan
Differential Revision: D53945333
fbshipit-source-id: 90e8b914ba8b4927806cbdd072ca36c78fd2093f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43049
This connects the OnLoad.cpp file used by OSS apps with the `rncli_cxxModuleProvider`.
This method is created by the CLI and takes care of querying all the TM CXX Modules discovered and returning them.
This PR is currently waiting on https://github.com/react-native-community/cli/pull/2296
Changelog:
[Internal] [Changed] - Hook the default-app-setup OnLoad.cpp file with the cxxModuleProvider from RNCLI
Reviewed By: cipolleschi
Differential Revision: D53812109
fbshipit-source-id: 47bc0ea699516993070cfa0127de97853acf8890
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43111
When mounting views in the interop layer, we register them in an array `reactSubview` that is added to `UIView`. However, when unmounting them, we were just removing them from the parent view.
This worked fine while the view we were adding to reactSubview was the same that we were adding to hierarchy. However, there are instances where libraries might wrap those views in some custom wrappers. This break the assumption that the same view we are adding to the UI hierarchy is the same view we will remove.
With this change, we make sure to use the same semantic when we add some view and when we remove it.
This also fixes a crash that happens with Mobile home when navigating away from the Ride's Map, using Fabric.
## Changelog
[internal] - Remove views from hierarchy using the view that is added to the `reactSubviews`
Reviewed By: sammy-SC
Differential Revision: D53943728
fbshipit-source-id: 56e669c14db74b6af683384b6ca72ad3f5cfdafe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43099
In all methods of FabricUIManager we check whether it's been destroyed before doing any logic, but we don't in this asynchronous method we're scheduling to report mounts.
This adds the check in that case as well to potentially fix some crashes we're seeing in current experiments for mount hooks on Android.
Changelog: [internal]
Reviewed By: sammy-SC
Differential Revision: D53920863
fbshipit-source-id: 3cc18cf5237d4866940739de80cc00604bcd0fb6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43070
**Context**
The `codegenNativeComponent` function is a hint for the codegen that the file that contains it is a Native Component spec. Static ViewConfig codegen overwrites this function call by the generated ViewConfig.
If this function is not overwritten by the codegen, it has runtime behaviour that falls back to `requireNativeComponent`. At the time when this system was built `requireNativeComponent` was not supported in Bridgeless mode because it is relied on some Bridge-only functionality. That's why it outputs error in Bridgeless mode.
---
This is not the case any more, we now have interop layers which provide the functionality needed by `requireNativeComponent`.
The SVC codegen is implemented as [Babel plugin](https://github.com/facebook/react-native/tree/main/packages/babel-plugin-codegen). The are scenarios when it is not run for the native component specs:
- If the plugin is not used for whatever reason.
- If Babel is not used for whatever reason.
In order to not to regress the DevX for such cases, we've turned the error into the warning.
**Note:** we use `console.info('⚠️...` instead of `console.warn('...`. That's because `console.warn` also prints a stack trace in the console, and we didn't want to create too much noise.
Changelog: [General][Changed] - codegenNativeComponent show warning and not error if not code generated at build time.
Reviewed By: huntie, rshest
Differential Revision: D53761805
fbshipit-source-id: c924c7668e6d2e45b920672b8a309221be767a73
Summary:
De-duplicate the logic for counting attachments.
This is a minor improvement in the context of my multi-PR work on https://github.com/react-native-community/discussions-and-proposals/issues/695.
## 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
-->
[INTERNAL] [CHANGE] - De-duplicate the logic for counting attachments
Pull Request resolved: https://github.com/facebook/react-native/pull/42596
Reviewed By: rshest
Differential Revision: D53917281
Pulled By: cipolleschi
fbshipit-source-id: cdb9bc834bddd7deffc60f33578464733982fedf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43105
This is a quality of like improvement for the project we create for the final users.
Codegen generates code in `rncore`, within `node_modules`. This is not the perfect approach but it is working so far.
To make it more robust, we added a small script in React-Fabric podspec to check that codegen run properly when building.
In this way, if a user run `yarn install` and, for any reason, react-native is regenerated, we can provide a better DevX to our users with an actionable message on how to fix the build problem.
##Changelog
[iOS][Added] - Add error message if codegen has not run properly
Reviewed By: cortinico
Differential Revision: D53927788
fbshipit-source-id: a01a33086e4a0a1b0ada6c83283a5fd3fb5ee3eb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43098
Changelog: [Internal]
Wraps Hermes's `CDPHandler::getState()` API in an engine-agnostic abstraction (`RuntimeAgentDelegate::getExportedState`).
An Agent's lifetime ends when its Target is destroyed, but it can occasionally be useful to persist some state for the "next" Target+Agent of the same type (in the same session) to read.
`RuntimeAgentDelegate` is polymorphic and can't just write arbitrary data to SessionState. Instead, it can now *export* a state object that we'll store and pass to the next `RuntimeTargetDelegate::createAgentDelegate` call.
Reviewed By: huntie
Differential Revision: D53919696
fbshipit-source-id: a8e9b921bc8fc2d195c5dddea9537e6ead3d0358
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43054
Changelog: [iOS][Android][Added] Experimental macro to autolink C++ turbomodules
This implementation is inspired by RCT_EXPORT_MODULE on iOS. We keep a global data structure that maps module names to a lambda that returns the C++ turbomodule. This will come with a hit to startup time. the only way to avoid that is a solution that does static analysis of the list of C++ turbomodules being linked to the library.
Reviewed By: fkgozali
Differential Revision: D53602544
fbshipit-source-id: 8ea49fa576dc718f44b1595b68ab7c606c2db605
Summary:
Changelog: [Internal]
Ports RN's Hermes CDP integration tests to `TYPED_TEST` so we can easily run them against a different Hermes engine adapter in another diff.
bypass-github-export-checks
Reviewed By: huntie
Differential Revision: D53810359
fbshipit-source-id: fb9717bbdc1346ed26b9c8796c13bac641bc5a60
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43091
Fix typo in unit test
Changelog:
[Internal] [Changed] - Fix typo in unit test
Reviewed By: mdvacca
Differential Revision: D53918471
fbshipit-source-id: 0453c01fab1dc04397058577ea61b50994124cf0
Summary:
Changelog: [Internal]
Hermes:
Adds the missing `validateExecutionContext` call to `Runtime.evaluate`.
React Native:
Adds an integration test case to cover the expected behaviour around targeting `Runtime.evaluate` by execution context.
bypass-github-export-checks
Reviewed By: huntie
Differential Revision: D53776532
fbshipit-source-id: 66676383ba5b373fdbf2deb8c75f22791b07e300
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43075
There is a `\` in the new_architecture.rb file that should not be there.
## Changelog:
[Internal] - remove unnecessary character
Reviewed By: cortinico
Differential Revision: D53886548
fbshipit-source-id: a614368bed9f467b80c3384e4adc4be2cbcaba2d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43081
When Hermes i used, it is hermes that provides JSI to React Native and not React-jsi.
This is required to fix the ODR violatons.
Dynamic frameworks requires that all the dependencies are declared explicitly, and missing the `hermes-engine` dependency was breaking the dependency graph.
## Changelog
[Internal] - Make JSIInspector depends o hermes-engine
Reviewed By: motiz88
Differential Revision: D53901016
fbshipit-source-id: a511719647e6203d082696fd572593fd851a1dde
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43065
Changelog: [Internal]
Implements support for [`Runtime.addBinding`](https://cdpstatus.reactnative.dev/devtools-protocol/tot/Runtime#method-addBinding) in the new RN CDP backend.
This implementation is mostly complete and matches Chrome's behaviour, but does not include the ability to target bindings by execution context (the optional `executionContextId` and `executionContextName` params) - that will come in a separate diff for ease of review/landing.
Incidentally, this diff also introduces the `JsiIntegrationPortableTest::expectMessageFromPage` helper, which allows us to "asynchronously" extract the contents of an expected message. For consistency and clarity, we refactor all the other `EXPECT_CALL(this->fromPage(), onMessage(JsonEq(...)))` assertions to use it as well.
Reviewed By: huntie
Differential Revision: D53266709
fbshipit-source-id: 046326acdf5dacc18e179e43589cdd2d012f353a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43064
Changelog: [Internal]
Aligns React Native's CDP backend with V8's behaviour of assigning a sequential ID (here unique within a given PageTarget) to each execution context.
Reviewed By: huntie
Differential Revision: D53776531
fbshipit-source-id: 950599c323f416e8180e42281d94ae9c00f15fb0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43063
Changelog: [Internal]
Moves the responsibility for managing CDP execution contexts out of the Runtime and into the Instance.
This includes the responsibilities to:
1. Assign execution context IDs/names
2. Emit events when execution contexts are created/destroyed
3. Route CDP messages to the correct Runtime
**Re 1:** We currently assign a *constant* execution context ID, which diverges from V8's implementation but is in line with what Hermes has done so far. I'll follow up separately to assign (locally) unique IDs, since this diff is long enough already.
**Re 3:** Right now, the message routing responsibility is mostly theoretical: only one Runtime exists at a time and "routing" can be done by RuntimeAgent simply deciding whether or not to act on a message (since it receives all messages by default and knows its own `ExecutionContextDescription`). True multi-Runtime / multi-context support is firmly a future concern, and we can revisit this ( = probably hoist more logic into Instance) when we get there.
In the `ExecutionContextNotifications` integration test we can see that a few minor bugs in the current Hermes-based implementation are fixed, and also that execution context management is now engine-agnostic (so we can use `JsiIntegrationPortableTest` instead of `JsiIntegrationHermesTest`).
Reviewed By: huntie
Differential Revision: D53759776
fbshipit-source-id: 50ac126789c95b25f845780df2c3346ec345d5d5
Summary:
While looking at another issue, I realized that in some cases the script was adding the same flags twice and it was leaving the RCT_NEW_ARCH_ENABLED behind.
## Changelog:
[iOS][Fixed] - Pass the right flags to libraries
Pull Request resolved: https://github.com/facebook/react-native/pull/43071
Test Plan: Fixed Unit tests
Reviewed By: huntie
Differential Revision: D53860576
Pulled By: cipolleschi
fbshipit-source-id: 1f6f4852df8d316293b93d7c5fbef09a249893a5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43060
When inestigating the reason why [`react-native-view-shot`]() ws not working, we realized that there are many libraries that follows this pattern:
```objc
[self.bridge.uiManager addUIBlock:^(RCTUIManager *uiManager, NSDictionary<NSNumber *, UIView *> *viewRegistry) {
if (UIView *view = viewRegistry[reactTag]) {
//do something with the View
}
}];
```
The problem is that, with the New Architecture, that view registry is usually empty, because the components are registered and tracked in another place.
This make many libraries stop working when used with the New Architecture.
This change introduces a class that behaves like a dictionary but that forward the calls to retrieve the view to the right place, in order to get the view that is needed.
Noticably, this approach allow us also to remove some shenanigans we were applying to make sure that the interop layer could access the views wrapped in it, so the current solution is more general and should work in multiple situations.
## Changelog
[iOS][Fixed] - Make sure that `addUIBlock` provides a Dictionary-look-alike object that returns the right views when queried.
Reviewed By: sammy-SC
Differential Revision: D53826203
fbshipit-source-id: 08d359676d69777b88fa9b18dc141187ac42dbce
Summary:
This is a preliminary change which converts RCTConvert to an objectiveC++ file. This is required by the next diffs in the stack.
## Changelog
[iOS][Changed] - Make RCTConvert an Objective-C++ (`.mm`) file in prep for DisplayP3 changes
Reviewed By: javache
Differential Revision: D53520228
fbshipit-source-id: cf45c42955401b4e14fe68221129077817b2598e
Summary:
This PR makes `__gitignore` file universal for Apple OOT platforms.
## Changelog:
[GENERAL] [CHANGED] - Make template's .gitignore file universal for OOT platforms
Pull Request resolved: https://github.com/facebook/react-native/pull/42963
Test Plan: CI Green
Reviewed By: NickGerleman
Differential Revision: D53674632
Pulled By: yungsters
fbshipit-source-id: cb510d9bd2ee6f1c39b77a842e7947b67def552a
Summary:
This PR fixes PerfMonitor option not showing on iOS when running bridgeless. The `initialize` method is not called in bridgeless which causes this option to not be added. I've converted this approach to work for both bridgeless and non-bridgeless.
bypass-github-export-checks
## Changelog:
[IOS] [FIXED] - Perf Monitor option not showing in Bridgeless
Pull Request resolved: https://github.com/facebook/react-native/pull/42891
Test Plan: Run RNTester, open Perf monitor
Reviewed By: RSNara
Differential Revision: D53518507
Pulled By: cipolleschi
fbshipit-source-id: c16d41006c5a3f96d53d4f76fd317941a1eb839f
Summary:
When analyzing the `hitTest:withEvent` function, I realized that we were not forwarding the touches to the legacy view.
The previous algorithm was returning the InteropLegacyWrapper view itself when the touches were happening in the legacy view, preventing the handlers attached to the legacy view to fire.
With this change, if the legacy view receives a touch, it can handle it.
## Changelog
[iOS][Fixed] - Make sure to forward touches to the wrapped component in the InteropLayer.
Reviewed By: sammy-SC
Differential Revision: D53806218
fbshipit-source-id: 87b0aa6e900935092e6f5e1533b871c1d224b718
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43018
Assuming that if View is a ViewGroup, its ViewManager is a ViewGroupManager is incorrect. Custom ViewManagers may use ViewGroups internally to represent complex views exposed to JS.
Type-check the ViewManager instead to avoid the crash seen in T178300877
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D53586565
fbshipit-source-id: 49408098cebc7f76d8be0e585187ba9b6ca52049
Summary:
This was introduced to support MapBuffer-based view managers (D33735245), but that experiment has been removed from the codebase (D53072714).
This indirection is preventing a proper fix for a crash we're seeing with RemoveDeleteTree (T178300877)
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D53586567
fbshipit-source-id: d391ca56b23fc3dd57429c5ad8a7a405e97a81f2
Summary:
Changelog: [Internal]
Fixes a small omission in D53756996 that will come into play in future diffs.
bypass-github-export-checks
Reviewed By: robhogan
Differential Revision: D53771004
fbshipit-source-id: 4c94db37ef51793420e126a81c5d6c0543493ec7
Summary:
Changelog: [Internal]
Along with all the places using it like the `_debugSource` on Fiber.
This still lets them be passed into `createElement` (and JSX dev
runtime) since those can still be used in existing already compiled code
and we don't want that to start spreading to DOM attributes.
We used to have a DEV mode that compiles the source location of JSX into
the compiled output. This was nice because we could get the actual call
site of the JSX (instead of just somewhere in the component). It had a
bunch of issues though:
- It only works with JSX.
- The way this source location is compiled is different in all the
pipelines along the way. It relies on this transform being first and the
source location we want to extract but it doesn't get preserved along
source maps and don't have a way to be connected to the source hosted by
the source maps. Ideally it should just use the mechanism other source
maps use.
- Since it's expensive it only works in DEV so if it's used for
component stacks it would vary between dev and prod.
- It only captures the callsite of the JSX and not the stack between the
component and that callsite. In the happy case it's in the component but
not always.
Instead, we have another zero-cost trick to extract the call site of
each component lazily only if it's needed. This ensures that component
stacks are the same in DEV and PROD. At the cost of worse line number
information.
The better way to get the JSX call site would be to get it from `new
Error()` or `console.createTask()` inside the JSX runtime which can
capture the whole stack in a consistent way with other source mappings.
We might explore that in the future.
This removes source location info from React DevTools and React Native
Inspector. The "jump to source code" feature or inspection can be made
lazy instead by invoking the lazy component stack frame generation. That
way it can be made to work in prod too. The filtering based on file path
is a bit trickier.
When redesigned this UI should ideally also account for more than one
stack frame.
With this change the DEV only Babel transforms are effectively
deprecated since they're not necessary for anything.
DiffTrain build for commit https://github.com/facebook/react/commit/37d901e2b81e12d40df7012c6f8681b8272d2555.
Reviewed By: kassens
Differential Revision: D53543159
Pulled By: tyao1
fbshipit-source-id: 8e5509a16ea8d3234881e2305149326fb31e3845
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43012
Changelog: [iOS][Added]
This implements the functionality to give access to the jsi::Runtime in iOS in bridgeless. In bridge, this value is a private selector on RCTBridge that is exposed via category. We build this into the backwards compatible RCTBridgeProxy here.
This should work out of the box in bridgeless if you are already retrieveing the pointer via the bridge. However, we recommend users to eventually migrate towards C++ TurboModule or the RuntimeExecutor if possible. This will be removed in the future.
Reviewed By: RSNara
Differential Revision: D53646413
fbshipit-source-id: a5584f22d433a580d537b8780a3bcd503680acb8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43013
Changelog: [Android][Added]
This is a pre-deprecated API to give access to the jsi::Runtime in Android in bridgeless. In bridge, this value is exposed via the ReactContext, but is not implemented in the BridgelessReactContext. We do that here.
This should work out of the box in bridgeless if you are already retrieveing the pointer via ReactContext. However, we recommend users to eventually migrate towards C++ TurboModule or the RuntimeExecutor if possible. This will be removed in the future.
Reviewed By: RSNara
Differential Revision: D53645247
fbshipit-source-id: b98657560c43a625bdf947d19d186952c9b44364
Ruslan Shestopalyuk
Ingrid Wang
Dustin Shahidehpour
Pieter De Baets
Phillip Pan
Moti Zilberman
Nicola Corti
Riccardo Cipolleschi
Rubén Norte
szymonrybczak
Dmitry Rykun
Jakub Trzebiatowski
Christoph Purrer
Fabrizio Cucci
zhongwuzw
Samuel Susla
Riccardo Cipolleschi
David Vacca
Oskar Kwaśniewski
sebmarkbage