-
This turned out to be more like a guide on how I did this and less of a discussable topic... But maybe the discussion could be if what I did is out-of-spec, and if not, maybe this could be included in the documentation. When using native modules, it was possible to use them within existing native apps without the necessity of creating a new module:
With Turbo Modules, this option is not mentioned in the documentation. I know that Turbo Modules are quite cutting-edge, but is it possible to use Turbo Modules directly within native apps, just like native modules? Well, it turns out, kind of :) (took me some time to figure out) Why do I want this? I'm trying to integrate React Native into my existing iOS and Android apps (Brownfield). By using native modules directly within my native apps, I can easily access old implementations/data without having to port them over into standalone modules. By doing some tinkering, I got this working on Android by essentially following the standard documentation but doing all the steps within my existing project. After that, I just had to overwrite the std::shared_ptr<TurboModule> javaModuleProvider(
const std::string &name,
const JavaTurboModule::InitParams ¶ms) {
auto module = RTNLoggingSpec_ModuleProvider(name, params); // <- this is my module
if(module != nullptr) {
return module;
}
// By default we just use the module providers autolinked by RN CLI
return rncli_ModuleProvider(name, params);
} On iOS, on the other hand, things were getting complicated for me. I placed the CodeGen artifacts within my iOS app (ios/build/generated/ios) and all my Spec files are there, just like on Android. But in order for XCode to recognize the Spec files, I had to include the folder After that, I could create a new objective-c++ file to implement the interface. However, XCode has no direct way to create objective-c++ files. After renaming my Turbo Native Module implementation file to I know this might not be the intended usage of Turbo Modules, but this really helps to adopt the new architecture in a brownfield scenario. Maybe somebody can build upon my approach, and I would appreciate any feedback. If something's not well described, feel free to reach out to me. |
Beta Was this translation helpful? Give feedback.
Replies: 5 comments 28 replies
-
If I understand correctly, you're asking how to use TurboModules without having to create an NPM package @flokol120 right? As you mentioned, this is possible, but it's not documented just because we believe there is possibility to polish a bit the local module setup. Once we have that experience polished, we'll document it accordingly. |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
@flokol120 This is brilliant ! It took me a while to find this post but this is exactly what we need... and that works perfectly. Typically our native code depends on the iOS scheme/target or the android variant. |
Beta Was this translation helpful? Give feedback.
-
It's now june, can we get some updated documentation on how to do this @cortinico? I tried following the steps inside of my app to create a internal turbo module, but when I try to generate the Java spec nothing is generated, even though I have the codegen config added into my |
Beta Was this translation helpful? Give feedback.
-
One thing I'm confused by: why do we need to add the explicit link to build/generated/ios when the NPM packages and local packages have the exact same structure within node_modules (with the exception of the local packages secretly being behind a symlink)? I'm also seeing Xcode having trouble linking to the generated ...Spec.h, but I don't understand how the NPM packages themselves are linking just fine. |
Beta Was this translation helpful? Give feedback.
If I understand correctly, you're asking how to use TurboModules without having to create an NPM package @flokol120 right?
As you mentioned, this is possible, but it's not documented just because we believe there is possibility to polish a bit the local module setup. Once we have that experience polished, we'll document it accordingly.