How much code duplication is expected in a backwards compatible Turbo Module?

[jerielng]

I'm referencing these instructions to migrate a Native Module over into a backwards compatible Turbo Module. From the docs, I was getting the impression that we are expected to maintain our method interfaces in two separate places, once in the Turbo Module Spec and separately in the legacy Native Module JS layer.

So far, I've only enabled the New Architecture compiler flags in my app's Gradle and pod install steps, defined the Codegen specs, and created an empty class stub for my Turbo Module spec. However, I'm finding that I'm able to access all the methods and constants at runtime without having to declare any method signatures in my Spec.

Is this expected behavior?

[cortinico]

However, I'm finding that I'm able to access all the methods and constants at runtime without having to declare any method signatures in my Spec

Sorry can you clarify your question.

1. Are you running on New Architecture or on Old Architecture?
2. To which instructions you're referring to specifically?
3. "I'm finding that I'm able to access all the methods and constants at runtime" Which methods are you referring to?

[jerielng]

Sure thing:

1. When running on either the New Architecture or the Old Architecture, I'm able to compile and run my library successfully, even though I didn't think my migration was fully complete yet.

2-3. To clarify, in the Old Architecture, I was previously maintaining all the method signatures for my Native Module in a JavaScript class, which depended on native implementations using RCT_EXPORT_METHOD in my iOS Objective-C code and @ReactMethod in my Android Kotlin code.

So far while testing on iOS, I have only added the conditional compilation macros in my iOS module from these instructions. And created an empty Spec class like so:

export interface Spec extends TurboModule {}

export default (TurboModuleRegistry.get<Spec>('MySpec') as Spec | null);

In short, I was expecting that I needed to duplicate all the method signatures that were previously in my JS Native Module into my Spec class, but I'm finding that without doing so, my library is compiling and working fine with an app built on the New Architecture. I wanted to verify if this was expected, or am I missing something and should be maintaining my method interfaces separately if I want to make my module backwards compatible?

Hope that clarifies the question! If I'm misunderstanding anything, please let me know.

[cortinico]

but I'm finding that without doing so, my library is compiling and working fine with an app built on the New Architecture.

I understand thanks for clarifying. What is happening is that your library is working in "backward compat" mode, behaving as a old architecture component. To ease the migration to New Architecture for our users, we're spending time in adding mechanism like this one, that let old libraries work on New Architecture.

You will still need to follow those instructions if you want to use all the new APIs from the New Architecture as your library is not effectively migrated yet.

[jerielng]

Ah got it, thanks so much! So if I understand it correctly, today, Native Modules are fully compatible with the New Architecture via backwards compatibility but until they are fully migrated to Turbo Modules, they will not be able to leverage new features in the future.

From the method implementation of TurboModuleRegistry.get, I understand that it looks for both NativeModules and TurboModules under the hood. Will this backwards compatibility migration logic always be available, or is it expected to be deprecated and removed in the future?

[cortinico]

Ah got it, thanks so much! So if I understand it correctly, today, Native Modules are fully compatible with the New Architecture via backwards compatibility but until they are fully migrated to Turbo Modules, they will not be able to leverage new features in the future.

Correct

or is it expected to be deprecated and removed in the future?

This logic is to make easier for folks to migrate. You can expect it to get stricter or be removed at some point in the future.