Summary:
After D28435078, TurboModules can conform to the RCTInitializing protocol, and implement the `-(void)initialize` method. This diff makes the TurboModule system execute the module's initialize method after the infra is done setting it up.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D28435429
fbshipit-source-id: fe945d616b97ed89f48b914b064e518b122a7b7b
Summary:
This diff has the bridge attach RCTCallableJSModules to our NativeModules.
Changelog: [Internal]
Differential Revision: D28395447
fbshipit-source-id: 01ca62442013826d28ba0f710e28a5963f5efb65
Summary:
After this diff, every NativeModule that has `synthesize bundleManager = _bundleManager`, will get access to an RCTBundleManager, that it can use to read from/write to the bridge's bundle URL.
Changelog: [iOS][Added] - Attach RCTBundleManager to NativeModules
Reviewed By: PeteTheHeat
Differential Revision: D28086319
fbshipit-source-id: 6e4cd815d300e9036957ec8c743e947d2cb3f365
Summary:
## Rationale
The TurboModuleManager should only be concerned with modules. The bridge and RCTInstance integrate the TurboModuleManager with the rest of React Native. Therefore, abstractions used by TurboModules that reach into the rest of React Native should be attached by the bridge or by RCTInstance.
## Changes
In this diff, we pull RCTViewRegistry attachment out of the TurboModuleManager. In bridge mode, it'll be attached to TurboModule by the bridge. In bridgeless mode, it'll be attached to TurboModules by the RCTInstance.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D28086320
fbshipit-source-id: 9d99835bdbb66bb6a41fbd0d8a3970cefae16b81
Summary:
All NativeModules/TurboModules can use the following Venice-compatible API instead:
```
synthesize moduleRegistry = _moduleRegistry
```
In bridge mode, it'll look up the module via the TurboModule system/bridge.
In bridgeless mode, it'll look up the module via the TurboModule system.
Therefore, there's no need to support this API.
Changelog: [iOS][Removed] - Delete synthesize turboModuleRegistry API in RCTTurboModule
Reviewed By: fkgozali
Differential Revision: D28070740
fbshipit-source-id: d2c8285fd4c05b67fb03ce82217bf6ddfd1dd685
Summary:
## Rationale
With the bridge, the invalidate method of every TurboModule gets called on the TurboModule's method queue. This ensures that we can safely clean up resources accessed in the TurboModule's async methods. In bridgeless mode, we don't invalidate each module on its method queue. After this diff, we will clean up every TurboModule on its own method queue.
## Changes
- Make RCTInstance dealloc itself on the JavaScript thread.
- Terminate the JavaScript thread on the JavaScript thread. This ensures that no work executes on the JavaScript thread after we clean up RCTInstance.
- Make [RCTTurboModuleManager invalidate] execute right before RCTInstance terminates the JavaScript thread.
- **Fix:** Make [RCTTurboModuleManger invalidate] synchronously invalidate modules on their own method queues.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D27933587
fbshipit-source-id: 7630e7fc074df2f5a3293192431105c747b8588f
Summary:
D27316129 made it mandatory for all RCTTurboModules to have a getTurboModule: method. So, there's no need to keep the getTurboModule:initParams method in RCTTurboModuleManagerDelegate. So, to simplify the TurboModule infra, this diff gets rid of that TurboModuleManager delegate method.
Changelog: [iOS][Removed] - Delete RCTTurboModuleManagerDelegate getTurboModule:initParams
Reviewed By: fkgozali
Differential Revision: D27316873
fbshipit-source-id: c0b8449c6088bf08f17ba9a8d1c2cb644e5a242d
Summary:
## Rationale
There are two ways to associate NativeModule ObjC objects with ObjCTurboModule jsi::HostObjects:
1. Via the NativeModule ObjC class's `getTurboModule:` method.
2. Via the TurboModule manager delegate's getTurboModule:initParams: method.
There's no good reason to support both options. So, this diff stack removes 2, and make 1 mandatory for all RCTTurboModules. Not only will this simplify the infra, but it should also help eliminate a class of runtime errors in the TurboModule standalone app migration: you forget to implement the getTurboModule: method.
Changelog: [iOS][Changed] - Make RCTTurboModule getTurboModule: required
Reviewed By: PeteTheHeat
Differential Revision: D27316129
fbshipit-source-id: baccd155b8c191d0f961b316db552bdfdbeb0a97
Summary:
We're making the getTurboModule: method required for all classes that conform to RCTTurboModule.
Many of our ObjC-only and Cxx NativeModules don't implement this method. This diff implements a getTurboModule: method on all those modules that returns nullptr.
**Question:** Why is it fine to make ObjC-only NativeModules return nullptr from their getTurboModule: method?
- Because they're only accessed from ObjC, and should appear as null on the JavaScript side. Longer term, these NativeModules will also go away.
**Question:** Why is it fine to make Cxx NativeModules return nullptr from getTurboModule: method?
- Because after D27316872, the TurboModuleManager checks if the module is a CxxModule first. If it is, we do an early return, and never call the module's getTurboModule: method.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D27316871
fbshipit-source-id: bc693f2927ab3b0de24e6e9e7699390ec0f7d729
Summary:
We're going to make RCTTurboModule getTurboModule: required in D27316129. So, RCTTurboModuleManagerDelegate getTurboModule:initParams is no longer necessary.
## Changes
1. Makes TurboModuleManager stop calling RCTTurboModuleManagerDelegate getTurboModule:initParams
2. Makes getTurboModule: have the lowest priority. So, Cxx NativeModules with a getTurboModule: method won't have their getTurboModule: method executed.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D27316872
fbshipit-source-id: a024e55b8e3692d7117420007dd3947ecfd5019c
Summary:
JSI callbacks are only destroyed if the callback is called. If the callback is never called, we're potentially leaking a lot of callbacks.
To mitigate this, we add a wrapper object that is owned by the std::function. Whenever the std::function is destroyed, the wrapper is destroyed and it deallocates the callback as well.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D27436402
fbshipit-source-id: d153640d5d7988c7fadaf2cb332ec00dadd0689a
Summary:
Changelog: [Internal] enable support for C++ 17.
C++ 17 in React Native targets.
Short and comprehensive list of C++ features:
https://github.com/AnthonyCalandra/modern-cpp-features#c17-language-features
Reviewed By: JoshuaGross
Differential Revision: D27431145
fbshipit-source-id: e8da6fe9d70e9b7343a8caec21cdbeb043478575
Summary:
Fix warnings about implicit type truncation.
## Changelog
[Internal] [Fixed] - Fix various C++ warnings
Pull Request resolved: https://github.com/facebook/react-native/pull/31002
Test Plan:
Almost all the changes here are simply making explicit conversions which are already occurring. With the exception of a couple of constants being changed from doubles to floats.
With these changes I am able to remove a bunch of warning suppressions in react-native-windows.
Reviewed By: shergin
Differential Revision: D26900502
Pulled By: rozele
fbshipit-source-id: d5e415282815c2212a840a863713287bbf118c10
Summary:
changelog: [internal]
### When does leak happen?
Leak happens anytime a callback isn't executed inside native module, it will never get cleaned up.
Imagine a native module with method that takes onSuccess and onFail callbacks. Only one of them will be called at any time and the other one will leak.
### Why does it leak?
It leaks because when `CallbackWrapper` is created using `CallbackWrapper::createWeak`. Inside `CallbackWrapper::createWeak`, the newly created object is inserted into `LongLivedObjectCollection`. This object collection will keep it alive until `CallbackWrapper::destroy` is called, which isn't called in case closure isn't executed.
### Solution
Introduce class RCTBlockGuard which ties cleanup of resources to lifetime of the block.
Reviewed By: RSNara
Differential Revision: D26664173
fbshipit-source-id: 9348f7c39eb317cf1e8e5d59e77a378e5e04f3eb
Summary:
For better cross-platform consistency, migrate usages of NDEBUG to REACT_NATIVE_DEBUG. See flags.h for explanation.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D26695016
fbshipit-source-id: 63e6f6fc919076d94f04416f6821f21e0b3707a3
Summary:
We still have usages of "fbsource//tools/build_defs/apple:flag_defs.bzl" in react-native-github. But this should get us closer towards not using the fbsource cell. Hopefully, this is enough to unbreak the test_docker CircleCI build.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D26289304
fbshipit-source-id: 1c6464bb84df4f82f8a797321a73a1ed324e319a
Summary:
This diff refactor strong references on TM infra to use weak references and avoid leaking objects
changelog: [internal] internal
Reviewed By: RSNara
Differential Revision: D26229814
fbshipit-source-id: d4a327dba227378d23764433d5917eb4378a4453
Summary:
The TurboModuleUtils.h includes "folly/Optional.h" which is not used and creates an unnecessary dependency on Folly.
In this PR we remove this unnecessary include.
It is required for the https://github.com/microsoft/react-native-windows/pull/6804 where we add an experimental support for the C++ TurboModules. While the C++ TurboModules use the same JSI and TurboModule code defined in react-native, we provide a layer that let them to work over the ABI-safe Microsoft.ReactNative.dll boundary. The RNW Nuget distribution with DLL files includes a few source files to create native/turbo modules that work through the ABI-safe API. The TurboModuleUtils.h is one of such files. By removing the dependency on Folly we reduce requirements for the native module code. After this PR is merged we will remove the fork of the TurboModuleUtils.h added in https://github.com/microsoft/react-native-windows/pull/6804.
## Changelog
[Internal] [Fixed] - Remove dependency on Folly in TurboModuleUtils.h
Pull Request resolved: https://github.com/facebook/react-native/pull/30672
Test Plan:
The change does not bring any functional changes. It may only affect code compilation where some code may depend on TurboModuleUtils.h when it needs the "folly/Optional.h". The fix is add the `#include <folly/Optional.h>` there explicitly.
I had run the iOS tests and they passed:
```
yarn
pod install in packages\rn-tester
./scripts/objc-test.sh test
```
Reviewed By: mdvacca
Differential Revision: D25758927
Pulled By: fkgozali
fbshipit-source-id: 347d8f6bc333a3df67095ea0dc7221c818432fab
Summary:
This new type will be valid in Flow strict mode and can be used by native modules and components to replace `Object`, with the same semantics.
This unblocks the migration of the most modules in the React Native package to Flow strict.
Changelog: [Internal] Add UnsafeObject type compatible with Flow strict mode to use in native modules and components
Reviewed By: RSNara
Differential Revision: D25540631
fbshipit-source-id: 60b80bbc84a53aecc747e3a1799cdf551e1859cd
Summary:
After this diff, NativeModules can synthesize the RCTModuleRegistry, and use that to query for UIViews of components, given their reactTags.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D25645052
fbshipit-source-id: bb17606cc4862d07b739ef2c31a5e57f59201364
Summary:
After we create the RCTSurfacePresenter in Venice, we use it to create an RCTBridgelessComponentViewProvider, and pass it over to the RCTTurboModuleManager. In Venice, this allows all TurboModules to query components' UIViews given their reactTag.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D25643261
fbshipit-source-id: 31da07c490d249534f700b7c8430e9cb43b5b0db
Summary:
Now, TurboModules that synthesize RCTModuleRegistry will have it available at runtime.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D25643260
fbshipit-source-id: e9915f3da8412de823ae3d3e17849979c5cbd465
Summary:
## Description
During TurboModule method invocation, when we convert JavaScript callbacks (i.e: jsi::Functions) into ObjC blocks inside the TurboModule jsi::HostObject, we [push them into an array](https://fburl.com/diffusion/r1n75ikx) that [gets cleared after the method gets invoked](https://fburl.com/diffusion/ubbvdmfs).
Prior to this experiment, we pushed these ObjC blocks into the array without copying them first. This goes contrary to ObjC best practices, which suggest that if you need to retain a block past its creation context for later invocation, you should defensively copy it to prevent it from being freed early. See the [Apple docs](https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/Blocks/Articles/bxUsing.html#//apple_ref/doc/uid/TP40007502-CH5-SW1):
> Typically, you shouldn’t need to copy (or retain) a block. You only need to make a copy when you expect the block to be used after destruction of the scope within which it was declared. Copying moves a block to the heap.
The diff that introduced the fix: D23764329 (https://github.com/facebook/react-native/commit/9b76e217bb16935069f0ea5b60f4c4d9b73f86d6).
Reviewed By: PeteTheHeat
Differential Revision: D25617672
fbshipit-source-id: 24863b31a2d82c8d39a91c8ea8eb3a62724b800a
Summary:
## Context
The legacy NativeModule infra implements promise methods using [async NativeModule method calls](https://fburl.com/diffusion/tpkff6vg). In the TurboModule infra, promise methods [treat as sync methods](https://fburl.com/diffusion/yde7xw71), and executed directly on the JavaScript thread. This experiment makes TurboModule promise methods async, and dispatches them to the NativeModules thread, when they're executed from JavaScript.
Reviewed By: fkgozali
Differential Revision: D25623192
fbshipit-source-id: 2b50d771c5272af3b6edf150054bb3e80cab0040
Summary:
Previously, we'd throw std::runtime_error objects when we invoked RCTPromiseResolveBlock and RCTPromiseRejectBlock. This would crash the app. Now, we'll just show RedBoxes. The RedBoxes also contain the name of the NativeModule, along with the method.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25549149
fbshipit-source-id: 33d5fc4480a577a1c17961c856ac42a9363b35f6
Summary:
During cleanup, RCTNativeAnimatedModule [requires the RCTEventDispatcher](https://fburl.com/diffusion/0bnln893) to remove itself from the dispatcher a dispatch observer.
When the bridge is invalidated, if RCTEventDispatcher is has been cleaned up by then, we don't warn when this lookup fails: https://fburl.com/diffusion/rfioe5ay. This diff replicates that behaviour in the TurboModule infra.
Notes:
- In the legacy NativeModule infra, we can still query NativeModules post invalidation - we just won't create them. In the TurboModule infra, all requests for TurboModules from the TurboModuleManager start returning nil. Therefore, I simply did an early return inside TurboModuleManager moduleForName in the case that we're already invalidated. In addition to not displaying the warning, we just don't request/create the TurboModule in the first place.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25560228
fbshipit-source-id: 102dcc147bab6121daacdb39890bad48c0e60894
Summary:
This is to address a UBN blocking FBiOSv300 rollout. A TM is attempting to invoke a promise more than once and crashing. We can't find the TM, so downgrading this to a warning to unblock the release.
Plan going forward:
- Replace this with some better logging to try and identify the culprit module.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D25539676
fbshipit-source-id: 5b75b71110eaa393378049de6e0d9a77e6328831
Summary:
This is a followup to the issue described in D25477044, basically the TM cache can get messed up if `TurboModuleManager` is asked for "RCTNetworking" vs "Networking". This solves that issue globally.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D25480624
fbshipit-source-id: 2024560eadbcf58cdc3d7d5675b4120aa2fa2582
Summary:
The bridge now creates the RCTModuleRegistry, and assigns it to all NativeModules it creates.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25414108
fbshipit-source-id: 81c6a05bde0e52cff8ed60297f27d8aa3ff15a87
Summary:
This is a codemod. All these NativeModules demand access to the bridge. However, they don't use it.
Changelog: [Internal]
Reviewed By: PeteTheHeat, RoelCastano
Differential Revision: D25386708
fbshipit-source-id: f05f4777d2527e96e53581e7ac58f6be47411dce
Summary:
This is the final diff in the JS TurboModule codegen stack for Android. It implements method dispatch using the TurboModuleSchema object.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D22837486
fbshipit-source-id: f91b03f064941457d4b8c5e37e011468559dee71
Summary:
JavaTurboModule will use instances of this class to perform method invocation. TurboModuleSchema is created by parsing the `jsi::Value` that represents the TurboModule's schema.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D22832729
fbshipit-source-id: 792736e176c33a302f6a41c6f63a4812b09af585
Summary:
## Android API
```
// Before we initialize TurboModuleManager
ReactFeatureFlags.useTurboModuleJSCodegen = true
```
## iOS API
```
// Before we initialize RCTBridge
RCTEnableTurboModuleJSCodegen(true);
```
## How is the JS Codegen actually enabled?
The above native flags are translated to the following global variable in JavaScript:
```
global.RN$JSTurboModuleCodegenEnabled = true;
```
Then, all our NativeModule specs are transpiled to contain this logic:
```
interface Foo extends TurboModule {
// ...
}
function __getModuleSchema() {
if (!global.RN$JSTurboModuleCodegenEnabled) {
return undefined;
}
// Return the schema of this spec.
return {...};
}
export default TurboModuleRegistry.get<Foo>('foo', __getModuleSchema());
```
Then, in our C++ JavaTurboModule, and ObjCTurboModule classes, we use the TurboModule JS codegen when the jsi::Object schema is provided from JavaScript in the TurboModuleRegistry.get call.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D24636307
fbshipit-source-id: 80dcd604cc1121b8a69df875bbfc87e9bb8e4814
Summary:
This change should make all type-safe NativeModules TurboModule-compatible.
Changelog: [Internal]
Differential Revision: D24729493
fbshipit-source-id: 7712708a24d675ca567225797016a7ff66a2920e
Summary:
Added a few FB vs OSS polyfills:
* react_native_root_target() to refer to the root FB react-native-github/ dir or repo dir in OSS
* react_native_xplat_synced_target() for anything xplat
* a few others
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D24437245
fbshipit-source-id: ee290a87a98a8e9be67b102a96f2faac2a2cb92b
Summary:
## Previously
- When TurboModules system was on, we'd only log events from the TurboModules system.
- When TurboModules system was off, we'd only log events from the NativeModule system.
This ultimately gives us less data to analyze both systems in production.
## Changes in This Diff
When perf. logging is on, we'll log events from both systems. Each QPL event now include an annotation of which system the event is coming from. Concretely, this will allow us to see how much of the NativeModule system is being exercised in the TurboModule test group.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D24232594
fbshipit-source-id: 7dff57bd74fc7ef744d3e06ff174304f25790456
Summary:
The captured `instance_` will result in a call to JVM code to release the reference when the lambda is destroyed. However, Hermes may destroy the lambda in a non-JVM background thread.
Since `instance_` is a member of the class, and `this` is already captured, there is no need to capture it.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D24141179
fbshipit-source-id: e3b268485ed229ee933281a80e5dbe2feba55719
Summary:
This compiles SampleTurboModule into RNTester Android. It also adds the NativeModule playground to show case TurboModule system to RNTester examples, just like in iOS.
{F337854369}
Changelog: [Android][TurboModule] Added TurboModule example to RNTester when `USE_CODEGEN` is set
Reviewed By: hramos
Differential Revision: D24004711
fbshipit-source-id: b682dd51fa998ee2e60f8d6ffd8c39220d13a7fe
Summary:
This is the Java/JNI impl of the NativeSampleTurboModule.js, just like on iOS. The files here are supposed to be generated by the react-native-codegen, but they are checked in to the repo for easier build integration with RNTester.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D23985746
fbshipit-source-id: 46340d778f3d964efe5b538d15ebe0f2cab04862
Ramanpreet Nara
Samuel Susla
Joshua Gross
Andrew Coates
David Vacca
Vladimir Morozov
Rubén Norte
Ron Edelstein
Peter Argany
Aditya Kumar
Kevin Gozali
Neil Dhar