StreamVideoClient instantiation error - Super expression must either be null or a function

Which package/packages do you use?

@stream-io/video-react-sdk
@stream-io/video-react-native-sdk
@stream-io/video-client

Is your feature request related to a problem? Please describe.

In React Native 0.73 the default language is no longer Java, but Kotlin for things such as MainApplication & MainActivity. The config plugin for Stream Video explicitly enforces java to be the language used, otherwise the config plugin is not applied.

Describe the solution you'd like

Add Kotlin support to the config plugin alongside Java:

stream-video-js/packages/react-native-sdk/expo-config-plugin/src/withMainActivity.ts

Line 6 in 5c725ca

const withStreamVideoReactNativeSDKMainActivity: ConfigPlugin<ConfigProps> = (

Describe alternatives you've considered
N/A

Additional context
N/A

@santhoshvai

It also seems like @stream-io/react-native-webrtc or @stream-io/video-client or @stream-io/video-react-native-sdk might require some additional patches to work on React Native 0.73.

This is what I get when I instantiate a new StreamVideoClient. This is not happening on React Native 0.72. Let me know if you need a separate issue report for this.

I'm getting the exact same error when instantiating the video client.

@fobos531 Are you able to instantiate the video client using any version of react-native before 0.73?

Asking because I'm getting the error even using the 0.72 (and it's minor versions, like 0.72.4 or 0.72.6). Also tried to downgrade the @stream-io/video-react-native-sdk to some previous versions but with no success.

Would you mind providing the exact versions of the packages related to the stream-video-js installation you are using?

@fobos531 Are you able to instantiate the video client using any version of react-native before 0.73?

Asking because I'm getting the error even using the 0.72 (and it's minor versions, like 0.72.4 or 0.72.6). Also tried to downgrade the @stream-io/video-react-native-sdk to some previous versions but with no success.

Would you mind providing the exact versions of the packages related to the stream-video-js installation you are using?

Hello @gabrielfurini

Yes, it works fine for me on 0.72.X. This started happening for me when I upgraded to Expo 50 Beta with React Native 0.73.

These are the versions of GetStream packages I use

"@stream-io/react-native-webrtc": "118.0.1",
  "@stream-io/video-react-native-sdk": "0.3.7",

Hello, thanks for reporting.

The config plugin does need to support kotlin
The other issue seems to be something broken with TS configuration,

we ll fix this asap. Thanks for your patience. Also, feel free to make PRs if you patch them. We ll be happy to merge it.

Hello Santhosh,

the config plugin should be pretty easy to fix, I'll see if I get some time to submit a PR for this, but for the other issue I definitely do not have enough expertise for that 😅

Hello @santhoshvai

You can find the added support for Kotlin in #1239 .

With that, only the TS configuration issue remains.

@fobos531 Are you able to instantiate the video client using any version of react-native before 0.73?
Asking because I'm getting the error even using the 0.72 (and it's minor versions, like 0.72.4 or 0.72.6). Also tried to downgrade the @stream-io/video-react-native-sdk to some previous versions but with no success.
Would you mind providing the exact versions of the packages related to the stream-video-js installation you are using?

Hello @gabrielfurini

Yes, it works fine for me on 0.72.X. This started happening for me when I upgraded to Expo 50 Beta with React Native 0.73.

These are the versions of GetStream packages I use
"@stream-io/react-native-webrtc": "118.0.1",
  "@stream-io/video-react-native-sdk": "0.3.7",

@fobos531 Thank you! My errors were related to a monorepo structure I'm using and how Metro was configured.

For those who are also using a monorepo, here's what I did to make it work:

