Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42727
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
Reviewed By: NickGerleman
Differential Revision: D53200096
fbshipit-source-id: 2d965ebcb568e7bbff4b37db11070c5079fa6394
Summary:
The goal is to provide testing utilities that use Fabric and concurrent rendering by default to support the new RN architecture. Currently most testing is done through ReactTestRenderer, which is an overly-simplified rendering environment, non-concurrent by default, and over exposes internals. A dedicated RN environment in JS can allow for more realistic test execution.
This is the initial commit to create the `react-native-test-renderer` package. It currently only offers a simple toJSON() method on the root of a test, which is used for snapshot unit tests. We will be iterating here to add a query interface, event handling, and more.
## Changelog:
[GENERAL] [ADDED] - Added react-native-test-renderer package for Fabric rendered integration tests
Pull Request resolved: https://github.com/facebook/react-native/pull/42644
Test Plan:
```
$> cd packages/react-native-test-renderer
$> yarn jest
```
Output:
```
PASS src/renderer/__tests__/render-test.js
render
toJSON
✓ returns expected JSON output based on renderer component (7 ms)
Test Suites: 1 passed, 1 total
1 passed, 1 total
Snapshots: 1 passed, 1 total
Time: 2.869 s
```
Reviewed By: yungsters
Differential Revision: D53183101
Pulled By: jackpope
fbshipit-source-id: 8e29ba35f55f6c4eb2613ab106bc669d72f33d1d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42740
Follow-up to a CircleCI breakage introduced by D53001971.
This was missed by both the typechecker (no Flow in file) and CI (no PR-time jobs covering this script).
Changelog: [Internal]
Reviewed By: cortinico, GijsWeterings, cipolleschi
Differential Revision: D53228096
fbshipit-source-id: fbbe1538ee52b8452399d86489239434d3a068be
Summary:
When we changed dark mode, the semantic color was not applied because we use color components, it's not dynamic. So let's store the `UIColor` for semantic color directly.
https://github.com/facebook/react-native/assets/5061845/bd6d15fe-01eb-4ad7-9844-a19ef8585dae
## Changelog:
[IOS] [FIXED] - [Fabric] Fixes semantic color not work when dark mode changed
Pull Request resolved: https://github.com/facebook/react-native/pull/42737
Test Plan: semantic color changed when switch dark mode.
Reviewed By: christophpurrer
Differential Revision: D53226806
Pulled By: cipolleschi
fbshipit-source-id: 66d5417fa1bb6a5da498e903675a93b20d920c0a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42636
Changelog: [Internal]
Models the Native instance lifecycle in the modern CDP backend, by:
1. Registering the instance, once created, with `PageTarget`.
2. While an instance is registered, delegating messages from `PageAgent` to an internal `InstanceAgent`.
3. Unregistering the instance once it is invalidated and about to be destroyed.
We use this infrastructure to implement two simple behaviours that will be superseded in future diffs (mainly by delegating work to the JSVM), but that are useful as stubs for testing:
* Sending [`Runtime.executionContextDestroyed`](https://cdpstatus.reactnative.dev/devtools-protocol/tot/Runtime#event-executionContextDestroyed), [`Runtime.executionContextsCleared`](https://cdpstatus.reactnative.dev/devtools-protocol/tot/Runtime#event-executionContextsCleared), and [`Runtime.executionContextCreated`](https://cdpstatus.reactnative.dev/devtools-protocol/tot/Runtime#event-executionContextCreated) events to the frontend when reloading the instance.
* Implementing a toy version of [`Runtime.getHeapUsage`](https://cdpstatus.reactnative.dev/devtools-protocol/tot/Runtime#method-getHeapUsage) (that always reports zero memory usage) to exercise the Page→Instance message dispatching logic.
iOS Bridge/Bridgeless and `PageTargetTest` are the only integrations that exist as of this diff, and are all updated here; Android will follow later.
## Object lifetimes
* PageTarget owns an InstanceTarget that it creates (in `registerInstance`) and destroys (in `unregisterInstance`).
* `registerInstance` returns a raw `InstanceTarget&` reference, which becomes invalid upon calling `unregisterInstance`. It's the caller's responsibility to stop using the reference at the point of calling `unregisterInstance`.
* InstanceTarget holds a raw `InstanceTargetDelegate&` reference. It's the caller's responsibility to keep this reference valid at least until `unregisterInstance` returns.
## Thread safety
* As with PageTarget's constructor and destructor, It's the caller's responsibility to invoke `registerInstance` and `unregisterInstance` on the main thread (or using appropriate synchronisation).
* `InstanceAgent` handles messages on the same thread as `PageAgent` (typically the platform-specific main thread) and receives a copy of the same thread-safe `FrontendChannel` for sending messages back.
Reviewed By: huntie
Differential Revision: D51214056
fbshipit-source-id: 2dc2ff30d2dda6887871831a818aa117ca3e6e91
Summary:
Internally, we synched the windows folders in react-native. This added the `windows` folder in the `platform` folder of react/graphics.
This breaks the build for iOS internally as the `React-graphics` pod is now importing both the `ios` and the `windows` folders, but, of course, some of the Windows headers are not available to iOS.
This change excludes the windows folder from the iOS Pod, when building for Meta engineers.
## Changelog:
[internal] - exclude the `plafrom/windows` folder from the `React-graphics` pod.
Reviewed By: motiz88
Differential Revision: D53228890
fbshipit-source-id: 2be5b71f6556e5da76496f0d64a98318477ad3c5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42731
This matches the behaviour we have for DefaultTurboModuleManagerDelegate, where we handle the lack of this being set gracefully. It's probably worth still logging this, as it may point at an incorrectly configured app.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D53048064
fbshipit-source-id: 3ef10da3a7779a1274a1a1793387cf8cdf36c535
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42735
This realigns the NDK versions used to build the two tools.
Changelog:
[Internal] [Changed] - Bump FBJNI to 0.6.0
Reviewed By: cipolleschi
Differential Revision: D53223301
fbshipit-source-id: 640e9008ed460e58423fb26b6e7030e264ef9320
Summary:
After update to the latest `react-native` version
we discover that we are unable to use `number%` value for `translate*` props :
```tsx
StyleSheet.create({
root: {
transform: [
{ translateX: '-50%' },
// ^^^^^^ TS Error: Type string is not assignable to type AnimatableNumericValue | undefined
],
}
});
```
---
percentage values are supported, demo: https://snack.expo.dev/retyui/test-tstransform
## Changelog:
[GENERAL] [FIXED] - Update typescript definition of `translateX` & `translateX` to be able to use percentage values
Pull Request resolved: https://github.com/facebook/react-native/pull/42671
Test Plan: `yarn tsc --noEmit`
Reviewed By: rozele, cortinico
Differential Revision: D53146046
Pulled By: NickGerleman
fbshipit-source-id: 3486e7a9b55b98c36cc96b2bca4bb27841061e80
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42730
Reviewing and modernising this script as part of simplifying our release publish workflow.
- Drop unused `--dependency-versions` arg from CLI entry point
- Simplify templating approach
- Type as Flow
- Drop dependencies on `shelljs` and `yargs`
- Relocate under `scripts/releases/`
- Rewrite tests as snapshot tests
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D53001971
fbshipit-source-id: e55a71a0bb37e3e18ba1e582a5c46ddd58823d81
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42699
Changelog: [internal]
The test was fine on C++. The reason is probably that C++ destroys the process between tests (effectively resetting singletons) while iOS doesn't.
This fixes the test by implementing a correct `TearDown` method to reset the flags.
Reviewed By: rshest
Differential Revision: D53178474
fbshipit-source-id: 6a0f67f1a59fe47f73a495344d4c0daa8eafa3c4
Summary:
This PR resolves issues with retrieving appearance in multi-window apps by calling `RCTKeyWindow()` instead of retrieving the AppDelegate window property. It also does small optimization in the RCTAlertController.
## Changelog:
[IOS] [FIXED] - Fix retrieving current appearance in multi-window apps
Pull Request resolved: https://github.com/facebook/react-native/pull/42231
Test Plan: CI Green, it should work the same as before
Reviewed By: NickGerleman
Differential Revision: D52802756
Pulled By: cipolleschi
fbshipit-source-id: 60b5f7045f41be19caae5102f0dc321d4ecdcd2f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42714
For 0.74, we would like to have Bridgeless as the default when the New Architecture is enabled.
## Changelog:
[Android][Breaking] - Make bridgeless the default when the New Arch is enabled
Reviewed By: cortinico
Differential Revision: D52600227
fbshipit-source-id: 0d967c73cd805710c501c020ad892f059a0fb117
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42182
For 0.74, we would like to have Bridgeless as the default when the New Architecture is enabled.
## Changelog:
[iOS][Breaking] - Make bridgeless the default when the New Arch is enabled
Reviewed By: cortinico
Differential Revision: D52598104
fbshipit-source-id: a551bbdda7f7b76d1647036137983e39e612ea45
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42708
When pressing `r` on simulator in Bridgeless mode, we have a race condition between:
- RCTKeyCommands evaluating the blocks to be invoked
- ReactNative invalidating the DevMenu with the list of RCTKeyCommands (on which ReactNative is iterating).
The fix checks which commands need to be executed, stores them in an array and then iterates on the array, which is local to the function call, avoiding any concurrency issue.
## Changelog:
[iOS][Fixed] - Refactored RCT_handleKeyCommand to avoid concurrency issues
Reviewed By: motiz88
Differential Revision: D53186262
fbshipit-source-id: 60ae8974a9df7289395c8a9e9abe2e34e4c40309
Summary:
This API is better implemented as a component: PopupMenuAndroid. Please see the ancestor diff D52712758.
Changelog: [Android][Deprecated] Deprecate UIManager.showPopupMenu, and UIManager.dismissPopupMenu
Reviewed By: mdvacca
Differential Revision: D52887565
fbshipit-source-id: 42da6bdaa707395c5694ec8ae3eb77b64cdefb69
Summary:
In React Native 0.75, we will remove UIManager.showPopupMenu(), UIManager.dismissPopupMenu().
To replace that API, we are introducing this <PopupMenuAndroid> component. This component works in both Fabric and Paper!
For the usage, please see PopupMenuAndroidExample.js.
Changelog: [Android][Added] - Introduce PopupMenuAndroid to replace UIManager.showPopupMenu()
Reviewed By: mdvacca
Differential Revision: D52712758
fbshipit-source-id: a87628a168d64fabbcc4d0f7b694fa639a927448
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42716
Migrates this to the new flag system just added.
Made a quick change to the Android template, to mark Kotlin accessors as `JvmStatic` to make calling from Java more idiomatic.
Next diff will wire to MC.
Changelog: [Internal]
Reviewed By: rubennorte, mdvacca
Differential Revision: D53198874
fbshipit-source-id: 6ab5b279d9ac59733c6e820c25be72383ce0e54a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42626
Right now this is done by some combination of string splitting, JS side regexing, etc. This will not scale for math expressions, and gets more and more annoying when we try to add more.
In preparation for adding more units, this adds a tokenizer/lexer for a subset of CSS grammar, based on the spec. This is not hooked up to anything yet, and doesn't add a parser.
The algorithm uses a subset of the comprehensive instructions provided at https://www.w3.org/TR/css-syntax-3/#tokenizer-algorithms as a reference, with some major simplifications.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D53030661
fbshipit-source-id: c48bc572c5e02daee0b05e91830f2441528193d1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42651
Lots of boilerplate to define hash functions for different enums, so we can use them in `hash_combine`. This should not be needed, and seems like it might have been an artifact of older C++ version of standard library with bugs.
https://en.cppreference.com/w/cpp/utility/hash
> In addition to the above, the standard library provides specializations for all (scoped and unscoped) enumeration types. These may be (but are not required to be) implemented as std::hash<std::underlying_type<Enum>::type>.
Also moves `hash_combine` SFINAE to concepts for clarity and better error messages.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D53074535
fbshipit-source-id: 5fcb653dbe4aa51aa3d9d96f1511da3b7541270d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42694
D53115471 commited all the automatically fixable lints by `ANDROIDLINT`. When I looked again, closer, there was one automatic fix that I'm fairly sure is incorrect.
Before:
`outTransform.postTranslate((int) (dx + 0.5f), (int) (dy + 0.5f));`
After:
`outTransform.postTranslate((dx + 0.5f), (dy + 0.5f));`
I think the linter did this because the underlying API accepts a float, so this was (incorrectly) seen as an extraneous cast causing precision loss, but the previous behavior was using the cast and addition to round the float, instead of adding 0.5 to it.
This replaces the call with an explicit rounding, for the same behavior as before (though, I'm not sure if the rounding is intentional, since in and out are both fp).
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D53158801
fbshipit-source-id: d268a5c429663dd7da0bfce2d717589986601196
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42616
PropsParserContext is an entity in Core with a lot of baggage. We used it in graphics only to access the `surfaceId` and the `contextContainer`. We don't need to bring to graphics the whole dependencies of core due to these two parts.
This change break the dependency by passing along only the elements that we actually need.
## Changelog
[Internal] - break dependencies between graphics and core by removing the include of the PropsParserContext
Reviewed By: sammy-SC
Differential Revision: D52999204
fbshipit-source-id: a4b92fc11238f5caa63e39a6e286273ab671c8de
Summary:
## Changelog: [Internal] Generated 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
Pull Request resolved: https://github.com/facebook/react-native/pull/42709
Reviewed By: huntie
Differential Revision: D53188549
Pulled By: blakef
fbshipit-source-id: 4d5eab7d393777d14c2848b33626dfa7c3be5b02
Summary:
fixed homepage url in package.json file of community cli plugin.
## Changelog:
[GENERAL][CHANGED] - changed community cli plugin homepage url.
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/42696
Test Plan: community-cli-plugin homepage url must be opened correctly.
Reviewed By: rubennorte
Differential Revision: D53179709
Pulled By: huntie
fbshipit-source-id: 7949a897d4fe1da228fce323fa8bb32640194273
Summary:
Just small fix for those who are copy & pasting commands from error message.
## Changelog:
[INTERNAL] [CHANGED] - Update erorr message to use `npx` when calling `react-native`
Pull Request resolved: https://github.com/facebook/react-native/pull/42691
Test Plan: _
Reviewed By: cipolleschi
Differential Revision: D53177186
Pulled By: cortinico
fbshipit-source-id: e680cde81fde1f560dfeb1a85c8ad90090d69653
Summary:
Cocoapods 1.15 (https://github.com/facebook/react-native/issues/42698) current breaks the build, limit to version >= 1.13 & < 1.15
This is currently broken and affecting users, we'll remove this limit once Cocopods fixes the regression. It's currently blocking 0.73.3.
## Changelog:
[iOS][Fixed] don't allow cocoapods 1.15.
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/42702
Test Plan:
```
bundle exec pod install
```
Reviewed By: cipolleschi
Differential Revision: D53180111
Pulled By: blakef
fbshipit-source-id: 4c5dd11db6d208e8d71249443a8f85e601913abd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42690
Issues triggered by `InspectorProxy*` tests under `packages/dev-middleware` (T169943794) can be root-caused to `dev-middleware` performing Babel registration within a test run, after Jest has hooked its own transformer.
Babel registration is only required when running this code (`dev-middleware`, etc) directly from source - we already have the `BUILD_EXCLUDE_BABEL_REGISTER` mechanism to strip it out from production builds, but we currently don't prevent registration under tests, where Jest's transformer should be allowed to do its work.
This adds the same `babel-plugin-transform-define` mechanism that we use for production builds to the Jest transformer.
Changelog:
[Internal] Prevent inadvertent Babel registration during running of repo tests
Reviewed By: huntie
Differential Revision: D53125777
fbshipit-source-id: 1f0a20315c96edaf79054e29a80c7a9561e5b352
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42681
CI failures in Windows JS tests recently (https://github.com/facebook/react-native/pull/41463) were caused by the triggering of Babel registration during tests, due to an import of `packages/dev-middleware` (index), breaking subsequent transformation of other tests.
## Root cause
Example of a problematic import:
https://github.com/facebook/react-native/blob/a5d8ea4579c630af1e4e0fe1d99ad9dc0915df86/packages/dev-middleware/src/__tests__/ServerUtils.js#L15
..which triggers a Babel registration:
https://github.com/facebook/react-native/blob/a5d8ea4579c630af1e4e0fe1d99ad9dc0915df86/packages/dev-middleware/src/index.js#L16-L18
That registration behaves differently on Windows due to the `ignore: [/\/node_modules\/\]`, which doesn't match against Windows path separators - Babel matches against system separators.
In particular, this changed whether `node_modules/flow-parser` was transformed when loading the RN Babel transformer. Transforming this file causes a `console.warn` from Babel due to its size:
> [BABEL] Note: The code generator has deoptimised the styling of /Users/robhogan/workspace/react-native/node_modules/flow-parser/flow_parser.js as it exceeds the max of 500KB.
This throws due to our setup:
https://github.com/facebook/react-native/blob/a5d8ea4579c630af1e4e0fe1d99ad9dc0915df86/packages/react-native/jest/local-setup.js#L27
This all manifests as the first test following a Babel registration (within the same Jest worker) that requires the RN Babel transformer throwing during script transformation.
## This change
This is the minimally disruptive change that makes Babel registration behaviour consistent between Windows and other platforms. The more durable solution here would be *not* to rely on any Babel registration for Jest, which has its own `ScriptTransformer` mechanism for running code from source. Given the fragile way our internal+OSS Babel set up hangs together that's a higher-risk change, so I'll follow up separately.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D53124578
fbshipit-source-id: 074a8e139e506a5dceec13f07d412599fb292d92
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42675
`ANDROIDLINT` config now has a base setup for RN. This enables it in arc linter, and fixes automatically fixable issues.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D53115471
fbshipit-source-id: 2556c21770f7c7ca54d1bccfff527d39df20101e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42686
D53072714 accidentally removed this call, which sets the values for props which have duplicates, and some precedence between them.
This organization is janky, and will be removed in D53073913 where we decuple the props from Yoga style (so the precedence and parsing order becomes a lot more sane).
Changelog:
[Android][Fixed] - Restore missing call to `convertRawPropAliases`
Reviewed By: mdvacca
Differential Revision: D53144603
fbshipit-source-id: 85da722b23992ea75fb681f1db15e62a0daa2a51
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42685
This diff fixes the TextInput-textStyles-e2e test.
The rootcause of this issue is that we were updating the lineHeight of ReactEditText (AppCompatEditText) when lineHeight is set as a prop from React.
This is a problem, because one one side lineHeight is managed by React Native (setting styles in the spannables) and on the other side we ar calling setLineHeight on AppCompatEditText, which breaks the rendering.
We should only manage lineHeight using RN styles, that's why I'm removing call to super.setLineHeight()
Changelog: [internal] internal
Reviewed By: NickGerleman
Differential Revision: D53142429
fbshipit-source-id: cedf803171a490afa67252e9e7f83749502326e6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42628
Changelog: [iOS][Deprecated] Retrieving initial notification requires UNUserNotificationCenterDelegate setup instead of reading UIApplicationLaunchOptionsLocalNotificationKey
# how to migrate:
if you are currently using `getInitialNotification` to check the notification on an app start (warm or cold), you will need to do a migration.
have an object become the delegate of `UNUserNotificationCenterDelegate`. you can use your app's `AppDelegate` to do this.
then, override `userNotificationCenter:didReceiveNotificationResponse:withCompletionHandler:`. in the implementation, add these lines:
if ([response.actionIdentifier isEqualToString:UNNotificationDefaultActionIdentifier]) {
id module = _reactHost ? [[_reactHost getModuleRegistry] moduleForName:"PushNotificationManager"]
: [_bridge moduleForClass:[RCTPushNotificationManager class]];
if ([module isKindOfClass:[RCTPushNotificationManager class]]) {
RCTPushNotificationManager *pushNotificationManager = (RCTPushNotificationManager *)module;
pushNotificationManager.initialLocalNotification = response.notification;
}
}
# reasoning:
when you start an app from a push notification, the `UIApplicationLaunchOptionsLocalNotificationKey` in `application:didFinishLaunchingWithOptions:` will contain the notification metadata that started the app. additionally, this was stored on the bridge, which is not compatible with the new architecture. however, `UIApplicationLaunchOptionsLocalNotificationKey` has been deprecated since iOS 10, which this PR aims to address.
apple's supported API to do this is `userNotificationCenter:didReceiveNotificationResponse:withCompletionHandler:` which is on `UNUserNotificationCenterDelegate`. this is a significant change from a pull to push model. in order to make this change without having to rearchitect the product layer, we're going to store the notification on the notification native module.
another caveat is that the API follows the delegation pattern, not the listener pattern. that means we can't make our notificaiton native module the delegate here - the app will probably need `UNUserNotificationCenterDelegate` to be a top level object - usually the scope of the app delegate.
in future, i actually think we need to unify this with `handleLocalNotificationReceived:`, but right now there's forked handling between platforms and some product code is only using the pull model, so this is still the minimum change in the product layer.
Reviewed By: ingridwang
Differential Revision: D52897071
fbshipit-source-id: 579578d1b3128c5f7e81249c75cf7655b8e360e2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42684
This addressed threading issue like this:
```
Attempting to set an overrideUserInterfaceStyle from a background thread. Modifying a view controller from a background thread is not supported
```
Changelog: [iOS][Fixed] Fixed potential threading issues accessing UIKit from background in RCTAlertManager
Reviewed By: philIip
Differential Revision: D52999194
fbshipit-source-id: 8ce8a89ef932ca9b75cb93d3c9f102a6b0494580
Summary:
Move all `ReactSpan` subclasses to a separate folder.
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.
I'm adding a new span class later, which was the direct motivation for this change.
## 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] - Move all `ReactSpan` subclasses to a separate folder
Pull Request resolved: https://github.com/facebook/react-native/pull/42594
Reviewed By: mdvacca
Differential Revision: D53123733
Pulled By: cortinico
fbshipit-source-id: 10db214a520d157c231e6f3b97948b4209a7ad4b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42678
Changelog: [internal]
This is a re-application of https://github.com/facebook/react-native/pull/42430, which had to be reverted because of crashes in optimized builds on Android:
```
Abort Reason: terminating due to uncaught exception of type facebook::jni::JniException: java.lang.ClassNotFoundException: com.facebook.react.internal.featureflags.ReactNativeFeatureFlagsProvider
```
The root cause of that was that that class was removed because it wasn't statically referenced from Kotlin/Java, but it was dynamically referenced from C++ (in `ReactNativeFeatureFlagsProviderHolder.cpp`).
This applies the same changes + adds `DoNotStrip` annotations for the affected class and all its methods.
Reviewed By: huntie
Differential Revision: D53122992
fbshipit-source-id: efc4d5636a3f2d39b86e9c098bff408b6688b80b
David Vacca
Jack Pope
Alex Hunt
Rubén Norte
zhongwuzw
Pieter De Baets
Moti Zilberman
Riccardo Cipolleschi
Nicola Corti
D N
Oskar Kwaśniewski
ankit-tailor
Ramanpreet Nara
Nick Gerleman
Samuel Susla
Ilia Vorobev
Blake Friedman
HoonJoo
szymonrybczak
Dmitry Rykun
Rob Hogan
Phillip Pan
Kevin Gozali
Wojciech Lewicki
Jakub Trzebiatowski