Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44822
Changelog: [Breaking]
This is to make `getContentOriginOffset` to have `includeTransform` information passed during Layout computation.
Reviewed By: NickGerleman
Differential Revision: D58223380
fbshipit-source-id: 4faa1409d9c87e2c92118941aa193ba0a0f34367
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44809
Adding react-native-codegen parser support for a new `EventEmitter` property type on C++ Turbo Modules.
It is possible to later expand this feature to other languages (Java, ObjC).
## Characteristics
An `EventEmitter` must:
- be non null:
`EventEmitter<string>` works, `?EventEmitter<string>` does NOT
- have a non null eventType:
`EventEmitter<number>` works, `EventEmitter<?number>` does NOT
- have at most 1 eventType, `void` is possible as well:
`EventEmitter<>` or `EventEmitter<MyObject>` work - `EventEmitter<number, string>` do NOT
- have a concrete eventType, `{}` is not allowed
`EventEmitter<{}>` does NOT work
- be used in `Cxx` Turbo Modules only at this time
## Example
For these 4 eventEmitters in on an RN JS TM spec
```
+onPress: EventEmitter<void>;
+onClick: EventEmitter<string>;
+onChange: EventEmitter<ObjectStruct>;
+onSubmit: EventEmitter<ObjectStruct[]>;
```
We now generate this code:
1.) in the spec based header `{MyModuleName}CxxSpec` in the constructor:
```
... // existing code
eventEmitterMap_["onPress"] = std::make_shared<AsyncEventEmitter<>>();
eventEmitterMap_["onClick"] = std::make_shared<AsyncEventEmitter<OnClickType>>();
eventEmitterMap_["onChange"] = std::make_shared<AsyncEventEmitter<OnChangeType>>();
eventEmitterMap_["onSubmit"] = std::make_shared<AsyncEventEmitter<OnSubmitType>>();
```
2.) as `protected` functions
```
void emitOnPress() {
std::static_pointer_cast<AsyncEventEmitter<>>(delegate_.eventEmitterMap_["onPress"])->emit();
}
void emitOnClick(const OnClickType& value) {
std::static_pointer_cast<AsyncEventEmitter<OnClickType>>(delegate_.eventEmitterMap_["onClick"])->emit(value);
}
void emitOnChange(const OnChangeType& value) {
std::static_pointer_cast<AsyncEventEmitter<OnChangeType>>(delegate_.eventEmitterMap_["onChange"])->emit(value);
}
void emitOnSubmit(const OnSubmitType& value) {
std::static_pointer_cast<AsyncEventEmitter<OnSubmitType>>(delegate_.eventEmitterMap_["onSubmit"])->emit(value);
}
```
## Changelog:
[General] [Added] - Add EventEmitter code-gen support for C++ Turbo Modules
Reviewed By: javache
Differential Revision: D57407871
fbshipit-source-id: 2345cc6dacf0cb0d45f8a374ad9d4cbf8082f9d6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44734
Fixes https://github.com/facebook/react-native/issues/44671
This integrates functionality for clipping content to padding box into `ReactViewBackgroundManager`, to be shared between several ViewManagers. In practice, this means:
1. `overflow: hidden` now works on `Text` and `TextInput`
2. ScrollView children are now clipped to the interior of borders, included curved ones via borderRadius
This will be made more generic, then start being used in ReactViewGroup, and eventually ReactImage. That abstraction will then hide away extra background management we will use for shadows.
Different places in code currently do clipping in any of `draw()`, `onDraw()`, or `dispatchDraw()`. The distinction between these, is that `draw()` allows code to run before drawing background even, `onDraw()` is invoked before drawing foreground, and `dispatchDraw()` is before drawing children. We don't want to clip out borders/shadows, but do want to clip foreground content like text, so I used `onDraw()` here.
Changelog:
[Android][Fixed] - Better overflow support for ScrollView, Text, TextInput
Reviewed By: rozele
Differential Revision: D57953429
fbshipit-source-id: ca3b788deb4b32706df7db958877d18f525c039c
Summary:
Before all React errors showed junk like this:
This is because `isComponentStack` detected a component stack but `parseComponentStack` couldn't actually parse it (it doesn't deal with React's current format like `in Foo (created by FeedItemInner)`) so `componentStack` was an empty array, resulting in the next block of code pushing stuff into `argsWithoutComponentStack` _again_, thus repeating its args.
The fix is not to do that. Result on my local copy:
Ofc this doesn't actually show the component stack but that was broken before too.
I edited in-place in my `node_modules` so I haven't verified this 100% works on main.
Hope this is useful!
## Changelog:
[General] [Fixed] - Remove accidental duplication in React warnings in Logbox
Pull Request resolved: https://github.com/facebook/react-native/pull/44812
Reviewed By: cortinico
Differential Revision: D58240357
Pulled By: rickhanlonii
fbshipit-source-id: b6ecb659d3b393e497caf5e7b2087a8e529f1b28
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44808
Adds an `AsyncEventEmitter` class which can be used as a property of currently C++ only Turbo Modules to send type safe data back to JavaScript.
Adding support for ObjC / Java Turbo Modules is possible, straight forward and can be added as an afterthought.
It implements this interface
```
export type EventEmitter<T> = {
addListener(handler: (T) => mixed): EventSubscription,
};
```
## Hybrid
It is a 'hybrid' object.
1.) You `addListener(handler: (T) => mixed)` in JavaScript for emitted events (coming from C++, native code)
2.) You `emit(...Arg)` events in C++, native code (getting sent to JavaScript)
## Changelog:
[General] [Added] - Add EventEmitter C++ bridging type
## Facebook:
Apps usually create custom functionality to achieve this kind of behavior - e.g. https://www.internalfb.com/code/fbsource/[e72bd42a028a]/arvr/js/apps/RemoteDesktopCompanion/shared/turbo_modules/TMSubscription.h
Reviewed By: javache
Differential Revision: D57424391
fbshipit-source-id: 4999cafe9daeac125712a4bb7679d7acb9a6c389
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44841
This change adds native support in Fabric for the remaining CSS cursor style values as defined here: https://developer.mozilla.org/en-US/docs/Web/CSS/cursor. Please note, this functionality is simply for prop parsing capabilities in Fabric, which are shared across all platforms. This does not add any additional cursor behavior support to iOS or Android, and the Flow and TypeScript types for cursor style values are still limited to `auto` and `pointer`.
## Changelog
[General][Added] Fabric prop parsing capabilities for all CSS cursor style values
Reviewed By: NickGerleman
Differential Revision: D58301970
fbshipit-source-id: 37ef8fcb4f62ac8c7613c7f6abcc48303953b71b
Summary:
Sometimes the events map can be a of type `SingletonMap` which will cause this code to throw exception when adding keys to it, so we change it to normal `HashMap`. Creating `SingletonMap` can especially happen in Kotlin when there is only one event added to a map, see:
https://github.com/plaid/react-native-plaid-link-sdk/blob/5ffab5eef576163528f0da504181162da3bef08b/android/src/main/java/com/plaid/PLKEmbeddedViewManager.kt#L21
## Changelog:
[ANDROID] [FIXED] - Cover SingletonMap when parsing events exported by module
Pull Request resolved: https://github.com/facebook/react-native/pull/42354
Test Plan: Create `getExportedCustomBubblingEventTypeConstants` as `SingletonMap` in some example module and see that the code does not throw.
Reviewed By: cipolleschi
Differential Revision: D58417266
Pulled By: cortinico
fbshipit-source-id: 6c46398ddf4d044386a36d0c1663bd071d642fb6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44835
As titled. The `vm` field is not part of the CDP spec and will not be used by the modern debugger frontend or proxy.
This change affects modern CDP targets only (using `InspectorPackagerConnection`). We aim to enable sharing of more detailed metadata over 1/ a new, dedicated CDP domain, and 2/ namespaced under the existing `reactNative` field (for the latter, strictly limited to metadata necessary for dev server functionality).
Changelog: [Internal]
(Note: `/json` endpoint behaviour is unchanged for legacy CDP targets)
Reviewed By: robhogan
Differential Revision: D58285587
fbshipit-source-id: dfef3a56b20486ba11891df9940f6c7bef59528e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44858
- Enables an opt-in to the Fusebox stack on Android for both architectures in open source.
- Templates use of this opt-in in RNTester.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D58359907
fbshipit-source-id: d565dc8e00747dff56d3060e36e7f59e7dd2aec5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44860
- Enables an opt-in to the Fusebox stack on iOS for both architectures in open source.
- Templates use of this opt-in in RNTester.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D58364053
fbshipit-source-id: c604b1589174bf7cfd0fe1bfb5624c4edd0a125d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44821
Changelog: [Internal]
- Originally D37994809 was attempted to fix `Inverted FlatList` but was put behind Feature Toggle because it was causing problems in other scenarios.
- Later, D45866231 which was trying to fix scaling transform issue helped solve the issue attempted by the original diff.
- But after that points, Unit test around `computeRelativeLayoutMetrics` was having two variants where Feature Toggle for D37994809 was checked in with a wrong expected value.
- This diff revert D37994809 changes and clean up the unit test.
Reviewed By: NickGerleman
Differential Revision: D58197918
fbshipit-source-id: d8ae552018617e785e4010bc5805c53a875e02a3
Summary:
## Changelog
make RNTesterApp take a `customBackButton` prop to enable overriding whether to display back button and the look
by default, only ios platform has a back button, and android app relies on back button on navigation bar that comes with platform
[Internal]
Reviewed By: christophpurrer
Differential Revision: D58218208
fbshipit-source-id: 63a47390cc6d3de057b92a3c522c1b00d942c69d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44792
X-link: https://github.com/facebook/yoga/pull/1663
Fixing https://github.com/facebook/yoga/issues/1658. We had a problem where if a child had a different flex direction than its parent, and it also set a position as a percent, it would look at the wrong axis to evaluate the percent. What was happening was we were passing in the container's mainAxis size and crossAxis size to use to evaluate the position size if it was a percent. However, we matched these sizes with the main/cross axis of the child - which is wrong if the flex direction is different.
I changed it so that the function just takes in ownerWidth and ownerHeight then calls isRow to determine which one to use for the main/cross axis position. This reduces the ambiguity quite a bit imo.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D58172416
fbshipit-source-id: eafd8069e03493fc56c41a76879d1ad9b7e9236d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44791
X-link: https://github.com/facebook/yoga/pull/1662
This should fix https://github.com/facebook/yoga/issues/1657. Rather insidious bug but we had code like
```
// The total padding/border for a given axis does not depend on the direction
// so hardcoding LTR here to avoid piping direction to this function
return node->style().computeInlineStartPaddingAndBorder(
axis, Direction::LTR, widthSize) +
node->style().computeInlineEndPaddingAndBorder(
axis, Direction::LTR, widthSize);
```
That comment is NOT true if someone sets both the physical edge and relative edge. So like paddingLeft and paddingEnd for RTL. This diff simply pipes the direction to that spot to use instead of hardcoding LTR. Every file changed is just to pipe `direction`.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D58169843
fbshipit-source-id: 5b4854dddc019285076bd06955557edf73ef7ec5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44852
This attempts to fix#44842 by capturing the accessed field in a new variable.
We don't have a way to reproduce this & this is a best guess fix.
Changelog:
[Android] [Fixed] - Tentative fix for NPE `JavaTimerManager$IdleCallbackRunnable.cancel`
Reviewed By: javache
Differential Revision: D58356826
fbshipit-source-id: d016df9a52f81a8d645a0a100c6bc6111841e24e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44851
This method is available on the (deprecated) CatalystInstance interface, but not on ReactContext, even though it is trivially supported.
Changelog: [Android][Added] - Added getNativeModule(name) to ReactContext
Reviewed By: cortinico
Differential Revision: D58355135
fbshipit-source-id: 0cc76bb2da2b49510dc626cb8b3a3e93db5a16b0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44823
Changelog: [internal]
This modifies the example for `IntersectionObserver` in RNTester to test that the API reports changes in intersection also coming from changes in layout (previously is was only from changes in scroll position).
Reviewed By: javache
Differential Revision: D58260057
fbshipit-source-id: 305d5996148730d718da30896f6cc62991b717f7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44805
Google has discouraged attempting to read the `status_bar_height` resource [since 2017](https://youtu.be/_mGDMVRO3iE?si=qGQd7gLa_qTmfLGL&t=1079). With the introduction of display cutouts there can be a mismatch between the resource value and the true status bar size (and issues like [this one](https://github.com/facebook/react-native/issues/33612) popped up). The recommended approach is to instead call `getInsets` with the proper status bar and navigation flags provided by `WindowInsets`. On older APIs where `getInsets` is not supported, we have access to `systemWindowInsetTop`.
Changelog:
[Android][Fixed] - Fixed StatusBar.currentHeight calculations to honor all cutout sizes
Reviewed By: tdn120
Differential Revision: D58088036
fbshipit-source-id: 9c035a79cbb96db1cf3b5b5c36242df7453fe205
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44854
In the previous change, I followed the suggestion of the linter but in that case I shouldn't.
This was breaking circleci and GHA
This change will fix it
## Changelog:
[Internal] - Fix OSS CI
Reviewed By: huntie
Differential Revision: D58358164
fbshipit-source-id: eba1f41c17a191aa9d3bd213fddddd8ff3c24a6a
Summary:
As discussed with cipolleschi offline, this PR adds visionOS to the prebuilt Hermes binary for the CI.
## Changelog:
[IOS] [ADDED] - Prebuilt version of Hermes for visionOS
Pull Request resolved: https://github.com/facebook/react-native/pull/44691
Test Plan: Check if CI builds xcframework for visionOS.
Reviewed By: cortinico
Differential Revision: D58189271
Pulled By: cipolleschi
fbshipit-source-id: dc76746b2c1e22670bef4c21411a598e43dad577
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44850
I'm removing this line from settings.gradle:
```
import com.facebook.react.ReactSettingsExtension
```
and just using a fully qualified class name in the `configure{}` block
as imports cannot be conditionally included and is making hard for RNTA
to integrated those changes.
Changelog:
[Internal] [Changed] - Remove import of `com.facebook.react.ReactSettingsExtension`
Reviewed By: huntie
Differential Revision: D58354443
fbshipit-source-id: bc45516661318021a042e1c5921e28d7217cacbc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44829
Another renaming that now we can merge to make clear what's the intent of this header.
Changelog:
[Internal] [Changed] - rncli.h -> autolinking.h
Reviewed By: javache
Differential Revision: D58284662
fbshipit-source-id: 7b69118f72d9b34a88ece7e0855918f5c717999a
Summary:
While writing some Jest tests, I noticed some instances of the following error:
```
Cannot read properties of undefined (reading 'remove')
```
Looks like there were two cases where the `{remove: () => {}}` return result was missing in the provided Jest mocks:
- `AccessibilityInfo.addEventListener`
- `Linking.addEventListener`
## Changelog:
[GENERAL] [FIXED] - Added missing `remove` methods for `Linking.addEventListener` and `AccessibilityInfo.addEventListener` Jest mocks
Pull Request resolved: https://github.com/facebook/react-native/pull/44270
Test Plan: N/A
Reviewed By: christophpurrer
Differential Revision: D58324784
Pulled By: robhogan
fbshipit-source-id: f46bd55db2517413f14182ae1bb81068d8d1e9f6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44828
I was using PackageList2 temporarily as I was migrating to Core Autolinking.
Now we can rename everything to `PackageList` to reduce the number of changes to the template for users.
Changelog:
[Internal] [Changed] - PackageList2 -> PackageList
Reviewed By: blakef
Differential Revision: D58284661
fbshipit-source-id: 8e1cc54e248519ece05336d79bb79e3f4ca706f4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44799
This is the final part of core autolinking:
1. I split RNGP into an `app-plugin` and a `settings-plugin`. This was necessary as the Gradle modules need to be loaded inside the settings.gradle.kts.
2. I've introduced a Settings Plugin to take care of either invoking the `config` command from CLI or receiving a file in input.
3. I've removed the former `RunAutolinkingConfigTask` as now the command is invoked inside the settings plugin
4. I've added hashing computed based on the lockfiles so we won't be re-executing teh `config` command if the lockfiles are not changed.
5. I've updated RN-Tester to use the core autolinking rather than manual linking for the 2 libraries it's using.
Changelog:linking
[Internal] [Changed] - RNGP - Autolinking. Add support for linking projects
Reviewed By: blakef
Differential Revision: D58190363
fbshipit-source-id: 6ab8b36729e77ca715f50a4a00aa0ca4eb5b63b1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44818
Introduce a new data source for Perfetto. This one turns on the Hermes sampler, and at the end we flush the state to Perfetto.
This provides JS sampling data in Perfetto traces that can be used to easily spot JS performance problems not otherwise obvious.
Reviewed By: javache
Differential Revision: D57226087
fbshipit-source-id: 77c4a335bb462e73d74345eedc3fa634405bfd0f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44827
After D57856389 (#44684), the build is now firing an issue as `libmapbufferjni.so` is exposed as a public `.so` and we're missing a pickFirst directive.
Changelog:
[Internal] [Changed] - Add libmapbufferjni.so to pickFirst directives
Reviewed By: javache
Differential Revision: D58284481
fbshipit-source-id: d476bd5df8ec4687177df7a698cbb6595ce62565
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44826
This was rolled out a while back, but some references remained.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D58190612
fbshipit-source-id: e7884909959c98eb5617c9dee75f4ce53834b05c
Summary:
In order to host a ReactNative surface whose size is controlled by the RN content rather than the size of the surface, we need the ability to remove the flex:1 style on the root View component.
`SurfaceHandler` has layout functions which take a `LayoutConstraint` (so min/max size). The root View component in `AppContainer` has a hardcoded `flex:1` style. This view is above the `WrapperComponent`, which we can currently override. But I dont see anyway to avoid the root View having that flex style. This flex style means that the rootview will always be the maxheight passed into the layout functions on `SurfaceHandler`. Which prevents allowing RN surfaces that can size themselves based on their content.
This change adds a `setRootViewStyleProvider` method to `AppRegistry`, which works similar to `setWrapperComponentProvider` but allows apps to override the style property on the root View component. In particular, this allows apps to remove the flex:1 style, which is required to enable react surfaces which are sized based on their contents.
## Changelog:
Pick one each for the category and type tags:
[GENERAL] [ADDED] - Added AppRegistry.setRootViewStyleProvider
Pull Request resolved: https://github.com/facebook/react-native/pull/44665
Test Plan: Will be including this change into react-native-windows to enable scenarios with content sized surfaces within Microsoft Office to work with the new architecture. Would like signoff on this direction before I go and integrate it there.
Reviewed By: javache
Differential Revision: D58138443
Pulled By: hoxyq
fbshipit-source-id: 95ab4842aa7f827867788d8787527f9675cf4fcc
Summary:
Hi, I'm Filip from software mansion. This PR solves a problem I stumbled upon.
On iOS, applications are always in light mode on initial load. Even if the device is turned to dark mode.
### Cause of the problem:
The initial appearance is taken from `RCTKeyWindow()`, but at the time of initialization of `RCTAppearance` it does not exist yet.
### Solution:
This PR moves repeats initialization of the appearance the first time `getColorScheme()` is called if it was not initialized properly before.
## Changelog:
[IOS] [FIXED] - Fix dark mode on initial load.
Pull Request resolved: https://github.com/facebook/react-native/pull/44335
Test Plan:
- Create new React native app with `npx react-native@latest init AwesomeProjec`
- Run the application on iphone using simulator
- turn on dark mode using `cmd+shift+A`
- close application and run it again
### without changes:
The application will turn on in light mode despite the simulator being set to dark mode.
When you reload the application it works as expected (is in dark mode)
### with changes:
Works as expected
#### note:
any change to device ui settings will trigger a listener that will set appearance to correct state, so testing of this problem should happen in as isolated conditions as possible.
Reviewed By: cortinico
Differential Revision: D58189058
Pulled By: cipolleschi
fbshipit-source-id: 9a864f3d045e966bc88601f661d221c4796c5c95
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44815
Remove our `test_ios_template` job for `test_ios_helloworld`.
NOTE: There needs to be a followup to do the same in our Github Actions.
Changelog: [General][Changed] use helloworld instead of template for CI tests.
Reviewed By: cipolleschi
Differential Revision: D57122797
fbshipit-source-id: 744c79230b716716fdfc234832f1eb241e091893
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44797
Noticed when profiling bridgeless that that every call into JS would be passed via a (default priority) background thread first. This is inefficient from a scheduling perspective. Instead use the Task's default/immediate executor to immediately execute the success callback on the current thread and avoid a thread change.
This diff adds a new feature flag, to use the immediate executor for any ReactInstance method that doesn't require further synchronization within ReactInstance. For most methods, this is indeed unnecessary as ReactInstance will synchronize internally by scheduling work on the JS thread.
Changelog: [Android][Added] Added featureflag to avoid additional background threads during execution
Reviewed By: cortinico
Differential Revision: D58186090
fbshipit-source-id: 67ffed2d34083a6b6e7871160a2f3d6f1967d630
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44767
Changelog: [Internal]
Fixes a lifecycle bug in both the Bridge (`com.facebook.react.bridge`) and Bridgeless (`com.facebook.react.runtime`) integrations of Fusebox in React Native Android, whereby `HostTarget::unregisterInstance` gets called after the `HostTarget` has been destroyed.
The solution consists of two parts:
1. If a ReactHost / InstanceManager is asked to destroy itself while it contains no active ReactInstance / ReactContext, we destroy the `HostTarget` immediately.
2. Otherwise, if there *is* a live ReactInstance / ReactContext that has yet to be destroyed, we wait for that to happen before destroying the `HostTarget`. In practice, we do this by checking for the BEFORE_CREATE ( = Host destroyed) lifecycle state every time we destroy a ReactInstance / ReactContext.
Reviewed By: javache
Differential Revision: D58031215
fbshipit-source-id: 321c73e85afd17a1b38c63f73aee5ebb59c00686
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44722
Add support for bundling, building and uploading on iOS. I've verified these locally and will enable on CircleCI to validate.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D57915365
fbshipit-source-id: 1e73918b31f70d337de4d3aee934c8acf88c86d0
Summary:
This PR adds cocoapods utility to set `SWIFT_ACTIVE_COMPILATION_CONDITIONS` to DEBUG, which is set to this value by default (when generating a new native Xcode project).
This allows to use the `#if DEBUG` compilator directive in Swift to work out of the box, without any changes on user's side:
```swift
override func bundleURL() -> URL? {
#if DEBUG
RCTBundleURLProvider.sharedSettings().jsBundleURL(forBundleRoot: "index")
#else
Bundle.main.url(forResource: "main", withExtension: "jsbundle")
#endif
}
```
## Changelog:
[IOS] [ADDED] - Set SWIFT_ACTIVE_COMPILATION_CONDITIONS to DEBUG
Pull Request resolved: https://github.com/facebook/react-native/pull/42330
Test Plan:
Run `bundle exec pod install` and check if the active compilation flags are populated:
Reviewed By: cortinico
Differential Revision: D58188103
Pulled By: cipolleschi
fbshipit-source-id: 64746f3c7bfbdf47c2dea5e5e8cb2962635b719b
Summary:
The new `customizeRootView` does not have the feature parity as `createRootViewWithBridge` where reusing RCTRootViewFactory to create a root view, it does not call `customizeRootView`. This PR moves the `customizeRootView` support from RCTAppDelegate into RCTRootViewFactory and improves the customizeRootView support.
## Changelog:
[IOS] [CHANGED] - Support `customizeRootView` from `RCTRootViewFactory`
Pull Request resolved: https://github.com/facebook/react-native/pull/44775
Test Plan:
Add customizeRootView to **packages/rn-tester/RNTester/AppDelegate.mm** and test whether RNTester has blue background color in both new arch and old arch mode.
```objc
- (void)customizeRootView:(RCTRootView *)rootView
{
rootView.backgroundColor = [UIColor blueColor];
}
```
Reviewed By: dmytrorykun
Differential Revision: D58179693
Pulled By: cipolleschi
fbshipit-source-id: 0fac9a1bd5b2583a2700b3a3d2c80d0f608c4481
Soe Lynn
Christoph Purrer
Nick Gerleman
Pieter Vanderwerff
dan
Eric Rozell
Wojciech Lewicki
Mauricio Meirelles
Alex Hunt
Nicola Corti
rickhanlonii (Meta Employee)
Zeya Peng
Joe Vilches
Pieter De Baets
Rubén Norte
Peter Abbondanzo
Riccardo Cipolleschi
Oskar Kwaśniewski
Levi Buzolic
Vitali Zaidman
Ingrid Wang
Benoit Girard
zhongwuzw
Andrew Coates
filip131311
Blake Friedman
Kudo Chien
Elene Botchoradze
Marlene Cota
Moti Zilberman