Summary:
## Context
Whenever the TurboModuleManager calls into its delegate, it [acquires a lock](https://www.internalfb.com/code/fbsource/[f14548634e72009989c844a2ef025915ef74159e]/xplat/js/react-native-github/ReactCommon/react/nativemodule/core/platform/ios/RCTTurboModuleManager.mm?lines=429%2C513). We initially introduced this mutex (in D21170099 (2c473e1a38)). It serializes access to the TurboModuleManager delegate during TurboModule create.
## Problems
- When we call into the delegate, we acquire a lock, and call into arbitrary product code: getModuleClassFromName, getModuleInstanceFromClass. If any of these two product methods create another TurboModule, the application will deadlock, because we'll acquire the same std::mutex twice.
## Fix
The delegate methods of TurboModuleManager are usually implemented as [switch cases over the NativeModule names or NativeModule classes](https://www.internalfb.com/code/fbsource/[f015e461de4e7a18d0d52a697a53086fe6a3b91c]/fbobjc/Apps/Wilde/FBReactModule2/FBReactModuleAPI/FBReactModuleAPI/Exported/FBReactModule.mm?lines=1481-1488%2C1490-1537%2C1539-1577). So, it should be safe to call into them concurrently for two different modules.
So, while we could fix the problem by migrating the TurboModuleManager to an std::recursive_mutex, one could make an argument that this locking shouldn't even be necessary in the first place. We don't have this locking in the Android TurboModule system.
## Changes
This diff introduces a flag in React Native that allows to to safely remove this TurboModuleManager delegate locking in production.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D30754875
fbshipit-source-id: d04a831c18a2a8b46e9bc07ddf690d8e4d0be8e0
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:
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:
## 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 (9b76e217bb).
Reviewed By: PeteTheHeat
Differential Revision: D25617672
fbshipit-source-id: 24863b31a2d82c8d39a91c8ea8eb3a62724b800a
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 diff ended up being a bit more complicated than I anticipated, since the source files in `ReactInternal` were depending on `RCTEventDispatcher`. I made the following changes:
1. Make `RCTEventDispatcher` a `protocol`, keep it in `ReactInternal`.
2. Rename the `RCTEventDispatcher` NativeModule to `RCTEventDispatcherModule`, make it conform to the `RCTEventEmitter` `protocol`, and move it to `CoreModules`.
3. Where necessary, replace categories of `RCTEventDispatcher` with functions.
Changelog:
[iOS][Added] - Make RCTEventDispatcher TurboModule-comaptible
Reviewed By: fkgozali
Differential Revision: D18439488
fbshipit-source-id: b3da15c29459fddf884519f33b0c3b8c036b5539
Summary:
Right now, when two threads require two NativeModules, both threads fight for the same `std::mutex`. Why? Because NativeModule require can read from/write to the shared `std::unordered_map<std::string, TurboModuleHolder*>`.
**A Few Thoughts:**
- All threads should be able to read from the TurboModule cache concurrently, without issue. Only writes into the cache require exclusive access. *With our current setup, both reads and writes acquire exclusive access.*
- During the lifetime of an application, there will only be tens of NativeModule create events (i.e: writes into the TurboModule cache). However, there may be hundreds, if not thousands of TurboModule cache lookups. *We don't need to serialize those hundreds/thousands of TurboModule cache reads.*
This is a potential optimization opportunity for the TurboModule infra.
## Changes
This diff introduces a `std::shared_mutex` inside `RCTTurboModuleManager`. We use either the regular `std::mutex` or the `std::shared_mutex`, depending on whether `RCTTurboModuleSharedMutexInitEnabled()` is `YES`.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D23413118
fbshipit-source-id: 0880413c691b141db98a2715648f0c3e05983307
Summary:
This notification was never used, I'd rather not have someone start relying on it, and need to figure out how to migrate them in bridgeless mode.
Changelog:[Internal]
Reviewed By: cpojer, RSNara
Differential Revision: D22513602
fbshipit-source-id: 80b179af8408abc6646a73380b4a66cade3f75f2
Summary:
TurboModule eager initialization is a bit dangerous if we get it wrong, which we did (twice): T69449176.
This diff gates TurboModule eager init behind a MC, so that we can control (i.e: turn off/on, and do gradually rollout of) TurobModule eager initialization in isolation from the larger TurboModules experiment.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D22460359
fbshipit-source-id: 3b8dce0529f1739bd68b8b16d6a28aa572d82c2c
Summary:
## Why?
1. RCTTurboModuleLookupDelegate sounds a bit nebulous.
2. In JS and Java, we use a `TurboModuleRegistry` interface to require TurboModules. So, this diff will make JS, Java, and ObjC consistent.
Changelog:
[Internal]
Reviewed By: PeteTheHeat
Differential Revision: D22405754
fbshipit-source-id: 30c85c246b39d198c5b8c6ca4432a3196ca0ebfd
Summary:
`RCTBridgeWillReloadNotification` has one job: whenever bridge reloads - trigger a reload in `RCTSurfacePresenter`.
Diff 1/2 deprecated bridge reloading APIs, and replaced them with `RCTReloadCommand`. Use that in `RCTSurfacePresenter` instead .
Changelog: [iOS][Deprecate] Deprecate RCTBridgeWillReloadNotification
Reviewed By: shergin
Differential Revision: D17880926
fbshipit-source-id: 00adc4d56d11d40ab371d81bb17a05609c184769
Summary:
Testing the waters with an idea for unifying RN lifecycle with/without bridge.
### Motivation/Background
RN bridge is being reloaded from [several different places](https://fburl.com/codesearch/ae3zeatt). When this happens, the bridge does a bunch of things:
1. Post `RCTBridgeWillReloadNotification` (RCTSurfacePresenter listens to this and reloads)
2. Invalidate batched bridge, which does:
a. invalidate display link
b. post `RCTBridgeWillInvalidateModules/RCTBridgeDidInvalidateModules` (TurboModuleManager listens to this and reloads modules)
c. clear js thread state
d. clear some local caches
3. Set up (reload bundle and batched bridge)
In a bridgeless world, there isn't one thing which owns all these peices of infra, and can reload them.
### Plan
Use `RCTReloadCommand` to handle reloads. This light class previously only handled CMD+R. The new workflow looks like this:
1. Anything which cares about reloads can register itself as a listener. (RCTBridge, RCTSurfacePresenter, TurboModuleManager...)
2. Anything that previously called `bridge reload` now calls `RCTTriggerReloadCommandListeners`.
3. Delete old notifications
### Alternate Plan
Use yet another NSNotification. I like `RCTReloadCommand` better.
### Unknowns
Looks like we log the reason for bridge reloading [here](https://fburl.com/diffusion/lc9jj8la), do we want to save this behaviour? Does anyone look at why bridge is being reloaded cc/Rick? If so, I can add back that functionality to `RCTReloadCommand`.
It should be possible to customize the order/priority of what gets reloaded first. There may be some racy behaviour that I haven't thought about yet.
Changelog: [iOS][Deprecated] Deprecate [bridge reload] API - prefer RCTReloadCommand
Reviewed By: shergin
Differential Revision: D17869635
fbshipit-source-id: 81f39eaa2c3ce08ea1bc6f2193684c2630d81a2d
Summary:
This diff introduces a new broadcasting event for Bridge that communicates that the bridge is being invalidated. This notification can be used by interested parties as a signal to start tearing down all bridge-dependant processes.
The biggest difference between the new event and `RCTBridgeWillInvalidateModulesNotification` is that the latter is being called asynchronously on the JavaScript thread, whereas the new one is being called on whatever thread caused the Bridge invalidation (deallocation) *synchronously*. In most cases that happens on the main thread that allows destroying strictly-main-threaded infra (mostly UI) synchronously and avoids races.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D18050889
fbshipit-source-id: 9364c820ea2b0358edf45f0e2b3e16a13d730a9c
Summary: Moves the reason to a constant because APPARENTLY this is a best practice in this establishment
Reviewed By: sammy-SC
Differential Revision: D17627819
fbshipit-source-id: 328fad8b7482d0e379a41b5f8c841f71db2bb5ac
Summary: This diff adds a method to call whenever a fast refresh happens. Right now this is only useful for reporting.
Reviewed By: cpojer
Differential Revision: D17528033
fbshipit-source-id: 17e82abe7a3e2bab6829de5adecda853fe5335c5
Summary:
This diff adds a new reloading method reloadWithReason that allows callers to provide a reason for why a reload was requested.
This reason is useful for understanding why users are reloading, and why Fast Refresh is bailing out to a full reload. I also updated the places we reload with the reasons listed below.
**Standard native reasons:**
- Redbox
- Command
- Global hotkey
- Profiling controls
- Dev menu - reload
- Dev menu - reset to default
- Dev menu - apply changes
**From JavaScript (added in a later diff):**
- Fast Refresh - Unrecoverable
- Fast Refresh - No root boundary
- Fast Refresh - Invalidated boundary
- Fast Refresh - Invalidated root boundary
**Misc reasons and fallback for when a reason is unavailable:**
- Unknown from JS
- Uncategorized from JS
- Unknown from bridge
- Unknown from cxx bridge
- Requested from bridge
- Custom executor class reset
Reviewed By: cpojer
Differential Revision: D17499339
fbshipit-source-id: 12a21ffa05708c9b921d93911f190cdffc5c78d5
Summary: There are still race condition during bridge invalidation. Some modules may be accessing other modules during invalidation, but it's racing with the TM manager clearing the cache.
Reviewed By: JoshuaGross
Differential Revision: D15947488
fbshipit-source-id: 3bd51382264f538a03ca565b0f099da40c3daadf
Summary:
Some ObjC NativeModules conform to `RCTInvalidating` protocol and implements `invalidate` method. This is typically used to clean things up during bridge teardown or reload. In TurboModule system the invalidate method can be replaced by pure destructors, but for backward compatibility, we call existing invalidate method on each module during teardown.
This also cleans up all existing LongLivedObject's.
Reviewed By: mdvacca, RSNara
Differential Revision: D15365655
fbshipit-source-id: 802844b39b5b7adb54970ea541f4d744bbf9e480
Summary:
With the introduction of TurboModules, it would be beneficial to measure the setup time of these modules, as we currently have it in place for NativeModules.
The instantiation of the TMs occurs in the `RCTTurboModuleManager`. In order to successfully measure the time it took to setup the module, we need to ensure that we don't take into account cached modules. As such, we need to:
1. Check if module is in `_turboModuleCache`
a. Start mark for `RCTPLTurboModuleSetup` tag if not found
2. Get the TM via `[self provideTurboModule:]`
3. Check if module is in `_turboModuleCache`
a. Stop mark for `RCTPLTurboModuleSetup` if we did not find module in cache prior to **step 2** and if it's now present in the cache.
b. Notify about setup time if the above is true.
4. Return TM
## Changelog
[iOS] [Added] - Gain insights on the the turbo module setup times by observing `RCTDidSetupModuleNotification`. The userInfo dictionary will contain the module name and setup time in milliseconds. These values can be extracted via `RCTDidSetupModuleNotificationModuleNameKey` and `RCTDidSetupModuleNotificationSetupTimeKey`.
Pull Request resolved: https://github.com/facebook/react-native/pull/24732
Differential Revision: D15362088
Pulled By: RSNara
fbshipit-source-id: e6a8044e4aba5a12ae63e9c7dbf707a17ec00180
Summary:
The `RCTBridge` contains numerous definitions of notification names, which we can observe in order to get insights into the React Native performance.
The Android implementation is a little different, such that you can listen for any of the [following](https://github.com/facebook/react-native/blob/master/ReactAndroid/src/main/java/com/facebook/react/bridge/ReactMarkerConstants.java) marker constants, simply by including the following code:
```java
ReactMarker.addListener(new ReactMarker.MarkerListener() {
Override
public void logMarker(ReactMarkerConstants name, Nullable String tag, int instanceKey) {
Log.d("ReactNativeEvent", "name: "+ name.name() + " tag: " + tag);
}
});
```
This will allow you to perform the necessary processing, calculations as required.
---
This PR enables observing for the module setup event (`RCTDidSetupModuleNotification`) by including the respective module's name & setup time in milliseconds.
[iOS] [Added] - Gain insights on the module setup times by observing `RCTDidSetupModuleNotification`. The `userInfo` dictionary will contain the module name and setup time in milliseconds. These values can be extracted via `RCTDidSetupModuleNotificationModuleNameKey ` and `RCTDidSetupModuleNotificationSetupTimeKey`.
Pull Request resolved: https://github.com/facebook/react-native/pull/23859
Differential Revision: D14579066
Pulled By: PeteTheHeat
fbshipit-source-id: 52645127c3fc6aa5bd73e3bd471fccd79cb05c14
Summary:
NativeModules are instantiated by the bridge. If they choose, they can capture the bridge instance that instantiated them. From within the NativeModule, the bridge can then be used to lookup other NativeModules. TurboModules have no way to do such a lookup.
Both NativeModules and TurboModules need to be able to query for one another. Therefore, we have four cases:
1. NativeModule accesses NativeModule.
2. NativeModule accesses TurboModule.
3. TurboModule accesses NativeModule.
4. TurboModule accesses TurboModule.
In summary, this solution extends the bridge to support querying TurboModules. It also introduces a `RCTTurboModuleLookupDelegate` protocol, which, implemented by `RCTTurboModuleManager`, supports querying TurboModules:
```
protocol RCTTurboModuleLookupDelegate <NSObject>
- (id)moduleForName:(NSString *)moduleName;
- (id)moduleForName:(NSString *)moduleName warnOnLookupFailure:(BOOL)warnOnLookupFailure;
- (BOOL)moduleIsInitialized:(NSString *)moduleName
end
```
If TurboModules want to query other TurboModules, then they need to implement this protocol and synthesize `turboModuleLookupDelegate`:
```
protocol RCTTurboModuleWithLookupCapabilities
property (nonatomic, weak) id<RCTTurboModuleLookupDelegate> turboModuleLookupDelegate;
end
```
NativeModules will continue to use `RCTBridge` to access other NativeModules. Nothing needs to change.
When we attach the bridge to `RCTTurboModuleManager`, we also attach `RCTTurboModuleManager` to the bridge as a `RCTTurboModuleLookupDelegate`. This allows the bridge to query TurboModules, which enables our NativeModules to transparently (i.e: without any NativeModule code modification) query TurboModules.
In an ideal world, all modules would be TurboModules. Until then, we're going to require that TurboModules use the bridge to query for NativeModules or TurboModules.
`RCTTurboModuleManager` keeps a map of all TurboModules that we instantiated. We simply search in this map and return the TurboModule.
This setup allows us to switch NativeModules to TurboModules without compromising their ability to use the bridge to search for other NativeModules (and TurboModules). When we write new TurboModules, we can have them use `RCTTurboModuleLookupDelegate` to do access other TurboModules. Eventually, after we migrate all NativeModules to TurboModules, we can migrate all old callsites to use `RCTTurboModuleLookupDelegate`.
Reviewed By: fkgozali
Differential Revision: D13553186
fbshipit-source-id: 4d0488eef081332c8b70782e1337eccf10717dae
Summary:
Some module classes may not be loaded yet, so looking up via classes may not always give the correct instance. This diff added a new lookup method that delegate to the bridge delegate to force load the modules as needed.
The existing moduleForName: method was left untouched because it's solely used by RCTUIManager at the moment.
Reviewed By: dshahidehpour
Differential Revision: D13033876
fbshipit-source-id: 4082fcd68498004f678b4b95adc82b5b134fefdf
Summary:
change RCTCxxBridge to use JSIExecutorFactory+JSCRuntime
instead of JSCExecutorFactory. Also remove JSC usage from RN in other
files. This allows deleting files, too, which is done further down
the stack.
Reviewed By: RSNara
Differential Revision: D9369111
fbshipit-source-id: 67ef3146e3abe5244b6cf3249a0268598f91b277
Summary: This change drops the year from the copyright headers and the LICENSE file.
Reviewed By: yungsters
Differential Revision: D9727774
fbshipit-source-id: df4fc1e4390733fe774b1a160dd41b4a3d83302a
Summary:
To be able to test out new approach for NativeModules, introduce a simple runtime flag to enable the new system (doesn't exist yet). In addition, each module should declare a static `+ (BOOL)allowJSIBinding` in the objc class to be considered for the new approach. Doing so skips the processing of the module during bridge startup.
Note: this doesn't do anything special for `- (NSArray *)extraModulesForBridge:(RCTBridge *)bridge` impl yet.
Differential Revision: D9554296
fbshipit-source-id: 3508db6589e9f72367f62aa7ca15fce3d3adda72
Summary:
`RCTJavaScriptWillStartLoadingNotification` is being posted when starting the bridge, not when starting to execute JS code.
Here, we add `RCTJavaScriptWillStartExecutingNotification`, and in post it before executing JS with `RCTCxxBridge`.
Reviewed By: fromcelticpark
Differential Revision: D7153659
fbshipit-source-id: 902075308d54a47bef43b6f57edf2e624f621ceb
Summary:
Includes React Native and its dependencies Fresco, Metro, and Yoga. Excludes samples/examples/docs.
find: ^(?:( *)|( *(?:[\*~#]|::))( )? *)?Copyright (?:\(c\) )?(\d{4})\b.+Facebook[\s\S]+?BSD[\s\S]+?(?:this source tree|the same directory)\.$
replace: $1$2$3Copyright (c) $4-present, Facebook, Inc.\n$2\n$1$2$3This source code is licensed under the MIT license found in the\n$1$2$3LICENSE file in the root directory of this source tree.
Reviewed By: TheSavior, yungsters
Differential Revision: D7007050
fbshipit-source-id: 37dd6bf0ffec0923bfc99c260bb330683f35553e
Ramanpreet Nara
Samuel Susla
Lulu Wu
Peter Argany
Christoph Nakazawa
Valentin Shergin
Andres Suarez
Rick Hanlon
Min ho Kim
Kevin Gozali
RCiesielczuk
Marc Horowitz
Héctor Ramos
David Aurelio
Dan Zimmerman
Sophie Alpert
Semen Zhydenko
Yujie Liu
Alex Dvornikov
Ben Nham