mirror of
https://github.com/facebook/react-native.git
synced 2025-11-01 09:14:26 +00:00
Ramanpreet Nara
3af66bf7fb
Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/36629 The scope of TurboModuleManager is increasing: - Eventually, it'll be capable of creating interop NativeModules (i.e: NativeModules that don't implement TurboModule). So, instead of creating duplicate methods for NativeModules on the TurboModuleManager, this diff changes the APIs of TurboModuleManager to work with the NativeModule interface. Thoughts? ## Questions **Question:** Is this a breaking change for open source? - Technically, yes. This diff changes the public interface of TurboModuleManager. **Question:** How large of a thrash will this cause for open source apps? - The thrash should be minimal. People in open source shouldn't be creating their own TurboModuleManager. They also shouldn't be directly accessing the TurboModuleManager object either. **Question:** Is this change safe? - Yeah. All the code that calls into TurboModuleRegistry converts TurboModules it returns into NativeModules. **Question:** Is this change move us in the right direction? - Long term, the TurboModule system will support legacy modules as well as TurboModules. - I think it makes a lot of sense to have one Java-facing registry: after all, Java will just treat these NativeModules/TurboModules as regular Java objects, and call public methods on them. It doesn't care if the module is TurboModule-compatible or not. - As for the TurboModuleRegistry abstraction, I think we should eventually rename this to NativeModuleRegistry after we delete the current NativeModuleRegistry. - Still thinking about this though. I will leave this diff in review to welcome comments. Changelog: [Android][Deprecated] - Deprecate TurboModuleRegistry.getModule(), getModules(), hasModule(), Reviewed By: mdvacca Differential Revision: D43801531 fbshipit-source-id: 4af7cbc2e2dc7c1d664acbd38c83aa93aae23c9f