Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48477
Over the years of copying and moving and renaming types through CodegenSchema, this type ended up in the Command params, although the Command parser doesn't allow it.
I made this change to a fixture:
{F1974104959}
and got this error
```
FAIL xplat/js/react-native-github/packages/react-native-codegen/src/parsers/flow/components/__tests__/component-parser-test.js
● RN Codegen Flow Parser › can generate fixture COMMANDS_DEFINED_WITH_ALL_TYPES
Unsupported param type for method "scrollTo", param "speed". Found UnionTypeAnnotation
127 | default:
128 | (type: empty);
> 129 | throw new Error(
| ^
130 | `Unsupported param type for method "${name}", param "${paramName}". Found ${type}`,
131 | );
132 | }
```
Also, a default value for enum an argument of a Command doesn't make sense anyways.
Commands should probably have support for enums and string literal unions, but that's out of scope here.
Still need to add to this vec\concat on www: https://www.internalfb.com/code/www/[ebfa58f888a6064e17879934d447f59bcc2b6951]/flib/intern/sandcastle/react_native/ota_steps/SandcastleOTACompatibilityCheckReportingStep.php?lines=62
Changelog: [internal]
Reviewed By: cipolleschi
Differential Revision: D67806808
fbshipit-source-id: f0f31cca30abbf61f569933ea7c49cf6bfd18a3f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48343
components store unions as 'StringEnumTypeAnnotation' even though it isn't actually a union, it's a literal.
Native Modules store these as 'StringLiteralTypeAnnotation' so this converges those and reuses the same types.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D67427656
fbshipit-source-id: e39028114285588584596012d07db40c117b4b94
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48318
These structures were the same, but the component side didn't use generics and just had duplicates. Making a base one to be shared.
I need to follow up to this and constrain the types that components allow.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D67371894
fbshipit-source-id: bb1a30fcd0efe6cc567b88bc6f11e7b385bd7c41
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48312
I figured out how to fix these FlowFixMes
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D67313962
fbshipit-source-id: 21b109824411c1537f397aca45b7cdc2495f5e11
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47349
This is needed to be able to recurse into the literals and compare them.
I'm primarily unsure if there is a problem representing doubles/floats as numbers instead of strings though.
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D65284058
fbshipit-source-id: b2de9ed5fb7f079a432c94aaea69027863879909
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47324
I need to reference this type somewhere else, but not an array of the type.
Generally we prefer that all exported types are the object itself, and it used as a member type of arrays when used.
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D65259014
fbshipit-source-id: 35fb5fe03a44bed61ad87337d0fc5c198744c0e9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47323
This change adds support for number literals as a type.
The codegen already has parsing support for these types
```
+passNumber: (arg: number) => void;
+passString: (arg: string) => void;
+passStringLiteral: (arg: 'A String Literal') => void;
```
This change now also supports
```
+passNumberLiteral: (arg: 4) => void;
```
On the native side this is treated the same as `number`. It could be strengthened in the future.
This is a pre-requisite for number literal unions and enums.
Changelog: [Added] Codegen: Added support for Number literals in native module specs
Reviewed By: makovkastar
Differential Revision: D65249334
fbshipit-source-id: 98b051d2a6bd1ad5cc6473ac88acfcbe82bd5c7d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46845
Previously, the parser was throwing away the values of a string union when storing it in the schema. It would only store the union as
```
{
type: 'UnionTypeAnnotation',
memberType: 'StringTypeAnnotation'
}
```
We now track the string literals through the parser and store them in the schema:
```
{
type: 'StringLiteralUnionTypeAnnotation',
types: [
{
type: 'StringLiteralTypeAnnotation'
value: 'light'
},
{
type: 'StringLiteralTypeAnnotation'
value: 'dark'
},
],
}
```
We aren't changing the generators, those still just output "string". They could eventually be made smarter.
The value of this is that the compat checker can now error when the union changes.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D63917685
fbshipit-source-id: 34a10e1f1910d2935837a3659f66049fd4473134
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46827
You can now define a native module that takes an argument that is a specific string literal:
Like this:
```
export interface Spec extends TurboModule {
+passString: (arg: string) => void;
+passStringLiteral: (arg: 'A String Literal') => void;
}
```
On the native side, this will still generate `string`, but the schema will now store the string literal, and it will be allowed in JS. This should allow more strict flow / typescript types for modules.
This will also allow the compatibility check to fail if the literal changes.
This is a step towards accepting a union of string literals.
Changelog: [General][Added] Codegen for Native Modules now supports string literals
Reviewed By: GijsWeterings
Differential Revision: D63872440
fbshipit-source-id: e54b97d34af4a3d1af51727db0777f26fb7b778c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46727
It makes scripts operating on the schema complicated when the elementType might be there or might not. Let's make it required, but VoidTypeAnnotation if it's unknown.
Arguably we shouldn't allow it to be unknown at all, but that's out of scope here.
Changelog: [Internal]
Reviewed By: GijsWeterings
Differential Revision: D63616703
fbshipit-source-id: 290586384b911928e55344aa522bd296f23a074c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46528
This is needed for a script that needs to switch over all possible type annotations in the codegen schema.
Reviewed By: GijsWeterings
Differential Revision: D62805189
fbshipit-source-id: 8fd113f4ad0b695b38e92b8d0fc45a991f597fb8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46237
I can't find any uses of this, it's not referenced in any fixtures, and flow and typescript both pass without it.
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D61892355
fbshipit-source-id: 8ebb4da3e104109c740d90c2495dbcc89d3978e5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46222
This value was typed as always being a string, even though it was containing both strings and numbers in the fixtures. This was because on this line https://fburl.com/code/9j7gh4av the input type is $FlowFixMe (from the source AST), which wasn't catching that it couldn't flow into just `string`.
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D61830075
fbshipit-source-id: 0d5a0239d7c0209049184ca858a7ceb1ada02f79
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46221
Previously the schema special cased unparseable elementType with elementType just being undefined. This causes issues for logic that requires recursively matching types. Instead of being implicit, this makes them explicitly an AnyTypeAnnotation
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D61825742
fbshipit-source-id: 47bf70d32d21647896d8f5319087378cc8ac8d4f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46220
We'll want to eventually combine the module and component capabilities more, but these are at least the trivially shared ones.
More work is required to merge the more complex object types.
This change also makes it more clear where capabilities are different between native modules and components
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D61740140
fbshipit-source-id: 9e7bf740cf6cd2431be8cad822ec69903dbbc71f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44919
## Changelog:
[Internal] [Fixed] - Call Turbo Module methods 'methods' in the Turbo Module JSON schema
We don't support `properties` on Turbo Modules. We only support methods (even eventEmitters are just methods)
Reviewed By: javache
Differential Revision: D58510557
fbshipit-source-id: 02b1dc93a37b58b47bb9fd94a9658b5a7301bf55
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44809
Adding react-native-codegen parser support for a new `EventEmitter` property type on C++ Turbo Modules.
It is possible to later expand this feature to other languages (Java, ObjC).
## Characteristics
An `EventEmitter` must:
- be non null:
`EventEmitter<string>` works, `?EventEmitter<string>` does NOT
- have a non null eventType:
`EventEmitter<number>` works, `EventEmitter<?number>` does NOT
- have at most 1 eventType, `void` is possible as well:
`EventEmitter<>` or `EventEmitter<MyObject>` work - `EventEmitter<number, string>` do NOT
- have a concrete eventType, `{}` is not allowed
`EventEmitter<{}>` does NOT work
- be used in `Cxx` Turbo Modules only at this time
## Example
For these 4 eventEmitters in on an RN JS TM spec
```
+onPress: EventEmitter<void>;
+onClick: EventEmitter<string>;
+onChange: EventEmitter<ObjectStruct>;
+onSubmit: EventEmitter<ObjectStruct[]>;
```
We now generate this code:
1.) in the spec based header `{MyModuleName}CxxSpec` in the constructor:
```
... // existing code
eventEmitterMap_["onPress"] = std::make_shared<AsyncEventEmitter<>>();
eventEmitterMap_["onClick"] = std::make_shared<AsyncEventEmitter<OnClickType>>();
eventEmitterMap_["onChange"] = std::make_shared<AsyncEventEmitter<OnChangeType>>();
eventEmitterMap_["onSubmit"] = std::make_shared<AsyncEventEmitter<OnSubmitType>>();
```
2.) as `protected` functions
```
void emitOnPress() {
std::static_pointer_cast<AsyncEventEmitter<>>(delegate_.eventEmitterMap_["onPress"])->emit();
}
void emitOnClick(const OnClickType& value) {
std::static_pointer_cast<AsyncEventEmitter<OnClickType>>(delegate_.eventEmitterMap_["onClick"])->emit(value);
}
void emitOnChange(const OnChangeType& value) {
std::static_pointer_cast<AsyncEventEmitter<OnChangeType>>(delegate_.eventEmitterMap_["onChange"])->emit(value);
}
void emitOnSubmit(const OnSubmitType& value) {
std::static_pointer_cast<AsyncEventEmitter<OnSubmitType>>(delegate_.eventEmitterMap_["onSubmit"])->emit(value);
}
```
## Changelog:
[General] [Added] - Add EventEmitter code-gen support for C++ Turbo Modules
Reviewed By: javache
Differential Revision: D57407871
fbshipit-source-id: 2345cc6dacf0cb0d45f8a374ad9d4cbf8082f9d6
Summary:
Previously we allow `{[key:string]:Something}` in codegen, `Something` is type-checked but thrown away, generating a `GenericObjectTypeAnnotation`.
In this change, `Something` is added to `GenericObjectTypeAnnotation` as an optional field.
For downstream code such as C++ codegen, this change is **backward compatible**. It allows C++ codegen to produce a more precious type optionally.
## Changelog:
[General] [Added] - Recognize dictionary type in codegen
Pull Request resolved: https://github.com/facebook/react-native/pull/37206
Test Plan:
```
yarn jest react-native-codegen
yarn jest react-native-codegen-typescript-test
```
Reviewed By: cipolleschi
Differential Revision: D45563340
Pulled By: dmytrorykun
fbshipit-source-id: 9a9ce36df6ded6d42d35c3dcb6fb0eaca16c4458
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36044
> **Notice**: This commit does not change any behaviour.
Parse and collect enum members in module specs instead of the current behaviour of parsing enum members as 'string' / 'number' and ignoring the member names.
This commit would allow us to generate native Enums corresponding to the schema's enums.
Prior to this commit, enum params were parsed as:
```
{
'name': 'qualityParam',
'optional': false,
'typeAnnotation': {
'type': 'EnumDeclaration',
'memberType': 'StringTypeAnnotation'
}
},
```
The name of the enum type and the members of the enum type were ignored.
After this commit, parsed modules would hold a new object member called `enumMap` that would look like this:
```
'enumMap': {
'QualityEnum': {
'name': 'QualityEnum',
'type': 'EnumDeclarationWithMembers',
'memberType': 'StringTypeAnnotation',
'members': [
{
'name': 'SD',
'value': 'sd'
},
{
'name': 'HD',
'value': 'hd'
}
]
},
// ...
}
```
And enum params would be exported as:
```
{
'name': 'qualityParam',
'optional': false,
'typeAnnotation': {
'name': 'NativeModuleEnumTypeAnnotation',
'type': 'EnumDeclaration',
'memberType': 'StringTypeAnnotation'
}
},
```
Combining the two new outputs would allow us to generate Native enums in the Native generators.
Changelog: [Internal] Parse and collect enum members in turbo module specs
Reviewed By: cipolleschi
Differential Revision: D42778258
fbshipit-source-id: 56479342e085bc4e13c5a3e12b265b140e49893c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36042
Pull Request resolved: https://github.com/facebook/react-native/pull/36028
Use aliasMap both in parsers and generators instead of using aliasMap in half of the places and aliases in the other.
This would also allow us to introduce "enumMap" more easily in the next commit.
Changelog: [Internal] rename module exports from "aliases" to "aliasMap"
Reviewed By: christophpurrer, cipolleschi
Differential Revision: D42888752
fbshipit-source-id: cf1929fcebde994d07e5c6bda5ab71106d417b21
Summary:
The [previous pull request](https://github.com/facebook/react-native/pull/35812) enables defining interfaces and using them in a turbo module, but all members are flattened, this is not the best option for codegen for object oriented languages.
In this pull request, an optional member `baseTypes` is added to aliased objects. Members are still flattened for backward compatibility, if a codegen doesn't care about that nothing needs to be changed.
### Example
```typescript
interface A {
a : string;
}
interface B extends A {
b : number;
}
```
#### Before the previous pull request
`interface` is not allowed here, you must use type alias.
#### At the previous pull request
`interface` is allowed, but it is translated to
```typescript
type A = {a : string};
type B = {a : string, b : number};
```
#### At this pull request
Extra information is provided so that you know `B` extends `A`. By comparing `B` to `A` it is easy to know that `B::a` is obtained from `A`.
## Changelog
[GENERAL] [CHANGED] - Turbo module codegen support interface with inheritance in module
Pull Request resolved: https://github.com/facebook/react-native/pull/36011
Test Plan: `yarn jest react-native-codegen` passed
Reviewed By: rshest
Differential Revision: D42882650
Pulled By: cipolleschi
fbshipit-source-id: 32d502e8a99c4151fae0a1f4dfa60db9ac827963
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35953
DimensionValue is a reserved prop type that can be a number or string (such as '50%'). On Java, it will get converted to a YogaValue (converter added to this diff); on C++ it will get converted to a YGValue (converter already exists as it's used in Fabric).
Changelog:
[Internal][Added] - Add codegen support for DimensionValue for components
Reviewed By: cipolleschi
Differential Revision: D42650799
fbshipit-source-id: 1d2bc30bbd93837dedbbb4c74f814963c8140957
Summary:
We have the expected module name available as part of the codegen schema, so we can remove the need for developers to implement the `getName` method as part of their module implementation.
Note that this method is not actually used when the TurboModules infra is used, as the moduleName from the turbo module manager is passed through to the TurboModule base class instead. Moving the method to codegen will make it easier to remove this method altogether once the old architecture is fully removed.
Changelog: [Android][Added] Support generating `getName` in react-native-codegen for Java TurboModules
Reviewed By: mdvacca
Differential Revision: D41615387
fbshipit-source-id: 6b117645fa39e5e9ab014b21198496a52f6f2ae2
Summary:
`Promise<T>` is used very often in turbo module as function return types. So `T` is a critical thing for type safety. To enable future generator to produce more specific type for `Promise`, `T` is added to the schema.
## Changelog
[General] [Changed] - Fix codegen to add `T` of `Promise<T>` in CodegenSchema.js
Pull Request resolved: https://github.com/facebook/react-native/pull/35345
Test Plan: `yarn jest react-native-codegen` passed
Reviewed By: lunaleaps
Differential Revision: D41304647
Pulled By: cipolleschi
fbshipit-source-id: 6cdd2357b83d4d8007c881a7090cbb8969f3ae9d
Summary:
This is the second diffs that backs out the Custom Native State from the Codegen. The reason why we are backing it out are:
1. It forces users to create new types in JS that are not ctually used there. For example, the NativeState you define, and eventually exports, in JS is not used anywhere in your JS code.
2. You need to put in the JS native state some types that does not exists in JS, only to have them generated by the Codegen. ImageRequest, for example, does not exists in JS, but you need it in your (iOS) state to load images
3. There are a lot of edge cases due to how C++ handles variables. Some variables needs to be created as pointers. Some others as `const &`. It does not scale to hard code all of them and there is the risk to have the same type that needs to be a pointer in some case and something else in others.
4. It is better to instruct the users on how to properly create a component with Custom State, Shadow Node and Descriptor.
## Changelog:
[General][Removed] - Back out parsing and generation of Custom Native State from Codegen
Reviewed By: cortinico
Differential Revision: D40426134
fbshipit-source-id: c368e122cc31ee8df056fe1bf6cecaab482140a4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34910
This Diff adds supports on the CustomState generation for ImageSource and ImageRequests, to enable NativeComponents to use the ImageSource loading provided by React Native.
To achieve this, I also had to fox some errors in the imports and to introduce some functions to decorate parameters.
This diff also introduces the tests for thise additional types in both generators and parsers.
## Changelog
[General][Added] - add support for ImageSource and ImageRequest in the State.
Reviewed By: cortinico
Differential Revision: D39884889
fbshipit-source-id: ae3d2d51dfe6a4fe688dc78fec83f428beb8d443
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34753
This Diff introduce a the capability to parse custom NativeStates in Flow. To achieve this I also had to define the CodegenSchema.
The parsing follows the exact same rules as props, as initial heuristic. This should allow enough customization for the developers who needs a custom state.
There is only a case I was not able to make it work that is STATE_ALIASED_LOCALLY, from the fixtures. I don't know how diffuse it is and I think we can live with some workarounds for the time being.
This diff also adds tests for the custom Native State Flow Parser.
## Changelog
[General][Added] - Implement custom Native State parsing in Flow
Reviewed By: cortinico
Differential Revision: D39686251
fbshipit-source-id: 446997a39b33b7e9351d5ba12cecaeff33df4d16
Summary:
There are cases where we want to pass an enum type into a TurboModule method which is handy to restrict certain arguments to a restricted set of values, e.g. restricting quality to ```enum Quality { SD, HD, }```
Approach:
- We are not generating an ```enum``` type in C++ but rather just cast type safe to the corresponding member type.
- We don't support mixed enum types at this time, e.g. ```export enum StringOption { One = 'one', Two = 2, Three = 'three', };``` will not work. See: https://www.typescriptlang.org/docs/handbook/enums.html#heterogeneous-enums
- We only support untyped (default to String), String, and Number enum properties
This is for C++ only, Java and ObjC are not supported atm.
Changelog:
[General][Added] - react-native-code-gen Add Enum Type support for C++ TurboModules
Reviewed By: RSNara
Differential Revision: D38880963
fbshipit-source-id: f2399b29948306bc555429b6f96c43ea4c39c46e
Summary:
There are cases where we want to pass a union type into a TurboModule method which is handy to restrict certain arguments to a restricted set of values, e.g. restricting quality to ```'low'```, ```high``` or resolution to ```720```, ```1080```.
- We are not generating an ```union``` type in C++ but rather just cast type safe to the corresponding member type.
- We don't support mixed primitive union types at this time, e.g. ```export type ChooseSomething = 'One' | 'Two' | 3 | false;``` does not work.
- We can support mixed object union types such as ... ```export type ChooseObject = {} | {low: string};``` - which need special logic in the C++ TM to correctly parse the resulting jsi::Object
This is for C++ only, Java and ObjC are not supported atm.
Changelog:
[General][Added] - react-native-code-gen Add Union Type support for C++ TurboModules
Reviewed By: javache
Differential Revision: D38919688
fbshipit-source-id: 0fd37545b32b4f2059a8babda62dab4a85de37a9
Summary:
There are cases where we want to pass arbitrary types to a TurboModule, which may then handle the values appropriately, but we haven't supported this use case. Since C++ TurboModules can accept any `jsi::Value` (unlike Java/ObjC) and we have real-world need for this (otherwise we must require JSON serialization), this now allows `mixed` (`unknown` in TypeScript) for C++-only TurboModules.
Changelog:
[General][Added] C++ TurboModule methods can now use mixed types
Reviewed By: RSNara
Differential Revision: D36611299
fbshipit-source-id: bbf29dfcc6aed67e213bb3eab06537c18c7db1fe
Summary:
## What This Does
- **Phase 1:** Given a component, convert its props (and all its ObjectTypeAnnotations) into this Pojo data structure under some namespace. This is a recursive operation.
- **Phase 2:** Loop over each Pojo data structure, and serialize it to Java class.
So...
- Each Component has its own namespace (i.e: its hasteModuleName) for Java Pojo objects.
- Each Component generates 1 Pojo object, for its props.
- Each Component generates 1 Pojo object for every ObjectTypeAnnotation in its props.
## Decisions
By design, [JNI can read/write to private properties on Java objects](https://stackoverflow.com/a/12208643). So, each Pojo, which represents an ObjectTypeAnnotation, contains only a private member variable for each of its properties, and a getter to retrieve the data from each of its private members.
## Todos
- Improved type-safety:
- ReservedTypeAnnotation (e.g: PointPrimitive). These currently map to ReadableMap.
- String enums, and Int enums don't actually generate Java enums.
- Verify if there are any compilation issues by wiring this up to the Codegen buck infra.
- To actually use the Pojos, we'll need C++/Jni codegen to transform C++ props into these Pojos. Building this out will give a more accurate assessment of the app-size cost of Pojos. However, we can do that if we deem that the app-size increase from adding just the Pojo classes is negligible enough to **not** rule out this entire approach.
- ~~Add some annotations to prevent these Pojo classes from being stripped at compile-time.~~ D26041103
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26038189
fbshipit-source-id: c137c4ca6b043ee76adb354105aff6e0f270df86
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
Eli White
Christoph Purrer
Zeya Peng
Sam Zhou
Zihan Chen (MSFT)
Riccardo Cipolleschi
Genki Kondo
Vitali Zaidman
Pieter De Baets
Riccardo Cipolleschi
Christoph Purrer
Scott Kyle
Andres Suarez
Ramanpreet Nara