Proposal about 0002-Turbo-Modules.md

[axe-fb]

No description provided.

[kelset]

I'm a bit confused, but I understand this is a WIP so I guess once it's complete it will be clear.
Just one question:

This proposal discusses a new architecture to speed up the way Native Modules are initialized and invoked from JavaScript.

Is this something else from Fabric and from the JSI? Or, like, a proposal that aims to explain a side of the Fabric approach?

Just asking because if it's "Fabric related" I think that adding a new label for Fabric could help.

[axemclion]

This is not related to fabric, but is built on to of JSI. It could have been done independent of JSI too, but taking advantage of using host objects makes this better.

While fabric is mostly for view managers, this is for native modules.

[kelset]

So, basically, if I understand correctly:

Native <--> JSI <--> Turbo Module <--> Fabric <--> [code you actually write]

Is this rough scheme correct?

[axe-fb]

Not really. While UIManagerModule today is a Native Module, it does not have to be one. We are looking to move FabricUIManager to directly be able to install bindings on JSI. This way, the diagram would be

Java View Managers <--> JNI <--> C++ Shadow Tree <--> JS code => This is Fabric
Java Native Modules <--> JNI <--> C++ <--> JSI <--> JS Code => This is TurboModules

[kelset]

Ah wow, that's a great diagram - I think it would be helpful to have inside the proposal md :)

[gwmccull]

the getting-started link 404s

[axe-fb]

Sounds good - if only i could auto merge your changes !!

[grabbou]

Interesting - that sounds like what we have talked about two weeks ago at Facebook. I thought that it was part of Fabric when I heard about it - sounds really interesting. Looking forward to the updated proposal that goes a bit more technical into how the native modules work right now.

I am currently planning on working on better link and this is highly interesting to me.

[karanjthakkar]

@axe-fb Possibly silly question: Since the links in the RFC point to Java code and this diagram also talks about the lifecycle of native modules in Java land, I was wondering if the optimisations mentioned in this RFC also apply to the iOS side of things?

[fkgozali]

I was wondering if the optimisations mentioned in this RFC also apply to the iOS side of things?

It’ll be the same concept in iOS, just without JNI, and it’ll be ObjC classes instead of Java classes. The C++/JSI layer will be shared across platforms.

[eliperkins]

Thanks for putting this up here, @axe-fb! I left some general feedback so far.

So far, this discussion seems favored heavily towards the Android side of things... Is it worth creating a separate discussion for how this will work with iOS?

[eliperkins]

if a newer version of JavaScript

What do you think about wording this "if a newer version of the JavaScript bundle" so that folks don't confuse it with a newer JavaScript version like ES2030 or whatever 😄

[eliperkins]

s/singleton/singletons

[eliperkins]

This seems to be specific to Android. Is it worth mentioning the process that React Native for iOS uses here?

[fkgozali]

yeah probably good to have section explaining iOS, though the end goal is to share the c++/jsi layer across platforms

[eliperkins]

s/reference/references

[eliperkins]

Does "internally" here refer to Facebook or React Native in general?

[fkgozali]

Facebook

[eliperkins]

This will still require a compilation step, however. Is that correct?

[fkgozali]

yeah, everything still needs to be compiled, but c++ doesn’t need to ask Java/ObjC about the “shape of the module” anymore, reducing cost of starting up the system

[eliperkins]

Would you mind removing "simply" here? While it may be simple for you, using this word here might make others feel stupid if they don't understand what's so simple about this step.

[jamonholmgren]

Could use "directly".

[matthargett]

what about modules that are 100% implemented in C++? we have a few modules like this, as did my previous employer. my guess is that it would be an even more efficient communication: JS<->C++<->JS, instead of JS<->C++<->Java/ObjC<->C++<->JS, right?

[matthargett]

to this end, I think a sample AsyncStorage module that uses C++ iostreams to demonstrate the happy and error paths would be useful. specifically, an interface that takes this kind of race/lifecycle issue into account: microsoft/react-native-windows#1888

[fkgozali]

C++ only modules are definitely a good use case to cover. We’ll have some hooks after the objc/java hooks are finalized. We do have some C++ based modules internally, but all of them today need to be backed by objc/java, via CxxNativeModule (eg deferring to the os API to get storage path, etc).

For now, first step is to make TurboModule compatible with CxxNativeModule mechanism, then improve the binding to allow direct C++ impl without objc/java as the second step.

[matthargett]

great! avoiding the cost of even "fast" marshaling across JNI/.NET is key for scraping back CPU cycles and memory usage, especially in case of AsyncStorage, WebSocket, etc where giant blobs are potentially being copied today.

[eliperkins]

Perhaps we should look into a "compiler" that is similar to the Relay compiler. That is, some tool that would do the code gen for us in OSS, that BUCK could then depend on.

In the OSS version, we could add this as a build script to projects outside of BUCK.

[fkgozali]

yeah, we can treat this as a “script” that the build system calls/executes, e.g. buck calls this script for us internally at Facebook

[shergin]

I would explicitly mention here that Native Modules does not directly tight with UI rendering pipeline and that currently-existing View Managers (which are also Native Modules) will go away soon.

[aleclarson]

@shergin Is there more information on the coming removal of View Managers?

[fkgozali]

view managers will be handled as part of fabric rollout: #4

exact details for migration path is TBD

[shergin]

I would also mention here quickness/grayish-area of methods returning result synchronously, I feel we have to "legalize" them.

[fkgozali]

existing NativeModules system already supports returning values synchronously - not a gray area

[karanjthakkar]

