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

[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]

I feel like if we want people to adopt the new architecture, this needs to be in place.

Totally agree. So far our (Meta) focus has been to ship the minimum amount of infrastructure needed to make the New Architecture available to use. We also spent significant amount of time making sure that 3rd party libs have the necessary infrastructure needed to migrate their lib.

Autolinking is a crucial piece of infrastructure as well that we'd love to have in place asap. Currently users can still use New Architecture but will have to manually link their libraries (definitely not ideal).

If someone from the CLI, Callstack or the Community is willing to take a stance on this, I'm happy to support it.

[thymikee]

Ok, Callstack will take care of this. I may reach out to you @cortinico to challenge some ideas :)

[cortinico]

Awesome, looking forward to it 👍

[thymikee]

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

[cortinico]

Awesome, thanks for sendign this over

[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.