Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41625
To tell React Native whether we are building with hermes or not on iOS, we were using 2 different build time flags:
- USE_HERMES
- RCT_USE_HERMES
The first was widely used by the OSS use case, while the latter was set internally.
Worse than that, their default values were the opposite and we were never setting the RCT_USE_HERMES explicitly with Cocoapods, while there was some piece of code that was trying to "smartly" detect whether Hermes was included or not.
This change unifies the behavior, removing the "smartness" in favor od a declarative approach.
## Changelog:
[Internal] - Unify the USE_HERMES flags
Reviewed By: christophpurrer
Differential Revision: D51549284
fbshipit-source-id: 829ad361e185d5b4fa227605523af3a8e590e95c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41626
In the codebase, we never set the RCT_USE_HERMES flag.
When we install the pods, we use the USE_HERMES flag and we set USE_HERMES as a build setting. So, the RCT_USE_HERMES flag will always be not set for the OSS.
https://pxl.cl/3RRxr
## Changelog:
[iOS][Fixed] - use the right USE_HERMES flag
## Facebook:
This change was incorrect as in OSS we never set the RCT_USE_HERMES flag, while we actually set the USE_HERMES one.
I will align the BUCK RNTester setup in the next diff of the stackog:
Reviewed By: dmytrorykun
Differential Revision: D51547810
fbshipit-source-id: 1da5b3a48a83a8ba49cf65382927bed2f9fc893d
Summary:
changelog: [internal]
From sammy-SC, we would like to minimize the number of times that React Native schedules Choreographer calls. For animations, we do not need choreographer running on every frame, it only needs to run on frames that have an animation active. This diff modifies the frame callbacks such that Choreographer calls are only enqueued if there is an ongoing animation.
Reviewed By: sammy-SC
Differential Revision: D50647971
fbshipit-source-id: d77b246beafc5c658c738e574b0e02dd68fadce9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41560
This diff gives some functions and variables more accurate names:
1. `appRoot` -> `projectRoot`
2. `handleThirdPartyLibraries` -> `findExternalLibraries`
3. `handleLibrariesFromReactNativeConfig` -> `findLibrariesFromReactNativeConfig`
4. `handleInAppLibraries` -> `findProjectRootLibraries`
It also removes `isAppRootValid` check that checks that `appRoot != null`, it is redundant since `appRoot`(now `projectRoot`) is required by the CLI.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D51309027
fbshipit-source-id: c5e34c2aa788a7795c68697a0fa9ddf0163cec0e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41558
Now that the previous diff in the stack (D51303793) provides proper dependency path resolution, we can process `react-native` as a normal dependency, and remove a special code path for it.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D51256764
fbshipit-source-id: 2a11641e9362d7bfad1ff9995b4f3bb4c92d9c0f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41654
This diff removes support for defining external codegen targets in `react-native.config.js` for iOS. Now you can simply add your external dependency to the project's `package.json` and it will be resolved as a normal Node packages.
## Motivation
The need for defining external codegen targets in `react-native.config.js` historically appeared due to limitations of how codegen searched for external dependencies. Basically we performed search only in the project directory. External dependency paths had to be listed in `react-native.config.js`.
After D51303793 has landed we don't need this any longer. We can simply rely on Node resolution to find those external dependencies.
Changelog: [iOS][Breaking] - Defining external codegen targets in `react-native.config.js` is not supported anymore. Define them as normal dependencies in `package.json`.
Reviewed By: cipolleschi
Differential Revision: D51308595
fbshipit-source-id: 97841a3a8c295aa717c577bb188d48373b04ba38
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41645
Right now, when defining concrete structs and Bridging headers for Cxx TMs we need to define their member types twice:
```
using ConstantsStruct =
NativeCxxModuleExampleCxxBaseConstantsStruct<bool, int32_t, std::string>;
template <>
struct Bridging<ConstantsStruct>
: NativeCxxModuleExampleCxxBaseConstantsStructBridging<
bool,
int32_t,
std::string> {};
```
Now we only need to define those once
```
using ConstantsStruct =
NativeCxxModuleExampleCxxConstantsStruct<bool, int32_t, std::string>;
template <>
struct Bridging<ConstantsStruct>
: NativeCxxModuleExampleCxxConstantsStructBridging<ConstantsStruct> {};
```
This change keeps the existing base types untouched - but they will be removed in the next RN version.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D51571453
fbshipit-source-id: 2783bd48bf786ffa80d322d06456b5d6f2d7ba8a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41391
X-link: https://github.com/facebook/yoga/pull/1461
Converts usages of `YGEdge` within internal APIs to `yoga::Edge` scoped enum.
With the exception of YGUnit which is in its own state of transition, this is the last public yoga enum to need to be moved to scoped enum form for usages internal to the Yoga public API.
Changelog: [internal]
Reviewed By: rshest
Differential Revision: D51152779
fbshipit-source-id: 06554f67bfd7709cbc24fdd9a5474e897e9e95d8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41390
X-link: https://github.com/facebook/yoga/pull/1460
Yoga passes `MeasureMode`/`YGMeasureMode` to express constraints in how a box should be measured, given definite or indefinite available space.
This is modeled after Android [MeasureSpec](https://developer.android.com/reference/android/view/View.MeasureSpec), with a table above `calculateLayoutImpl()` explaining the CSS terms they map to. This can be confusing when flipping between the spec, and code.
This switches internal usages to the CSS terms, but leaves around `YGMeasureMode` since it is the public API passed to measure functions.
Reviewed By: joevilches
Differential Revision: D51068417
fbshipit-source-id: 0a76266a4e7e0cc39996164607229c3c41de2818
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41392
X-link: https://github.com/facebook/yoga/pull/1458
We're moving `CompactValue` to be an internal detail of `yoga::Style`, where users outside of the style will be dealing with a resolved/non-compact representation.
This change renames usages of `CompactValue` to `Style::Length`, which will be Yoga's representation for CSS input lengths. Right now one is just a type alias of the other, but this will let us change the internals of CompactValue with the rest of the world looking the same.
A few factory functions are added to `yoga::value` for creating CSS values. There are some shenanigans around how we want to represent CSS pixels (one YGUnitPoint), when we also end up adding CSS points (slightly larger than one YGUnitPoint). For now, I reused `point` until making other changes.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D51000389
fbshipit-source-id: 00f55e72bfb8aa291b53308f8a62ac8797be490f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41640
react-native-svg reported that the SVG library was not building on the latest RC of React Native because Codegen was not finding the proper files.
By inspecting an example app with SVG, we realized that React-Codegen was not depending on `React-FabricImage`, while having access to their headers.
We added the dependency, but them the build was failing due to a circular dependency because the `React-ImageManager` was dependeing on `React-RCTImage`.
This dependency is conceptually wrong (a piece of Core should not depend on Library which depends on Core... 😑) and I verified that by removing that dependency the framework continue to build.
## Changelog:
[Internal] - Fixed dependencies of Codegen on React-Image
Reviewed By: cortinico
Differential Revision: D51564037
fbshipit-source-id: 8e7108b83f878be1063df5562311d862d4998121
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41643
Code in `AndroidTextInputComponentDescriptor` will rewrite Yoga props for padding based on Android theme, if a value isn't supplied. It determines this by adding props in `AndroidTextInputProps` which reads Yoga RawProps to tell if they were set.
RawProps are keyed using separate prefix/name/suffix, instead of the combined string name of the prop. This means that searching for the name `paddingLeft`, would be different from reading one with a name of `padding` and a suffix of `Left`.
This updates the keying, based on the changes in D51510562.
We should refactor this in the future (D20109605, introducing this code, admitted as much). We already have a phase, for aliased props, where we transform input props into the Yoga style (they don't need to be 1:1). This doesn't depend on RawProps, extra props, or prop mutations.
Changelog:
[Android][Fixed] - Fix AndroidTextInputProps Detection of Padding
Reviewed By: GijsWeterings
Differential Revision: D51566900
fbshipit-source-id: ca744b23d71382941903da42d86ad3eef7b65de8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41549
Changelog: [Internal]
Introduces the `JSRuntime` interface as a straightforward wrapper around `jsi::Runtime`, and refactors `ReactInstance` to hold a `JSRuntime` instead of a `jsi::Runtime`. In an upcoming diff we'll add debugging-related methods to `JSRuntime` and specialise their implementations for Hermes.
NOTE: `JSRuntime` is somewhat analogous to `JSExecutor` in the Bridge architecture.
Reviewed By: huntie
Differential Revision: D51447934
fbshipit-source-id: cfcab9ae0dd3d2a34c064abaac6cb676f435e216
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41642
This allows opening an example within RNTester without tapping the module card. If the app receives an openURL request with the format `rntester://example/<key>`, open that example (if exists) directly. Such URL request may come from various sources (e.g. custom test run, etc).
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D51543385
fbshipit-source-id: f9a01963cefb4602b629da0b01be6e334c28a912
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41623
`static` fields require additional code to ensure the field is only ever initialized once. We already have a static "default props" field in the shadow node, so let's reuse that as much as possible.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D51547638
fbshipit-source-id: e4957ffb0f9352847b8cd8dc3a010dcfac8be699
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41628
# Changelog:
Even though `onClick` is used on Android (e.g. via Pressability), the fact of having the handler registered didn't get through to the C++ side on New Architecture, because of being filtered out via the corresponding static view config.
As the result, there was no way to know on C++ side whether the corresponding event handler is registered for the view or not. Dynamic updates to the prop also wouldn't correctly propagate to C++, which may be a problem if a view gets e.g. the handler dynamically added.
Reviewed By: javache
Differential Revision: D51551255
fbshipit-source-id: 0783f5a27c7250f83fb357173bbe5be6213277e5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41613
Changelog: [Internal]
We were keeping ref in the AppContainer's state before migrating these components to functions.
We actually need a real ref here, so we can use `useImperativeHandle` on it later. These refs will be passed as an argument for DebuggingRegistry subscription, whichi will call them on all necessary AppContainers to highlight required components.
Reviewed By: javache
Differential Revision: D51536772
fbshipit-source-id: d49035874ce3c9b1acf08d5ab666886f68e6f40e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41562
Changelog: [Internal]
We will use this native component as a single layer for drawing debugging information: both for trace updates and inspected components from React DevTools.
Reviewed By: javache
Differential Revision: D51470789
fbshipit-source-id: 6c4633d2b70c2c2635a2bbfcd7adf1c727b73585
Summary:
Several deprecation warning messages related to components that were removed from `react-native` were outdated.
Some repositories have been moved, some packages were renamed/re-published under new names. A couple **never existed** (`react-native-community/segmented-checkbox` and `react-native-community/react-native-image-picker`).
This updates all messages to include links to the latest repositories and references to npm packages.
Because `react-native-community/art` is deprecated I've also slightly amended the message with the suggestion from its [repo readme](https://github.com/react-native-art/art#deprecated---this-package-is-deprecated-if-you-need-a-similar-package-please-consider-using-react-native-svg).
## Changelog:
[GENERAL] [FIXED] - Update pkg/repo names in deprecation messages
Pull Request resolved: https://github.com/facebook/react-native/pull/41618
Test Plan: No code change, just documentation/text.
Reviewed By: cipolleschi
Differential Revision: D51546345
Pulled By: cortinico
fbshipit-source-id: 5d7176a70d94c8b1e8111f4d84fba89eacde456a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41621
Currently, if you have a dependency that is alphabetically smaller than `app`, it's evaluation will happen before `app`.
This means that the namespace auto-discovery and the JVM toolchain configuration won't be working and the project will fail to buid.
This fixes it by introducing a root-project Gradle Plugin that takes care of enforcing the evaluation order on the `app` project.
Fixes#41620
Changelog:
[Android] [Fixed] - Fix projects being broken on dependencies starting with `a..`
Reviewed By: huntie
Differential Revision: D51547294
fbshipit-source-id: 65df7149548b7087dd8928e556fb803b3baf7b79
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41557
The `configFileDir` CLI argument is used to help to find paths to the 3rd party dependencies of the app. Since we only care about dependencies listed in the root `package.json`, we can use `node` resolution instead of having to construct paths manually. In that case `configFileDir` becomes redundant.
Changelog: [iOS][Breaking] - Delete configFileDir CLI argument.
Reviewed By: cipolleschi
Differential Revision: D51303793
fbshipit-source-id: 46cb61197ddf51515af634c8fc6b85a8d218c51e
Summary:
This PR addresses the problem raised in the https://github.com/facebook/react-native/issues/41004 issue.
The current logic is that `selectionColor` on iOS sets the color of the selection, handles, and cursor. On Android it looks similar, while it doesn't change the color of the handles if the API level is higher than 27. In addition, on Android there was an option to set the color of the cursor by `cursorColor` prop, but it didn't work if the `selectionCursor` was set.
## 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
-->
[GENERAL] [ADDED] - Make same behavior of the `selectionColor` prop on Android as iOS
[ANDROID] [ADDED] - Introduced `selectionHandleColor` as a separate prop
[ANDROID] [CHANGED] - Allowing `cursorColor` and `selectionHandleColor` to override `selectionColor` on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/41092
Test Plan:
Manual tests in rn-tester:
### `selectionColor` same as iOS, sets selection, handles and cursor color
_There is a way to set only "rectangle" color by setting other props as null_
### `selectionHandleColor`
### `cursorColor`
Reviewed By: NickGerleman
Differential Revision: D51253298
Pulled By: javache
fbshipit-source-id: 290284aa38c6ba0aa6998b937258788ce6376431
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41609
Aggregate edges will no longer be exposed. Inline debugStringConvertibleItem string printing for it.
Previously included in D50998164
Changelog:
[Internal]
Reviewed By: joevilches
Differential Revision: D51510790
fbshipit-source-id: aaabaa4fdd899bd9c602b9a5ab5dd35265c7269b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41611
Aggregate edges will no longer be exposed. Inline the convertRawProp parsing functions for it.
This is a little bit more code, but subjectively easier to reason about.
Previously included in D50998164
Changelog:
[Internal]
Reviewed By: joevilches
Differential Revision: D51510562
fbshipit-source-id: 30440e19422a3a3fb49a754b5ecd8279ce1521a2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41612
We never use the position edges for Yoga style. We should not keep extra props, and instead just parse directly into the Yoga style.
Previously included in D50998164
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D51508217
fbshipit-source-id: ff28cf7168446068b10901fbba258414b561f07f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41614
Fixes https://github.com/facebook/react-native/issues/41545
SafeAreaView works by adding padding in order to shift content out of the safe area. This may change the layout dimensions of the SafeAreaView, in turn effecting its safe area insets.
This can cause layout results to change, which in turn changes the inset value. Because of this, there is a tolerance, where safe area inset changes do not trigger a new update.
Yoga is instructed to round layout dimensions to the closest physical pixel, so a very small difference in layout may result being off by about a pixel. Right now the tolerance is exactly one physical pixel, and if there is FP error here, we may not pass the test, and start oscillating with different layout values.
After changing affected ShadowNode order to always be root-first, the first call to set the frame of the `SafeAreaView` happens when a non-zero-sized RootView is present, which I think may lead to a safe area inset update communicated that wasn't before? Or other cosmic butterflies. Layout rounds to one physical pixel in difference, and our tolerance is `0.00001` dips off (not helped that 1/3 screen scale cannot be represented as decimal, even without FP error).
This adds a small tolerance beyond just the pixel boundary, matching the logic in Fabric, which seems to resolve the issue.
Changelog:
[iOS][Fixed] - FP Tolerance in iOS Paper SafeAreaView debouncing
Reviewed By: philIip
Differential Revision: D51539091
fbshipit-source-id: 88bddc38c7cd8d93feef5f12da64b124af22f46d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41599
Changelog: [iOS][Breaking]
this is not used in our framework, delete. feel free to fork this implementation if you are using it or interested in using it
Reviewed By: cipolleschi
Differential Revision: D51516680
fbshipit-source-id: 4ca23a5b78bf18a84ea0ab4fe16419db7aea03d9
Summary:
Adding `initialize()` to FabricUIManager just as was done by JSIModule
Without this change switching to UIManagerProvider would cause the UI to be Frozen and the events not correctly registered.
Pull Request resolved: https://github.com/facebook/react-native/pull/41594
Reviewed By: javache
Differential Revision: D51456979
fbshipit-source-id: 8d97533340a88ec6bb2bf0f257b6acfaa59da471
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41466
## Context
In open source, all apps use the same turbomodulemanager delegate (i.e: the default delegate).
This diff introduces the buck infra that makes the oss default delegate work for meta apps.
Concretely, we are going to make React Native use the same delegate for **all** Meta apps.
Each Meta app will:
1. At build time, generate a unique TMProvider map
2. At app init time, initialize the default delegate with the TMProvider map.
## Implementation
**Step #1:** At build time, generate a unique TMProvider map
**Insight:** Buck genrules can accept, as input, the output of a buck query.
So, here's how we get this done:
1. Buck query (i.e: input to Genrule): Given the app's deps, query all the schemas in the app.
2. Genrule: Read the schemas to generate the TMProvider map. The TMProvider map will also contain **all** the app's C++ module codegen.
Concretely:
1. This diff introduces a macro: rn_codegen_appmodules(deps).
2. rn_codegen_appmodules(deps) generates appmodules.so, which contains the TMProvider map.
**Step #2:** At app init time, initialize the default delegate with the TMProvider map.
This is how we'll initialize the DefaultTurboModuleManagerDelegate:
1. DefaultTurboModuleManagerDelegate will load appmodules.so during init.
2. When loaded, appmodules.so will assign the code-generated TMProvider map to DefaultTurboModuleManagerDelegate.
## Impact
This should allow us to:
1. Get one step closer to getting rid of the `js1 build turbomodule-manager-delegates --target <app>` script
3. Remove the TurboModuleManagerDelegate from React Native's public API. (Because we use one delegate for all React Native apps in Meta and OSS)
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D50988397
fbshipit-source-id: 0ca5dec14e2dae89ec97f5d39a182c7937c5c7bf
Summary:
Bitfield enums are not sequential, so use of these functions on these enums would be invalid.
I looked at whether we could trivially move `bitCount` to template based on `ordinalCount`. `bitCount` must be constexpr, since we use it directly as a bit-field size constant. `log2` and `ceil` to be constexpr, which isn't here until C++ 26.
Reviewed By: javache
Differential Revision: D51518899
fbshipit-source-id: 256f15bbed517be6f90bf43baa43ce96e9259a71
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41555
This diff splits `generateNativeCodegenFiles` into two simpler steps: `generateSchemaInfos` and `generateCode`. `SchemaInfo` is a (library, schema) pair, it is convenient for further transformations.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D51204077
fbshipit-source-id: 8a1f585a79a2a0241b544a8a131b59250d803e2e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41554
This diff removes inefficiency where we first write schema to disk in `combine-js-to-schema.js`, and then read it from disk in `generate-specs-cli-executor.js`. With this change we can just pass it as an argument.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D51161162
fbshipit-source-id: 35d14ca3e53e4bf999520c635c66909c20081096
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41534
This diff deletes calls to `node` from `generate-artifacts-executor.js`, and replaces them with normal `requires` of JS sources.
This is a squashed version of (D51116291 ... D51158799).
The following sequence of changes has been made:
1. Require and directly invoke `generate-specs-cli-executor` instead of using `node`.
2. Use `codegen-util` to get `RNCodegen` in `generate-provider-cli.js`.
3. Use `RNCodegen` directly instead of using `node`.
4. Move all implementation code from `combine-js-to-schema-cli.js` to `combine-js-to-schema.js`.
5. Decouple building the codegen from getting the codegen CLI.
6. Use `combine-js-to-schema` directly instead of using `node`.
7. Delete unit test that was testing node invocation.
8. Delete `nodeBinary` argument form `generate-codegen-artifacts.js` and its callsites.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D51158845
fbshipit-source-id: 5e039801c8045a42349f7cb6ca28e2df24634589
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41603
changelog: [internal]
`ShadowNode::IdentityTrait` was already a thing. Let's make it available in ConcreteComponentDescriptor.
Reviewed By: rshest
Differential Revision: D51471666
fbshipit-source-id: 7919a9b7238d766ee3913a5ab239bf254fab0996
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41589
This is a cleanup diffs that removes some of the usages of RCT_NEW_ARCH_ENABLED.
Now that we are shipping all the pods, there is no need to conditionally compile-out part of the codebase depending on whether the new architecture is running or not.
This change will not alter the behavior of the app.
## Changelog:
[iOS][Breaking] - Remove some usages of RCT_NEW_ARCH_ENABLED. The change should be transparent BUT some **Swift** libraries might get broken by this change.
Reviewed By: dmytrorykun
Differential Revision: D51498730
fbshipit-source-id: c83416480eea1f7bbc55f72c31e7b69ad0e9e01a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41588
This change always installs all the Pods for both architecture.
This unify the behavior between iOS and Android.
## Changelog:
[Internal] - Always install all the pods
## Facebook:
The inly four pods that are changed when flipping between the new and the old arch with RNTester are:
- MyNativeView
- NativeCxxModuleExample
- React-RCTAppDelegate
- ScreenshotManager
The only change there is the RCt_NEW_ARCH_ENABLED flag being set or not in those pods
Reviewed By: dmytrorykun
Differential Revision: D51494498
fbshipit-source-id: 4cafdef4a4c2b86381067373aed27ed18524e4be
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41579
This change remove a flag that is unused.
## Changelog
[Internal] - Remove unused Flag
Reviewed By: dmytrorykun
Differential Revision: D51493765
fbshipit-source-id: f8cbce991d80d4f51363cdd4f379e6b214b2b2df
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41561
The RN_FABRIC_ENABLED has been deprecated and superseded by the RCT_NEW_ARCH_ENABLED for a while now.
This change removes it, from the codebase as now we always have the Fabric pod available to the codebase.
## Changelog
[Internal] - Remove RN_FABRIC_ENABLED flag
Reviewed By: dmytrorykun
Differential Revision: D51468332
fbshipit-source-id: 6b2fc554e6bf5ac748b9e45d7c14f9ba9b57820c
Riccardo Cipolleschi
Bill Alves
Dmitry Rykun
zhongwuzw
Christoph Purrer
Intl Scheduler
Nick Gerleman
Moti Zilberman
Kevin Gozali
Samuel Susla
Ruslan Shestopalyuk
Pieter De Baets
Ruslan Lesiutin
Frieder Bluemle
Nicola Corti
Jakub Grzywacz
Phillip Pan
Arushi Kesarwani
Ramanpreet Nara
Sam Zhou