@fkgozali Is there an officially supported way to return values from Native Modules synchronously? Or is this just something that's present internally but not exposed?

[fkgozali]

The support has existed for a while, you may use it, but just note that Chrome debugger doesn't support such synchronous call, so it may make debugging JS harder for you. It's kinda why it's not fully documented. See #7 for some context on debugging.

iOS: Use RCT_EXPORT_SYNCHRONOUS_TYPED_METHOD () instead of RCT_EXPORT_METHOD(): https://github.com/facebook/react-native/blob/ca898f4367083e0943603521a41c48dec403e6c9/React/Base/RCTBridgeModule.h#L175

Android: add (isBlockingSynchronousMethod = true) to your @ReactMethod annotation:
https://github.com/facebook/react-native/blob/c8e000b19a3dc47d58bc3ea1ede8211a370d59bb/ReactAndroid/src/test/java/com/facebook/react/bridge/BaseJavaModuleTest.java#L103

[matthargett]

just to note: both companies I have worked at ended up using sync calls in a surgical way for notable user-visible perf improvements.

[shergin]

I don't think that initialization of a native module should/can be tight with life-cycle of RootView; it can be before or after depending on particular module.

[axe-fb]

I agree - all I am saying is that it MAY happen at the rootView initialization for now, but this could also happen at other times - typically during a "bridge-prewarmup"

[matthargett]

keeping a "warm" bridge around initialized with the common first slice of the RAM bundle was used in a few RN Windows apps depending on if people launched the full app, or the "mini" tray app. I suspect this optimization is more common than even I know.

[shergin]

Why do they have to have same lifetime as JS scope especially if they are not singletons?

[fkgozali]

The C++ host objects have destructors (which will be called when the JS object gets GC'ed) which can tell platform specific classes to "clean up" or deallocate themselves.

[shergin]

Oh, I know, I know. My point is that JS scope usually can increment and decrement ref-counter, this does not always mean that the life-times are identical. I think we are on the same page, I would just clarify the spec.

[dryganets]

It sounds like we can't use typescript for react-native modules in new architecture unless we will generate/define the flow types for every module.

Is there a way to avoid flow usage?

[acoates-ms]

I believe the code gen tool has an intermediate data format for defining the module shape. Facebook happens to be generating that from flow, but an additional generator from typescript could easily be written and still use the same code gen. We can probably also add code gen that generates d.ts files also, which would allow the typescript definitions files to always be up to date for native modules -- even ones defined in flow, which would be an improvement over the hand generated ones people currently have to use.

[fkgozali]

Just an update for this exploration:

• We're still waiting for JSI commit to land in github, so OSS side of RN can start utilizing it. There are a bunch of testing we need to do internally before we're confident to land it.
• We have some early prototypes for this new system working internally - will be moved to github pending JSI commit.
• Will share the specifications once it's more stable, and again, pending JSI commit
• In the first phase:
  • It's all about feature parity with existing implementation for efficiency/perf purpose.
  • Expect all existing NativeModule classes (Java/ObjC) to be 100% backward-compatible with the new system. Eventually, we'll deprecate unnecessary layers.
  • The mechanism to register of each module may need some adjustments, and may involve codegen/scripting, but more details on that later. Eventually:
    • iOS: we're trying to move away from implicit +load inserted by RCT_EXPORT_MODULE() and other macros like RCT_EXPORT_METHOD().
    • Android: we're trying to move away from annotations like @ReactModule and @ReactMethod.

Also, like in #4, feel free to ask questions about the new system and we'll try to answer as best as we can.

[axe-fb]

I think we should merge this proposal PR into the repo. Like Fabric, we can use an issue for addressing questions. As we have updates, we can continue to update this doc.

If no one says otherwise, I plan to merge this on Sep 11, 2018, 10 am PDT.

[radex]

This is then used to generate Java and ObjC classes with method stubs with matching signatures, which can be extended for the actual implementation.

I'm not sure I'm understanding this 100% right, so: Are the generated ObjC classes just to make it easier to the user, or does the new system still rely on macros or ObjC runtime somehow to figure out the native module's methods and arguments? (I'm guessing no.)

In other words: will I be able to write plain Swift native modules, without having to hand-write the ObjC .m stub?

[fkgozali]

Are the generated ObjC classes just to make it easier to the user, or does the new system still rely on macros or ObjC runtime somehow to figure out the native module's methods and arguments?

What's generated is just objc @protocol and Java interface (or abstract class) that your module class just need to implement. The methods in those generated output are based on JS type (e.g. Flow), so you won't need any of the RCT_EXPORT_* macros or @ReactMethod annotations to expose your method signature to JS. This also provides build-time check to make sure that the JS and native "signature" are the same.

For Swift, in theory we could improve the scripting/codegen tool to additionally output Swift protocols.

[radex]

Thanks for clarifying! Unless it’s much more complicated than I expect, I’d be happy to contribute Swift codegen 👍

[axe-fb]

I would like to merge this in since we are working on this.

[fkgozali]

@axe-fb yup let’s do that, then we can open an issue for q&a like fabric

[karanjthakkar]

Hello 👋 Continuing this discussion from Twitter, I wanted to link to some notes that I wrote that paraphrase, in layman(hopefully) terms, how Turbo Modules is going to work and what are the advantages an RN team can expect out of this: https://gist.github.com/karanjthakkar/b0f75dde2f1717a450878bb9ea917104#turbo-modules. I'd love to know if I have the correct understanding of the implementation and impact from this.

[gianpaj]

Compatiability/Compatibility/s

[matthargett]

so... merge?