Summary:
When TurboModules are created, we need to broadcast this event using `NSNotificationCenter`. This is important because a number of TurboModules/ObjC classes listen to this notification and perform side effects.
I found these using https://fburl.com/codesearch/j0a9p3dr.
- FBReactKitServerSnapshotTests: After the RCTExceptionsManager is initialized, it assigns itself as the delegate to the RCTExceptionsManager instance.
- FBProfilePictureUploadFlowController: After FBProfileFrameNativeModule is initialized, it calls `[module setFlowController: self]`
- RCTFBSession: After every NativeModule is initialized, if that NativeModule conforms to the RCTFBSessionModule protocol, assign the session to it.
- TwilightLocalMedia: Hack to figure out when the bridge is initialized.
- FBMarketplaceMenuItemHandler: After FBMarketplaceNativeModule is initialized, attach a data source obtained from the session to the module. Then, attach module to data source.
- RCTModuleInitTests: Set local state based on if certain modules are initialized (https://fburl.com/e34kezb5).
- IGReactModule: When the RCTImageLoader is initialized, set it's image cache to `[IGReactImageCache new]`.
- RCTIGUserSession: Like RCTFBSession
- FBReactModuleTracker: This keeps a list of all dispatched notifications (for some reason).
- RCTModuleInitNotificationRaceTests: Sets self.didDetectViewManagerInit to true if RCTTestViewManager is initialized.
Reviewed By: fkgozali
Differential Revision: D14281557
fbshipit-source-id: 9fcf1bb5f5650fcc3a3e50c6d93405b0b618e271
Summary: [IOS] [FIXED] - This may cause weird race condition if JSI is accessed via multiple threads within the same method invocation. Since only the objc class methods need to be executed on the right queue, we can keep the conversion to jsi::Value in the originating JS thread.
Reviewed By: RSNara
Differential Revision: D14277167
fbshipit-source-id: c506aebb71e190e2afcbf19dce05088ce2b97833
Summary: Let JS decide if a missing method should be treated as an error, or whether it allows optional methods (e.g. methods that are only for android or for ios).
Reviewed By: JoshuaGross
Differential Revision: D14155799
fbshipit-source-id: 1e298b46a59761cf09e98147da885b1e9a9a675a
Summary:
Some modules may have args with types stricter than just `NSDictionary`. For now, allow these modules to manually define a __turbo__* variant of the same method that receives basic NSDictionary/NSArray typed args. That helper method can do the conversion to the stricter type as necessary. This is only needed during migration phase of TurboModule.
Without this workaround, existing methods may get unrecognized selector errors.
Reviewed By: PeteTheHeat
Differential Revision: D14115981
fbshipit-source-id: ca7fcf497490ef9cce14c3d3444991c50d3cb550
Summary: Depending on the timing of the method call from JS to a CxxModule, we may be accessing memory that has been deallocated, causing exception to RN runtime. This fixes it.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D14033831
fbshipit-source-id: 5a77aa41223b1fc3146dcf78b7f8e93375605d6d
Summary: Similar macro as the existing one, but this one checks for the class directly.
Reviewed By: RSNara
Differential Revision: D14016664
fbshipit-source-id: aae9a9c1cc95f56d2eff6c9021a714ed4a843db3
Summary: At times, the lookup logic may find a class that's not compliant with RCTTurboModule. If so, it shouldn't be instantiated, and we assume the module doesn't exist.
Reviewed By: JoshuaGross, RSNara
Differential Revision: D13979004
fbshipit-source-id: ac1fa9cc456715cddd101fff13f5a41f9528a74e
Summary: Simple macro to do check if TurboModule is enabled and the particular object is RCTTurboModule compliant.
Reviewed By: PeteTheHeat
Differential Revision: D13978368
fbshipit-source-id: 660c7cab7bb074d80d57abead951dad19306ae73
Summary: Just tightened up the lookup logic to guard against nullptr.
Reviewed By: RSNara
Differential Revision: D13948001
fbshipit-source-id: 55bf46619712e60e195ea12f2b8eb799f80a3bbe
Summary:
It's okay for TurboModules to not exist. Therefore, `__turboModuleProvider(moduleName)` should return null if `moduleName` doesn't refer to an actual TurboModule. The current implementation assumes that the TurboModule must exist, and therefore, it crashes the app when it doesn't (assertion error).
This change is important because it helps us land D13887962. When we switch `I18nResources` to `TurboModuleRegistry` in D13887962, on Wilde, it won't be found in `NativeModules`. Therefore, we'll try to lookup this module in `__turboModuleProvider`, and this will crash the app. It seems like `I18nResources` is a Java-only module?
Reviewed By: fkgozali
Differential Revision: D13924589
fbshipit-source-id: 7ac7b1873e06852e5aafcaaef5c24cbc548ee444
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:
For better modularity, each module conforming to RCTTurboModule should provide a getter for the specific TurboModule instance for itself. This is a bit more extra work for devs, but simplify tooling and allow better modularity vs having a central function that provides the correct instance based on name.
Note: Android may or may not follow this new pattern -- TBD.
Reviewed By: RSNara
Differential Revision: D13882073
fbshipit-source-id: 6d5f82af67278c39c43c4f7970995690d4a82a98
Summary:
This commit moves all the turbo module files for Android to Github.
Note that gradle build is not yet enabled.
Sample Turbo Modules will be added in a later commit.
Other missing features
- Support for `CxxModule`
- Remove usage of folly::dynamic for arguments and result conversion
- Support for Promise return types.
Reviewed By: mdvacca
Differential Revision: D13647438
fbshipit-source-id: 5f1188556d6c64bfa2b2fd2146ac72b0fb456891
Summary:
The original commit was backed out due to a build failure, which seems to be due to compiler flag misconfiguration. That has been fixed.
Original commit: https://github.com/facebook/react-native/commit/f2fccbb327f891673cdc7eebd8df8e89909e36ec
Reviewed By: mdvacca
Differential Revision: D13593075
fbshipit-source-id: f3a65e8bd9830f6ac2ea829020500b4632ee2149
Summary:
This is the iOS binding for TurboModule.
To install the TurboModule binding:
* Provide `RCTCxxBridgeDelegate`
* Provide `RCTTurboModuleManagerDelegate`
Somewhere in `RCTCxxBridgeDelegate` impl:
```
RCTTurboModuleManager *manager = [[RCTTurboModuleManager alloc] initWithRuntime:&runtime bridge:bridge delegate:self];
[manager installJSBinding];
```
Doing so will install `global.__turboModuleProxy()` in JS space.
Note:
* The full instructions will be provided once all pieces are moved to OSS.
* Sample modules and binding setup will be provided later.
Reviewed By: RSNara
Differential Revision: D13583442
fbshipit-source-id: bb1cabd973e8a9ec59da6b145826e9ea234a96b3
Summary:
This is only the core C++ part of TurboModule - moving to github to make integration with existing NativeModules system slightly easier. Other bindings for iOS/Android are not yet ready to move.
Notes:
* TurboModules is not ready to use at the moment.
* Build configuration is not yet provided (cocoapods/.xcodeproj/gradle), just like Fabric.
* No effort was done to make this lib C++17 strictly compliant yet (there will be in the future).
Reviewed By: RSNara
Differential Revision: D13551211
fbshipit-source-id: cd3b458e6746ee9218451962ca65b1ad641a32db
Ramanpreet Nara
Kevin Gozali
Jonathan Kim
Ram N