Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43730
# Changelog:
[Internal] -
As in the title, converts corresponding type declarations in `react/devsupport/LogBox*.java` to Kotlin.
Reviewed By: NickGerleman
Differential Revision: D55574528
fbshipit-source-id: 56cf5de75d18cd73929cb7f0c9375a3f62e83574
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43754
Moves off of deprecated `DisplayMetrics.scaledDensity` API to builtin font scaling API, while still clamping to max multiplier using previous logic.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D55623674
fbshipit-source-id: 2668eea8dbd154cc046e2c515323ad66b289dc64
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43729
# Changelog:
[Internal] -
As in the title, converts corresponding type declarations in `react/uimanager/*Util.kt` to Kotlin.
Reviewed By: tdn120
Differential Revision: D55574531
fbshipit-source-id: 974234bd57c77e863aa723388e48ffc455e73a96
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43728
# Changelog:
[Internal] -
As in the title, converts corresponding type declarations in `react/uimanager/layoutanimation/*Type.kt` to Kotlin.
Differential Revision: D55574530
fbshipit-source-id: 8527b5c9b491435c60ed9c05092ffeccd7552f9c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43727
# Changelog:
[Internal] -
As in the title, converts this one particular Java file to Kotlin.
Reviewed By: arushikesarwani94
Differential Revision: D55574526
fbshipit-source-id: 04af5b870670a5560eaba7ab8c029c580032d09a
Summary:
## Context
Prior, ReactContext used to implement bridge logic.
For bridgeless mode, we created BridgelessReactContext < ReactContext
## Problem
This could lead to failures: we could call bridge methods in bridgeless mode.
## Changes
Primary change:
- Make all the react instance methods inside ReactContext abstract.
Secondary changes: Implement react instance methods in concrete subclasses:
- **New:** BridgeReactContext: By delegating to CatalystInstance
- **New:** ThemedReactContext: By delegating to inner ReactContext
- **Unchanged:** BridgelessReactContext: By delegating to ReactHost
## Auxiliary changes
This fixes ThemedReactContext in bridgeless mode.
**Problem:** Prior, ThemedReactContext's react instance methods did not work in bridgeless mode: ThemedReactContext wasn't initialized in bridgeless mode, so all those methods had undefined behaviour.
**Solution:** ThemedReactContext now implements all react instance methods, by just forwarding to the initialized ReactContext it decorates (which has an instance).
Changelog: [Android][Removed] Delete ReactContext.initializeWithInstance(). ReactContext now no longer contains legacy react instance methods. Please use BridgeReactInstance instead.
---
Reviewed By: fkgozali
Differential Revision: D55505416
fbshipit-source-id: ce1e3ab379eb788d26130dd44a66544aada3db02
Summary:
## Context
Prior, ReactContext used to implement bridge logic.
For bridgeless mode, we created BridgelessReactContext < ReactContext
## Problem
This could lead to failures: we could call bridge methods in bridgeless mode.
## Changes
Primary change:
- Make all the react instance methods inside ReactContext abstract.
Secondary changes: Implement react instance methods in concrete subclasses:
- **New:** BridgeReactContext: By delegating to CatalystInstance
- **New:** ThemedReactContext: By delegating to inner ReactContext
- **Unchanged:** BridgelessReactContext: By delegating to ReactHost
## Auxiliary changes
This fixes ThemedReactContext in bridgeless mode.
**Problem:** Prior, ThemedReactContext's react instance methods did not work in bridgeless mode: ThemedReactContext wasn't initialized in bridgeless mode, so all those methods had undefined behaviour.
**Solution:** ThemedReactContext now implements all react instance methods, by just forwarding to the initialized ReactContext it decorates (which has an instance).
Changelog: [Android][Removed] Delete ReactContext.initializeWithInstance(). ReactContext now no longer contains legacy react instance methods. Please use BridgeReactInstance instead.
Reviewed By: javache
Differential Revision: D53145010
fbshipit-source-id: 2405bc24afb00864117d3c504fc9c4cbffd7203a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43661
# Changelog: [Internal]
1. Remove `BridgelessDebugReactPackage.java`, this was added in D43407534. Technically, its the same as `DebugCorePackage.java`.
2. `ReactInstance` to add `DebugCorePackage`, so `DebuggingOverlay` view manager will be included in the bridgeless build.
3. Fix `RNTesterApplication.kt` to NOT create `MyLegacyViewManager` for every possible viewManagerName, apart from `"RNTMyNativeView"`, return null instead.
Reviewed By: cortinico
Differential Revision: D55375350
fbshipit-source-id: 1d3cb6b5ad3c0248df1def9f37c8c49b308f4473
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43653
Changelog: [internal]
This will allow us to clean up some code in `UIManager` (using methods in the native module instead) and prepare to use the DOM APIs in OSS behind a feature flag.
This doesn't enable the DOM APIs in OSS, only the native module.
Reviewed By: javache
Differential Revision: D55365252
fbshipit-source-id: 70ec0eb022df586ad554c5b8ce6915b8ceddef5f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43251
Integrates the modern CDP backend with `CatalystInstanceImpl` (the React Native instance implementation) on Android.
This complete the modern CDP integration for Bridge.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D51458010
fbshipit-source-id: 6f73868da9d0d4cc5d086a4569c78444cb1b83ec
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43657
This include is not correct and is breaking the OSS build
Changelog:
[Internal] [Changed] - Fix header import inside ReactInstanceManagerInspectorTarget.h
Reviewed By: rshest
Differential Revision: D55368321
fbshipit-source-id: 0530257ad5c548476beb882174d73842775b3726
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43626
The things that create ReactApplicationContext should instead create BridgeReactContext.
Long-term, ReactApplicationContext will be abstract. This diff pulls noise out from that eventual diff.
Changelog: [Internal]
Reviewed By: arushikesarwani94
Differential Revision: D55218591
fbshipit-source-id: d359c794f3da4a1ecb2fa8edbed5eeeb620b137b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43627
Eventaully, ReactApplicationContext.initailizeWithInstance() will be moved to BridgeReactContext.
Doing the migration up-front to remove noise from the eventual diff.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D55218593
fbshipit-source-id: c542c44cf8b36b9dc2a01db2bf6173639fb8698a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43624
Eventually, we will move all bridge methods to BridgeReactContext.
Long-term, ReactApplicationContext and ReactContext will become abstract. And these two contexts will only contain methods common to both modes.
Changelog: [Android][Added] Introduce BridgeReactContext
Reviewed By: cortinico
Differential Revision: D55218592
fbshipit-source-id: 731d4940d492a1ed3f855c9a181d2a6f9eeb9623
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43250
Integrates the modern CDP backend with `ReactInstanceManager` on Android.
`ReactInstanceManager` is equivalent to the CDP page / `HostTarget` concept, therefore we register the `addPage`/`removePage` calls with this object's lifecycle.
Implementation notes:
- `ReactInstanceManagerInspectorTarget` is created to avoid converting `ReactInstanceManager` to JNI (impacting tests).
- Its constructor receives a `TargetDelegate` object, so that we avoid passing the entire `ReactInstanceManager` class through (avoids cyclic dependency from `com.facebook.react.bridge` to `com.facebook.react`).
Changelog:
[Internal] - Register `ReactInstanceManager` with modern CDP backend
Reviewed By: motiz88
Differential Revision: D51456960
fbshipit-source-id: 942255bb2487fdc581eb4fa0903c8e68106f8b35
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43615
This class is used for a one-time setup of bindings into the jsi::Runtime. The lambda will retain ownership of any java components required, and we can rely on the teardown of the JS runtime to clean up any dependencies.
Changelog: [Internal]
Reviewed By: dmytrorykun
Differential Revision: D55241233
fbshipit-source-id: f7541f28277307be9b3a5f4f780c7eca1a467c57
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43614
Storing a global_ref to `jThis` in a JNI hybrid object leads to a reference cycle which cannot be cleaned up by Java GC. The Java object will keep the C++ object alive and vice versa.
In this class, we didn't seem to need this reference anyway.
Changelog: [Internal]
Reviewed By: dmytrorykun
Differential Revision: D55241232
fbshipit-source-id: 933521ed1483c149f693988ca17f4c53565dbfe0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43612
This class is used for a one-time setup of bindings into the jsi::Runtime. The lambda will retain ownership of any java components required, and we can rely on the teardown of the JS runtime to clean up any dependencies.
Changelog: [Internal]
Reviewed By: dmytrorykun
Differential Revision: D55241234
fbshipit-source-id: ee80ca0f91ebe95f8c44874b27912b260f70b572
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43618
Both common and Android implementations of AsyncEventBeat use weak_ptrs
to determine if the object is still valid before invoking the callback.
Move the write to `isBeatCallbackScheduled_` down so it's protected by
that same check.
Changelog: [Internal]
Reviewed By: javache, NickGerleman
Differential Revision: D55226529
fbshipit-source-id: 9e2a34369346d11dcea69d120dfa5935320f9ba1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43642
Changelog: [internal]
This change broke some apps at Meta. Reverting until we figure out a safe way to land this.
Reviewed By: rshest
Differential Revision: D55324557
fbshipit-source-id: 684d3dc3780fc41e2e91f367d97fa5cd392e6638
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43580
Changelog: [internal]
This introduces a new feature flag to commit state updates synchronously from the UI thread (generally) instead of dispatching them to the JS thread to be processed there. We can do this now because we introduced a UI consistency mechanism in D55024832 to JS would see a consistent revision during the execution of a specific task.
Reviewed By: sammy-SC
Differential Revision: D55083029
fbshipit-source-id: 8aa84ddaee383f098252fa679cfb07012ba29bf8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43577
Changelog: [Internal]
This updates all the DOM APIs in React Native (defined in the `NativeDOM` native module) to make use of the UI consistency mechanism introduced in Fabric (if available, otherwise the behavior is the same we have now — we consume the latest version of the tree available).
As part of that work, this creates a new `DOMMethods` class that implements all methods using purely C++ APIs (not JSI), moves a lot of logic that was specific for this functionality from `UIManager` to `DOMMethods` and modifies `NativeDOM` to use this new class.
This should make it easier to add unit tests for `DOMMethods` in the future.
Reviewed By: NickGerleman
Differential Revision: D55077311
fbshipit-source-id: f96bf5f3a97236fd24dbd2315256de4ce979e151
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43581
Changelog: [internal]
This implements a mechanism to ensure that JavaScript tasks have a consistent view of the state of the UI during their execution.
## Context
Fabric allows committing new revisions of the ShadowTree from any thread, but we don't make use of this capability and instead always commit them from the JS thread (e.g.: when we schedule Fabric state updates to update the offset of a list on scroll). This was done to make sure that JS work didn't see changes in the state of the tree at random points during its execution. E.g.:
```
useEffect(() => {
const rect = ref.current.getBoundingClientRect();
// do something
const newRect = ref.current.getBoundingClientRect();
// `rect` and `newRect` should always be the same
}, []);
```
This isn't used by Reanimated at the moment, which means JS can inadvertently see the result of animations in non-specific times during execution.
You can find additional context about this in the [RFC for DOM Traversal & Layout APIs in RN](https://github.com/react-native-community/discussions-and-proposals/blob/main/proposals/0607-dom-traversal-and-layout-apis.md#consistency-and-updates).
This works correctly at the moment, but we introduce a limitation in the execution model to prevent updating the tree synchronously from the main thread. One of the main problems this introduces is that computing intersections (for `IntersectionObserver`) relies on the information in the shadow tree, but this is updated asynchronously on scroll.
There are 2 potential solutions for that problem:
1) Send the timestamp of the scroll even with the state update to backdate the timestamps of the intersections. This could work but introduces more complexity and possibly accuracy problems due to batching those state updates with other changes (e.g.: what happens if we update the state and commit another tree in the same task? should we use the backdated timestamp or wait for mount?).
2) (**Preferred**/ this diff) Allow committing new revisions from any thread, but lock the JS thread into seeing a specific revision, which would only update/progress in specific moments when it's safe. Some of those moments would be:
1) When we start a new JS task.
2) When we commit a new tree from React (JS).
## Changes
This implements the solution outlined in 2), creating a few abstractions to handle what's the current tree that should be visible to JS and to lock/unlock it in specific moments.
More specifically:
* Creates `ShadowTreeRevisionProvider` as an abstract class for APIs consuming the visible revision of the ShadowTree (mainly DOM APIs and layout methods like `measure`, etc.).
* Creates `ShadowTreeRevisionConsistencyManager` as an abstract class to handle what trees are visible (with a `lockRevision` and `unlockRevision` to be called from `RuntimeScheduler` at the beginning and end of each JS task).
* Creates 2 different implementations of these abstractions:
* One that preserves the current behavior (`LatestShadowTreeRevisionProvider`, which just returns the last committed revision at the time of the call).
* One that locks revisions lazily (the first time they're accessed) (`LazyShadowTreeRevisionConsistencyManager`).
Reviewed By: sammy-SC
Differential Revision: D55024832
fbshipit-source-id: b59985bc83714ae7ec915baba72bf92b3d6fa140
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43611
Storing a global_ref to `jThis` in a JNI hybrid object leads to a reference cycle which cannot be cleaned up by Java GC. The Java object will keep the C++ object alive and vice versa.
In this class, we didn't seem to need this reference anyway.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D55240490
fbshipit-source-id: 9ba6f5b4b958cb273ad1923332b7b29a75630aea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43613
Storing a global_ref to `jThis` in a JNI hybrid object leads to a reference cycle which cannot be cleaned up by Java GC. The Java object will keep the C++ object alive and vice versa.
We can replace the reference in this class by using the this pointer passed in when `installJSIBindings` is invoked.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D55241235
fbshipit-source-id: 64883752a87f363a52a9f6661d6ddaa24a56fe62
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43609
When users are building from source for React Native they don't have an ndkVersion variable specified. So we want to fallback to the global NDK version we set for the whole build here.
Changelog:
[Android] [Fixed] - Fix build from source for hermes-engine
Reviewed By: dmytrorykun
Differential Revision: D55240603
fbshipit-source-id: 3c725a164b40e176548af8ada9fcb13d391ef017
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43594
I've been migrating `react-native-view-shot` to Fabric by using the `InteropUiBlockListener`
and I've realized that the interop layer doesn't work well.
1. FabricUIManager needs to implement `UIBlockViewResolver` in order for the interop layer to work correctly.
2. We need to hook `addUIBlock` to the `didDispatchMountItems` callback otherwise the UIBlocks won't be executed at all.
Changelog:
[Android] [Fixed] - Fix InteropUIBlockListener to support react-native-view-shot on Bridgeless
Reviewed By: javache
Differential Revision: D55187939
fbshipit-source-id: d048b4b5eed77fa856fdfac17c0df5f23fd44844
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43563
Fixes https://github.com/facebook/react-native/issues/42874
## Sumary
D9405703 added some custom logic for Flings, to support FlatList scenarios where content is being added on the fly, during Fling animation. This works by allowing start Fling to not have bounds, then correcting/cancelling Fling when overscroll happens over a bound that would normally be allowed.
This has some math to try to determine max content length, and will clamp to this when scrolling over it. This logic is incorrect when content length is less than scrollview length, and we end up snapping to a negative offset.
This change adds clamping, so that we don't snap to negative position in horizontal scroll view. This clamping was already indirectly present on vertical scroll view. https://www.internalfb.com/code/fbsource/[b43cdf9b2fec71f5341ec8ff2d47e28a066f052e]/xplat/js/react-native-github/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/views/scroll/ReactScrollView.java?lines=609
## Test Plan
Above issue no longer reproes. Flinging while content is being added to horizontal FlatList still works correctly.
Changelog:
[Android][Fixed] - Fix Android HorizontalScrollView fling when content length less than ScrollView length
Reviewed By: javache
Differential Revision: D55108818
fbshipit-source-id: 7cf0065f9f92832cc2606d1c7534fc150407b9c9
Summary:
- `rrc_textinput` at the moment points to a wrong subdirectory and needlessly adds a prefix path
- `rrc_text` is missing headers for `attributedstring` which it depends on
## Changelog:
[ANDROID] [FIXED] - Fixed prefab header paths for `rrc_text` and `rrc_textinput`
Pull Request resolved: https://github.com/facebook/react-native/pull/43591
Reviewed By: fkgozali
Differential Revision: D55199580
Pulled By: cortinico
fbshipit-source-id: 85126c00943f82e908a52e05587661597761852e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43520
Refactor ReactDelegate to have a private `getDevSupportManager()` that can also be re-used by `reload()`
This method conditionally provides the correct DevSupportManager in cases of Bridge & Bridgeless
Changelog:
[Internal] internal
Reviewed By: cortinico
Differential Revision: D54967130
fbshipit-source-id: 37d585de33a50b98d01803d3080c5693a8c494b9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43385
`rncore` and `FBReactNativeComponentSpec` contain the same symbols, which leads to conflicts when we try to merge them into a single shared library. Cleanup the duplication and standardize on `FBReactNativeComponentSpec` everywhere. I've left the Android OSS targets as is, to avoid breaking deps.
Changelog: [Internal]
Reviewed By: cortinico, dmytrorykun
Differential Revision: D54630694
fbshipit-source-id: 75cb961ded9fd75508755c0530e29409fef801cf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43504
Changelog: [internal]
We identified the issue in the experiments already, so we can remove this flag.
Reviewed By: sammy-SC
Differential Revision: D54945099
fbshipit-source-id: 4d547569eb3bbfd011f5d6894d87bfa542cac07b