Summary:
Not totally sure if this is the best way to handle this. In Venice if a native module is missing I try to log the name of the module, but I noticed that the error I was getting was getting this:
{F161460962}
Presumably this is because importing from NativeModules looks for `__esModule`, but NativeModules uses `module.export`. So it's trying to access that property on my cpp proxy object, which doesn't exist...? Changing TurboModuleProxy to use `require` seems to fix the problem.
Reviewed By: fkgozali
Differential Revision: D15787508
fbshipit-source-id: 4b9df4e3c179117999fe6de6363edbef427a8263
Summary:
Reverse the order in which we look for modules in TurboModuleRegistry to check TurboModules first, and then fall back to legacy native modules. The main motivation for this is Venice, since requiring NativeModules.js fatals because there's no batched bridge. But we'll probably want to do this eventually anyway.
I ran a mobilelab for Marketplace home and am not seeing any significant difference in TTI.
Reviewed By: fkgozali
Differential Revision: D15703655
fbshipit-source-id: d65a4d7e09077474c30fb3938e38aee63bfa4eca
Summary: More verbose but descriptive error message when `TurboModule.getEnforcing` fails to find a native module.
Reviewed By: cpojer, gaearon
Differential Revision: D15619293
fbshipit-source-id: 0e8af4986d6ce9002966bb062766218ce9f89a13
Summary:
This is the next step in moving RN towards standard path-based requires. All the requires in `Libraries` have been rewritten to use relative requires with a few exceptions, namely, `vendor` and `Renderer/oss` since those need to be changed upstream. This commit uses relative requires instead of `react-native/...` so that if Facebook were to stop syncing out certain folders and therefore remove code from the react-native package, internal code at Facebook would not need to change.
See the umbrella issue at https://github.com/facebook/react-native/issues/24316 for more detail.
[General] [Changed] - Migrate "Libraries" from Haste to standard path-based requires
Pull Request resolved: https://github.com/facebook/react-native/pull/24749
Differential Revision: D15258017
Pulled By: cpojer
fbshipit-source-id: a1f480ea36c05c659b6f37c8f02f6f9216d5a323
Summary: `__turboModuleProxy` doesn't exist if you're not in the TurboModules QE. If such is the case, then we should just return null when `TurboModuleRegistry.get` is called.
Reviewed By: fkgozali
Differential Revision: D13937143
fbshipit-source-id: d3f11c52b7cbecaefba675d714f0d67236071389
Summary: For now, do `require('NativeModules')` instead of `import {NativeModules} from 'react-native'`.
Reviewed By: mdvacca
Differential Revision: D13934066
fbshipit-source-id: 5188b11428a4dca8cecd1934e593d89a6e3fde2e
Summary:
Moved the JS wrapper function to github. To access a TurboModule from JS:
```
export interface Spec extends TurboModule {
+func1: () => number,
}
const module = TurboModuleRegistry.get<Spec>('SampleTurboModule');
```
This assumes:
* the binding on the native side has been installed properly, i.e. `global.__turboModuleProxy` needs to be installed properly.
* the module `SampleTurboModule` is registered properly in native.
More instructions will be provided later.
Reviewed By: yungsters
Differential Revision: D13584561
fbshipit-source-id: 50d29d88787f8d9caa7a3ee0d54d378db866515c
Emily Janzer
Tim Yung
James Ide
Ramanpreet Nara
Kevin Gozali