0.73: Introducing Bridgeless Mode 🎉

[RSNara]

Important

Exciting news for Bridgeless, starting from React Native 0.74. Read more here

TL;DR - Bridgeless mode is the next stage of work to enable the React Native's New Architecture. It removes all remaining dependencies on the legacy bridge architecture and improves reliability. You will need to explicitly enable Bridgeless mode and migrate any relevant APIs as shared. Please leave feedback for use-cases that aren't supported.

In React Native 0.68, we released the first pillars of the New Architecture: the new native module system (TurboModules) and the new renderer (Fabric). In 0.73 we are excited to release the next stage: Bridgeless Mode!

Read on to learn

• What Bridgeless Mode offers
• How to enable Bridgeless Mode and what APIs you may need to migrate

What is Bridgeless Mode?

Prior to the New Architecture, the React Native bridge was used to facilitate communication between JavaScript and native. The bridge was a message queue for instructions like rendering views, calling native callables, or registered event handlers, to name a few. The bridge was limiting React Native in its asynchronous design, message batching and serialization costs.

Removing the bridge

A large part of the New Architecture effort is to remove React Native's dependency on the bridge. With TurboModules, we moved native calls off the bridge. With Fabric, we moved component rendering off the bridge.

With Bridgeless mode, we are moving everything else (i.e: the rest of the React Native runtime: error handling, global event emitters, timers, and more) off the bridge and no longer initializing the bridge.

For more background on removing the bridge, see [React Native EU] The New React Native.

Support for Legacy Native Modules

Since we no longer have access to a bridge in Bridgeless mode, we've introduced an interoperability layer to continue support for legacy native modules.

With the interlop layer, most legacy modules registered with React Native will be supported by the new native module system (TurboModules).

See Enabling Bridgeless Mode: Step 3 for more details on what is supported and caveats.

Static ViewConfigs

In addition, Bridgeless Mode optimizes component rendering with Static ViewConfigs.

ViewConfigs tell React what props and events a native component supports. Prior, ViewConfigs were generated at run-time by analyzing a native component's ViewManager.

With Static ViewConfigs, we move this work to build-time by analyzing a native component's Flow or TypeScript spec file. If a native component does not have a spec file, then Bridgeless will fallback to run-time ViewConfig generation.

For more background on this work, see Modernizing React Native's JavaScript.

Enable Bridgeless Mode

Prerequisites for enabling Bridgeless mode:

• Migrate to React Native 0.73
• Migrate to supporting the new architecture

1. Update Static ViewConfig Babel Plugin

If your project has an explicit dependency on metro-react-native-babel-preset, update it to @react-native/[email protected]

More details in "v0.73 Release Notes/Babel Package Renames".

2. Enable Bridgeless flag in native

Android

In your MainApplication.kt file, update the onCreate function by passing the bridglessEnabled = true flag to the load invocation.

// MyMainApplication.kt

import com.facebook.react.defaults.DefaultNewArchitectureEntryPoint.load

override fun onCreate() {
  ...
  if (BuildConfig.IS_NEW_ARCHITECTURE_ENABLED) {
    // Set bridgelessEnabled to true here to enable Bridgeless, it's false by default
-   load()
+   load(bridgelessEnabled = true)
  }
  ...
}

iOS

To enable Bridgeless for your React Native app, you need to override function bridgelessEnabled in app’s AppDelegate.mm:

// AppDelegate.mm
 
- (BOOL)bridgelessEnabled
{
    return YES;
}

3. Migrate legacy APIs

The interop layer ensures compatibility with legacy bridge calls however there may be some APIs that need to be migrated. Review the following instructions and let us know if your use-case isn't covered.

JavaScript

If your JavaScript registers callable JavaScript modules, please migrate to this API:

Before:

BatchedBridge.registerCallableModule(
  'FooModule',
  FooModule,
);

After:

global.RN$registerCallableModule(
  'FooModule',
  () => FooModule,
);

