Summary:
Tests for Native Modules. Fixtures, Failures and the e2e tests were copied from the flow parser, modified for TypeScript and then the snapshots were diff'ed to ensure the parsers generated the same schema given the same (in spirit, different in syntax) input.
Changelog:
[General][Add] - Tests for TypeScript support for Native Module Codegen spec parsing
Reviewed By: RSNara
Differential Revision: D33081127
fbshipit-source-id: 3d7270dddd568090ec93d475a08a6a6011dad63c
Summary:
Tests for Native Components. Fixtures, Failures and the e2e tests were copied from the flow parser, modified for TypeScript and then the snapshots were diff'ed to ensure the parsers generated the same schema given the same (in spirit, different in syntax) input.
Changelog:
[General][Add] - Tests for TypeScript support for Native Component Codegen spec parsing
Reviewed By: RSNara
Differential Revision: D33080789
fbshipit-source-id: ae71d384f6d93da6b89eeb179c4ba7ebcd6ae03d
Summary:
These files are directly copied from the flow parser to aid in reviewing the next two Diffs: D33080789 and D33081127.
The only things that were changed during the copy are the import/require paths to ensure this diff could ship independently. (For this diff, these tests will still test the flow parser instead of importing the typescript parser).
Changelog:
[Internal][Add] - Copy Flow parser tests to aid in Diff review
Reviewed By: RSNara
Differential Revision: D33136296
fbshipit-source-id: 007e18618c9eba13728d19e4e342fbe9642adacc
Summary:
This adds the main entry point for the TypeScript parser as well as adds the logic to use the new parser if the spec file's extension is `.ts`
`js/react-native-github/packages/react-native-codegen/src/parsers/typescript/index.js` is mostly a direct copy from the flow parser.
Changelog:
[General][Add] - Choose Flow or WIP TypeScript Codegen parser based on spec's file extension
Reviewed By: RSNara
Differential Revision: D33081296
fbshipit-source-id: 267823685e6723e3c1f19752bbbe692e895c075b
Summary:
Similar to D33080623, this is the logic for parsing Native Modules and the files were copied from the flow parser and updated for TypeScript. The logic and code path is almost identical to the flow parser.
Also, like D33080623, while there is considerable duplication to the flow parser, I decided there are enough subtle differences to warrant keeping this logic separate.
Changelog:
[General][Add] - Add WIP TypeScript support for Native Module Codegen spec parsing
Reviewed By: RSNara
Differential Revision: D33081035
fbshipit-source-id: 5a196e4693df73c0fb88abafe2b4e6be032ea7ed
Summary:
These files are directly copied from the flow parser to aid in reviewing the next Diff, D33081035
Changelog:
[Internal][Add] - Copy Flow parser module logic to aid in Diff review
Reviewed By: RSNara
Differential Revision: D33134982
fbshipit-source-id: 9afea2ce15404338fd2c920a8b7eafe980f18688
Summary:
This is the logic for parsing Native Components. The files were copied from the flow parser and updated for TypeScript specific types and differences in the shape of the AST. The logic and code path is almost identical to the flow parser.
While there is considerable duplication to the flow parser, I decided there are enough subtle differences to warrant keeping this logic separate.
Changelog:
[General][Add] - Add WIP TypeScript support for Native Component Codegen spec parsing
Reviewed By: RSNara
Differential Revision: D33080623
fbshipit-source-id: a68c8d4c4570e65a88a97dcea3cd18a6976c53c7
Summary:
These files are directly copied from the flow parser to aid in reviewing the next Diff, D33080623
Changelog:
[Internal][Add] - Copy Flow parser component logic to aid in Diff review
Reviewed By: RSNara
Differential Revision: D33130222
fbshipit-source-id: ba7233b17d698793559da8b81bb7e1a78654e614
Summary:
These are utility functions that the TypeScript parser uses and are copied from and follows the same logic as the flow parser with some TypeScript specific changes. Also added dependency of `babel/parser` as the parsing engine we're using for TypeScript.
Changelog:
[General][Add] - Add foundation for WIP TypeScript parser for Codegen
Reviewed By: RSNara
Differential Revision: D33080527
fbshipit-source-id: d4bd515af549a41f07a2e3ee1a16b5ed678180b2
Summary:
This is a direct copy of the following files from the flow parser:
```
react-native-codegen/src/parsers/flow/errors.js
react-native-codegen/src/parsers/flow/utils.js
```
Changelog:
[Internal][Added] - Copy flow parser foundation files to aid in diff review
Reviewed By: RSNara
Differential Revision: D33137685
fbshipit-source-id: 1345c8bb0785c90b2bd64d4e6e2447f3fdb0ae6b
Summary:
This diff stack enables codegen to parse TypeScript spec files and generate an identical schema to our current Flow parser.
This first diff is a small cleanup of our current flow parser.
Changelog:
[General][Fixed] - Fix typo in error string and improve consistency in Codegen's flow parser tests
Reviewed By: sota000
Differential Revision: D33080423
fbshipit-source-id: 7bf817761a7704d807a0b809c9f2270354b5c6fa
Summary:
This diff runs the codemod to add type annotations to function parameters in preparation for Flow's local type inference (LTI) project. I ran the codemod over xplat/js and reverted any files that had flow errors in them. See the list of commands run to see the regeneration of various files.
Changelog:
[Internal][Changed] - Added type annotations
Reviewed By: yungsters
Differential Revision: D32075270
fbshipit-source-id: 6a9cd85aab120b4d9e690bac142a415525dbf298
Summary:
String type seems to be already supported by codegen, but it was not included in the list for command methods.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29306740
fbshipit-source-id: 44b267c09f471dc601759ed2f7211a9e0fc1bb90
Summary:
This pre-suppresses the 154 error diff ahead of its release, since it is large.
Changelog: [Internal]
Reviewed By: samwgoldman
Differential Revision: D29065246
fbshipit-source-id: f418041305a46df410dcbe3d9a4db81a61ac7014
Summary:
Right now, running the codegen parser on regular JavaScript files causes it to throw an error:
https://www.internalfb.com/intern/diffusion/FBS/browsefile/master/xplat/js/react-native-github/packages/react-native-codegen/src/parsers/flow/index.js?commit=1e93f27aac8890f1731650fdcc38b702ae8874e2&lines=59-63%2C106-107
This makes the parser less usable, because you can't simply loop over a list of JavaScript files, and run codegen on them. You need to do some filtering beforehand, or surround each invocation of the parser with a try/catch.
Our codegen schema supports the idea of an empty schema:
```
{
modules: {}
}
```
To improve the parser's ergonomics, this diff migrates the codegen parser over to returning the empty schema when it cannot detect a Component or NativeModule spec inside a JavaScript file.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D26034052
fbshipit-source-id: c2f15aba9c0e052012396eaed2034537f5918e33
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:
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
{| ... |} -> { ... }
**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:
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:
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:
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:
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:
## 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:
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:
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. Update the RN Codegen Module Parser
2. Update all RN Codegen Module Parser Jest tests & snapshots.
Changelog: [Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: PeteTheHeat
Differential Revision: D24236505
fbshipit-source-id: e24a39b4837c75a90fb4c957c56dfcf789511cc9
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. Update the RN Codegen Component Parser
2. Update all RN Codegen Component Parser snapshots.
Changelog: [Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: PeteTheHeat
Differential Revision: D24236503
fbshipit-source-id: 975d97dd29bb5ca08e5de96e7814290c3dc4357b
Summary:
According to Node's documentation: https://nodejs.org/api/util.html#util_util_inspect_object_showhidden_depth_colors
> The util.inspect() method returns a string representation of object that is intended for debugging. **The output of util.inspect may change at any time and should not be depended upon programmatically.**
Therefore, this diff switches over our RN Codegen snapshot tests to use a `JSON.stringify` call, followed by a replace of `"` with `'`. This gets the job done without compromising readability.
**Question:** Why do we not use `"`? A: Jest escapes all `"` in the snapshots, which makes reading the snapshots/using them in the console harder.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D24157056
fbshipit-source-id: 2f1aa2df28ac3ed4aa17bcdbcd23846ddbf804cf
Summary:
Previously, all our type annotations contained a `nullable` property. This diff removes that property from all our NativeModule type annotations, and instead introduces a `NullableTypeAnnotation`.
**Some Benefits:**
- In all our serialization functions, we use Flow exhaustive checking to ensure that all type-annotations can be serialized. Since nullability is now recorded as a type annotation, Flow will ensure we always explicitly handle nullability. Previously, with nullability as a property, we could ignore it without any feedback from flow.
- This aligns the NativeModule schema with the ESTree spec.
- After this diff, we're one step closer to sharing type annotations with Codegen's schema. Many NativeModule type annotations now have the same shape as their Codegen counterparts. They will be merged in a subsequent diff.
**Downsides:**
- If you want to check whether a type annotation is of type `T`, you have to remember to unwrap the type annotation *yourself*. Flow won't warn you if you forget to unwrap the type, which can lead to incomplete handling to nullable types in our generators.
- When you're creating type annotations in code, previously, you *had* to specify nullability, since it was a property on all type annotation objects. Now, it's very possible for you to forget to wrap the type annotation, which will just lead to nullability bugs.
**Notes:**
- In the scheam, exported type annotations are *always* required. They can be made nullable using the new `Nullable` genric type.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24026887
fbshipit-source-id: 9e71e2c6102dc506824403dbb712488ca8507d08
Summary:
The Flow Parser's snapshots, which are serializations of the CodegenSchema object, are extremely difficult to read. In this diff, I explicitly serialized the schema objects using Node's `util.inspect`.
**Benefits:**
- The snapshots are more readable now.
- You can copy-paste the objects from the snapshot files directly into the Chrome console, or into other JavaScript files. This is a very useful feature, when we're testing the generators, or other infra that depends on the codegen.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D24063112
fbshipit-source-id: 2c6ec3424aac8bab2688dc6ae286b73f90e4bef1
Summary:
We have first class support for Promises in our codegen. So, it's more appropriate to just call this PromiseTypeAnnotation, as opposed to GenericPromiseTypeAnnotation.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D23645209
fbshipit-source-id: bfc0b909750e221e18be33acf197f342a2918aa9
Summary:
We were using `$ReadOnly<NativeModuleAliasMap>` everywhere, so I figured we'd just make the type itself `$ReadOnly`.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D23645207
fbshipit-source-id: 4e018d5768f4fcfd00492def7d840a5054cb2b73
Summary:
Consider this case:
```
type Animal = ?{|
name: string,
|};
type B = Animal
export interface Spec extends TurboModule {
+greet: (animal: B) => void;
}
```
The generated output for this spec is:
```
namespace JS {
namespace NativeSampleTurboModule {
struct Animal {
NSString *name() const;
Animal(NSDictionary *const v) : _v(v) {}
private:
NSDictionary *_v;
};
}
}
protocol NativeSampleTurboModuleSpec <RCTBridgeModule, RCTTurboModule>
- (void)greet:(JS::NativeSampleTurboModule::Animal &)animal;
end
```
Observations:
1. The codegen looks as though we wrote `+greet: (animal: ?Animal) => void;` as opposed to `+greet: (animal: B) => void;`
2. The generated struct is called `Animal`, not `B`.
## After this diff
Whenever we detect a usage of a type alias, we recursively resolve it, keeping a track of whether the resolution will be nullable. In this example, we follow B to Animal, and then Animal to ?{|name: string|}.
Then, we:
1. Replace the `B` in `+greet: (animal: B) => void;` with `?Animal`,
2. Pretend that `Animal = {|name: string|}`.
Why do we make all type alias RHSs required?
2. This design is simpler than managing nullability in both the type alias usage, and the type alias RHS.
3. What does it mean for a C++ struct, which is what this type alias RHS will generate, to be nullable? ¯\_(ツ)_/¯. Nullability is a concept that only makes sense when talking about instances (i.e: usages) of the C++ structs. Hence, it's better to manage nullability within the actual TypeAliasTypeAnnotation nodes, and not the associated ObjectTypeAnnotations.
## Other Changes
- Whenever we use the `Animal` type-alias, the e2e jest tests validate that the type alias exists in the module schema.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D23225934
fbshipit-source-id: 8316dea2ec6e2d50cad90e178963c6264044f7b7
Summary:
## Test Structure
- Parameter Parsing
- For type in [optional, nullable, optional and nullable, required]:
- Can parse Primitives
- Can parse Object
- Can parse Arrays
- Can parse primitive element types
- Can parse Object element types
- Can parse Array element types
- Can parse Reserved Type element types
- Can parse Type alias element types
- Can parse Object Literals
- Can parse Function
- Can parse Reserved Types (e.g: RootTag)
- Can parse Type alias
- Can parse Object Literals
- For prop type in [optional, nullable, optional and nullable, required]:
- Can parse primitive prop types
- Can parse Object prop types
- Can parse Array prop types
- Can parse Reserved Type prop types
- Can parse Type alias prop types
- Can parse Object Literal prop types
- Return Parsing
- For type in [nullable, required]:
- Can parse Promises
- Can parse Primitives
- Can parse Object
- Can parse Arrays
- Can parse primitive element types
- Can parse Object element types
- Can parse Array element types
- Can parse Reserved Type element types
- Can parse Type alias element types
- Can parse Object Literals
- Can parse Function
- Can parse Reserved Types (e.g: RootTag)
- Can parse Type aliases
- Can parse Object Literals
- For prop type in [optional, nullable, optional and nullable, required]:
- Can parse primitive prop types
- Can parse Object prop types
- Can parse Array prop types
- Can parse Reserved Type prop types
- Can parse Type alias prop types
- Can parse Object Literal prop types
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D23089925
fbshipit-source-id: 73c3b1ef33b402265c14f0ac9e364414a5d54dca
Summary:
This diff:
1. Simplifies the NativeModule schema Flow types.
2. Simplifies the NativeModule Flow parser, to accomodate the modified schema, and to reduce code duplication.
**Notes:**
- If the parser detects an unrecognized type within the context of parsing an Array's element type, it'll omit the `elementType` property of the `ArrayTypeAnnotation`. Details: T72031674. **Rationale:** Basically, when an array element type is supported, we use it in our generators. When it's unsupported, we ignore it. In the unsupported case, there's no point in trying to parse the Array element type, which is why I decided to omit the `elementType` property. Ideally, our NativeModule specs would never use unsupported types, in any context. This would allow us to always parse and use the elementType. However, that seems like a it could be a hefty migration: we have > 400 specs. Since, this isn't a battle we need to fight right now, I left a TODO at the relevant lines instead.
- The legacy codegen would generate structs for each object literal type in the file. In this re-implementation of the parser, I only insert into the aliases array when we detect a usage of a type-alias to an ObjectLiteral type annotation. With this decision, we won't be able to generate these unnecessary structs. This is good because we get rid of dead code. It's bad because it might make our migration to this codegen bit more difficult.
[WARNING] This diff produces flow failures that will be addressed in subsequent diffs.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D23201387
fbshipit-source-id: 55ce0df925a8bae0e7d5bb2a9b63167607eba461
Summary:
## Changes
- Started doing cleanup under `/parsers/flow/modules/methods.js`
- Rename `NativeModuleMethodTypeShape` -> `NativeModulePropertyShape`
- Moved optional property from `FunctionTypeAnnotation` to the `NativeModulePropertyShape`
- Introduced a nullable property inside what was once `FunctionTypeAnnotation`.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D23146050
fbshipit-source-id: 2fe97bb9c0736242682133e4923131a54bbea54b
Summary:
## Changes
- Generating the aliases was split over `parsers/flow/modules/index.js`, and `parsers/flow/modules/aliases.js`. I moved everything to the latter file.
- Generating methods was split over `parsers/flow/modules/index.js` and `parsers/flow/modules/methods.js`. I moved everything to the latter file.
- More type-safety
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D23143382
fbshipit-source-id: e11b76bee7917a7db37ae7f1af64da5f046c5d1e
Andres Suarez
Luna Wei
Charles Dudley
Evan Yeung
Tim Yung
Andrei Shikov
Daniel Sainati
Ramanpreet Nara
Rubén Norte
Kevin Gozali