Summary:
Changelog: [Internal]
This diff add types to some of the common globals so uses of
them through `global` are now typed.
All the globals are marked as read-only for their intented uses.
However, some of them do have write cites (mostly are in tests to
deliberately set up a special test environment). Those write cites
are considered as "necessary evil" and annotated as `FlowFixMe`.
Reviewed By: yungsters
Differential Revision: D30158145
fbshipit-source-id: 93a99063361a4b7a1e33d9fc97a661be30a4d8f9
Summary:
Changelog:
[General][Changed] Make the RootTag an opaque type
Reviewed By: yungsters
Differential Revision: D27992320
fbshipit-source-id: 2901f0e59f573106295b986fe04db227134235da
Summary:
The import of DialogManagerAndroid in [Alert.js](https://fburl.com/diffusion/n57e4l50) causes "Unable to get iOS TurboModule for DialogManagerAndroid" log.
Don't call ` TurboModuleRegistry.get` on DialogManagerAndroid when the Platform is iOS.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D27376204
fbshipit-source-id: 948da5c162100ffe196d5e0a54dc8b85659239ae
Summary:
There are a surprisingly large number of nil modules in both bridge and bridgeless. So far, features may silently fail if a module is nil.
We can't log with with console.error or console.warn because many tests will break even though modules aren't used in the test.
Differential Revision: D27285601
fbshipit-source-id: 1467100f2a4c48e97de5dd6e846c26981c14f099
Summary:
ES Modules implicitly enable strict mode. Adding the "use strict" directive is, therefore, not required.
This diff removes all "use strict" directives from ES modules.
Changelog:
[Internal]
Reviewed By: motiz88
Differential Revision: D26172715
fbshipit-source-id: 57957bcbb672c4c3e62b1db633cf425c1c9d6430
Summary:
This new type will be valid in Flow strict mode and can be used by native modules and components to replace `Object`, with the same semantics.
This unblocks the migration of the most modules in the React Native package to Flow strict.
Changelog: [Internal] Add UnsafeObject type compatible with Flow strict mode to use in native modules and components
Reviewed By: RSNara
Differential Revision: D25540631
fbshipit-source-id: 60b80bbc84a53aecc747e3a1799cdf551e1859cd
Summary:
The Flow team has been building a new implementation of the system that typechecks the body of generic functions and classes. This system is more sound than the previous approach and detects errors that were uncaught previously. This diff turns on the new generic system by setting generate_tests=false in the .flowconfig, and suppresses newly discovered errors.
This diff modifies and re-signs some generated modules, because syncing from www pulled in a ton of other changes that have runtime differences, and I'm not equipped to verify that the changes are safe to land.
Changelog: [Internal]
Reviewed By: panagosg7
Differential Revision: D24801184
fbshipit-source-id: bb31fe4c5a4107d183649b436a548df5ff42e217
Summary:
There's no reason for us to have lint ignores for `react-native/codegen/react-native-modules`. This diff removes all such ignores. I'll address any actual problems with the specs in subsequent diffs.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24529238
fbshipit-source-id: bbd2f4fb5dace65d803a8f93bd0d9a1c5a1cfb34
Summary:
Open source this ESLint rule so that we can lint our open source NativeModule specs.
Changelog: [Internal]
Reviewed By: shergin, cpojer
Differential Revision: D23791748
fbshipit-source-id: e44444bc87eaa9dc9b7f2b3ed03151798a35e8a5
Summary:
**Note:** This is a carbon copy of D22832730 (3df6f5fb2c). The fixes are stacked on top of this diff, in D22888030.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D22888032
fbshipit-source-id: 2f1b7ecd39437a3c5ee9c3214419716fde2bbdff
Summary:
`babel-plugin-codegen` will run the NativeModules codegen on each NativeModule spec, and inline the generated schema into the spec's `TurboModuleRegistry.get(Enforcing)?` call. This diff will forward that schema to `__turboModuleProxy` function (i.e: the TurboModule C++ infra).
**Note:** Both this and D2280384 can't be landed until D22743294 (650c0f64f1) hits production (1-2 weeks).
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D22832730
fbshipit-source-id: aecaf9943f9b01be805ff6b90249a6cbc6abdd20
Summary:
Adds `RootTag` as a valid type for arguments and return types in TurboModules (on both Android and iOS).
This will enable us to change `RootTag` into an opaque type. There are two compelling reasons to do this:
- JavaScript will no longer be able to safely depend on `RootTag` being a number (which means we can change this in the future).
- Call sites using `unstable_RootTagContext` will can get a `RootTag`, but call sites using the legacy `context.rootTag` will not. This means the opaque type will give us a strategy for migrating away from legacy context and eventually making `unstable_RootTagContext` the only way to access `RootTag`.
Changelog:
[Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: RSNara
Differential Revision: D21127170
fbshipit-source-id: baec9d7ad17b2f8c4527f1a84f604fc0d28b97eb
Summary:
Fixed some typos in the comment.
## Changelog
[Internal] [Fixed] - Fixed typo in the comments
Pull Request resolved: https://github.com/facebook/react-native/pull/28269
Test Plan: Changes are only made in the comments, so test is not necessary.
Reviewed By: cpojer
Differential Revision: D20342637
Pulled By: shergin
fbshipit-source-id: f6e7dd538ee54c43e1570c35e1f8c4502054e328
Summary:
We are rolling out exact-by-default syntax to xplat/js.
I had to manually move around some comments to preserve proper placement.
Changelog: [Internal]
Reviewed By: jbrown215
Differential Revision: D18633611
fbshipit-source-id: 48f7468dcc55b1d00985419d035a61c6820b3abe
Summary:
Changelog: [Internal]
Reverting the import to the previous local module style since importing from react-native seems to introduce some perf regression. We'll revisit this later in the future.
Reviewed By: yungsters
Differential Revision: D18383893
fbshipit-source-id: f11d46a4545768f39199fd6fd22fcf14905d0a74
Summary:
Changelog: [Internal]
Moved the imports for `TurboModuleRegistry` and `TurboModule` from `react-native`. This was a jscodeshift with the script: P120688078
Reviewed By: yungsters
Differential Revision: D18262538
fbshipit-source-id: 48fac15229c897408928511c5ecbb42f17ec7b42
Summary: This diff renames `RCTExport` to `DEPRECATED_RCTExport`. I'll deal with the repercussions of this change in subsequent diffs.
Reviewed By: fkgozali
Differential Revision: D16468382
fbshipit-source-id: 571abbefbf68b03e351327cb52835cce2dfbc8bb
Summary: Requiring legacy native modules fails in bridgeless mode because they use the batched bridge, so we need to check for turbomodules first to avoid crashing. In D15703655 I reversed the order of this check for everyone, but this had some unintended side effects (everyone got turbomodules). This time I'm just using my flag to check for bridgeless mode so we can bail out of legacy native modules instead.
Reviewed By: fkgozali
Differential Revision: D15857106
fbshipit-source-id: 9d33161ae059e7a357f135c82b6865f4d2a57add
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:
This provides various versions of SampleTurboModule, that are:
* compatible with existing NativeModule
* TurboModule compliant
Variants:
* RCTSampleTurboModule (traditional objc module)
* RCTSampleTurboCxxModule (objc++ module using CxxModule)
* SampleTurboModule (pure C++ impl of a TurboModule, no ObjC)
As noted in some files, they need to be codegen'ed based on the `NativeSampleTurboModule.js` (Flow type). The codegen script is not yet usable in OSS (we'll work on it some time in H2 2019). For now, these files need to be manually synced with Flow type.
Reviewed By: cpojer
Differential Revision: D14932539
fbshipit-source-id: fb887192384e5e6e4dff4cac68b4e037a4783cd9
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