Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
CodeGen Discussion #92
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.
This is also a place for questions related to this effort and its direction.
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.
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.
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.
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++.