Make sure not to set config.resolver.disableHierarchicalLookup in your metro.config.js files. (expo/expo#22323)
(Android only) @notifee/react-native is not resolved by default by Maven; you need to set it manually using the expo-build-properties library. (invertase/notifee#808 (comment))

@santhoshvai Perhaps it would be useful to add these steps to the installation docs mentioning them for Expo + monorepo project.

Hello @gabrielfurini

Thank you for the tip, but unfortunately I'm not affected by any of the two solutions you proposed: I don't have disableHierarchicalLookup set in my metro.config.js in the first place (even though I do have a monorepo), and I'm not experiencing the @notifee/react-native issue described in that other issue. I always was able to successfully compile notifee on Android.

@fobos531 Sorry for the misunderstanding.
The issue you opened is not related to mine at all. You reported an issue with Expo SDK 50 and RN 0.73, while mine, despite having the same error message, is related to Expo SDK 49 and monorepo configuration.
I mentioned @santhoshvai to describe what fixed my issue, just to possibly add the tips to an Expo installation possible issues section.

I think it's best to delete my comments and open a separate issue. Please let me know when you do so, and I can proceed.

Thank you, and sorry again.

@gabrielfurini thanks for your inputs, I will clarify the notifee compilation in our doc

Keeping this issue open, due to StreamVideoClient instantiation issue only on 0.73

Hey @santhoshvai

Just a heads up, Expo SDK 50 with React Native 0.73 was officially released today, so it is possible that more users will start encountering this issue.

One interesting thing that I noticed is that if I manually install event-target-shim in my app, I no longer get this error and it seems like the StreamVideoClient is instantiated properly, but this obviously is a suboptimal solution.

@santhoshvai

This might be related: react-native-webrtc/react-native-webrtc#1488

@fobos531 I think this can be solved if we update the tsconfig of the webrtc library

Thanks for linking the issue

@fobos531 I think this can be solved if we update the tsconfig of the webrtc library

Thanks for linking the issue

No problem. That would be great, I would be happy to test whatever you come up with!

@fobos531 a small question, is your expo app in a monorepo setup ?

@fobos531 a small question, is your expo app in a monorepo setup ?

Hey @santhoshvai . Yes, that is correct, my Expo app is part of a monorepo.

Hello, I'm following the linked issue, and I tried applying the fix described in this comment: react-native-webrtc/react-native-webrtc#1488 (comment)

but I get this error Cannot call a class as a function, js engine: hermes

Did you encounter it in your testing?

2024-01-25 22:55:18.382 29685-29867 dev.expo.updates        com.uxdotapp.pureshop.dev            I  {"timestamp":1706219718382,"message":"UpdatesModule: getConstants called","code":"None","level":"info"}
2024-01-25 22:55:18.386 29685-29867 ExpoModulesCore         com.uxdotapp.pureshop.dev            I  ✅ Constants were exported
2024-01-25 22:55:18.466 29685-29867 ReactNativeJS           com.uxdotapp.pureshop.dev            E  TypeError: Cannot call a class as a function, js engine: hermes
2024-01-25 22:55:18.477 29685-29867 ReactNativeJS           com.uxdotapp.pureshop.dev            E  TypeError: Cannot call a class as a function, js engine: hermes
2024-01-25 22:55:18.477 29685-29867 ReactNativeJS           com.uxdotapp.pureshop.dev            E  TypeError: Cannot read property 'prototype' of undefined, js engine: hermes
2024-01-25 22:55:18.477 29685-29867 ReactNativeJS           com.uxdotapp.pureshop.dev            E  Invariant Violation: Failed to call into JavaScript module method AppRegistry.runApplication(). Module has not been registered as callable. Bridgeless Mode: false. Registered callable JavaScript modules (n = 9): Systrace, JSTimers, HeapCapture, SamplingProfiler, RCTLog, RCTDeviceEventEmitter, RCTNativeAppEventEmitter, GlobalPerformanceLogger, HMRClient.
                                                                                                              A frequent cause of the error is that the application entry file path is incorrect. This can also happen when the JS bundle is corrupt or there is an early initialization error when loading React Native., js engine: hermes
2024-01-25 22:55:18.515 29685-29785 ExpoInsights            com.uxdotapp.pureshop.dev            W  Status code 200
2024-01-25 22:55:18.822 29685-29726 flipper                 com.uxdotapp.pureshop.dev            I  flipper: Not started
2024-01-25 22:55:19.828 29685-29744 EGL_emulation           com.uxdotapp.pureshop.dev            D  app_time_stats: avg=69.74ms min=1.17ms max=1439.82ms count=27

Hmm,

I think it might still be an issue with React Native 0.73 & latest available WebRTC, since the exact same setup worked completely fine on RN 0.72 and earlier. I tried removing all imports in my app and it still didn't work, so I'm assuming it must be something upstream in the WebRTC library.

hey @fobos531 I got the same error Cannot call a class as a function, js engine: hermes

My guess is that it is because if we force RN to use event-target-shim v6 then the api is incompatible. We instead have to make RN use v5 and rn-webrtc use v6. The only way I found that was using @rnx-kit/metro-resolver-symlinks

You can look at the new metro config in our example app here. https://github.com/GetStream/stream-video-js/blob/main/sample-apps/react-native/expo-video-sample/metro.config.js

Metro has changed to resolve to using v5 even for webrtc somehow. It looks like the algorithm to resolve the node_modules has changed in their end.

Hey @santhoshvai

Thank you! I have tried the solution you proposed and it seems like it really works. I had some other minor font loading issues in my app but I think they are unrelated to this.

There's also ongoing discussion of potentially reverting the API of react-native-webrtc to match the event-target-shim of React Native, but I'm not sure if any changes are going to be done in the end.

With that said, I'm not sure if this issue can be considered resolved or not. If you think this is a good enough solution, then this should for sure be mentioned in the docs.

I completely agree with you. Will add it to the docs soon.

a workaround is now mentioned in the expo config plugin README