TurboModules (NativeModules Re-architecture) #40
Comments
This comment was marked as off-topic.
This comment was marked as off-topic.
@empyrical, this isn’t related to turbomodules, but rather one of the other projects I’m working on. This won’t need to be lazy because requireNativeComponent won’t exist and the only work that will be done is returning the string “RCTView”. There will be no round trips to native so it won’t provide value to make this async. |
Does this proposal (and related parts such as JSI) mean C++ native modules will become a first class, documented citizen of the RN universe? That would be awesome, I’m doing a lot of work in this area and most of it had to be figured out by reverse engineering/trial and error. |
Depends on what you meant by first class citizen. You can already build C++ class that talks directly to the VM via JSI's An example consumer is https://github.com/facebook/react-native/blob/94d49e544d10d0039a1178dc97533e96a4354198/ReactCommon/fabric/uimanager/UIManagerBinding.h We plan to build a thin C++ wrapper on top of this direct access to HostObject to make the binding slightly easier in the future, but the first focus will be ObjC/Java modules. Documentation will come when they are all ready and stable. So yes, C++ modules will become first class in this angle. |
This is really interesting, thanks for the pointers. So far we've been working with Will have a proper look into it when time allows, we are doing some pretty interesting stuff with C++/React Native integration which pushes it fairly hard and could make a good test case for some of this stuff, so if you'd be interested in discussing in more detail please feel free to get in touch (details in Github bio)! |
@fkgozali Do you mean in the current version of react native we can already build and register C++ classes using jsi's HostObject to the VM? Are there any examples of this? I'm particularly unclear on where the registration would occur -- from outside of RN core. |
Yeah same question here - would be nice to know the recommended way to register a C++ JSI module |
Yes. We're working on a cleaner abstraction, but at the moment you can try something like this at your own:
Expect more documentation when TurboModule is ready to use. We moved a bunch of code for iOS already to github, Android coming soon, but sample code will be provided at later time. |
Thanks very much - I was looking at this today but it would have taken me a while to figure that out :) I noticed the Turbomodules stuff in github - seems to be adding a new layer of abstraction for this stuff? Would you say it’s better to develop against what is in master than what is in the RC branch if we want to have more of a chance of keeping close to the final API? |
That's correct. It's abstraction for crossing C++-->ObjC and C++-->Java. You don't need it if you want to stay in pure C++ via
Nothing in master/RC is ready to use, but you can get the idea about where we're headed. If you for some reason needs to play with |
@fkgozali I wonder if you'd be able to advise me a little further on the Android side of this? I was able to get it up and running on iOS without too much trouble and it seems great, but on Android I'm having issues and as I'm pretty new to the Android platform, not sure quite where I am going wrong. You said:
So, the only way I could find to get access to the I'm then passing the
Then in my
But this causes it to crash with a useless stack trace and no errors that I can see in logcat: Indeed, either of the lines Like I say, new to all this so I may be making some stupid mistake – if you have any pointers (heh...) or examples of doing this on Android, I'd be really grateful! Thanks, |
Will TuboModules make it easier to write native modules in Swift? Right now we still have to write Objective-C bridging code which is far from ideal. |
In case it helps, I wrote a module to automate away the creation of
bridging code:
NPM: https://www.npmjs.com/package/react-native-swift-bridge
GitHub: https://github.com/rhdeck/reactnative-swift-bridge
And eagerly await TM to find out how the bridge changes to similarly make
swift code easier for us native devs.
…On Thu, Feb 14, 2019 at 8:54 PM Rhys Powell ***@***.***> wrote:
Will TuboModules make it easier to write native modules in Swift? Right
now we still have to write Objective-C bridging code which is far from
ideal.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#40 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ALov_2APjndVX1WTDOSW5PI8psWUrowHks5vNhNkgaJpZM4XaH5o>
.
|
TurboModule foundation is just JSI + platform specific binding. JSI is C++, and for iOS, we need a binding to convert c++ calls into objc++ class methods. To support swift, such c++ to swift binding needs to be built (we won’t be building this as we’re focused on objc support right now). Then with codegen, swift code per module can be generated to some degree. |
@fkgozali Can you introduce more about the jsi/jsc refactor? Some native modules may need the jsContextRef which is now gone facebook/react-native@c49d365#diff-e15318f48b6447f2d9936c5e047d882fL395 |
See the comment above for now: #40 (comment) Why would you need direct access to the VM though? |
@fkgozali the webgl context needs this https://github.com/react-native-community/react-native-webgl/blob/master/cpp/RNWebGL.cpp#L205 |
The existing nativemodules system was not designed to provide you access to the VM directly since that can be dangerous (e.g. multithreaded access, since JS is single threaded, etc). The jsContextRef just happened to be added for a different purpose in the past. With JSI/TurboModule, you can achieve the same thing as https://github.com/react-native-community/react-native-webgl/blob/master/cpp/RNWebGL.cpp#L205 without getting access to the VM. This is done by subclassing JSI HostObject: https://github.com/facebook/react-native/blob/0d7faf6f73b942126e1f45016cde8fd480fd0164/ReactCommon/jsi/jsi.h#L98 -- In fact, TurboModule is just a special subclass of HostObject. So if your webgl stuff registers itself as TurboModule compatible and you provide your own HostObject subclass, then you don't need any access to the VM directly. This process is work in progress and will be documented when they're ready. For now, you can see the comment above as I previously pasted. #40 (comment) |
@fkgozali Thanks for your detailed explanation! I'll give it a try. |
@DomiR let's hope they create good guides for TurboModules, because let's be honest, I didn't get much information from the current NativeModules guides on reactnative.dev. My only source of information were 6 month old medium articles. I've thought about contributing to the docs and rewriting the Native Modules sections to be more detailled, but I'm afraid once TurboModules launch all of this will just be wasted time since NativeModules will be "deprecated" sooner or later anyways. |
hey folks - there's no updated at this point in time around TurboModules. I am aware that FB is cooking up something for the next 0.64 release that will be related to that. I don't want to give you false promises or misinformations, but what I know is that TurboModules before end of 2020 is still the plan on their side. |
@kelset Sorry for asking again. But i was checking 0.64 release issue and there is no mention of turbomodule or fiber. |
The Turbomodules, as well as JSI, is pretty much working and you can use it even right now – a great example of this is the new version of Reanimated which uses both JSI and Turbomodules to provide the best possible performance. But all the JSI bindings have been written by hand which is hard. That's why Codegen is that important in order to get to the point where we use Turbomodules for all the libraries and it's stable. But as you can see in the commit history there are lots of commits related to add support for Codegen for android. The iOS part seems to be ready. Also, there are constant commits of Fabric related things as well. There is no ETA but everything is in active development AFAIK. |
+1 on what @terrysahaidak is saying (thanks for answer that, I was on holiday last week). Just a correction on my last comment, the
Was scraped so I don't think in 0.64 there's going to be any TurboModule specific feature drop. |
@terrysahaidak @kelset I'm wondering how will the |
Nothing really changes for Animated API. Right now (alpha.7 version) you can see in Reanimated 2 installation instruction how to enable TurboModules. After that all the React Native modules (at least on iOS) will use TurboModules and JSI. But nothing changes because Reanimated 1 and 2 will allow you to write custom animation logic that will be executed on the UI thread directly, just like useNativeDriver does. |
@terrysahaidak thank you, will animated still be inefficient to be used compared to |
Not really. The main benefit of Reanimated - code is executed on UI Thread. Even with sync access to style updating from JS Thread, you still can just block the thread by some expensive business logic or for example when you render a new screen. The same thing may happen on web - that's why css3 transitions is used for such things. |
@terrysahaidak thanks, but still |
Too early to say.
The removal of the bridge will happen at a later stage. The bridge will be around for a while even after JSI + TurboModules + Fabric will be fully rolled out to ensure that everyone can smoothly transition. |
Could you elaborate on the performance gap you refer to, in your question ? Are you talking about startup, TTI, or simply calling native calls ? FWIW, you can use RN plugins with Flutter - http://blog.nparashuram.com/2018/12/using-react-natives-plugins-with.html, and the calling mechanism is similar. |
Reanimated is actually an excellent example of how JSI is used. At a high level, jumping back and forth between Native to JS would be much simpler. I am also hoping that we are able to use JSI to make interruptable or JS Controllable animated APIs. |
@axemclion reanimated not only benefit the jsi but it also run the javascript part of the animation on the UI thread |
Are you saying that JSC or Hermes would run on the UI thread ? Could you elaborate what you mean by running JS on the UI thread ? If I understand TurboModules correctly, you would basically "interrupt" UI thread, and wait for a response to the curve function from JS, and then resume the UI thread. Similar to how android animations work, where you have a separate function that helps you calculate the curve. |
It would help to define what you mean by CPU here. Are you refering to the various threads ? For example, if you run JS with Hermes, you would still use a separate thread which will still run the Hermes bytecode. This would be no different than what happens today. |
@axemclion Reanimated 2 will spawn a secondary JS context on the UI thread that then is able to run JavaScript functions. |
@lorenzoangelini it looks like you are not backing your claims with data and without those it's really hard to understand the actual differences you seem to imply there are EDIT: for future memory, this conversation looks like it doesn't make much sense because the original comment from the author quoted above disappeared (maybe he canceled it). |
Does it have any chance to support remote debugging in Chrome like it currently working? I really like reanimate 2 library, it awesome. but large debugging is required for large projects |
In case you are working on more data-type supports can you consider the followings as well?
|
When approximately these TurboModules will be ready? |
Since Swift is already the mainstream language for iOS development (and is easier to understand than ObjC, for JS developers at least) it would make sense to provide first class support for creating TurboModules in Swift. I've seen a lot of people refusing to edit anything natively since Objective-C land is a "frightening place". That's why using Swift results in a lot more people getting ready to jump into native development and increasing the overall react-native community engagement (see #253) While it is theoretically possible to use Swift for TurboModule development, it would be a real pain to interop with the JSI layer since that's written in C++. Correct me if I'm wrong, but afaik stuff like calling host functions, interacting with host objects, etc require a separate bridging layer that's built in one of two ways:
Either way you're very limited with C++ language features and can't use C++ types or templates in the second approach since Swift <-> C++ interop isn't fully available yet (see "How developed is C++ interoperability?") I think that it would make a lot of sense to make use of Swift's Property Wrappers (see Properties, scroll down to "Property Wrappers") for stuff like exporting functions, properties, TurboModules etc, which can then be transformed using codegen internally. Pseudo code on how this would look for turbo modules: @ReactModule
class AddTurboModule {
@ReactMethod
func add(a: Int, b: Int) -> Int {
return a + b
}
} Pros:
Note that a good developer experience almost always results in a good product.
Do you have any info to share about that part? @fkgozali |
The long term plan is to allow adding custom generators that consume the schema produced by Right now both generators live directly in the package, but later this year, we want to explore providing API to install your own custom generators outside of that package. When then happens, then more generators for other languages can be built and installed as "plugins" to your apps. This allows us to properly support Kotlin, Swift, pure C++, C# at least, like how ObjC and Java are supported. In summary: we have plans to allow this, but we won't be focusing directly on Swift support in core anytime soon. We see the react-native-codegen project to be the path towards providing more language support in the future. |
Introduction
This is a place for discussions around the upcoming "TurboModule" feature.
Terminology
TL;DR
From @axe-fb's blogpost, here's a temporary description of TurboModules (please consider that this is not yet finalized, it may change in the future)
Available Materials
At ReactConf 2018 @axe-fb did a talk about React Native's New Architecture, which also explains the 3 concepts above: JSI, Fabric, TurboModule.
IN Q1 2019, @kelset wrote a more high-level explanation in a blogpost: https://formidable.com/blog/2019/fabric-turbomodules-part-3/ and did a talk about the whole rearchitecture in April 2019 at React Edinburgh.
@kelset also did a more in-depth talk at React Advanced London in Oct 2019: youtube recording & slides.
Q&A
This is also a place for questions related to this effort and its direction.
The text was updated successfully, but these errors were encountered: