New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CodeGen Discussion #92

Open
kelset opened this Issue Jan 24, 2019 · 8 comments

Comments

Projects
None yet
5 participants
@kelset
Copy link
Collaborator

kelset commented Jan 24, 2019

Intro

With this issue I'd like to try and create a "one stop" for all the information available around the CodeGen: a tool to "glue" JS and native side: it will allow for supercharge static types (TS, Flow) for compatibilty with native binaries, among other things.

Terminology

  • Fabric: just the UI layer re-architecture, to take full advantage of concurrent React architecture. (dedicated issue)
  • TurboModules: re-architecture of NativeModules, also using JSI. (dedicated issue)
  • JSI: JavaScript Interface, it's a unified lightweight general purpose API for (theoretically) any JavaScript virtual machine. It enables every other piece of the rearchitecture. (dedicated issue)

TL;DR

From @axe-fb's blogpost, here's a temporary description of the CodeGen (please consider that this is not yet finalized, it may change in the future)

In both TurboModule and Fabric, interface available to JavaScript could be defined using Flow (or TypeScript). We can further leverage this interface definition to generate many of the C++ classes, and the interfaces/protocols for Java/ObjC implementations. For example, in case of TurboModules, the C++ class that wraps the Java/ObjC class and exposes the methods using a JSI object can be generated.
This will ensure that all JavaScript calls have implementations available on the native side, and will continue to ensure this with over the air updates like code push.

Available Materials

@TheSavior did an in-depth Twitch stream to explain the purpose of CodeGen.

Q&A

This is also a place for questions related to this effort and its direction.

@rhdeck

This comment has been minimized.

Copy link

rhdeck commented Feb 15, 2019

I'd love to learn more about this initiative. I've developed a couple of codegen modules to accelerate native development in swift on iOS (react-native-swift-bridge) and Kotlin on Android (react-native-kotlin-bridge). Greasing these skids so native devs can make RN-enabled modules with a minimum of RN-focused fuss is my goal.

@rhdeck

This comment has been minimized.

Copy link

rhdeck commented Feb 19, 2019

What is the directionality of the planned codegen?

For example: My work on RN-swift-bridge and RN-kotlin-bridge has been enabling native devs to write their work and minimize the "react native" overhead by generating the bridge and first-level JS bindings. So a swift developer writes swift, and then the ObjC and JS is auto-generated.

@kelset

This comment has been minimized.

Copy link
Collaborator Author

kelset commented Feb 19, 2019

cc @TheSavior @rickhanlonii they may be able to help you

@rickhanlonii

This comment has been minimized.

Copy link

rickhanlonii commented Feb 19, 2019

@rhdeck woah those projects are awesome!

The direction we're going is from javascript to native (so the source of truth is Flow/TS). Is there a particular reason you chose the other direction?

@rhdeck

This comment has been minimized.

Copy link

rhdeck commented Feb 19, 2019

To my mind the most valuable native extension functionality - once you get past common core components - is about applying deep knowledge within the platform and bringing it to JS land for orchestration. JS developers know how to conduct, but they don't know how to play every instrument.

Enabling a specialist in a piece of native tech (say, CoreML) to bring that tech with a minimum of friction to the JS context seems like the direction of value, and is the reason I wrote the bridges the way I did.

In most cases the more expensive resources are the deeper specialists, so greasing their paths to (once) create modules reusable by the army of react devs who don't need to be versed in the more arcane aspects of the native interface seems like the direction of highest value.

All my opinion of course. Would love to understand the RN team's POV on the other direction and the codegen plan.

@TheSavior

This comment has been minimized.

Copy link

TheSavior commented Feb 19, 2019

One of the main reasons our directionality was picked was to enforce cross platform compatibility. We want to push the ecosystem to provide modules that work across more platforms instead of only a single one. However, we need to continue supporting single platform modules. If we generated from native code, would we generate from java files? What about iOS only modules? If we generated from ObjC/Swift then what about java only modules? Do we write the codegen for each language so someone can use whatever they feel most comfortable in? Then other people in the ecosystem are less likely to be able to contribute to that module and the codegen will be fragmented across multiple implementations.

We could move the definition to cross platform c++ but we think people are even less likely to feel comfortable writing quality c++.

The common language for all React Native projects, on any platform not just including iOS/android but also VR, Windows, TV, Mac, Web is JavaScript. We figure that getting people to write a single interface file in JS would be the easiest choice to create modules that support all the needs. This is also a major part of why we are not using something like WebIDL as the source of truth.

@rhdeck

This comment has been minimized.

Copy link

rhdeck commented Feb 19, 2019

That's a good manifesto! Will give the approach more thought.

@michalchudziak

This comment has been minimized.

Copy link

michalchudziak commented Feb 21, 2019

I like the idea. I think having such a CodeGen would lower the entry barrier for devs w/o native knowledge and encourage them to play with native modules a bit more, which seems like the right direction to follow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment