Turbo EventEmitters

[Dunedubby]

Hi, I'm having a little trouble understanding how the new EventEmitters are working behind the scenes on iOS, and if there's a disconnect between the documentation and what actually happens. So my understanding is that every function that is created in the JSI module gets a jsi::Value __hostFunction_... function generated in the ...-generated.cpp file, as well as a virtual method declaration in the SpecJSI.h file, among other things. Should we expecting similar functions to exist for a onThingHappens JS method, after we declare a readonly onThingHappens: EventEmitter<blah>? Or is there another syntax to call these events on the JS side?

[Dunedubby]

Okay so it seems that when they get added to the separate eventEmitterMap_ object, they are then checked separately after the method checks, as shown here: https://github.com/facebook/react-native/blob/35f0e1cca2299b5816cbc1847410651eb20a3f02/packages/react-native/ReactCommon/react/nativemodule/core/ReactCommon/TurboModule.h#L143

What scenarios could cause the methodMap_ objects to be recognized as functions, but the eventEmitterMap_ objects to not?

[Dunedubby]

Actually, after investigating more, it appears that in Obj-C modules, this create() function gets overridden in https://github.com/facebook/react-native/blob/main/packages/react-native/ReactCommon/react/nativemodule/core/platform/ios/ReactCommon/RCTInteropTurboModule.mm#L249

Except this implementation doesn't even look at the eventEmitterMap_ or any reference to the event emitters at all. In other words, it seems like Obj-C Turbo modules can't access the new EventEmitter framework at all, contrary to what the docs say. @cipolleschi am I missing something?

[Dunedubby]

I was missing something: bridged/legacy-compatible modules use RCTInteropTurboModule.mm, but bridgeless modules use RCTTurboModule.mm (if I understand correctly). After switching to fully bridgeless the EventEmitters seemed to connect correctly. Maybe this is worth mentioning in the docs (that legacy-compatible modules will have a hard time using the new EventEmitters), but at least the new EventEmitters are working with Swift, yay.

[cipolleschi]

@Dunedubby thanks for the thorough investigation and I apologize for the delay in answering. Last week we were bus with some internal projects and I could not dedicate a lor of time to Github, sadly.

Please consider that the configuration with TurboModule, Fabric and Bridge mode is not supported anymore. We keep providing the possibility to disable bridgeless for debugging purpose, but users are supposed to use the New Architecture as a whole: TurboModule, Fabric and Bridgeless.

I'm also a bit concerned in updating the docs with so low level details. You did a great job investigating and diving deep in the code, but those details will change in the future (for example when we approach the removal of the Old Architecture) so writing those down in the docs also mean that we have to keep them updated. Plus, I don't see how much they will benefit the average users who don't need to go in such details to learn and use React Native.

What do you think?

[stul-5230]

I am trying to understand the principles of React Native. At present, we are just starting to study the communication between JS and Native. The TurboModule System can enable JavaScript and Native to communicate synchronously. My question is, using JSCore's JSCntent can also enable JS and Native to communicate synchronously. What are the differences through JSI? This question may be foolish, but I look forward to your answer.

In addition, the new architecture has many concepts that are difficult to understand, but I would like to understand its principles. Do you have any recommended articles

[cipolleschi]

JSI is an abstraction on top of the JS Engine. There are multiple JS engine around: JSCore, maintained by Apple, Hermes, that is the default for React Native and that is developed by Meta and V8, to mention a few of them.

Synchronous communication is possible with any of them probably, but JSI allow us to abstract them to a common interface so that we can swap engines without having to change the implementation or the method we call. So, yes, you can achieve the same thing by directly use the JSCore APIs, but then it would not work with Hermes, for example.

---

o understand better the New Architecture, I suggest to:

• read the documentation on the website:

  • The New Architecture is here: https://reactnative.dev/blog/2024/10/23/the-new-architecture-is-here
  • Guides
    • Codegen: https://reactnative.dev/docs/next/the-new-architecture/what-is-codegen
    • Native Development: https://reactnative.dev/docs/next/native-platform
  • Architecture: https://reactnative.dev/architecture/overview

• Have a look at the various conference talks we provided over the years:

  • https://www.youtube.com/watch?v=FqMTXagEvHo
  • https://www.youtube.com/watch?v=UcqRXTriUVI
  • https://www.youtube.com/watch?v=52El0EUI6D0
  • https://www.youtube.com/watch?v=M-Fl6_vKcWw
  • https://www.youtube.com/watch?v=QwoQgzBgJu8&t=803s
  • https://www.youtube.com/watch?v=zyTYWAeORKg
  • https://www.youtube.com/watch?v=0qKoUriD86U
  • https://www.youtube.com/watch?v=KhN_qwQL0R0
  • https://youtu.be/FZ0cG47msEk?feature=shared&t=1534
  • https://youtu.be/Q5SMmKb7qVI?feature=shared