Summary:
## Problem
Suppose we have this NativeModule spec, that uses Object literals that contain a property called "id":
```
export interface Spec extends TurboModule {
// Exported methods.
+getConstants: () => {|
id: string,
|};
+getObject: (arg: {id: Object}) => Object;
}
```
For both object literals, we'll generate C++ structs, backed by NSDictionaries. The method in each struct will be named "id_" to avoid a name clash with ObjC's `id` identifier. However, calling that id_ method should still access the "id" property in the corresponding NSDictionary.
## Expected Output
```
inline id<NSObject> JS::NativeSampleTurboModule::SpecGetObjectArg::id_() const
{
id const p = _v[@"id"];
return p;
}
inline JS::NativeSampleTurboModule::Constants::Builder::Builder(const Input i) : _factory(^{
NSMutableDictionary *d = [NSMutableDictionary new];
auto id_ = i.id_.get();
d[@"id"] = id_;
return d;
}) {}
```
## Actual Output
```
inline id<NSObject> JS::NativeSampleTurboModule::SpecGetObjectArg::id_() const
{
id const p = _v[@"id_"]; // <-- HERE!
return p;
}
inline JS::NativeSampleTurboModule::Constants::Builder::Builder(const Input i) : _factory(^{
NSMutableDictionary *d = [NSMutableDictionary new];
auto id_ = i.id_.get();
d[@"id_"] = id_; // <-- HERE!
return d;
}) {}
```
NOTE: This code was generated by running `jf get --version 119805822 && buck build //xplat/js:FBReactNativeSpec_Sample-flow-types-ios --show-output`
This diff fixes this mistake.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D25907493
fbshipit-source-id: cb37cbf49db4f871b3f4046f7397a7b1b7df0357
Summary:
Changelog: [internal]
Codegen was generating code with return value number instead of boolean.
Reviewed By: RSNara
Differential Revision: D25863062
fbshipit-source-id: 780f88dd2d83e303b03d1ed9cc837ac6733f1702
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:
## Changes
All `rn_library(codegen_modules = True)` must now also specify native_module_android_package_name, like so:
```
rn_library(
name = "FBAuth"
codegen_modules = True,
native_module_spec_name = "Foo",
native_module_android_package_name = "com.facebook.fbreact.specs",
)
```
This will generate the FBAuth Java spec files under the appropriate directory: "com/facebook/fbreact/specs". It will also make the code-generated specs have the appropriate package name: "com.facebook.fbreact.specs".
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D25723176
fbshipit-source-id: 6efec1cbee43d70110c0ef23e2422e08609b61d4
Summary:
NativeModule methods are meant to be called from JavaScript. As such, they may not necessarily have call-sites in Java. This means that they're succeptible to being stripped by proguard.
This diff annotates all exported NativeModule methods with DoNotStrip, so that proguard doesn't strip them. We already do this in the legacy codegen.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25723801
fbshipit-source-id: a7c8701e0a5d03a970f5f19cc6ae6b320a2e99a1
Summary:
This test was used to compare the old codegen output with the new codegen output. It was written predominately to test the ObjC++ generator. A few reasons why we should delete this:
1. We do not want the old and the new codegen targets co-existing because it will slow down buck query.
2. The new ObjC++ codegen output is different from the old. In the new ObjC++ generator, we aren't generating dead structs. Therefore, this test simply won't work on the most sophisticated generator (i.e: the generator it was designed to run on). The other generators are really simple. We've also been running the ObjC++ and the Java generators in production for over a month for react-native-github specs. These are arguably the most complicated specs we maintain, so generator correctness isn't too much of a concern.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D25683069
fbshipit-source-id: b2175f34f50a078d80ef738e59024f546628219a
Summary:
Generate Fabric C++ files along side TM spec files for RNTester. The combined .so then has both TM and Fabric files.
This commit also removed the checked-in JNI files.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25674313
fbshipit-source-id: 8091d5a00f42849a74cab50e8d24f4010d500e5b
Summary:
For core components, we can start using the codegen output during build time instead of the checked in files in: https://github.com/facebook/react-native/tree/master/ReactAndroid/src/main/java/com/facebook/react/viewmanagers
Note: Some files seemed to be handwritten, so this only removed those that use codegen.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D25453157
fbshipit-source-id: f7eabddfd3fd668bef0c4aef3fddcb38c8b046a0
Summary:
Some of the existing files under uimanager/ are self contained and used by the component codegen output. This commit split out those files into a dedicated uimanager/interfaces/ dir/target so that more targets can depend on it without causing dep cycle.
Also, the component codegen output doesn't need LayoutShadowNode at all, so this removed the import.
This will allow us to combine the Java codegen output for TM spec and Fabric components, simplifying build and dependency management (not in this commit yet).
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D25451409
fbshipit-source-id: 827545a3d78ebed1815cf9e52da2fa896b012aa1
Summary:
This commit:
* Generate Fabric component Java files along side Java NativeModule specs, when `USE_FABRIC=1` is set
* Adjust the component codegen to place output files in a subdir based on package name
* Adjust existing Buck targets to filter the right nativemodule vs component java files (this avoids duplicated symbols)
* Compiles the Java output during build time on RNTester/ReactAndroid (Gradle)
Not in this commit:
* Fabric C++ files
* Removing checked-in generated component files.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25416614
fbshipit-source-id: fd670ead2198c9b5a65812c692b7aed9f3d7cd58
Summary:
In the Codegen, we need to answer the following questions:
*Question:* What are all the calls into TurboModuleRegistry?
*Answer:* Find all CallExpressions that represent TurboModuleRegistry.get<Spec>() or TurboModuleRegisty.getEnforcing<Spec>().
*Question:* Is this a component spec?
*Answer:* Does this spec have a CallExpression where the callee is 'codegenNativeComponent'?
*Question:* Is this a module spec?
*Answer:* Does this spec have an interface that extends TurboModule?
All these answers can be implemented using the visitor pattern. Hence, this diff introduces the `visit` utility, and uses it to answer these questions.
**Motivation:** Cleaner code.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D25162617
fbshipit-source-id: 66ec95fc07ecb29aa9bf9993cb826204af283d03
Summary:
**Motivation:** After this change, we can show this ParserError using the React Native Module ESLint rule. Previously when we declared more than one NativeModule spec in a file, we incorrectly reported that there were *no* NativeModule specs in the file.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D25163299
fbshipit-source-id: 92bc09d09cdbc323e0ac1f317c40a767880f5bc2
Summary:
## What is `guard`?
`guard` accepts some JavaScript function that can throw a ParserError. If a ParserError is thrown by that JavaScript function, it captures and pushes the error to some global array, and returns null. If no ParserError is thrown, it simply returns the return value of the JavaScript function. This utility is used in the NativeModule spec parser to help it continue parsing even after it detects errors. Why do we want to do this? In the NativeModule spec linter, we want to display all these ParserErrors via ESLint.
## Changes
This diff renames `guard` to `tryParse` because `tryParse` more appropriately captures the intent/function of this utility: the work passed to it "tries" to parse some Flow types. A name like "guard" is a bit more ambiguous: What is it guarding against? What is the work doing? ¯\_(ツ)_/¯
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D25156185
fbshipit-source-id: 516647770579daa8613dbd67535074823f1aa848
Summary:
## Changes
1. In the NativeModule spec parser, the moduleName is now being extracted from the TurboModuleRegistry.get<Spec>(...) call by examining the Flow ast node. Previously, we used regex parsing, which was unsafe because it could be fooled by TurboModuleRegistry.get<Spec>(...) calls in comments.
2. The logic to parse and validate the TurboModuleRegistry.get<Spec>(...) call is now centralized in the NativeModule Spec Parser (it was removed from the react-native-modules ESLint rule). The linter is now only responsible for three things:
1. Detecting if a JavaScript file contains a TurboModuleRegistry.get<Spec> call or a TurboModule interface, and if so
2. Running the NativeModule spec parser on it.
3. It also validates that the Module spec's filename starts with the prefix "Native".
The React Native Modules linter now completely delegates to the NativeModules Spec parser, without doing any error checking of its own. If an error is reported by the React Native Modules linter, and that error doesn't have anything to do with the "Native" prefix, then it *must* be addressed. Otherwise, it will cause the NativeModule Spec Parser to fail on that particular spec.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D25153243
fbshipit-source-id: da74dbb66b1d8dca3a2b1952402222c6696b73d6
Summary:
Changes `react-native/babel-plugin-codegen` to generate calls to `NativeComponentRegistry` instead of `registerGeneratedViewConfig`.
The only notable changes in behavior from this will be:
1. In bridgeless mode, all components using `codegenNativeComponent` will no longer access `UIManager`.
2. In bridge mode, all components using `codegenNativeComponent` will no longer verify equivalence in production. Only in `__DEV__`. (This may improve performance slightly.)
This also changes the `ViewConfig` to be lazily allocated and drops support for `__INTERNAL_VIEW_CONFIG`, which we no longer need.
Changelog:
[Internal]
Reviewed By: JoshuaGross
Differential Revision: D25135881
fbshipit-source-id: ca2191872c02622ab2279b808102eeb1f664d207
Summary:
## Changes
{| ... |} -> { ... }
**Motivation:** In Flow, object literals are exact by default. So, there's no need for the pipes. Also: Now, the syntax for object literals is consistent across react-native-codegen.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D24774771
fbshipit-source-id: 24ceb6f5876122aa8ad9e08c7e903215864ad6f5
Summary:
This type annotation was declared inline twice. Just pulling it out into a type alias in this diff.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D24723191
fbshipit-source-id: 9f2061087172979ea838dfdf2533e17b9b559c71
Summary:
Int32EnumTypeAnnotation represents a union of numbers. In the corresponding type annotation, we represent options as `$ReadOnlyArray<{value: number}>`. Since each option is a number, we could instead represent options as `$ReadOnlyArray<number>` - there's no need to use an object with a singular property (i.e: 'value'). The same is could be said of StringEnumTypeAnnotation.
In this diff, we change `Int32EnumTypeAnnotation.options` to `$ReadOnlyArray<number>`, and `StringEnumTypeAnnotation.options` to `$ReadOnlyArray<string>`.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D24723107
fbshipit-source-id: 4734cf72a4a29b6b321d8161bea70cf524ce0963
Summary:
Commands are `FunctionTypeAnnotation`, but they don't have a return type. I this diff, I introduced a `FunctionTypeAnnotation<+P, +R>` utility type, and made the `CommandTypeAnnotation` be an instantiation of it, with the return type fixed to `VoidTypeAnnotation`.
Now, the shape of a FunctionTypeAnnotation is unified across the NativeModule and Component schemas.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D24719965
fbshipit-source-id: 0089c3b23f05b0c534ba28dbe336c7f2db5866b3
Summary:
Everywhere else in the CodegenSchema, type annotation partials are suffixed with "Shape". In the NativeModule schema, we were using the suffix "Schema". In this diff, we standardize on the "Shape" suffix.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D24719395
fbshipit-source-id: 307935f5fe0681c31cd52e9cf4ae579f61c1ae68
Summary:
CodegenSchema exports `NativeModuleMethodParamSchema` and `NativeModuleObjectTypeAnnotationPropertySchema`, which are partials of NativeModule type annotations. This creates unnecessary coupling between the type annotations of CodegenSchema and the files that depend on it.
**Actual Problem:** Suppose that we want to rename one of these partials. Then, all imports in all files would have to be updated, even when the actual shape of the composed type annotation wasn't changed.
This diff removes these partials, which reduces the surface area of the exports of CodegenSchema.js
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D24719396
fbshipit-source-id: c822aaa252f156c524f4ef4917ebb61b1a39ff9e
Summary:
The names of events and props flow type annotations are singular. The names of the commands flow types are however plural. This diff renames all "Commands*" flow types to be singular.
**Motivation:** Consistency
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D24708276
fbshipit-source-id: 5d5d2123426ca1139953169d0ea764b82b2f3809
Summary:
All throughout the Codegen schema, we re-declare the following shape:
```
{
type: 'ObjectTypeAnnotation',
properties: $ReadOnlyArray<{
name: string,
optional: boolean,
typeAnnotation: ...
}>
}
```
This diff introduces an `ObjectTypeAnnotation<T>` utility type and replaces those re-declarations with instantiations of this type.
**Motivation:** To reduce noise in the CodegenSchema. This should be a pure refactor, and shouldn't actually change any behaviour.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D24707963
fbshipit-source-id: 6b4eb711ddd041f3a041109ade5ad5644fb16924
Summary:
This diff re-organizes CodegenSchema to declare the larger types first, which use smaller undeclared types. The smaller types are declared further down the file, and they themselves use even smaller undeclared types.
**Motivation:** Increase the readability of CodegenSchema.js. Now, if people want to understand the shape of the Codegen Schema, they can just read the file from top to bottom.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D24701424
fbshipit-source-id: 181e87bff5e32d998463221891f459b0df26ef52
Summary:
Reserved type annotations can appear in three different contexts: commands, props, and NativeModules. For now, commands and NativeModules share the same reserved type annotations. In the future, we may want to merge these reserved type annotations with the props reserved type annotations.
**Motivation:** The meaning of FunctionValue in FunctionValueTypeAnnotation isn't clear - in fact, it's downright confusing. Therefore, this diff renames this Flow type to ReservedTypeAnnotation, which I believe sufficiently captures the intent of the type annotation.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D24701322
fbshipit-source-id: bde0273b4a89c9e7175c60ed3468ed870b320044
Summary:
Our CodegenSchema is littered with types that have the following shape
```
{
name: string,
optional: boolean,
typeAnnotation: ...
}
```
In all these types, the only difference is the typeAnnotation. This diff introduces a new utility type called `NamedShape`, that just creates this shape, given a type annotation. This should help reduce the amount of noise in the CodegenSchema, and make it a bit easier to read.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D24701331
fbshipit-source-id: a30d3e22933116e3dabf7929615905febacecba3
Summary:
All ObjectTypeAnnotation *properties* in the codegen have the following shape:
```
{
name: string,
optional: boolean,
typeAnnotation: ...
}
```
EventObjectTypeProperty is a property of some ObjectTypeAnnotation, yet it doesn't follow this pattern. This diff cleans up EventObjectPropertyType. This is a part of a larger effort to clean up the Component Schema and unify the notion of a "type annotation" across the Component and Module schemas.
Reviewed By: yungsters
Differential Revision: D24701027
fbshipit-source-id: edc7dc632a217fb5a82ffd8a62aef990baf398c2
Summary:
This fixed a bug in the JS Java spec generator. Optional methods were still marked `abstract` before this fix. Instead it should be a normal method with potentially falsy return value.
The JavaPoet version does this correctly already, but there was a minor typo with void return type vs optional.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D24524432
fbshipit-source-id: 57a248580a78bc255f34d0492ebe3a4691e66667
Summary:
We don't currently support object spreads in `ObjectTypeAnnotation`s. This diff adds an explicit error for the case in the parser, so that when people use object spreads in ObjectTypeAnnotations, they get feedback from the linter rule and parser.
Previously, the Linter would crash, and the parser would fail, but the error wouldn't be immediately obvious.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24543650
fbshipit-source-id: 76f389c72f858ee6281c5aff5ce797f3be685096
Summary:
This moves the test script that generates **all outputs using all generators** to a dedicated "generate-all" CLI. This allows us to use it via Buck, at FB and OSS.
Also renamed the target to be more specific: "rn_codegen" => "generate_all_from_schema"
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D24513995
fbshipit-source-id: 8435d3d065718eb1309c1c61fe28fb592787311a
Summary:
For now, separate the definition of `modules` generator per platform to avoid file output collision. Additionally:
* For Android, produce files under java/ (plus nested subdirs based on packageName) and jni/ (for C++ files) - JavaPoet version already does it
* Allow configuring packageName for Android - JavaPoet version has this
* Avoid tmp directory dance in the CLI script, given the proper modules separation
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D24410864
fbshipit-source-id: 9bd6bc1d65bec037bfca32ec478f3af50d72e927
Summary:
## Rationale
Previously, the NativeModule spec parser would throw an error the first time it encountered an invalid Flow type. While this is ideal from a parsing standpoint, from a linting standpoint, however, we may want to display all errors that make the NativeModule spec invalid.
## Changes
This diff extends the NativeModule spec parser to collect all parsing errors in an array. In the codegen, if after building the schema, any parsing errors were detected, we throw the first one. In the ESLint rule, if after building the schema, any parsing errors were detected, the plan is to display them all.
## Notes
- All ParserErrors keep a track of the invalid AST Node
- When a Parsing error occurs, the Parser tries its best to continue parsing the rest of the source. For function parameters, it'll move on to the next param. For object proroperties, it'll move to the next property. It'll form a half-baked schema in the process, when a parsing error occurs. However, higher up in the stack, we have a check that discards the half-baked schema, if any ParsingErrors were collected.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24379511
fbshipit-source-id: 1989433da9b356b9ad5d9dcf901b429f585803c2
Summary:
## Why
We want to reuse these functions inside the ESLint rule. Therefore, it's better to make them accept the AST node object, as opposed to a custom type defined in codegen.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24379512
fbshipit-source-id: 9f7378fc6c5f48cce34da109f5a7c017332b302a
Summary:
In our Codegen generators, we were using `codegenModuleName` to refer to the name of the spec file. Calling this `hasteModuleName` makes it more clear what this name refers to (i.e: the name of the spec file). This diff performs that rename.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24386282
fbshipit-source-id: fe2beda9a0abf63a5cf88fa0664f83416c9f1aa2
Summary:
The specific file filtering in the CLI only covers the case where the input is a directory. We should filter when files are provided as well.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D24399225
fbshipit-source-id: 186e39c157faf90bdd825ec5c5860017d49e9404
Summary:
The GenerateModuleJavaSpec.js mistakenly treated nullable getConstants() properties as required, such that the Java spec will throw an exception when the properties are missing. This fixed it.
Note that the JavaPoet-based generator got this correct already.
Changelog: [Internal]
Differential Revision: D24381941
fbshipit-source-id: c95d2181c66443e2191318f09b6454a5296009e4
Summary:
The NativeModules spec parser uses `moduleName` to refer to the name of the NativeModule spec. This is confusing, because the NativeModules spec also has a `moduleNames` array, which refers to names of the NativeModules that get required in the spec.
This diff renames `moduleName` to `hasteModuleName` within the NativeModule spec parser.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24386279
fbshipit-source-id: 8e4eb8dfc647241bf2bdae54dc8d9ab0122f49f9
Summary:
If a native module schema has `excludedPlatforms` defined, honor it and skip the module that doesn't belong to the platform.
E.g. NativeImagePickerIOS shouldn't generate anything for Android codegen output.
Similarly, IntentAndroid shouldn't generate anything for iOS codegen output.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D24373092
fbshipit-source-id: cfeb455a18c92f60191d988af2e9ce7ea5021304
Summary:
Some existing NativeModules have either Android or IOS suffix to denote the exclusive intent for that platform. For now, note this in the codegen schema output, so that the generator can skip irrelevant modules. Long term, each Flow type for module Spec should denote the intended/excluded platforms directly.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D24370568
fbshipit-source-id: 8f725bdb39107d73c1aba0689db7f47ed7c374b0
Summary:
NOTE: Flow and Jest won't pass on this diff. Sandcastle, should, however, be green on D24236405 (i.e: the tip of this stack).
## Changes
1. NativeModule generators now use the new RN Codegen NativeModule schema.
2. Tangential: We're no longer removing the `Native` prefix from the NativeModule filename, assuming that that's the module name (problem: wrong), and prefixing again with Native (problem: redundant), when we're generating code. Instead, like the internal codegen, we simply pass the filename to the Codegen output. Our linters enforce that all NativeModule specs are contained with files that start off with `Native`.
3. `GenerateModuleCpp` was fixed to use the actual module name as opposed to the spec name. I added a comment inline.
Changelog: [Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: PeteTheHeat
Differential Revision: D24236405
fbshipit-source-id: ccd6b5674d252c350be0ec8a86e7ca5f2f614778
Summary:
NOTE: Flow and Jest won't pass on this diff. Sandcastle, should, however, be green on D24236405 (i.e: the tip of this stack).
Changelog: [Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: PeteTheHeat
Differential Revision: D24236504
fbshipit-source-id: 0ca70101a855fb713fa15ed63849b138eb73dc6c
Summary:
NOTE: Flow and Jest won't pass on this diff. Sandcastle, should, however, be green on D24236405 (i.e: the tip of this stack).
## Changes
Previously, the "Module" schema could either contain a `components` property, or a `nativeModules` property. The existence of the `components` property was used to determine (1) if the generators would run and (2) filter schemas on which the generators would run. Now, we simply check whether the type of the "Module" schema is `Component`.
Changelog: [Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: PeteTheHeat
Differential Revision: D24236508
fbshipit-source-id: 68cb3f25178b6757c9a4aee767bb6173db4932a6
Ramanpreet Nara
Andrei Shikov
Samuel Susla
Rubén Norte
Kevin Gozali
Tim Yung