expo modules vs codegen complexity

[mfazekas]

I like the idea of the codegen. To use a typescript spec to generate bindings on the native side, and then have type safety through native and ts code, it sounds great.
But It's very very complicated. We're using swift and on iOS side to add a new component. We need 7 files :

• Foo.swift (implements the component in Swift)
• FooComponentView.mm and .h - (for new architecture - implements a view wrapping Foo in contentView)
• FooManager.mm, and FooManager.swift (RCTViewManager - implements methods on the view, I think only for old arch)
• FooModule.h, FooModule.mm - forwards methods to the FooManager

On android it's better only 3 files:

• FooManager.kt
• Foo.kt
• FooModule.kt

And we need 2 files for the spec:

• specs/FooNativeComponent.ts, specs/NativeFooModule.ts - (codespec)

While I think on expo modules I could do that in a single file per platform. https://docs.expo.dev/modules/module-api/. The only reason I don't use expo-modules is because it requires the app itself to use expo. Also I don't know any package outside of expo using expo-modules, so people are unfamiliar with it.

I also understand that this setup will improve once the migration to new arch is complete, but it will take a while until we can remove old arch files, also with swift C++ interop we can remove some more files.

[cortinico]

Yup we're aware that asking lib authors to pick between expomodules and turbomodules is not ideal.

We summarised our recommendation in the RFC here:
https://github.com/react-native-community/discussions-and-proposals/blob/main/proposals/0759-react-native-frameworks.md#what-do-we-recommend-to-react-native-library-developers