Android

Prior to Bridgeless Mode, native modules could access the bridge and call methods on it. In Bridgeless Mode, this call will throw an error.

// 🚩throws UnsupportedOperationException as the bridge doesn't exist
const catalystInstance = reactContext.getCatalystInstance();
...
catalystInstance.getJSModule(AppRegistry.class);

Instead, move all previous calls on the bridge to reactContext directly

// ✅ Use reactContext directly
reactContext.getJSModule(AppRegistry.class);

In most cases the method name will be the same. However these are the exceptions. If your method is not available, please comment below and let us know which method and your use-case.

Old name on catalystInstance	New name on reactContext	Caveat
runJSBundle()	-
hasRunJSBundle()	-
getSourceURL()	getSourceURL()
invokeCallback()	-
callFunction()	-
destroy()	-
isDestroyed()	hasActiveReactInstance()
initialize()	-
getReactQueueConfiguration()	-
getJSModule()	getJSModule()
hasNativeModule()	hasNativeModule()
getNativeModules()	getNativeModules()	Will return only the already initialized native modules.
getNativeModule()	getNativeModule()
getJSIModule()	getJSIModule()
extendNativeModules()	-
addBridgeIdleDebugListener()	-
removeBridgeIdleDebugListener()	-
registerSegment()	registerSegment()
getJavaScriptContextHolder()	-
getRuntimeExecutor()	-
getRuntimeScheduler()	-
addJSIModules	-
getJSCallInvokerHolder()	-
getNativeMethodCallInvokerHolder()	-
setTurboModuleManager()	-

iOS

For APIs that returned a bridge prior to Bridgeless, Bridgeless now returns a "bridge look-a-like" (RCTBridgeProxy) object.

// In bridgeless, you'll receive an instance of RCTBridgeProxy instead of the actual bridge
@synthesize bridge = _bridge;

RCTNetworking *module = [_bridge moduleForName:@"Networking"];

RCTBridgeProxy supports the majority of legacy bridge APIs. Here are the APIs that it doesn't.

• (void)loadAndExecuteSplitBundleURL:(NSURL*)bundleURL     onError:(RCTLoadAndExecuteErrorBlock)onError      onComplete:(dispatch_block_t)onComplete;
• @property (nonatomic, assign) int64_t flowID;
• @property (nonatomic, assign) CFMutableDictionaryRef flowIDMap;
• @property (nonatomic, strong) NSLock *flowIDMapLock;

If you are using any of the above APIs, please comment and let us know which one and what your use-case is.

Feedback Welcome

Bridgeless mode is a huge milestone for New Architecture! Please let us know of any use-cases we may not be supporting today. Thanks!

[mrousavy]

So exciting!!! I guess it's time to migrate my libs to the new arch now... 😅

[mrousavy]

Question; What would be the new way of accessing the JS Runtime in bridgeless mode?

I guess I have two separate use-cases for this:

1. react-native-mmkv

This is a C++ JSI Module, which I currently initialize from a Native Module.

• Android: https://github.com/mrousavy/react-native-mmkv/blob/de2bde2638498660f9fa070684bd2ca42bfbfc0f/android/src/main/java/com/reactnativemmkv/MmkvModule.java#L34
• iOS: https://github.com/mrousavy/react-native-mmkv/blob/de2bde2638498660f9fa070684bd2ca42bfbfc0f/ios/MmkvModule.mm#L41

I guess in this case it would be possible to create a C++-only JSI TurboModule, then I assume I'd have direct access to the JSI Runtime there, right?

2. react-native-vision-camera

I have a View (the Camera) which I can call methods on, for example takePhoto, startRecording, focus, etc, which are all defined in the Native Module/ViewManager (Swift/ObjC and Kotlin/Java)

In addition to those methods, I also have one C++ method, called setFrameProcessor, which does some additional JSI magic to convert the given function to a Worklet, then wraps it in ObjC/Java types passes it to the native Camera View.

