TurboModules (NativeModules Re-architecture) about discussions-and-proposals HOT 102 CLOSED

Please when will TurboModule be integrated?

All the support is already in Github, and we have enabled it on RNTester app on Android and iOS, so you can take a look at the integration if you like. 0.64 may not have all the pieces in place, but master branch has them. The major thing missing is the integration with 3rd party modules and migration playbook, which we are working on finalizing for later this year.

from discussions-and-proposals.

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

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:

• Swift -> Objective-C -> Objective-C++
• Swift -> C -> C++

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:

• Makes react native module development a lot easier (and therefore more beginner friendly, increasing community engagement)
• Essentially provides more performance since Swift can be faster than Objective-C in some cases. And don't we all want our apps to be as fast as possible?
• Less boilerplate
• Support for APIs written in Swift (there are a lot of those already)
• As an added bonus, this also makes writing a native module for iOS very similar to writing a native module for Android, since Attributes such as @ReactMethod are used in Android as well.

Note that a good developer experience almost always results in a good product.

Then with codegen, swift code per module can be generated to some degree.

Do you have any info to share about that part? @fkgozali

from discussions-and-proposals.

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.

from discussions-and-proposals.

When approximately these TurboModules will be ready?

from discussions-and-proposals.

Here is roadmap update from react native team

https://reactnative.dev/blog/2021/08/19/h2-2021

Looks like they are planning to release new architecture by end of this year.

from discussions-and-proposals.

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.

from discussions-and-proposals.

I noticed the Turbomodules stuff in github - seems to be adding a new layer of abstraction for this stuff?

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 jsi::HostObject.

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?

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 jsi::HostObject sooner, by all means go for it. If you're in no rush, I'd wait for more official guidelines/docs on how to use TurboModule.

from discussions-and-proposals.

+1 on what @terrysahaidak is saying (thanks for answer that, I was on holiday last week).

Just a correction on my last comment, the

I am aware that FB is cooking up something for the next 0.64 release that will be related to that.

Was scraped so I don't think in 0.64 there's going to be any TurboModule specific feature drop.

from discussions-and-proposals.

@henrymoulton

Fast Refresh should work normally, but old Chrome debugger flow won't work because of the lack of sync call support in that env. We're still hashing out the debugger solution later, but a few things you can try:

• On Android, if you're using Hermes, try to use Flipper and Hermes debugger flow there
• On iOS, for now you could try Safari tool described here: http://blog.nparashuram.com/2019/10/debugging-react-native-ios-apps-with.html
  • or if you're on 0.64 release, you could try out the Hermes support introduced there and use the same debugging flow as Android: https://reactnative.dev/blog/2021/03/12/version-0.64#hermes-opt-in-on-ios

If you're hitting issue with Fast refresh, make sure you're not connected to the old Chrome debugger flow (the one you launch from dev menu) and see if the problem is solved. If not, would you mind opening a new issue and linking to it here?

To disable TurboModule in RNTester (not recommended but OK for your own exploration), change the flag(s) here:

• iOS: set this to NO: https://github.com/facebook/react-native/blob/master/packages/rn-tester/RNTester/AppDelegate.mm#L84
• Android: change this gradle build flag to false instead of using $enableCodegen: https://github.com/facebook/react-native/blob/master/packages/rn-tester/android/app/build.gradle#L160
• Then rebuild the app

from discussions-and-proposals.

Hi guys,

if you need to play with TurboModule and CodeGen outside react-native master. Check out my repo: https://github.com/thegamenicorus/TurboModulePlayground

from discussions-and-proposals.

@mrousavy

Do you have any info to share about that part?

The long term plan is to allow adding custom generators that consume the schema produced by react-native-codegen. Today, we're just focusing on ObjC and Java generators because that's what React Native core supports directly.

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.

from discussions-and-proposals.

Hey @sav007, you can use Java/Kotlin as you would use before. Turbomodules aren't about rewriting everything to C++, they are about several things:

1. Lazy initialization – allows you to initialize module instance only then you calling it at the very first time, not on the app initialization itself.
2. JSI – JavaScript Interface – in fact, this is the new iteration of the "bridge" helping you triggering all the Java code from the JS. The old bridge has overhead – JSON serialization of each call on both sides – from the JS and from the Java. But JSI allows you to skip that part, so it's much faster.
3. JSI is completely synchronous.

So you will need to create a module spec and "codegen" the C++ part of it, it will create a JSI "bridge" for your module in order to allow you to call all your methods from JS really easy and get response blazingly fast.

from discussions-and-proposals.

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

from discussions-and-proposals.

You can be sure that JVM -> JNI -> JS is still waaaaaay faster than a previous serializable bridge. Yes, there is always some overhead, JS VM is already overhead, but it allows us to use all the cool features React provides us.

