Is there a way to enable TurboModule only without Fabric?

[nujhong]

Currently different new architectures are managed by an overarching flag RCT_NEW_ARCH_ENABLED

My use case is to start adopting JSI and writing cross-platform native modules in C++ for my app (out-of-tree platform), so some core components using Fabric view is still experimental.

I am wondering if this is feasible, I've tried the following solutions but neither work.

1. Disabling fabric_enabled

  use_react_native!(
    :path => '../node_modules/react-native',
    :hermes_enabled => true,
    :fabric_enabled => false, # ENV['RCT_NEW_ARCH_ENABLED'] == '1'
    # An absolute path to your application root.
    :app_path => "#{Pod::Config.instance.installation_root}/.."
  )

2. Overriding these methods in AppDelegate.mm

// https://github.com/facebook/react-native/blob/a9551641b47ebe9a032754fb0274b57c8ee18ea1/packages/react-native/Libraries/AppDelegate/RCTAppDelegate.mm#L130-152

- (BOOL)turboModuleEnabled
{
  return [self newArchEnabled];
}

- (BOOL)fabricEnabled
{
  return [self newArchEnabled];
}

- (BOOL)bridgelessEnabled
{
  return [self newArchEnabled];
}

[cortinico]

Why are you trying to enable only TurboModules without Fabric? The New Architecture is designed so you enable both TM, Fabric and Bridgeless mode together. We haven't tested different configuration combination so we cannot ensure it will work correctly.

[nujhong]

Thanks for the clarification.

To expand on it, the out-of-tree platform I'm developing on (i.e. https://github.com/microsoft/react-native-macos), has experiment support for Fabric core components. For example, TextInput or Touchable may not be responding to events correctly, while everything else (Views) renders just fine.

It's likely and edge case, so I was wondering whether this is technically possible from an architecture perspective, then I could experiment with different preprocessor directives.

// https://github.com/facebook/react-native/blob/68a6b69b27275998b4083797942f3e26a92d3adb/packages/react-native/Libraries/AppDelegate/RCTAppSetupUtils.mm#L49-L59

UIView *
RCTAppSetupDefaultRootView(RCTBridge *bridge, NSString *moduleName, NSDictionary *initialProperties, BOOL fabricEnabled)
{
  if (fabricEnabled) {
    id<RCTSurfaceProtocol> surface = [[RCTFabricSurface alloc] initWithBridge:bridge
                                                                   moduleName:moduleName
                                                            initialProperties:initialProperties];
    return [[RCTSurfaceHostingProxyRootView alloc] initWithSurface:surface];
  }
  return [[RCTRootView alloc] initWithBridge:bridge moduleName:moduleName initialProperties:initialProperties];
}

Now understanding how the new arch was designed with everything as one, I'll explore the different combinations as a one-off use case 👍

[cortinico]

cc @cipolleschi can tell you more on how to enable TurboModules only.
Anyway as I mentioned before, this is an untested/not-reccomended combination.

[cipolleschi]

The right way is to override those methods in the AppDelegate.mm.

If you override them, the app should respect those setting. However, Bridgeless needs Fabric and Fabric needs Turbomodule, so the proper setup should be:

- (BOOL)turboModuleEnabled {
  return YES;
}
- (BOOL)fabricEnabled {
  return NO;
}
- (BOOL)bridgelessEnabled {
  return NO;
}
- (BOOL)newArchEnabled {
  return NO;
}

[cipolleschi]

that if react-native-macos does not do anything to change how they behave.

[lencedev]

Thanks for the clarification.

To expand on it, the out-of-tree platform I'm developing on (i.e. https://github.com/microsoft/react-native-macos), has experiment support for Fabric core components. For example, TextInput or Touchable may not be responding to events correctly, while everything else (Views) renders just fine.

It's likely and edge case, so I was wondering whether this is technically possible from an architecture perspective, then I could experiment with different preprocessor directives.

// https://github.com/facebook/react-native/blob/68a6b69b27275998b4083797942f3e26a92d3adb/packages/react-native/Libraries/AppDelegate/RCTAppSetupUtils.mm#L49-L59

UIView *
RCTAppSetupDefaultRootView(RCTBridge *bridge, NSString *moduleName, NSDictionary *initialProperties, BOOL fabricEnabled)
{
  if (fabricEnabled) {
    id<RCTSurfaceProtocol> surface = [[RCTFabricSurface alloc] initWithBridge:bridge
                                                                   moduleName:moduleName
                                                            initialProperties:initialProperties];
    return [[RCTSurfaceHostingProxyRootView alloc] initWithSurface:surface];
  }
  return [[RCTRootView alloc] initWithBridge:bridge moduleName:moduleName initialProperties:initialProperties];
}

Now understanding how the new arch was designed with everything as one, I'll explore the different combinations as a one-off use case 👍

Given the experimental state of Fabric core components on react-native-macos, it's definitely possible that certain components like TextInput and Touchable behave differently due to how the Fabric renderer handles events compared to the legacy renderer.