I am currently doing this a bit weird, where I just install this JSI function lazily in the global namespace, then look up the component via that - but this can go out of sync, I'd prefer to have that be directly associated to the view, just like takePhoto and the other methods.

Is there a recommended approach for this problem with the new arch? Can I add a custom C++ JSI method to my existing ObjC/Swift view?

[RSNara]

I guess in this case it would be possible to create a C++-only JSI TurboModule, then I assume I'd have direct access to the JSI Runtime there, right?

A C++-only TurboModule would definitely solve the problem!

Is this good enough for your use-case? If there are problems, I'd love to hear them.

[mrousavy]

For the first one that'd be fine, but how about the second one (VisionCamera), which is kinda hybrid, I need some C++ JSI methods and some basic view manager Kotlin/ObjC methods for the same view?

[RSNara]

@mrousavy, are you referring to these ViewManager methods?

https://github.com/mrousavy/react-native-vision-camera/blob/dc8df8008513d84e3d24d756083fa1b13b0a9f71/package/ios/CameraViewManager.m#L63-L85

Fabric components support commands. e.g: TextInputComponentView:

https://github.com/facebook/react-native/blob/0fd7bd3a7f62b72f70da42608ff933a9fb1a63d9/packages/react-native/React/Fabric/Mounting/ComponentViews/TextInput/RCTTextInputComponentView.mm#L430-L433

I'll follow up with a few folks, and get you more code pointers!

[ospfranco]

I also have the same setup as @mrousavy in my libraries:

Android
iOS

I've been trying for the last couple of hours to migrate to a turbo module. I first started with a Kotlin Turbo Module, basing my work on this PR by @WoLewicki, where he migrated the old library to Turbo Modules. The nice part of his implementation is that it is compatible with the old arch. Only after I got it running, I realized it doesn't solve the issue with bridgeless, since there is still no way to access the JS runtime instance, even if it is a turbo module. This PR has been of great help in understanding what changes I have to make, without it I would have been even more lost.

Following this discussion, I started to take a look into Cxx Turbo Modules but the guide is quite confusing actually. I've been trying to get it to work but with no success. From what I understand it would also require changes to the native code of the people consuming Cxx Turbo Modules, which I find not ideal at all.

While I do not disagree with the move to bridgeless, there is currently no clear migration strategy, it would be great to have:

