TurboModule Deep Dive

[cortinico]

Hi all,
I'm opening this discussion to discuss about one of the component of the New React Native Architecture: the TurboModule System.

Feel free to ask your questions/ideas/doubts related to this TurboModule in this discussion.

Relevant resources

• Enabling TurboModule support on Android
• Enabling TurboModule support on iOS
• Initial TurboModule proposal
• TurboModules (NativeModules Re-architecture) react-native-community/discussions-and-proposals#40
• Proposal about 0002-Turbo-Modules.md react-native-community/discussions-and-proposals#11

[jacobp100]

Something I can't quite find the answer to is the status of the bridge. I've heard the term 'bridgless' thrown about, but turbo modules still have a bridge.

I'm currently the only person maintaining a web-workers-like module, which uses the bridge. I want to take a stab at migrating this over to the new architecture, but wanted to know if this approach is going to be ok going forward.

[cipolleschi]

Hi @jacobp100, thanks for your question.

Currently yes, TurboModule still require the bridge to be initialized for backward compatibility.
When we use the TurboModule with the new architecture enabled, what happens is that the communication does not go through the bridge, but it uses JSI to share memory between the JS part and the native part.

In practice, JS holds references to C++ objects, and it can call methods on those objects directly, instead of serializing the required data in JSON and send them through the bridge.

I hope that this answer your question, feel free to ask more if you need. We are also working on improving the documentation, so more information will arrive soon.

PS: sorry for the late reply!

[jacobp100]

Thanks for your reply - that makes a lot of sense!

[cortinico]

To add to @cipolleschi 's answer, I can totally recommend this talk from Emily Janzer if you want to learn more about bridgeless mode & the New React Native Architecture:
https://www.youtube.com/watch?v=52El0EUI6D0

[ClaudiuHBann]

Hi @jacobp100, thanks for your question.

Currently yes, TurboModule still require the bridge to be initialized for backward compatibility. When we use the TurboModule with the new architecture enabled, what happens is that the communication does not go through the bridge, but it uses JSI to share memory between the JS part and the native part.

In practice, JS holds references to C++ objects, and it can call methods on those objects directly, instead of serializing the required data in JSON and send them through the bridge.

I hope that this answer your question, feel free to ask more if you need. We are also working on improving the documentation, so more information will arrive soon.

PS: sorry for the late reply!

What are the Bridging template specializations for? Just to map the properties of an c++ complex object to javascript?
For example the Bridging specialization for std::string will copy the data into a jsi::String:

If i have a std::map<std::string, std::string> this will be pretty expensive to "reference" it into the javascript runtime.

Can I move my C++ objects into the JSI objects? if not, can I at least have a view over them?

[tido64]

I'd like to know (or at least find out) what needs to be done in order to support autolinking TurboModules in the CLI. From what I can see, there's a lot of boilerplate code, and most of it (if not all) look like they could be generated. I also think that we should have this in place sooner than later.

cc @thymikee, @jsamr

[cortinico]

Awesome, looking forward to it 👍

[thymikee]

Draft PR: react-native-community/cli#1603

[cortinico]

Awesome, thanks for sendign this over

[shubham-ghanghotia]

Hi @tido64, thanks for your question. Can you point out the boilerplate code, please?

I can talk for iOS, while @cortinico may answer you about Android. In iOS, to enable autolinking, we need:

1. a podspec file for the module;
2. a xcodeproj situated in the ios folder.

If those two requirements are satisfied, the pod install step will be able to autolink the module.

I agree that we can improve the situation: I think that the requirement for the xcodeproj should be dropped and that many files can be generated automatically.

I hope this helps, let me know if you have more questions on the iOS part.

PS: sorry for the late reply!

That's great!
@cipolleschi How can I generate the .xcodeproj file in iOS for the library created using react-native-create-library?

[cipolleschi]

You can use Xcode to generate a new project and then add all the Swift/Objective-C/Objective-C++/C/C++ files you need.

[DanielFrTB]

Hi @cortinico ,
Does TurboModule support Running on the main thread?
on the old arch:
- (dispatch_queue_t)methodQueue { return dispatch_get_main_queue(); }

[cipolleschi]

RCTTurboModule doesn't have the same capability of specifying a queue and have every methods running on that queue, but if you implement the method methodQueue, we are keeping honoring it for backward compatibility.

In general, with TM, you should be able to handle the execution queue as you desire.

But what are you trying to do? Why you need to run a TM in the main queue?

[DanielFrTB]

@cipolleschi
We are trying to create a UIView on TurboModules and pass its instance to RCTViewComponentView.

[cipolleschi]

In the New Architecture, that's not supported nor advised.
TurboModule system and Fabric are meant to talk to each other through JS.
You should not try to create a View in a Turbomodule: that's also why Fabric does not need ViewManagers (which are native modules) to run in bridgeless mode.

We want to enforce a cleaner separation between Modules and Views because this architecture solves a classes of bugs we used to have in the Old Architecture due to Modules tinkering with the Views.

If you can explain a little bit more what you want to achieve (why you need to create a UIView in a TM and pass it to a RCTViewComponentView?), we can brainstorm together what's the best approach.