Summary:
Adds `flow` (or `noflow`) to all files in this directory and ensures that Flow succeeds (by adding type annotations, using minor refactors, or suppressing errors due to intentionally dynamic logic).
This will help improve type safety when making changes both in these files as well as files that these depend on.
Changelog:
[Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/51652
Test Plan:
Ran Flow and Jest tests successfully:
```
$ yarn flow
$ yarn test
```
Ran a Jest unit test internally to make sure they work with our internal environment setup:
```
$ cd ~/fbsource
$ js1 test /View-test.js
```
Reviewed By: javache
Differential Revision: D75488160
Pulled By: yungsters
fbshipit-source-id: 536cef9699acfa1edcd3dcf61c53ebcd92f560f9
Summary:
This PR adds a new cloning method, allowing for updating multiple nodes in a single transaction. It works in two phases:
1. Find which nodes have to be cloned (i.e. nodes given on input and all their ancestors)
2. Clone nodes in the bottom up order - so that every node is cloned exactly once
So the idea is that when we want to update all the red nodes in this picture, we first find the nodes in the green area and the clone only them in the correct order (children are cloned before parents):

Adapting this method [brought a huge performance gain to reanimated](https://github.com/software-mansion/react-native-reanimated/pull/6214). I want to upstream it, so that:
1. we can optimize it further, because making it a part of the `ShadowNode` class gives us access to the parent field in `ShadowNodeFamily` so we can traverse the tree upwards, allowing for a optimal implementation of the first phase (in reanimated we repeatedly call `getAncestors`, which revisits some nodes multiple times)
2. the community can use it
A naive approach that calls `cloneTree` for every node is much slower, as it has to repeat many operations.
## Changelog:
[GENERAL] [ADDED] - Added `cloneMultiple` to `ShadowNode` class.
Pull Request resolved: https://github.com/facebook/react-native/pull/50624
Test Plan:
I tested it with the following reanimated implementation and everything works fine:
<details>
```c++
const auto callback =
[&](const ShadowNode &shadowNode,
const std::optional<ShadowNode::ListOfShared> &newChildren) {
return shadowNode.clone(
{mergeProps(shadowNode, propsMap, shadowNode.getFamily()),
newChildren
? std::make_shared<ShadowNode::ListOfShared>(*newChildren)
: ShadowNodeFragment::childrenPlaceholder(),
shadowNode.getState()});
};
return std::static_pointer_cast<RootShadowNode>(
oldRootNode.cloneMultiple(families, callback));
```
</details>
I would like to add tests for it, but I'm not sure what's the best approach for that in the repo.
Reviewed By: mdvacca
Differential Revision: D75284060
Pulled By: javache
fbshipit-source-id: 0704c4386c3041eb368adf6950d46de197479058
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51657
changelog: [internal]
Introduce a new ShadowNodeTraits: `Unstable_uncullableView` and `Unstable_uncullableTrace`. As the name suggests, this is not stable API yet.
When a shadow node sets this trait, it will be opted out of view culling together with its ancestors all the way to the root.
The trait is propagated to its parent in 4 different places:
1. When node is first created.
2. When node is cloned.
3. When child is appended.
4. When child is replaced.
we can safely do it only in those places because React constructs nodes from bottom up. We are leveraging this implementation detail here but if that changes in the future, a traversal will be required.
Alternative solution considered here was a traversal of shadow tree during commit phase to propagate `Unstable_uncullable` trait. This could be done in a separate traversal or as part of layout phase where layout information is copied out of Yoga tree. Leveraging the fact that React is cloning bottom up makes the implementation simpler.
If React changes its cloning approach in the future, this will be caught by tests.
Reviewed By: lenaic
Differential Revision: D75476847
fbshipit-source-id: f1e98804565c140c64945662af0247b1bd0e1882
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51656
This fixes an issue with the internal networking layer when `enableModuleArgumentNSNullConversionIOS` is enabled, as we'd try to pass `NSNull` as trackingName instead of omitting it.
`
Changelog: [Internal]
Reviewed By: fabriziocucci
Differential Revision: D75516619
fbshipit-source-id: 91a3bba32772fdd66edde1e24b7edd977918f727
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51639
changelog: [internal]
### Fix Crash in View Culling
This diff fixes a crash that occurs when a view is unflattened or flattened in a deep hierarchy where each node has a top offset.
The problem is that nodes passed to *calculateShadowViewMutationsFlattener* via argument *unvisitedOtherNodes* have their positions calculated in a different coordinate space and the view culling algorithm does not have the correct data to determine visibility of a node. To fix this, we pass another argument to *calculateShadowViewMutationsFlattener* which does have original view culling context with which these nodes had their position calculated.
Reviewed By: javache
Differential Revision: D75455704
fbshipit-source-id: 925f14dfdc6c2b669c89e100629291921f27cd1e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51622
We currently support an optional 3rd params for `target_compile_reactnative_options` which allows to specify a LOG_TAG macro.
No one is actually reading that Macro. The only usage would be logging from the Android SDK which we don't explicitely use.
Here I'm updating our build to specify a LOG_TAG as `ReactNative` for all the targets without allowing to customize it as it just complicates our build setup.
Changelog:
[Internal] [Changed] -
Reviewed By: mdvacca
Differential Revision: D75445577
fbshipit-source-id: a426ce77ba6d1dfd0800e874d9f7838bfdc5b877
Summary:
RuntimeExecutor.h has sync ui thread utils:
* executeSynchronouslyOnSameThread_CAN_DEADLOCK
The ios platform has js -> ui sync calls. This util, when it executes concurrently with those sync calls, deadlocks react native.
On ios, we're going to resolve these deadlocks, which'll involve customizing this util: D74769326. Therefore, this diff forks an implementation of these sync ui thread utils for ios.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D74901907
fbshipit-source-id: f502df4216e9ba57f458435c696a2f086becf24f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51633
To fully support props diffing for a component, the component's Props implementation needs to implement the prop diffing for the derived class.
Because all Props classes extend the ViewProps, all Props classes implement the `getDiffProps` function. To support testing that the props diffing implementation support all properties of the derived Props class for the component being mounted, this diff adds the virtual function `getDiffPropsImplementationTarget` which returns the `ComponentName` that the `getDiffProps` function supports.
This removes the need for a hard-coded list of components that support props diffing and enables the use of codegen to conditionally enable props diffing.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D75465020
fbshipit-source-id: 2850a76f1036cfe930c3c69b98d478ef86a2d457
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51650
This diff adds support to diff props with Point type
changelog: [internal] internal
Reviewed By: mlord93
Differential Revision: D75469451
fbshipit-source-id: a6844b691d8e32326d04c2bd51e6509980feb611
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51642
This diff asserts that ImageRequest won't be used as prop type
changelog: [internal] internal
Reviewed By: mlord93
Differential Revision: D75469453
fbshipit-source-id: e9e46bc8806e00c104b76825445fe72779106220
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51551
This allows hit RN's hit testing to find nested spans, and click them.
This mechanism is fully separate from the one used by a11y virtual views, and ClickableSpan, such as those added for links via dataDetectorType (and also the `link` role).
When we do have a link accessibilityRole, that ClickableSpan hit test seems to prevent the React one, and we only activate the onPress once (but then add keyboard interaction, press visual, and add to the a11y tree).
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D75257326
fbshipit-source-id: 0c693f581ec121cf4b4e3e2040d141985118224f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51635
Enables a feature flag by default, that reduces the memory usage of`Animated`. For more details, see: https://github.com/facebook/react-native/pull/49184
Changelog:
[General][Changed] - Enabled a feature flag that optimizes `Animated` to reduce memory usage.
Reviewed By: jehartzog
Differential Revision: D75466724
fbshipit-source-id: 3fdb57f394448bbd0530dcb558a58958010d0edd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51514
This util can execute arbitrary runtimeWork, which can throw.
In the future, we'll also make these utils execute ui blocks posted from the javascript thread. And those will be able to throw.
Therefore, let's remove the noexcept. Otherwise, if an exception bubbles up to this util, it will just crash this app.
Changelog: [General][Changed] - RuntimeExecutor: Remove noexcept from sync ui thread utils
Reviewed By: javache
Differential Revision: D75183993
fbshipit-source-id: 6c3a319fe3a76165a265815e6343220cf9db6fde
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51429
If we use promises, I believe the code is just easier to understand.
Changelog: [Internal]
Reviewed By: javache, yungsters
Differential Revision: D74941734
fbshipit-source-id: a9bc5ac715c84a5a92f8f1c6635ebef9fe538377
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51626
This just migrates the `MapBuilder` file to Kotlin.
Users on Kotlin should still use the built-in collection extensions rather than using this class that will go away at some point in the future.
Changelog:
[Internal] [Changed] -
Reviewed By: fabriziocucci
Differential Revision: D75448739
fbshipit-source-id: 2bfa24ad9bd37bd571ea4551bd9a10e848841e0a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51629
Changelog: [internal]
The native module will never be defined in tests, so there's no point in logging this warning there.
Reviewed By: rshest
Differential Revision: D75451414
fbshipit-source-id: cdc1f674d01fcaf58c1c2342c994d95e6b3b6847
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51623
This fix relaxes some dependencies on React-hermes that should not be in the code.
## Changelog:
[Internal] - Remove dependencies from React-Hermes when they are not needed.
Reviewed By: cortinico
Differential Revision: D75447910
fbshipit-source-id: 6d7695f0e2b6c936b4c5ed9e70261f1d3b28a3d0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51625
This just migrates this class to Kotlin, which is also the last class in this package.
Changelog:
[Internal] [Changed] -
Reviewed By: rshest
Differential Revision: D75448161
fbshipit-source-id: d5457dd8017fd459d166d2945ff440c303943db2
Summary:
As I reviewed some examples, I noticed that this one's dark mode could be improved, and the code could be modernised a bit as well by converting its classes into functional components.
## Changelog:
[INTERNAL] - Fix InputAccessoryView example in dark mode and convert to functional components
Pull Request resolved: https://github.com/facebook/react-native/pull/51583
Test Plan:
<details>
<summary>Screenshots</summary>
| Dark | Light |
|--------|-------|
|  |  |
</details>
Reviewed By: fabriziocucci
Differential Revision: D75404561
Pulled By: cortinico
fbshipit-source-id: 3318e9869919e99055e47b59c89de0b22976f142
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51619
RNTester Android is currently instacrashing in OSS due to 3rd-party packages not having the `RN_SERIALIZABLE_STATE` definition.
That's because the `INTERFACE` definition is not properly propagated on the prefab boundaries.
This was happening for `react-native-popup-menu-android` and `react-native-test-library` and will also happen for Codegen libraries.
This fixes it. 3p developers with custom CMake files will also have to use the `target_compile_reactnative_options` functions to make sure the compilation flag are properly populated.
Changelog:
[Android] [Breaking] - Correctly propagate RN_SERIALIZABLE_STATE to 3rd party CMake targets. Users with custom CMake and C++ code should update to use `target_compile_reactnative_options` inside their CMakeLists.txt files. See the 0.81 release notes for more information.
Reviewed By: cipolleschi
Differential Revision: D75441245
fbshipit-source-id: 3855fdf11cbe7f4b01f68e0dde68b63b3240ad35
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51616
changelog: [internal]
doesn't seem to be used by anything. let's delete it.
Reviewed By: javache
Differential Revision: D75218695
fbshipit-source-id: eeb3a826f06456be8de6941fa95d6ffc7917dcf8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51615
changelog: [internal]
rename methods to reflect that they are getters and mark them as noexcept const
Reviewed By: rshest
Differential Revision: D75217535
fbshipit-source-id: c7d77060d0f54f8043a7552eec7e2b231cb5b7bf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51618
Changelog: [internal]
This sets the argument to `pullTransaction` to `true` in the cases where the call is done from the JS thread and the transactions are mounted asynchronously in the UI thread (basically platforms using the push model for mounting coordinator).
It was missing on an experiment for Android (compatibility mode for Props 2.0)
Reviewed By: lenaic
Differential Revision: D75439105
fbshipit-source-id: a106a3a674e44b0cf2603782302343f60ee5450e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51620
The spirit of "Decouple Hermes from JSI nd simplify dependencies" is good, but the problem is that when we ships prebuilds of hermes-engine, it tries to load `libjsi.dylib` and that library is not available.
{F1978594163}
I'll have to investigate more how to properly decouple Hermes prebuilds and how to pass jsi to Hermes and react-native. We might have to decouple it further and have a separate job that builds jsi and feed it to hermes.
This problem will go away with SwiftPM, though, so probably not worth solving this.
## Changelog:
[Internal] - Fix nightlies with a backout
Reviewed By: cortinico
Differential Revision: D75442056
fbshipit-source-id: f1085be8247c0974854254c6bd631ca258488beb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51614
`JSEventLoopWatchdog` is not used in react-native package. This diff moves it to rn-tester which previously deep imported it from react-native (which we want to avoid).
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D75410548
fbshipit-source-id: d4996742578e3b068e7acad9479394388b1907ac
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51603
In `rn-tester` TextAncestor was used to create a inlineView wrapper:
```js
function InlineView(props) {
return (
<TextAncestor.Provider value={false}>
<View {...props} />
</TextAncestor.Provider>
);
}
```
however, it is already done in View.js and TextAncestor shouldn't be used outside of react-native package:
```js
if (hasTextAncestor) {
return <TextAncestor value={false}>{actualView}</TextAncestor>;
}
return actualView;
```
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D75408231
fbshipit-source-id: 7f12278296dcfe56246f6b7065f5a094e4099f7a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51602
Changelog: [GENERAL][FIXED] - Fixed the generated type definitions for `Animated.FlatList` and `Animated.SectionList` to correctly infer item types.
Current definitions for animated list components cast away their generic definitions, preventing the types to be inferred from usage. This diff addresses that.
Reviewed By: huntie
Differential Revision: D75407762
fbshipit-source-id: c86f20298ded707971c05a78d025a63e82fe2a64
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51611
changelog: [internal]
AnimationDriver does not use enable_shared_from_this, let's remove it. Also mark a few methods as noexcept and const.
This helps with C++ binary size.
Reviewed By: rshest
Differential Revision: D75172851
fbshipit-source-id: d6552cd577371a51c3fa3b394b451d7ed2b61e44
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51610
changelog: [internal]
No need to store uiManagerBinding in a shared_ptr. Let's just get it, pass it to classes that need it and not store it.
This helps with C++ binary size a little bit.
Reviewed By: rshest
Differential Revision: D75174567
fbshipit-source-id: 1d4e5a9f89ba2f2d2eb733eac9d103ee97550d0f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51609
changelog: [internal]
NativeAnimatedNodesManagerProvider is not subclassed. Let's remove virtual methods and make it a final class.
Reviewed By: lenaic
Differential Revision: D75169108
fbshipit-source-id: 32121cf372ba94c8a7b86c61fd96efd75560f789
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51517
The Props 2.0 implementation for ScrollView added two missing props which were Android specific.
This diff moves these to a separate HostPlatformScrollViewProps class so that other platforms wouldn't include them
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D75183132
fbshipit-source-id: 44d0e0aa974e69f8584ad6bd681fad100c3493d8