Summary:
## Context
`NativeModuleRegistryBuilder` calls `TurboReactPackage.getNativeModuleIterator()` to access ModuleHolders for all the NativeModules in the `TurboReactPackage`. We then filter out the ModuleHolders that contain `TurboModules`, before using that list to make create the `NativeModuleRegistry`.
## Problem
Creating `ModuleHolders` has the side-effect of actually creating the NativeModule if it requires eager initialization. See [ModuleHolder.java](https://fburl.com/diffusion/4avdtio0):
```
class ModuleHolder {
// ...
public ModuleHolder(ReactModuleInfo moduleInfo, Provider<? extends NativeModule> provider) {
mName = moduleInfo.name();
mProvider = provider;
mReactModuleInfo = moduleInfo;
if (moduleInfo.needsEagerInit()) {
mModule = create(); // HERE!
}
}
```
So, we need to filter out TurboModules before we even create ModuleHolders.
Changelog:
[Android][Fixed] - Refactor TurboModule filtering in NativeModuleRegistryBuilder
Reviewed By: PeteTheHeat, mdvacca
Differential Revision: D18814010
fbshipit-source-id: a120d2b619b9280ba70e21d131dccc5a9fc6346d
Summary:
The TurboModuleManagerDelegate now supports a `getEagerInitModuleNames()` method, which is supposed to return a `java.util.List` containing the names of all NativeModules that require eager initialization. The NativeModuels are created when the `TurboModuleManager` is created. This happens inside `ReactInstanceManager.createReactContext` slightly after the NativeModuleRegistry is created, which is when our legacy NativeModules are eagerly initialized.
All NativeModules declared in `TurboReactPackages` that are wired into the `TurboModules` infra via `ReactPackageTurboModuleManagerDelegate` can use the `ReactModule(needsEagerInit = true)` annotation. Our build pipeline should correctly process the annotation into a `ModuleInfo`, and `ReactPackageTurboModuleManagerDelegate` should correctly forward the eagerly initialized module names to TurboModuleManager.
Changelog:
[Android][Added] - Implement TurboModule eager initialization support
Reviewed By: mdvacca
Differential Revision: D18819552
fbshipit-source-id: b2009a3b8f4e064362d2abeb5281637962531678
Summary:
When the TextInput is updated on the Java side, make sure C++ State gets updated. We do this by making sure that the AttributedString data-structured in mirrored in Java and in C++.
In practice, the AttributedString is copied into Java a few times during initialization, and then after then, 99% of the time Java is writing without receiving updates from C++. This means that we should optimize the Java-to-C++ update path most aggressively in the future.
However, it turns out that for now, at least, we can't reuse NativeWritableMaps/NativeWritableArrays because they're consumed on the C++ side and can't be modified after that. This is a perf improvement for the future.
This allows us the user to edit any fragments, and the changes will flow through C++ State. This also allows us to edit across multiple Fragments.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18785960
fbshipit-source-id: 97b283ec411081eca4d2d7a4cce2b31b5e237c42
Summary:
Fix and simplify `AndroidTextInputShadowNode::getAttributedString` so that it (1) works, and (2) is aligned with the equivalents in the old Java code.
The issue is that we weren't picking up `text` attributes since we're only traversing children and not the TextInput node itself. If a `text` attribute is present it needs to be treated as its own Text node.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18739830
fbshipit-source-id: 4b3bc81dbe8c241c2e06fe5be1f9b50e49132890
Summary:
Motivation: TextInput.js frequently sends commands to views as they're disappearing (`blur`, for instance).
We should fix that in the future, if possible. For now, just log the issue and continue. It shouldn't cause any user-facing issues since 1) it appears that TextInput knows the underlying view is gone; 2) the View has already disappeared so the user can't interact with it, so commands can go safely into the void.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18821448
fbshipit-source-id: 980dbbce8cdb2cc0bb4bf60b3bccc90869208f01
Summary: Making the open source NetworkingModule TM-compatible.
Reviewed By: mdvacca
Differential Revision: D18770987
fbshipit-source-id: 64966f91308e31bdcf9bfa959381d4e40ccb2753
Summary:
There are multiple `DoNotStrip` in Yoga java binding, they aren't needed.
##Changelog:
[Internal][Yoga] Allow redex to optimize more of yoga by removing unneeded DoNotStrip marks
Reviewed By: SidharthGuglani
Differential Revision: D17519844
fbshipit-source-id: 8b26800d720f34cae87754d85460abf88acbe713
Summary:
## Step 1
I'm going to make every Java NativeModule type-safe and TurboModule-compatible. The first step is to make sure that every type-unsafe NativeModule has a dependency on its spec's codegen target.
## Input
Module -> owner(Module): P123320255
Module -> name(Module): P123320256
Module -> owner(spec(name(Module))): P123320257
### Excluded NativeModules
NativeModules without Specs: P123320644
Java only NativeModules: P123320645
Changelog:
[Internal] - Add buck dependencies for NativeModule specs
Reviewed By: mdvacca
Differential Revision: D18781629
fbshipit-source-id: 89f39017b8224355d9d7b43bf6c162b0957760ee
Summary:
Changelog: [Internal] Remove Hermes heap tripwire cooldown parameter.
Delete all references to the cooldown parameter for Hermes's GCConfig, it is no longer
used (instead, the tripwire callback is called at most once per Runtime).
Reviewed By: JoshuaGross
Differential Revision: D18768200
fbshipit-source-id: e7a02ed59ad45e8e4d1b32b37d752076c40caf0b
Summary: Removing the methods I recently added for storing/retrieving an instance key on a ReactContext.
Reviewed By: PeteTheHeat, mdvacca
Differential Revision: D18710637
fbshipit-source-id: d34683ec660bd999db8112865e15392606fc9237
Summary:
When SourceCode was converted to a TurboModule in D17586276, we had to check in `NativeSourceCodeSpec` into the codebase. Since all the OSS NativeModule base classes are now checked into `react-native-github`, it's no longer necessary to keep `NativeSourceCodeSpec`. So, I'm deleting it.
Changelog:
[Android][Removed] - Delete com.facebook.react.modules.debug.NativeSourceCodeSpec
Reviewed By: PeteTheHeat, mdvacca
Differential Revision: D18732997
fbshipit-source-id: 6026b4bcb9ebb9c4d7ba556bc644698eb550a9de
Summary:
Added method which checks if value(methodId, fieldId, class ...) returned by JNI functions (getMethod, getField, getClass ...) is valid or not and throw exception if they are not valid
##Changelog:
[Internal][Yoga] Add defensive check for result returned after JNI calls
Reviewed By: astreet
Differential Revision: D18745718
fbshipit-source-id: 2af26eda15fbe7834e1c9b274deeed4f106274ab
Summary:
## Changelog:
[Internal][Yoga] Add YogaJniException class to be used later for jni exceptions
Reviewed By: astreet
Differential Revision: D18745609
fbshipit-source-id: 53503b54dbc59e9fe47f599dee6be9cb68134cb2
Summary:
Eventually, we want these to extend the abstract base class code-generated from the NativeModule spec. That base class extends `ReactContextBaseJavaModule`. So, this is a step in the right direction.
Changelog:
[Internal] Make ExceptionsManagerModule extend ReactContextBaseJavaModule
Reviewed By: PeteTheHeat, mdvacca
Differential Revision: D18718061
fbshipit-source-id: 70ba5c45b3ef1dd7602e1186763c8bc7ab5d4f42
Summary:
This diff re-throw and logs exceptions in the animated module of RN Android
Changelog: internal
Reviewed By: JoshuaGross
Differential Revision: D18694124
fbshipit-source-id: bb4cb56dce99f09c56b0bc62733e8264f2df5a3f
Summary:
This diff adds extra logging in the method that handles exceptions for RN Android
Changelog: internal
Reviewed By: JoshuaGross
Differential Revision: D18694123
fbshipit-source-id: e275445b65473ed55eec9d4b823938e32fa805e5
Summary:
In AndroidTextInput, support codegen'd ViewCommands in native and add three commands that will eventually replace usage of setNativeProps on Android.
TextInput will use these commands in a future diff.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D18612150
fbshipit-source-id: 5d427040686e8c5ab504dd845bc8ef863f558c35
Summary:
Use a similar setup as Paragraph, and support in Fabric:
- Correct measuring of AndroidTextInput
- Correct display of AndroidTextInput attributed strings
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18669957
fbshipit-source-id: 84e0ad8021c9edf8219e0c673c781276ca29787d
Summary:
We need to make our ExceptionsManagers into TurboModules. To do so, we need to first make them type-safe. This requires extending the base class code-generated from the NativeModule JavaScript spec. That base class extends `ReactContextBaseJavaModule`, which requires `ReactApplicationContext` to instantiate. Unfortunatley, our ExceptionsManagers need to be created before the `ReactInstanceManager`. This means that the `ReactApplicationContext` isn't available by the time they're created.
In this diff, I make the `ReactContextBaseJavaModule` have a 0 argument constructor that simply sets its ReactApplicationContext to null. This will allow us to eventually migrate our ExceptionsManagers to the TurboModule system.
Changelog:
[Android][Added] - Give ReactContextBaseJavaModule a 0 arg ctor
Reviewed By: mdvacca
Differential Revision: D18717908
fbshipit-source-id: 203ffc49f2ec0b32a809402801795879d3b3a64b
Summary:
R8 shows warning that **com.facebook.react.bridge.JavaScriptModule**, **com.facebook.react.bridge.NativeModule** are interfaces so proguard rules must use implements instead of extends. This PR changes proguard rules to fix the warnings.
## Changelog
[Android] [Changed] - Fix R8 warning
Pull Request resolved: https://github.com/facebook/react-native/pull/27291
Test Plan: RNTester builds and runs as expected.
Differential Revision: D18658704
Pulled By: mdvacca
fbshipit-source-id: a679643542bc55b89141f58c3236a29cf83c20d2
Summary:
We hope that will help us to understand more.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18599164
fbshipit-source-id: 431f83de707fc7113e04abd3dd5b59ee5c9cc675
Summary:
We recently realized that `JNativeRunnable` instances that RN uses to pass C++ callables to Java land actually are GC managed objects. That makes their lifetime quite unpredictable (longer than necessary). Normally, it's fine but some C++ code explicitly relies on deallocation order.
To make the behavior of `JMessageQueueThread` more predictable, now we clear/reset stored `std::function` object right after an invocation to explicitly free all associated resources (`JNativeRunnable` still holds some wrapper but that wrapper holds nothing).
Changelog: [INTERNAL]
Reviewed By: JoshuaGross
Differential Revision: D18603390
fbshipit-source-id: 362f6cc0901cbe14d3360b928c98e204d277b1aa
Summary:
We are rolling out exact-by-default syntax to xplat/js.
I had to manually move around some comments to preserve proper placement.
Changelog: [Internal]
Reviewed By: jbrown215
Differential Revision: D18633611
fbshipit-source-id: 48f7468dcc55b1d00985419d035a61c6820b3abe
Summary:
This diff introduces a new ReactFeatureFlag that will be used to enable / disable a custom implementation of getChildVisibleRect in the classes ReactViewGroup, ReactHorizontalScrollView and ReactScrollView.
The new ReactFeatureFlag is disabled by default bevause of T57363204
This is disabling the code landed as part of D17782658 / https://github.com/facebook/react-native/pull/26334
Changelog: Introduce ReactFeatureFlag to disable custom implementation of getChildVisibleRect (disabled by default)
This will disable the custom algorithm created on https://github.com/facebook/react-native/pull/26334
Reviewed By: yungsters
Differential Revision: D18621042
fbshipit-source-id: 35ca3417b596117b47edab29515a824c1726c2ce
Summary:
4a69b3e636 changed the way the cpp files for yogajni are included but it doesn't work. I looked at other places where we are using `wildcard` and we need to add `LOCAL_PATH` otherwise the base path will be where this file is included initially, in this case the `react/jni` folder. This causes no cpp files to be included and the jni bindings are not initialized.
## Changelog
[Internal] [Fixed] - Fix yogajni build with gradle
Pull Request resolved: https://github.com/facebook/react-native/pull/27275
Test Plan: Tested that it builds properly and doesn't crash because of missing native implementation.
Differential Revision: D18633950
Pulled By: mdvacca
fbshipit-source-id: e229fffb53bc335d441060da3c5d4fd840a3c5b0
Summary:
RCTDevLoadingView wasn't hooked up to the codegen. This diff makes RCTDevLoadingView type-safe and also makes it TurboModule-compatible.
Changelog:
[iOS][Added] - Make RCTDevLoadingView TurboModule-compatible
Reviewed By: PeteTheHeat
Differential Revision: D16969764
fbshipit-source-id: 47e6682eea3fc49d3f0448c636b5f616d5bce220
Summary:
Changelog: [Internal]
Introduce native command `setNativeRefreshing`, it has the word Native in order to avoid name conflict with setRefreshing in Android implementation. Even this component is iOS only, it would make it easier to merge them in the future.
Introduce `RCTRefreshableProtocol` and make `RCTRefreshControl` and `RCTPullToRefreshViewComponentView` to conform to the protocol so view manager can forward command to both, Paper and Fabric component.
Reviewed By: mmmulani
Differential Revision: D18475804
fbshipit-source-id: 4c19225784efc931b7b8f2d2671cc839bce429bf
Summary:
Modifying ImageLoaderModule to be TM-compatible by extending the generated abstract class and fixing the conflicting method signatures (int -> double).
Changelog: [Android] [Changed] Changing method signatures for ImageLoaderModule to accept double for requestId
Reviewed By: mdvacca
Differential Revision: D18435628
fbshipit-source-id: bc2a82bda49e339d1feebfe917b0862a1af15a1f
Summary:
We read from / write to `CatalystInstanceImpl.mTurboModuleRegistry` from multiple threads. To ensure that we directly read/write from memory, and not a stale cache, we should make this variable `volatile`.
Changelog:
[Android][Fixed] Make TurboModuleRegistry in CatalystInstanceImpl.java volatile
Reviewed By: fkgozali
Differential Revision: D18542954
fbshipit-source-id: 0a47f05e0653b4f7f58503c678bdf31c68eab9bf
Summary:
This diff deprecates the constructors and getter method exposing CallerContext in ReactImageManager.
This will be replaced by the ReactCallerContextFactory class
Changelog: Deprecation of constructors and methods that expose CallerContext in ReactImageManager class
Reviewed By: JoshuaGross
Differential Revision: D18474012
fbshipit-source-id: d8190f938e00da0499bfef7e81522dc8022a8836
Summary:
This diff exposes the ReactContextContainerFactory class on ReactImageViewManager and it customize ChainContext to improve Fresco logging
Changelog: Expose new ReactContextContainerFactory class as part of ReactImageViewManager
Reviewed By: JoshuaGross
Differential Revision: D18474013
fbshipit-source-id: 143461da22966694e5b1e2c3b5b39e3d6be91fd6
Summary:
This diff exposes the surfaceID as part of ReactRootView.
Changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D18474014
fbshipit-source-id: 98f651b211d3cc4df88c6b1eb257bc12129eff57
Summary:
Document which methods can be called on UI thread or ANY thread.
In the future we should see if we can use only `ThreadConfined` or the AndroidX annotations instead of using both / choosing between them at each site.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18532542
fbshipit-source-id: 3b5406ea5035615a0ebf83484bf8ec0747a6b6f7
Summary:
This diff extends ThemeReactContext class to store the surfaceID field
The getSurfaceID method is being exposed as a public method
Changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D18474015
fbshipit-source-id: ee1f859a802d36c51dec537fa91d90022523e88d
Summary:
This interface is used from ReactImageManager to customize the CallerContext object associated with each instance of ReactImageView.
CallerContext are used on Fresco to customize Debug and logs
Changelog: Introduce ReactCallerContextFactory interface, this interface is intended to customize Debug and logging on Fresco
Reviewed By: JoshuaGross
Differential Revision: D18474017
fbshipit-source-id: eda0fc9d3f64bbcc23ee1b7f5d779b441da1fe6c
Summary:
Fixes T54997838 by preventing any view mutations during `onMeasure` calls.
There might still be places where this is possible, but this is where I'm seeing all the crashes currently.
See comments in ReactRootView for why views were mutated during onMeasure.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18518591
fbshipit-source-id: 1406af8a6b0bfcc86f4cc5b451b3967f312dfd85
Summary:
`ReactFeatureFlags.useTurboModules` can be written to and read from any number of threads. We should use `volatile` to make sure that all threads read/write this data straight from/to memory.
Changelog:
[Android][Fixed] - Make ReactFeatureFlags.useTurboModules volatile
Reviewed By: fkgozali
Differential Revision: D18505673
fbshipit-source-id: 0b2527b8cb95c1e1aedc6b03b12a6b1e6a6cdaa4
Summary:
## Changelog:
[General] [Yoga] - Use vanilla jni instead of fbjni for all the jni communication
Reviewed By: astreet
Differential Revision: D17808005
fbshipit-source-id: 5e9a1ed73978f519c71c248774a28e5a294e7c7f
Summary:
As a part of the migration from `setNativeProps` in Fabric and Paper, we are replacing it by view commands in the RefreshControl component on Android.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18475428
fbshipit-source-id: f2e978d88e34c74771f8582247ecc82b2b942557
Summary:
As a part of the migration from `setNativeProps` in Fabric and Paper, we are replacing it by view commands in the Checkbox component on Android.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18451524
fbshipit-source-id: 566f3574b85a1ae97f78b2fb95548b8529c0c92f
Summary:
This diff migrates ReactViewPagerManager to use the generated delegate for setting its properties.
Changelog: [Android] [Added] - Use generated Java delegate for setting properties on ReactViewPagerManager
Reviewed By: mdvacca
Differential Revision: D18298049
fbshipit-source-id: f989bedb16e3cabe6a9a8e4238a2b74515041d23