Gradually adoption of TurboModules, issues with Bridges, UIManager and RCTConvert

[davidseek]

Hello everyone,

first of all thank you for taking me in to the community.

I'm working on enabling TurboModules in our React-native 0.68.x App. The idea is to enable TurboModules, but leave all the existing Bridges (1p and 3p) as NativeModules. Only React-native itself would then run using TurboModules, and we would gradually upgrade existing Bridges.

I was following the Enablement documentation.

Application Overview

Our App is technically not using CocoaPods. Instead we have one parent Xcode project which links precompiled artifacts in form of .a libraries and Xcode frameworks.

For React-native artifacts, we're using a Dummy project with Cocoapods, solely to compile .a libraries for each Target within the CocoaPods Xcode project. All .a files as well as the Public Headers are then linked to Xcode project A. Project A is then compiled as framework, and that framework is linked to the parent Xcode project, to then compile the App.

Our current tool-chain requires us to have this workaround.

Missing NativeModules

Once we used RCTEnableTurboModule(YES), all NativeModules, which where not part of the parent Xcode project, where not found anymore. I was able to fix this using extraModulesForBridge and hard-coded declaration of all NativeModules.

Again: All Bridges, that where part of the parent Xcode project where found just fine. All Bridges, which where linked as precompiled artifacts, just like we did it before RCTEnableTurboModule(YES), where missing afterwards.

I was able to successfully link them using extraModulesForBridge - which we didn't have to implement before.

UIManager Components

Once we used RCTEnableTurboModule(YES) we got the following issue for every single UIManager NativeModule:

Invariant Violation: requireNativeComponent: "Foo" was not found in the UIManager.

The issue was, that the UI Component Foo should internally resolve to FooManager, which did not happen. The following override of the RCT_EXPORT_MODULE macro fixed my issue for all UI Components:

#define RCT_EXPORT_MODULE(js_name)          \
--
  |   | RCT_EXTERN void RCTRegisterModule(Class); \
  |   | +(NSString *)moduleName                   \
  |   | {                                         \
  |   | NSString *className = NSStringFromClass([self class]);\.  <--- new
  |   | NSDictionary *classToModuleMap = @{     \                <--- new
  |   | @"AIRMapManager": @"AIRMap",        \              <--- new
  |   | @"RNDateTimePickerManager": @"RNDateTimePicker",\      <--- new
  |   | @"RNCSafeAreaViewManager": @"RNCSafeAreaView",\       <--- new
  |   | @"RCTVideoManager": @"RCTVideo",    \         <--- new
  |   | };             <--- new
  |   | NSString *module = classToModuleMap[className];\     <--- new
  |   | return module ? module : @ #js_name;    \     <--- new
  |   | }                                         \
  |   | +(void)load                               \
  |   | {                                         \
  |   | RCTRegisterModule(self);                \
  |   | }

This tells me, that View Components, (most likely), which are not part of the parent Xcode project, are not resolving in their expected Foo/FooManager relationship.

RCTConvert Extensions

Once we used RCTEnableTurboModule(YES), all RCTConvert implementations, which are not part of the parent Xcode project, throw the following issue:

No +[RCTConvert RNSVGLength:] function found.
No +[RCTConvert RNSVGUnits:] function found.
No +[RCTConvert MKMapType:] function found.
...

I have yet to find an elegant solution for this problem. My assumption is, that once those implementations are part of the parent Xcode project, it should work just fine.

Summary

My hypothesis is, that this all leads down to us fully missing out on the concept of auto-linking. Additionally, in the Cocoapods world, all files are available as source files, while we're providing pre-compiled artifacts.

Is my hypothesis correct? Or what could be the reason, why the described issues and their solutions occurred?

[davidseek]

The solution for the missing RCTConvert extensions, happened to be linking the 3p packages directly with the final Xcode project. Linking through the aggregator package did not work anyone, once we used RCTEnableTurboModule(YES).

We still have to declare extraModulesForBridge and RCT_EXPORT_MODULE overrides for our 1p bridges and functionalities, but all 3p packages (SVG, Map, etc) now work without any additional configuration.

[cortinico]

I'm working on enabling TurboModules in our React-native 0.68.x App. The idea is to enable TurboModules, but leave all the existing Bridges (1p and 3p) as NativeModules.

What you're attempting to do is not recommended. The New Architecture is currently experimental and we support it only in the latest stable version (i.e. 0.72). There has been a number of highly significant changes between New Arch in 0.68 and 0.72, which makes the whole experience so different. So I highly suggest you that you first update RN version to the latest stable, and then start exploring the New Architecture.