@axemclion once mentioned on some conference talk that fully Fabric application will allow you to run 60 fps animation using requestAnimationFrame cause the performance of JSI is enough to do it, let's see :)

from discussions-and-proposals.

I kinda lost track of the current state of all of this - Is it already possible to write TurboModules or do we have to wait for the whole react-native re-architecture (including JSI, Fabric, ...)? I can't find a lot of examples, there is this guide that somehow explains how to create a TurboModule in Android, but I haven't tried it out yet. Also, I couldn't find anything for iOS, especially not for Swift.

I'm currently writing a native module that could benefit from a performance boost using TurboModules, also I could write a quick cheat sheet for migrating from native modules, or TurboModules in Swift all together.

from discussions-and-proposals.

In case you are working on more data-type supports can you consider the followings as well?

1. Int64 and UInt64 and other primitive data-types (https://developer.mozilla.org/en-US/docs/Mozilla/js-ctypes/js-ctypes_reference/Int64).
2. Typed arrays (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Typed_arrays).
3. Blob objects with actual data possibly in native side (https://developer.mozilla.org/en-US/docs/Web/API/Blob), with networking support.
4. Null character in strings (facebook/react-native#24129)

from discussions-and-proposals.

Here's the magic 🪄:

// from java:
CallInvokerHolderImpl callInvoker = (CallInvokerHolderImpl) context.getCatalystInstance().getJSCallInvokerHolder()
initialize(runtime.get(), callInvoker)

// in c++:
extern "C" JNIEXPORT void JNICALL Java_com_mrousavy_MyModule_initialize(JNIEnv* env, jclass clazz, jlong jsiRuntime, jni::alias_ref<facebook::react::CallInvokerHolder::javaobject> callInvoker);

// cast:
auto jsCallInvoker = jsCallInvokerHolder->cthis()->getCallInvoker();

But keep in mind that this is pretty unrelated to the issue.

from discussions-and-proposals.

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?

Yes. We're working on a cleaner abstraction, but at the moment you can try something like this at your own:

• iOS
  • provide RCTCxxBridgeDelegate for the bridge in your app
  • #import <React/RCTBridge+Private.h>
  • in the protocol impl for - (std::unique_ptr<facebook::react::JSExecutorFactory>)jsExecutorFactoryForBridge:(RCTBridge *)bridge
    • return nullptr;
    • before returning, get the jsi::Runtime off the bridge: jsi::Runtime *runtime = (jsi::Runtime *)bridge.runtime;
    • once you get the runtime, you can do whatever you want to install your jsi::HostObject to JS. Example: https://github.com/facebook/react-native/blob/acc2ed2488761cd3d63839d56cbf95079c8cd551/ReactCommon/turbomodule/core/TurboModuleBinding.cpp#L25-L38
• Android
  • Same deal as iOS, but get the runtime off catalystInstance.getJavaScriptContextHolder(), which you can pass down to JNI, then cast it to jsi::Runtime * like in iOS.

would be nice to know the recommended way to register a C++ JSI module

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.

from discussions-and-proposals.

With facebook/react-native@0bd931e, SampleTurboModule was installed into RNTester iOS. You can the sense of how it works end-to-end. To try:

• You must use CocoaPods version of RNTester, so do pod install like usual, then open RNTesterPods.xcworkspace
  • If you open RNTester.xcodeproj directly, TurboModule system won't be installed.
• Open RNTester's TurboModuleExample

from discussions-and-proposals.

I still think the main reason it hasn't been released yet is the fact that there is no solution fo remote debugging. As soon as you enable turbo modules, debugger is not available. The only way to debug is it connect to remote context. And it's way far from best debugging experience.

The current solution for this I guess is to enable Hermes in dev on iOS. It supports chrome debugger protocol so it should be easy to integrate existing debugger (as well as VSCode one) but the whole thing will be executed on the device/simulator which allows us to have access to JSI based stuff.

from discussions-and-proposals.

@kelset Sorry for asking again. But i was checking 0.64 release issue and there is no mention of turbomodule or fiber.

from discussions-and-proposals.

@yaaliuzhipeng As a rule of thumb, report issues like this one either on github.com/reactwg/react-native-new-architecture/ (if you don't have access yet, you can apply for it with the form in the README).

Could not find method react() for arguments

This happens as you don't have the React Gradle Plugin applied in that module. I would say that you miss a:

plugins {
  id("com.facebook.react")
}

but not knowing your full gradle file setup, makes hard to say if this is the only issue

from discussions-and-proposals.

Does this proposal (and related parts such as JSI) mean C++ native modules will become a first class, documented citizen of the RN universe?

Depends on what you meant by first class citizen. You can already build C++ class that talks directly to the VM via JSI's HostObject - all JSI code is already in master: https://github.com/facebook/react-native/blob/bf2500e38ec06d2de501c5a3737e396fe43d1fae/ReactCommon/jsi/jsi.h#L80

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.

from discussions-and-proposals.

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.

from discussions-and-proposals.

I'm wondering how will the Animated Api when Turbomodules & jsi are fully out, and how would it compare to reanimated 1 and reanimated 2 ?

Too early to say.

afaik, JSI & TurboModules will eliminate using the RN bridge,

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.

from discussions-and-proposals.

So I tried to make my own TurboModule and Fabric Module the other day. I could already make a JSI C++ module no problem, so I wanted to try a real turbo module next. The only missing piece at this piece seems to be the codegen. It is in master and I am able to track how react native calling it when building for iOS, but could not really figure out how I would use it with a new module not in the react native core.

Anyways, just wanted to report that it seems to be really close and I am pumped (as a C++ dev by day) to start using them.

from discussions-and-proposals.

I'm wondering how will the Animated Api when Turbomodules & jsi are fully out, and how would it compare to reanimated 1 and reanimated 2 ?

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.

from discussions-and-proposals.

from discussions-and-proposals.

@patrice4github any luck?

I'm getting the following error upon upgrading to latest RN version

 *** Terminating app due to uncaught exception 'RCTFatalException: Unhandled JS Exception: Invariant Violation: TurboModuleRegistry.getEnforcing(...): 'DevSettings' could not be found. Verify that a module by this name is registered in the native binary.', reason: 'Unhandled JS Exception: Invariant Violation: TurboModuleRegistry.getEnforcing(...): 'DevSettings' could not be found. Verify that a module by this name is registered in the na..., stack:
getEnforcing@2052:28
<unknown>@41002:50
loadModuleImplementation@271:14
<unknown>@40961:40
loadModuleImplementation@271:14
<unknown>@35542:18
loadModuleImplementation@271:14
<unknown>@28660:16
loadModuleImplementation@271:14
guardedLoadModule@163:47
global code@323476:4
'

from discussions-and-proposals.

Just FYI, @stmoy has opened a dedicated conversation to discuss how developers are expected/should expect to start using TurboModules -> #195

I'm sure he'd love to hear your experiences & ideas (since quite a few of you already tried them out!)

from discussions-and-proposals.

Sorry if this is the wrong place. I didn't find any good place to post this possibly turboModules issue.

I just upgraded from RN 0.63.2 to 0.64. And my project doesn't build anymore due to this:
shared_timed_mutex' is unavailable: introduced in iOS 10.0
Error located in RCTTurboModuleManager

My build target is ios 10.0. I even tried to bump it to 11. Googling this error brings nothing, which is quite rare when googling RN problems.

Should I post this elsewhere?
Any idéas?

Edit:

My bad, sorry. Solved.
facebook/react-native#31250

from discussions-and-proposals.

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

from discussions-and-proposals.

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.

from discussions-and-proposals.

I want to use TurboModules to send events from Java to JS using JSI bridge. But i am not able to find a right docs or sample code to proceed. Below is what I have achieved so far.

Code to register and later callback

 void TrimNativeModule::sendKeyEvent(jsi::Runtime &rt, const jsi::Object &arg) {
        if (keyCallback != nullptr) {
            jsi::Function funPtr = keyCallback->getFunction(rt);
            jsInvoker_->invokeAsync([&rt, &funPtr](){
                funPtr.call(rt);
            });
        }
    }

    void TrimNativeModule::registerKeyCallback(jsi::Runtime &rt, const jsi::Function &callback) {
        keyCallback = &callback;
    }

Below is the JS side code

  global.trimModule?.registerKeyCallback(() => {
  console.log("Got Call back");
});

Registration is working but when I tried to do call sendKeyEvet later for an event from Java native function call back is not called back

Any help or pointers on this will be helpful

from discussions-and-proposals.

@radelcom

iOS

1. import RCTTurboModule.h
2. use bridge.jsCallInvoker (RCTBridge)

Android

1. Use context.getCatalystInstance().getJSCallInvokerHolder() (ReactApplicationContext)

from discussions-and-proposals.

This is really interesting, thanks for the pointers. So far we've been working with CxxModule, looks like this could be a cleaner alternative!

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)!

from discussions-and-proposals.

@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:

Android
Same deal as iOS, but get the runtime off catalystInstance.getJavaScriptContextHolder(), which you can pass down to JNI, then cast it to jsi::Runtime * like in iOS.

So, the only way I could find to get access to the JavaScriptContextHolder was to create a new Native Module, and get hold of this in the initialise method like: long context = getReactApplicationContext().getJavaScriptContextHolder().get(); (in iOS, I was able to do this without a module, in my AppDelegate by just getting .runtime from the RCTCxxBridge instance, but I couldn't work out the equivalent in Android).

I'm then passing the context over JNI to C++, so my native module code looks like:

package com.reactnativejsi;

import com.facebook.react.bridge.NativeModule;
import com.facebook.react.bridge.ReactApplicationContext;
import com.facebook.react.bridge.ReactContext;
import com.facebook.react.bridge.ReactContextBaseJavaModule;
import com.facebook.react.bridge.ReactMethod;

public class JSIModule extends ReactContextBaseJavaModule {
    static {
        System.loadLibrary("test_module_jni");
    }

    public JSIModule(ReactApplicationContext reactContext) {
        super(reactContext);
    }

    @Override
    public void initialize() {
        super.initialize();

        long context = getReactApplicationContext().getJavaScriptContextHolder().get();
        install(context);
    }

    @Override
    public String getName() {
        return "JSIModule";
    }

    public native void install(long runtime);
}

Then in my TestModule.cpp, I'm installing the module by calling runtime.global().setProperty(runtime, testModuleName, std::move(object)); - the code is roughly:

std::shared_ptr<TestModuleBinding> testModuleBinding;

extern "C" {
  JNIEXPORT void JNICALL
  Java_com_reactnativejsi_JSIModule_install(JNIEnv* env, jobject thiz, jlong runtimePtr) {
    testModuleBinding = std::make_shared<TestModuleBinding>();
    jsi::Runtime* runtime = (jsi::Runtime*) runtimePtr;

    auto testModuleName = "testModule";
    auto object = jsi::Object::createFromHostObject(*runtime, testModuleBinding);
    runtime->global().setProperty(*runtime, testModuleName, std::move(object));
  }
}

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 auto object = jsi::Object::createFromHostObject(*runtime, testModuleBinding); or runtime->global().setProperty(*runtime, testModuleName, std::move(object)); on their own is enough to cause the crash, or even just trying to access runtime->global() and assign it to something... so I am guessing there is something bad about my runtime instance, but I'm a bit of a loss how to debug further!

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,
Tom

from discussions-and-proposals.

@rhdeck that’s awesome and a great idea. We are actually planning on building this into the system for TurboModules. ;-) Have you seen this discussion? #92

from discussions-and-proposals.

TurboModule/Fabric are not ready for wide adoption yet, we're still working on it. You can expect announcement & proper documentations when that happens later this year.

from discussions-and-proposals.

Hi folks,
I have a question regarding Android. Specifically what all these mean for existing native modules written on Java / Kotlin that lives in JVM world, should they be rewritten on C/C++ in order to be consumed as TurboModules?
If not I guess the only way to make them work is using JNI? What about the performance, won't it be a bottleneck JVM -> JNI -> JS as it involves marshalling across the JNI layer? I don't even mention about the complexity it can bring in multithreading environment.

from discussions-and-proposals.

JSI – JavaScript Interface – in fact, this is the new iteration of the "bridge" helping you triggering all the Java code from the JS. The old bridge has overhead – JSON serialization of each call on both sides – from the JS and from the Java. But JSI allows you to skip that part, so it's much faster.

So in order to build such communication JNI is going to be used, right? That brings to my second question:

What about the performance, won't it be a bottleneck JVM -> JNI -> JS as it involves marshalling across the JNI layer?

https://developer.android.com/training/articles/perf-jni

Minimize marshalling of resources across the JNI layer. Marshalling across the JNI layer has non-trivial costs. Try to design an interface that minimizes the amount of data you need to marshall and the frequency with which you must marshall data.

It looks like the existing RN bridge is going to be replaced by another JNI bridge that concerns me from perf perspective.

from discussions-and-proposals.

I ended up trashing my project, starting over with a client project, reimporting the files one by one...
Took me forever.

I'm realizing that with RN I spend more time investigating and debugging framework issues. Going back to native development for now.

from discussions-and-proposals.

@TheSavior it's not a new project, an older project but I just upgraded RN version to 0.61.4 from 0.60.5 and started getting this error. From what I can tell TurboModules isn't enabled.

Weirdly, if I am building the 'debug' configuration it doesn't show up, everything works fine. We have a few custom configurations and it's showing up when I build our Staging configuration.

I came across this: facebook/react-native#26987 and seems like others are having similar issues.

from discussions-and-proposals.

@DomiR

Why isn't caching constants in JS done more generically (e.g. within the TurboModuleRegistry class), instead of re-implementing the "spec" like done in the diffs? It seems to me that we are introducing the whole boilerplate from the spec just to cache the constants... if this is a good practice, why not do it for everyone?

1. This is NOT a good practice. TurboModule no longer special-case getConstants() unlike the old NativeModules. Which is why we'll be moving away from getConstants() specifics, like general caching in the old system. This is for simplicity and better overall performance.
2. However, we're trying to isolate some regression that may be caused by the modules affected in the commit you linked. If we can pinpoint the problematic module, it would be easier to investigate the infra fix for it, or tweak the module impl to fix the issue. Doing it for all modules will make it impossible to isolate the issue.
3. In the future, @RSNara has some plan to allow per-method memoization with simple annotation in the spec, but not for TurboModule v1.
4. Finally, stay tuned for proper documentation explaining all these details (when it's closer to release time later this year).

from discussions-and-proposals.

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

from discussions-and-proposals.

@terrysahaidak @kelset I'm wondering how will the Animated Api when Turbomodules & jsi are fully out,
and how would it compare to reanimated 1 and reanimated 2 ?

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.

from discussions-and-proposals.

@terrysahaidak thank you,
afaik, JSI & TurboModules will eliminate using the RN bridge, which is the main limitation for the Animated Api, any why SWM had to create their awesome RNGH & Reanimated.

will animated still be inefficient to be used compared to reaniamted 1 or 2 ?

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.

from discussions-and-proposals.

Please when will TurboModule be integrated?

I probably taught it would be shipped with [email protected].

from discussions-and-proposals.

cc @kelset - wanna label this one with "Transparency"? I don't have access looks like.

cc @axe-fb

from discussions-and-proposals.

Not sure if native components would get covered by this. But, I wonder, could lazy loading native components take advantage of Suspense? Something like this:

const RCTWebView = lazy(() => lazyRequireNativeComponent('RNCUIWebView'));

Then, in the wrapper component:

<Suspense fallback={this.props.renderPlaceholder()}>
  <RCTWebView />
</Suspense>

The placeholder view could be specified by the developer as a prop.

This may be a little hacky, however, since it expects to be only used with a promise returned from import().

So the promise returned by this hypothetical lazyRequireNativeComponent would need to be an object like: { default: [the native component] }

from discussions-and-proposals.

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

from discussions-and-proposals.

Yeah same question here - would be nice to know the recommended way to register a C++ JSI module

from discussions-and-proposals.

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?

from discussions-and-proposals.

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.

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.

from discussions-and-proposals.

@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

from discussions-and-proposals.

Some native modules may need the jsContextRef which is now gone

See the comment above for now: #40 (comment)

Why would you need direct access to the VM though?

from discussions-and-proposals.

@fkgozali the webgl context needs this https://github.com/react-native-community/react-native-webgl/blob/master/cpp/RNWebGL.cpp#L205
I am not familar with c++, is there anyway to access the vm in the legacy native module?

from discussions-and-proposals.

I am not familar with c++, is there anyway to access the vm in the legacy native module?

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)

from discussions-and-proposals.

@fkgozali Thanks for your detailed explanation! I'll give it a try.

from discussions-and-proposals.

Hello fkgozali,

I wanted to know the official FB status of

• TurboModules
• JSI
• Fabric

it is officially released?
I am looking to 3rd party native components using the new design, and haven't find any that uses the new architecture (host object and fabric).
The official facebook documentation still explain how to create a native module with RCT_METHOD(iOS), and @ReactMethod(Java), i.e the old style.
I am just wondering if the developments are ready or not, and why the official FB documentation doesn't explain how to create a native module in pure C++ with the new design. It is definitely helpful to have the same code written once for both iOS and android.
My other question is about compatibility layer I heard of in some articles, that makes it possible to existing 3rd party modules to work without being recoded.
If not official yet, any date for the planned official released? (and the documentation to write new modules, and migrating existing modules to new design of course)
Many thanks

from discussions-and-proposals.

@fkgozali Will those TurboModules provide a uniform interface for promise rejections? As of RN 0.59 rejected error objects shapes vary with platform.

from discussions-and-proposals.

Hello fkgozali,

thanks for your answer, I have anticipated and implemented my native module with jsi. I have however noticed a problem with Chrome debugger crashing. Now sync function are going to be extensively used by newly created 3rd party native modules, is there any action taken on FB side to allow Chrome debugging with jsi? It is a kinda important feature. many thanks

from discussions-and-proposals.

Chrome debugger

Please follow discussions in #7

from discussions-and-proposals.

@sunnylqm
Hi, I am trying to make react-native-webgl work with RN0.58 on Android too.
Have you managed to make it work on RN 0.58 yet? I'm seeking for any help.
Thanks

from discussions-and-proposals.

Is there any guidelines on building C++ JSI turbomodules using cmake?
How should I include the header files?

from discussions-and-proposals.

Is it possible to expose a "native class" using JSI?
Eg. would it be possible to create a native class that can be instantiated using new keyword in JS?
(const myinstance = new SomeClass()).

My problem is that the current Blob module does not support \0 characters, and i would like to make a "native" implementation where i can pass the "native" blob instance to my other native code

Forgive my ignorance, but i'm new to JSI.

Mikkel

from discussions-and-proposals.

Is there a way to turn off TurboModules for an application?
The call to getEnforcing currently returns null in my app and I can't find why to save my life.

It looks like this in TurboModuleRegistry.js:

export function getEnforcing<T: TurboModule>(name: string): T {
  const module = get(name);
  invariant(
    module != null,
    `TurboModuleRegistry.getEnforcing(...): '${name}' could not be found. ` +
      'Verify that a module by this name is registered in the native binary.',
  );
  return module;
}

In order to have my application loading, I hacked around it in the mean time:

export function getEnforcing<T: TurboModule>(name: string): T {
  if (name == "ExceptionsManager") {
    const legacyModule = {
      reportSoftException: () => {},
    }
    return ((legacyModule: any): T);
  } else {
    const legacyModule = NativeModules[name];
    return ((legacyModule: any): T);
  }
}

Anyone would know why the TurboModuleRegistry.getEnforcing is not returning anything?

from discussions-and-proposals.

Hey @patrice4github, AFAIK TurboModules should be off by default unless you call RCTEnableTurboModule(YES); in - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions in your AppDelegate.mm.

I actually looked into something similar the other day trying to get TurboModules working. In my case, I was trying to copy how RNTester uses TurboModules, and this error was occurring because my AppDelegate did not implement RCTCxxBridgeDelegate and RCTTurboModuleManagerDelegate correctly.

With current master, it seems you need at a minimum:

#import <React/RCTCxxBridgeDelegate.h>
#import <ReactCommon/RCTTurboModuleManager.h>
#import <React/CoreModulesPlugins.h>

@interface AppDelegate() <RCTCxxBridgeDelegate, RCTTurboModuleManagerDelegate>{
  RCTTurboModuleManager *_turboModuleManager;
}

# pragma mark - RCTCxxBridgeDelegate

- (std::unique_ptr<facebook::react::JSExecutorFactory>)jsExecutorFactoryForBridge:(RCTBridge *)bridge
{
  __weak __typeof(self) weakSelf = self;
  return std::make_unique<facebook::react::JSCExecutorFactory>([weakSelf, bridge](facebook::jsi::Runtime &runtime) {
    if (!bridge) {
      return;
    }
    __typeof(self) strongSelf = weakSelf;
    if (strongSelf) {
      strongSelf->_turboModuleManager = [[RCTTurboModuleManager alloc] initWithBridge:bridge delegate:strongSelf];
      [strongSelf->_turboModuleManager installJSBindingWithRuntime:&runtime];
    }
  });
}

#pragma mark RCTTurboModuleManagerDelegate

- (Class)getModuleClassFromName:(const char *)name
{
  return RCTCoreModulesClassProvider(name);
}

- (std::shared_ptr<facebook::react::TurboModule>)getTurboModule:(const std::string &)name
jsInvoker:(std::shared_ptr<facebook::react::JSCallInvoker>)jsInvoker
{
  return nullptr;
}

- (std::shared_ptr<facebook::react::TurboModule>)getTurboModule:(const std::string &)name
instance:(id<RCTTurboModule>)instance
jsInvoker:(std::shared_ptr<facebook::react::JSCallInvoker>)jsInvoker
{
  return nullptr;
}

in your AppDelegate.mm, otherwise there is no getModuleClassFromName implementation and getEnforcing can't look up any modules to instantiate them. This took quite a lot of digging through debug stacks etc. so I suspect this is one part of TurboModules that is not ready for prime – another issue I noticed is that in the latest release, images don't work with TurboModules enabled but they do in master.

from discussions-and-proposals.

Thanks for this input, much appreciated.

After my upgrade to 0.61.1, all of my images stopped working, even though I didn't turn TurboModule on. I suspect it could be on by default...

from discussions-and-proposals.

Interesting, I was using 0.61.1 and not seeing that behaviour 🤔 maybe should be reported as a bug against RN if that is happening

Have you tested from a clean react-native init project?

from discussions-and-proposals.

react-native init : Yes I have, it's working ok.

I'm toying with the idea of opening a bug. I however don't have a "reproducible scenario" (unless I'm willing to share my entire project, which I'm not at this time. is that just me?). My gut feeling, there's something wrong with PlatformConstants, it gave me some errors yesterday, but that all I have for now. I'm investigating further.

Thanks.

from discussions-and-proposals.

PlatformConstants was the first module I saw the problem with when I enabled Turbomodules, I believe this is just because it is the first native module that the JS tries to call into when it starts up. You can poke around the following bits of RN if you are interested, not got time right now to remember exactly which bits helped diagnose the issue:

It sounds like Turbomodules is somehow enabled in your project when it shouldn't be. First I'd check there are no calls to RCTEnableTurboModule(YES); anywhere - you could also drop a breakpoint in the implementation of this, in RCTBridge.m line 106, to check its not being called. You can also verify in line 93 of that file that it defaults to disabled, static BOOL turboModuleEnabled = NO;

from discussions-and-proposals.

Thanks for the hint, doing that now. Ah! I was about to say this, my gut feeling is that PlatformConstants is part of the problem...

It's used quite a bit in react-native-gesture-handler, react-navigation, react-navigation-stack.
PlatformConstants in react-native-gesture-handler is problematic I think...

from discussions-and-proposals.

static BOOL turboModuleEnabled = NO; at line 93, correct.

RCTEnableTurboModule is not firing.

TurboModuleRegistry.getEnforcing is called nevertheless.

from discussions-and-proposals.

Hmm... I wonder if one of your dependencies is somehow triggering this. Dunno what to suggest except the old "disable dependency and try again" dance ;)

from discussions-and-proposals.

@Jonovono do you have TurboModules enabled in your app or are you seeing that getEnforcing error message in a fresh project with TurboModules disabled?

from discussions-and-proposals.

@Jonovono, in your podspec file, are you depending on the React-CoreModules pod? RCTDevSettings was moved to CoreModules, so you may have to update your dependencies. Please let me know if this fixes your problem.

from discussions-and-proposals.

@RSNara hmm, I had pod 'React-CoreModules', :path => '../node_modules/react-native/React/CoreModules' in my Podfile already.

from discussions-and-proposals.

@Jonovono, are other NativeModules in CoreModules also available in the app? You could try to access them via the NativeModules object.

from discussions-and-proposals.

Hey @sav007, you can use Java/Kotlin as you would use before. Turbomodules aren't about rewriting everything to C++, they are about several things:

1. Lazy initialization – allows you to initialize module instance only then you calling it at the very first time, not on the app initialization itself.
2. JSI – JavaScript Interface – in fact, this is the new iteration of the "bridge" helping you triggering all the Java code from the JS. The old bridge has overhead – JSON serialization of each call on both sides – from the JS and from the Java. But JSI allows you to skip that part, so it's much faster.
3. JSI is completely synchronous.

So you will need to create a module spec and "codegen" the C++ part of it, it will create a JSI "bridge" for your module in order to allow you to call all your methods from JS really easy and get response blazingly fast.

great

from discussions-and-proposals.

I have tried experimenting with turbo module, I am interested in developing a pure c++ turbo module, but wondering how to handle async elements.

I took the following steps :-

1. checked out react-native master
2. built the RNTester app documented here :- https://github.com/facebook/react-native/tree/master/RNTester (taking care with the version of cocoapods used)
3. This includes a test called “TurboModule”
4. The test TurboModule is an objective c module, but there is a sample C++ module which uses JSI, and you can enable it by changing this loc https://github.com/facebook/react-native/blob/fa9ff07017edbc76595fe2f2d964ee13c5f4088a/Libraries/TurboModule/samples/NativeSampleTurboModule.js#L35 to say ‘SampleTurboCxxModule’
5. The cxx (= c++) module is here https://github.com/facebook/react-native/tree/master/ReactCommon/turbomodule/samples whereas the objective c one is in platform/ios subdir

However the promise example does block the UI, and I am wondering if anyone can advise a non blocking approach? (I tried this which doesn't entirely work and I am pretty sure its wrong)

 jsi::Value SampleTurboCxxModule::getValueWithPromise(
    jsi::Runtime &rt,
    bool error) {
  return createPromiseAsJSIValue(
      rt, [error, this](jsi::Runtime &rt2, std::shared_ptr<Promise> promise) {
      std::thread([=, &rt2](  ) {
        std::this_thread::sleep_for(std::chrono::seconds(5));
        if (error) {
          promise->reject("intentional promise rejection");
        } else {
          promise->resolve(jsi::String::createFromUtf8(rt2, "result!"));
        }
      }).detach();
  });
}

from discussions-and-proposals.

I just saw facebook/react-native@96fdaa5 and similar diffs. Why isn't caching constants in JS done more generically (e.g. within the TurboModuleRegistry class), instead of re-implementing the "spec" like done in the diffs? It seems to me that we are introducing the whole boilerplate from the spec just to cache the constants... if this is a good practice, why not do it for everyone?

from discussions-and-proposals.

The current state is that it mostly works but we have not seen yet any documentation and no official announcement. I guess we need to still be more patient. I don't know why the react-native team won't do a "is-it-ready-yet" page like the react team did for fiber but I guess they are into big reveals now, as with the announcement of hooks.

But is also a good strategy to wait for a somewhat stable API (adaption will be a bit slower than usual, because it is a new feature and not something "under the hood" as it was the case with fiber, so making sure that lib devs only need to write new code once is probably the right way to go). Of course, it is also an expectation management strategy, as any missed deadlines will be aggressively pointed out by unruly Twitter users.

The good news is, that there are some mentions, that Facebook is already dogfooding TurboModules internally and they already said multiple times that they plan to release it later this year (it was mid of this year before corona). React-reanimated v2 is already written as a TurboModule, but it takes some extra steps to get it running. They've implemented some workarounds and will probably have to re-implement some parts as soon as the official release is here, but it's an early alpha you can check out for reference.

from discussions-and-proposals.

@terrysahaidak @kelset I'm wondering how will the Animated Api when Turbomodules & jsi are fully out,
and how would it compare to reanimated 1 and reanimated 2 ?

from discussions-and-proposals.

@terrysahaidak thank you,
afaik, JSI & TurboModules will eliminate using the RN bridge, which is the main limitation for the Animated Api, any why SWM had to create their awesome RNGH & Reanimated.

will animated still be inefficient to be used compared to reaniamted 1 or 2 ?

from discussions-and-proposals.

@terrysahaidak thanks, but still jsi & turbomodules would bring a lot of benefits to the Animated Api.

from discussions-and-proposals.

@kelset When the re architecture is completed, do you think that the performance gap with flutter will be filled?

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.

from discussions-and-proposals.

@axemclion reanimated not only benefit the jsi but it also run the javascript part of the animation on the UI thread

from discussions-and-proposals.

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

from discussions-and-proposals.

@axemclion for example the use of cpu.

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.

from discussions-and-proposals.

@axemclion Reanimated 2 will spawn a secondary JS context on the UI thread that then is able to run JavaScript functions.
have a look on worklet in reanimated 2 doc

from discussions-and-proposals.

@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).

from discussions-and-proposals.

Do TurboModules support multiple callbacks per function? I noticed that with the "legacy" native module system you cannot pass a Callback (RCTResponseSenderBlock) and a Promise (RCTPromiseResolveBlock + RCTPromiseRejectBlock) into the same function, I assume that by building upon JSI this will work out of the box, no?

from discussions-and-proposals.

@fkgozali sorry not relevant to this thread but is there documentation on how to disable TurboModules on RNTester? I think it's breaking fast refresh and debugging with Chrome.

from discussions-and-proposals.

@prakashjais99 quick question, I am also in the similar situation but was wondering how where you getting reference to the jsInvoker_ value?

from discussions-and-proposals.

@mrousavy follow up question... when passing the invoker to the cpp-adapter.cpp file, what is the proper way to cast the invoker?

extern "C" JNIEXPORT void JNICALL Java_com_MyAwesomeModule_initialize(JNIEnv* env, jclass clazz, jlong jsi, jobject invoker) { installMyAwesomeModule(*reinterpret_cast<facebook::jsi::Runtime *>(jsi), invoker); }

my cpp file has this declaration
void installMyAwesomeModule(jsi::Runtime& jsiRuntime, std::shared_ptr<react::CallInvoker> jsInvoker)

from discussions-and-proposals.

Another workaround to "old debug flow not working": If you're using Hermes you can follow the steps here: https://reactnative.dev/docs/hermes#debugging-js-on-hermes-using-google-chromes-devtools
This doesn't require Flipper

from discussions-and-proposals.

@mrousavy follow up question... when passing the invoker to the cpp-adapter.cpp file, what is the proper way to cast the invoker?

extern "C" JNIEXPORT void JNICALL Java_com_MyAwesomeModule_initialize(JNIEnv* env, jclass clazz, jlong jsi, jobject invoker) { installMyAwesomeModule(*reinterpret_cast<facebook::jsi::Runtime *>(jsi), invoker); }

my cpp file has this declaration void installMyAwesomeModule(jsi::Runtime& jsiRuntime, std::shared_ptr<react::CallInvoker> jsInvoker)

dude , did you solved this cast problem ? I encountered this too .

from discussions-and-proposals.

hey ! guys ! As the rn0.68.0 released the new arch feature; I'm about digging into rn's new archi adoption;
👉🏻 https://reactnative.dev/docs/next/new-architecture-library-android
I met this gradle error when building

Could not find method react() for arguments [build_cbn8oel6m6i7bg72w8bsdvl$_run_closure3$_closure11@ef70746] on object of type org.gradle.api.internal.artifacts.dsl.dependencies.DefaultDependencyHandler

my library 'module-level' react spec looks like below

react {
    libraryName = "Test"
    codegenJavaPackageName = "com.iturbomodule.test"
    root = rootProject.file("..")
    jsRootDir = rootProject.file("../js/")
    reactNativeDir = rootProject.file("../react-native/")
    codegenDir = rootProject.file("../react-native-codegen/")
}

from discussions-and-proposals.

@yaaliuzhipeng As a rule of thumb, report issues like this one either on github.com/reactwg/react-native-new-architecture/ (if you don't have access yet, you can apply for it with the form in the README).

Could not find method react() for arguments

This happens as you don't have the React Gradle Plugin applied in that module. I would say that you miss a:

plugins {
  id("com.facebook.react")
}

but not knowing your full gradle file setup, makes hard to say if this is the only issue

love you dude, I did missed the plugin, everything goes fine after this plugin's added ! ! ! guess I have to learn gradle for a while 😅

from discussions-and-proposals.