• A more detailed step-by-step guide on creating a Cxx Turbo Module (on which we can access the jsi::Runtime object) as an external library
• Some information on how to keep compatibility with the old arch, at least while libraries are migrating to bridgeless (akin to Wo's PR)
• Or even ideally, still have a way to access the JS runtime from Kotlin/ObjC turbo modules so we can install our Cxx bindings without having to do major refactorings since many other libraries also follow this installation method (quick-base64, @craftzdog/react-native-buffer, quick-crypto)

[dmytrorykun]

I feel like we could create a custom script for running codegen, maybe I can draft something up. Something like yarn codegen to make this a bit easier and also do some error checking.

This is actually a work in progress: facebook/react-native#41925
The idea is that you configure the input/output directories in codegenConfig in your project's package.json, then run npx react-native codegen, and that's it.

[mrousavy]

Dope, love it!

[ospfranco]

Awesome! Thank you very much @dmytrorykun @cortinico @RSNara

[ospfranco]

Just saw a or that makes bridgeless the default on 0.74? What's the final call here? Will we get access to the runtime from non cxx turbo modules? At least for op-sqlite I also need variables and paths not accessible from c++, so it would be great to keep it available there.

[cipolleschi]

Hi @ospfranco, thanks for posting.
The New Architecture was thought with Bridgeless as one of the foundational pieces of it, so the suggested usage is to have Bridgeless enabled when the New Architecture is enabled. Hence, the PRs you saw.

At least for op-sqlite I also need variables and paths not accessible from c++,
What are the variables and paths not accessible from C++ for op-sqlite? Knowing that could help us moving forward.

We are still discussing internally what's the best approach, but we are close to the final answer. We will provide docs and comms as soon as we reach an agreement point in this very same working group!

[WoLewicki]

I've just made a PR adding bridgeless compatibility for RNScreens: software-mansion/react-native-screens#1990. For now I use hacky way to get the eventDispatcher so the events are passed to Animated correctly. Kind of the same thing is done for ScrollView. Is there a better way to do it maybe @RSNara ? (see https://github.com/software-mansion/react-native-screens/pull/1990/files#diff-ad35cf2dc9a86855afc1d2443a42a133ccf0dd8b17589719cb1aab4a81d20604R107)

[RSNara]

@WoLewicki, mUiMessageQueueThread should definitely not be null.

There is probably an issue with the way how Bridgeless mode is configured.

Is there a quick and easy way to reproduce this problem?

Update:

I also left a comment on https://github.com/software-mansion/react-native-screens/pull/1990/files#diff-ad35cf2dc9a86855afc1d2443a42a133ccf0dd8b17589719cb1aab4a81d20604R107

[WoLewicki]

Is there a quick and easy way to reproduce this problem?

Yes, just create a bare project, add react-native-screens and such code should be enough to trigger the exception:

    <SafeAreaView style={{flex: 1}}>
      <ScreenStack>
        <Screen>
          <View />
        </Screen>
      </ScreenStack>
    </SafeAreaView>

[WoLewicki]

I also left a comment on software-mansion/react-native-screens#1990 (files)

I replied to it

[RSNara]

@WoLewicki, I just replied to your comments!

In short, we'll have to create a hand-written component descriptor + shadow node to make this work.

Component descriptors have access to the context container.

Bridgeless mode puts the image loader into the context container.

https://github.com/facebook/react-native/blob/main/packages/react-native/ReactCommon/react/runtime/platform/ios/ReactCommon/RCTInstance.mm?fbclid=IwAR3P0PqMbqTxkekrZsbx6zm3ZS87ul77PNQAQctk2DzYlaTdV5XTnDLQ8NM#L270-L277

The component descriptor will (on iOS) pluck the event dispatcher and image loader from the context container, and decorate the shadow node with a C++ object that can call into both. See Image's component descriptor:

Cross-platform code:

https://github.com/facebook/react-native/blob/f7f9250f6e90a41e798a8f62738925a2859a751a/packages/react-native/ReactCommon/react/renderer/components/image/ImageComponentDescriptor.h#L20-L39

Android impl (noop):

https://github.com/facebook/react-native/blob/f7f9250f6e90a41e798a8f62738925a2859a751a/packages/react-native/ReactCommon/react/renderer/imagemanager/platform/cxx/react/renderer/imagemanager/ImageManager.cpp

iOS impl:

https://github.com/facebook/react-native/blob/f7f9250f6e90a41e798a8f62738925a2859a751a/packages/react-native/ReactCommon/react/renderer/imagemanager/platform/ios/react/renderer/imagemanager/ImageManager.mm

The fabric native component has access to the shadow node.

So, the fabric native component just grabs that c++ object from the shadow node, and calls into it, which delegates to image loader and event dispatcher under the hood. Please see the < Image /> component code examples!

[cortinico]

Following up here. The problem with react-native-screens & Bridgeless in 0.73 has been fixed here:
software-mansion/react-native-screens#2022

For 0.74 we'll actually have a better fix in place that handles all the scenarios and doesn't require change in the library code at all

[WoLewicki]

Things taken from bridge on iOS that are not available right now:

• jsCallInvoker (QuickSQLite, Reanimated)
• runtime (QuickSQLite, Reanimated, RNGH)
• surfacePresenter - scheduler, runtimeExecutor, mountingManager (Reanimated)
• uiManager (available as a proxy) - observerCoordinator (Reanimated)

I can update the list after I go through more libraries and Android. Do you want me to collect those things for further work on compatibility?

[mrousavy]

@WoLewicki impressive stuff man - how do you get access to the jsi::Runtime in your TurboModule's install method? Is it just always passed, just like in a JSI HostFunction?

[WoLewicki]

cpp TurboModule methods get jsi::Runtime as an argument by default if you mean e.g. this code: https://github.com/software-mansion/react-native-gesture-handler/pull/2708/files#diff-e92177b4f8a69cbc9aa18fce4a126ca7269e17969d31b728cf5418d930b902e5R10.

[TheRogue76]

I was doing the same for Lottie and i came across the same item @WoLewicki found:

I was wondering A) If this is now a requirement for sending events like this and B) if so, which version of RN initially added this? I am basically wondering how the import for this would work

