fkgozali ( Kevin Gozali )

 class MessageQueue {     const moduleMethods = this.getCallableModule(module);     invariant(       !!moduleMethods,-      'Module %s is not a registered callable module (calling %s)',-      module,-      method,+      `Module ${module} is not a registered callable module (calling ${method}). This can happen when the application entry file path is incorrect.+      On Android, verify 'getJSMainModuleName()' in 'MainApplication.java' and 'project.ext.react.entryFile' in 'android/app/build.gradle'.+      On iOS, verify '- (NSURL *)sourceURLForBridge:(RCTBridge *)bridge' in 'AppDelegate.m' and 'ENTRY_FILE' env. variable passed to 'react-native-xcode.sh' (if any) in 'Build Phases' -> 'Bundle React Native code and images'.

The error message for Android/iOS here assumes specific usage of a build system, which is not always the case (e.g. some uses BUCK to build). I'd just remove them, or provide url to a section in the https://reactnative.dev/ with platform specific instructions.

This can happen when the application entry file path is incorrect.

Note that this is not the only reasons this error happens, some times a bad JS bundle, or an early initialization error when loading React Native will cause this error.

vonovak

comment created time in a month

issue commentreact-native-community/discussions-and-proposals

TurboModules (NativeModules Re-architecture)

@DomiR

Why isn't caching constants in JS done more generically (e.g. within the TurboModuleRegistry class), instead of re-implementing the "spec" like done in the diffs? It seems to me that we are introducing the whole boilerplate from the spec just to cache the constants... if this is a good practice, why not do it for everyone?

This is NOT a good practice. TurboModule no longer special-case getConstants() unlike the old NativeModules. Which is why we'll be moving away from getConstants() specifics, like general caching in the old system. This is for simplicity and better overall performance.
However, we're trying to isolate some regression that may be caused by the modules affected in the commit you linked. If we can pinpoint the problematic module, it would be easier to investigate the infra fix for it, or tweak the module impl to fix the issue. Doing it for all modules will make it impossible to isolate the issue.
In the future, @RSNara has some plan to allow per-method memoization with simple annotation in the spec, but not for TurboModule v1.
Finally, stay tuned for proper documentation explaining all these details (when it's closer to release time later this year).

fkgozali

comment created time in 2 months

issue commentreact-native-community/releases

v0.63.0 Discussion

Might want to pick https://github.com/facebook/react-native/commit/e5a6655e71d41a58ce0e51d37aa9fb8792e37dd5, that should fix long-standing iOS crashes: https://github.com/facebook/react-native/issues/27463

TheSavior