[RSNara]

@WoLewicki, thank you so much for all this input!

I'm just trying to finish up some end of year stuff. So, I haven't had some time to dig into this deeply.

I will follow up early next year! I hope that is fine.

[WoLewicki]

Following up on the topic since PR for RNGH seems to be ready:

• jsCallInvoker and runtime - for now only available for me from the cpp TurboModule (see e.g. https://github.com/software-mansion/react-native-reanimated/pull/5519/files#diff-f20f363cc1285443aab0afeb96c57bae506d8cafe9dc86684400fcc2c483cdacR17)
• surfacePresenter - there is a dedicated setter for it: https://github.com/software-mansion/react-native-reanimated/pull/5519/files#diff-76b5bf496f9cf24eac20f5689d8aa1cd033229e0a0659c3205c3393cc670d62cR165
• cpp uiManager - can be still taken from here: https://github.com/software-mansion/react-native-reanimated/blob/77898c556dfe7283a032d985fbfe98a07170836a/apple/REAModule.mm#L95

[frankcalise]

Hi @RSNara, thanks for the information!

Can I ask what is the best way to report issues back to library maintainers when testing bridgeless mode in an existing application to provide feedback for core RN / third party libraries?

My assumption is that for this to work enabled in any application, all libraries must support these changes. If turning this on as an experiment, should we be looking for particular logs / information that would be helpful in reporting (or contributing changes) to packages that need work?

[RSNara]

Hey @frankcalise!

Can I ask what is the best way to report issues back to library maintainers when testing bridgeless mode in an existing application to provide feedback for core RN / third party libraries?

I think, at the very least, if you could document what libraries were failing, and how, and share that list (+ code pointers) with us, that would be super helpful! If you think repros would also be valuable in understanding/solving the problems, that'd also be great!

[frankcalise]

Thanks, will do!

[tido64]

Hey folks, I'm adding support for bridgeless mode in @rnx-kit/react-native-host and noticed a couple of things:

1. There are two RCTHost methods used in RCTAppDelegate.mm that are currently "hidden" away in RCTHost+Internal.h (specifically, setBundleURLProvider: and setContextContainerHandler:).
   • Is RCTHost+Internal.h meant to be a public at all?
   • I kind of get that we're supposed to use RCTAppDelegate.mm directly, but this cannot be used in hybrid apps.
   • Can we merge RCTHost+Internal.h with RCTHost.h?
   • Anything that is used in RCTAppDelegate.mm should be public to support hybrid apps.
2. I also noticed that JSEngineInstance was renamed JSRuntimeFactory, but this is detectable so it's not really an issue.

[okwasniewski]

Hey @tido64,

You might be interested in this PR that I've been working on: facebook/react-native#42263

Introducing RCTRootViewFactory which is something similar to react-native-host

[cipolleschi]

Hi @tido64, thanks for raising these issues.
I'd like to summon also @RSNara which has much more context on RCTHost APIs and bridgeless in general.
Answering to:

I kind of get that we're supposed to use RCTAppDelegate.mm directly, but this cannot be used in hybrid apps.
Anything that is used in RCTAppDelegate.mm should be public to support hybrid apps.

I completely agree with you. I created the RCTAppDelegate one year and something ago, when I was still ramping up on React Native and I haven't grasped all the use cases for it. In hindsight, I think that all that code should be wrapped an an object that the app's AppDelegate (or a ViewController) own and that it can use to spin up React Native surfaces.

It is a work that I'd like to tackle somewhen in the near future, but currently we are focus on other priorities.

If you can list what APIs you need, I'm sure we can find a way to expose them! :D

[tido64]

If you can list what APIs you need, I'm sure we can find a way to expose them!

For starters, can we move all the methods in RCTHost+Internal.h to RCTHost.h? That will be enough to get bridgeless mode for now, at least until you get around to turning RCTAppDelegate into the equivalent Default* classes on Android 😄

[cipolleschi]

🤔 Is there a specific reason why you can't/would rather to not import/include RCTHost+Private directly?

Is it just because the word Private could imply that we are going to break those methods?

[tido64]

🤔 Is there a specific reason why you can't/would rather to not import/include RCTHost+Private directly?

Is it just because the word Private could imply that we are going to break those methods?

This is what I'm currently doing for 0.73 at least. The +Internal part does imply that the header might become internal in some future version. Maybe it won't be needed in a future version, but it would be nice if the header didn't go away without replacements.

[TheRogue76]

We added support for Brigeless mode in 6.7.0 RC1 on Lottie React Native (had to tweak some type definitions and bring them in line with the docs / remove paper name from the BubblingEventHandler until 73.4 comes out). Let's see what the community's feedback ends up being. Also, should we update #6 to include a column for Libs that have validated Bridgeless support?

[cortinico]

Also, should we update #6 to include a column for Libs that have validated Bridgeless support?

Most of the libraries will just work in Bridgeless mode, and we're looking into having the most popular libraries supporting Bridgeless mode by the time 0.74 hits stable. If this is not the case, we'll add a 3rd column then

[surajj2223]

I am trying to find a View in android native using its reactTag being passed from a Turbo module.

Problem
I see UIBlock class doesn't work anymore with the newArch being true;hence I don't have access to the NativeViewHeirarchyManager which would get me the view instance.

In RN 0.74-RC's there is a fabric.interop package with UIBlock and UIBlockViewResolver which gives access to resolving the view on native using its react tag.

I am on 0.73.6 and the UIBlockViewResolver is introduced in 0.74-rc's & we cant upgrade to 0.74-rc as of yet.

Relevant work done(facebook/react-native@24a3dad) for the react-native-view-shot library can be seen utilizing the UIBlockViewResolver

Is there any other way this can be achieved without having to have the need for UIBlockViewResolver ?

[cipolleschi]

cc. @cortinico who worked on that part specifically.
However, as far as I know, UIBlock was missing pre 0.74 and we implemented it in 0.74 only. So, the suggestion would be to:

• wait for 0.74 to be released, we are close to do a stable release, so it won't be a lot.
• update the app to 0.74.
• finalize the migration to the New Architecture on 0.74.

We are aware that this process is a bit painful, but the New Architecture is still experimental, so we are suggesting to everyone who wants to use it to always be on the latest version of React Native.

[cortinico]

I am trying to find a View in android native using its reactTag being passed from a Turbo module.

@surajj2223 what you're trying to do here seems wrong. View manipulation should happen inside ViewManagers and not inside TurboModules. Can you elaborate on what you're attempting to achieve?

[surajj2223]

@cipolleschi the UIBlock was available under the UIManager inside com.facebook.react.uimanager.UIBlock. I think you are referring to the interop.UIBlock which got introduced as part of 0.74-rc.0

@cortinico
Basically I need a View reference in native to rasterize it (as Bitmap) and save it on disk as an image so no View manipulation is to be done.

The same behavior was doable using react-native-view-shot and i got inspired by the same library code.
If you look at the libs v3.8.0, you should be able to see

if (tag == -1) { // reactTag
      view = currentActivity.getWindow().getDecorView().findViewById(android.R.id.content);
} else if (uiBlockViewResolver != null) {. 
       // starting 0.74-rc.5
       view = uiBlockViewResolver.resolveView(tag);
} else {
        // < 0.74-rc.5
        view = nativeViewHierarchyManager.resolveView(tag);
}

SInce I cannot go to 0.74-rc's & the uimanager.UIBlock doesnt work on 0.73 with newArch, hence now, we are trying to query the view using

view = currentActivity.getWindow().getDecorView().findViewById(reactTag)

For most of the times, the findViewById is working for us, however lot of times, the view is not found. I can only think of a problem that may be the UI tree is not built when we are querying the tree using findViewById using the reactTag ((while the React Tree was built) & it must be the reason for using the UImanager / BlockViewResolver.

[surajj2223]

Hi, I am still counting on this thread. Is there a better way to achieve this ?

[cortinico]

Since I cannot go to 0.74-rc's & the uimanager.UIBlock doesnt work on 0.73 with newArch

@surajj2223 why you can't go to 0.74-rcs? The fabric.interop package with the UIBlock reimplementation have been added in 0.74 exactly to solve scenarios like yours.

If you can't access the fabric.interop package, you can achieve what you're attempting to with:

// Retrieve the UIManager from the viewTag
UIManager uiManager =
  UIManagerHelper.getUIManagerForReactTag(mReactApplicationContext, viewTag);
// Use the same resolveView method from UIBlockViewResolver
uiManager.resolveView(viewTag);

That works on every version on both Old and New Architecture.

[fobos531]

Hello,

I'm experimenting with bringing bridgeless support for Android to https://github.com/react-native-menu/menu. What would be the correct approach to dispatching events in that case? The library implementation utilizes an init block https://github.com/react-native-menu/menu/blob/master/android/src/main/java/com/reactnativemenu/MenuView.kt#L26, and there they call the prepareMenu() function which has

  mContext
      .getJSModule(RCTEventEmitter::class.java)
      .receiveEvent(id, "onPressAction", args)

However, in that case I get

 FATAL EXCEPTION: main
                                                                                                    Process: com.microsoft.reacttestapp, PID: 13248
                                                                                                    java.lang.IllegalStateException: Tried to access a JS module before the React instance was fully set up. Calls to ReactContext#getJSModule should only happen once initialize() has been called on your native module.
                                                                                                    	at com.facebook.react.bridge.ReactContext.getJSModule(ReactContext.java:180)
                                                                                                    	at com.reactnativemenu.MenuView.prepareMenu$lambda$1(MenuView.kt:219)
                                                                                                    	at com.reactnativemenu.MenuView.$r8$lambda$tBA4nBTitTAIw1A6E3OOLYWnA9U(Unknown Source:0)
                                                                                                    	at com.reactnativemenu.MenuView$$ExternalSyntheticLambda0.onMenuItemClick(Unknown Source:2)
                                                                                                    	at com.android.internal.view.menu.MenuItemImpl.invoke(MenuItemImpl.java:148)
                                                                                                    	at com.android.internal.view.menu.MenuBuilder.performItemAction(MenuBuilder.java:935)
                                                                                                    	at com.android.internal.view.menu.MenuBuilder.performItemAction(MenuBuilder.java:925)
                                                                                                    	at com.android.internal.view.menu.MenuPopup.onItemClick(MenuPopup.java:128)
                                                                                                    	at android.widget.AdapterView.performItemClick(AdapterView.java:330)
                                                                                                    	at android.widget.AbsListView.performItemClick(AbsListView.java:1257)

Which is probably due to the fact that this work is performed within the init block, in which the React instance is probably not fully set up yet. Which approach do you recommend in this case? It is worth noting that I only experience this with bridgeless enabled, with disabled it works just fine

[cipolleschi]

@cortinico @RSNara can help you out with the Android implementation! 😄

[cortinico]

@fobos531 please look at my PR here:

• [Android] Move to EventDispatcher instead of RCTEventEmitter react-native-menu/menu#749

TL;DR: you should use EventDispatcher rather than RCTEventEmitter which works on both architectures and is not deprecated

[ShivamRawat0l]

Nice 🔥 🔥
Waiting for some benchmarks :)

[olokobayusuf]

I've looked through the discussion on accessing the jsi::Runtime in bridgeless mode, but there still doesn't seem to be an authoritative approach on doing this. From what I've gathered:

1. Writing a pure C++ Turbo module does provide access to the jsi::Runtime, but this has a bad UX for library authors because downstream users of such libraries must manually register the library (e.g. in AppDelegate.mm).
2. Writing an ObjC/Java Turbo module does not provide access to the jsi::Runtime.

How can library authors who are building libraries for bridgeless mode access the jsi::Runtime, and do it in such a way that just works for downstream users?

[olokobayusuf]

@philIip This is great. I've been able to re-enable bridgeless mode with access to the runtime. In my code I've added the following #ifdef:

#ifdef REACT_NATIVE_HAS_JSI_BINDINGS_INSTALLER
    #import <ReactCommon/RCTTurboModuleBindingsInstaller.h>
#endif
    ...

#ifdef REACT_NATIVE_HAS_JSI_BINDINGS_INSTALLER
- (RCTTurboModuleBindingsInstaller*) createBindingsInstaller {
    ....
}
#endif

Does React compile with version-specific definitions that I can use to #define REACT_NATIVE_HAS_JSI_BINDINGS_INSTALLER?

[philIip]

we won't have that but you can do something like

#if __has_include(<ReactCommon/RCTTurboModuleWithJSIBindings.h>)

but technically you don't really need it, it's just an optional way to have some compile time safety check. we check for the selector, not the protocol due to perf constraints. on android though, you will probably need an explicit check for BindingsInstallerHolder.h

[atlj]

Hey @olokobayusuf I'm working on create-react-native-library, and we have an ongoing effort to implement cxx-only turbo modules based on the xplat turbo modules guide from the React Native New Architecture Working Group.

I've created a repo to get the initial implementation working.
Note: This implementation needs react-native-community/cli#2387 to be merged.

[olokobayusuf]

@philIip thanks! I think I'm all set.

@atlj this looks good. It looks like react-native-community/cli#2387 is ready to be merged? I see latest activity was 2 weeks ago, so do you know the current status?

[atlj]

We need to make a documentation update on that PR, but you can still have a cxx turbomodule without that, you would need a build.gradle file tho.

[AhmedAyachi]

can someone explain this to me please, When claiming there's nothing standing between JavaScript and the Native Code, how is that even possible exactly, there's a js thread and a UI thread that run on two different programming languages, there should be always a bridge of some sort for communication.

[cipolleschi]

@AhmedAyachi great question! There is indeed something that bridges the two worlds, but this is not a single, specific component that works as a serialization point.

Instead, React Native uses a technology called JavaScript Interface (JSI).

With JSI, we can share memory between JavaScript and C++. We are not constrained anymore to serialize messages through a single component, as the JavaScript runtime can hold direct references to C++ objects and viceversa.

[AhmedAyachi]

@cipolleschi You're saying, instead of sending serialized messages back and forth through the bridge, we just send a lighter message via JSI that tells c++ to call some sort of function called with params located in that shared memory, so basically instead of sending the whole serialized object, we just send its reference ?

[cipolleschi]

yes, basically yes. But there is no sending around. Different objects in C++ can hold references to different JS objects.
When they need to call some methods, then they jump to the JSThread, but there is no serialization nor message passing.

[AhmedAyachi]

Thanks