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:
During the CoreContributor summit, we discovered that the `react-native-codegen` tests cannot be executed in the OSS due to this [issue with Jest](https://github.com/facebook/jest/issues/2567).
This PR moves the required variables inside the proper closure so that we can run tests in the OSS.
## Changelog
[General] [Fixed] - Enable the `react-native-codegen` tests in the OSS.
Pull Request resolved: https://github.com/facebook/react-native/pull/34594
Test Plan:
1. Run `yarn install` in the `react-native-codegen` folder.
2. Run `yarn jest`, see the test fail.
3. Apply the changes in this diff.
4. Run `yarn jest`, see the test pass.
Reviewed By: cortinico
Differential Revision: D39259164
Pulled By: cipolleschi
fbshipit-source-id: 7c4c0a7baa3c9b5e90a7ef75a37a0ec9d1b89db0
Summary: Add annotations to function parameters required for Flow's Local Type Inference project. This codemod prepares the codebase to match Flow's new typechecking algorithm. The new algorithm will make Flow more reliable and predictable.
Reviewed By: bradzacher
Differential Revision: D37388949
fbshipit-source-id: cdcbc98035ce9b6994842005ea46df42de54f9b8
Summary: Add annotations to function parameters required for Flow's Local Type Inference project. This codemod prepares the codebase to match Flow's new typechecking algorithm. The new algorithm will make Flow more reliable and predicatable.
Reviewed By: bradzacher
Differential Revision: D37363351
fbshipit-source-id: a9d3df7db6f9d094ac2ce81aae1f3ab4f62b243a
Summary: Add annotations to function parameters required for Flow's Local Type Inference project. This codemod prepares the codebase to match Flow's new typechecking algorithm. The new algorithm will make Flow more reliable and predicatable.
Reviewed By: evanyeung
Differential Revision: D37353648
fbshipit-source-id: e5a0c685ced85a8ff353d578b373f836b376bb28
Summary:
I was trying to add an object property to my ViewManager and got a really opaque error (and I almost thought Objects weren't supported by the codegen) until I realized it expected the object to wrapped in a $ReadOnly type.
Changelog: [Internal] Improved error in codegen
Reviewed By: mdvacca
Differential Revision: D34006557
fbshipit-source-id: b3ab15a40cb66fdcd377f4e68df92060498e8e7f
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:
## 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:
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:
## 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:
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:
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:
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
- 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
Summary:
Currently, the codegen supports `$ReadOnly` values, but not `$ReadOnly` properties on objects. This adds support for those (by pretty much ignoring them).
Changelog:
[General][Added] - Support `$ReadOnly` in object properties when defining native event types
Reviewed By: TheSavior
Differential Revision: D22023142
fbshipit-source-id: 7167852050925bf31392607923576f023e729f5f
Summary:
Currently the schema only allows to exclude a single platform (iOS OR Android). There are cases where we need to exclude multiple. This change converts the previous `excludePlatform` string property into an `excludePlatforms` array.
Changelog:
[Internal][Changed] - Added support to exclude multiple platforms in Codegen.
Reviewed By: sammy-SC
Differential Revision: D21426950
fbshipit-source-id: eff36ffa207109274794b4b300bf6313f8286161
Summary:
Adds support for `RootTag` in the new codegen for Native Component Commands.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D21169371
fbshipit-source-id: 3b25433f3328e9c04cfe45bb176fc06d63559f14
Summary:
Straightforward rename to clarify the purpose of this type.
The current naming made more sense before the codegen also produced code for NativeModules.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D21160793
fbshipit-source-id: 6787ef298e32ff1b4d506afd831af96764f5af6f
Summary:
Straightforward rename to clarify the purpose of this type.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D21160790
fbshipit-source-id: eaf5e8c9f51e16134e153a6321857234be1aa338
Summary:
This gets us on the latest Prettier 2.x:
https://prettier.io/blog/2020/03/21/2.0.0.html
Notably, this adds support for TypeScript 3.8,
which introduces new syntax, such as `import type`.
Reviewed By: zertosh
Differential Revision: D20636268
fbshipit-source-id: fca5833d003804333a05ba16325bbbe0e06d6c8a
Summary:
This Pull Request implements the PlatformColor proposal discussed at https://github.com/react-native-community/discussions-and-proposals/issues/126. The changes include implementations for iOS and Android as well as a PlatformColorExample page in RNTester.
Every native platform has the concept of system defined colors. Instead of specifying a concrete color value the app developer can choose a system color that varies in appearance depending on a system theme settings such Light or Dark mode, accessibility settings such as a High Contrast mode, and even its context within the app such as the traits of a containing view or window.
The proposal is to add true platform color support to react-native by extending the Flow type `ColorValue` with platform specific color type information for each platform and to provide a convenience function, `PlatformColor()`, for instantiating platform specific ColorValue objects.
`PlatformColor(name [, name ...])` where `name` is a system color name on a given platform. If `name` does not resolve to a color for any reason, the next `name` in the argument list will be resolved and so on. If none of the names resolve, a RedBox error occurs. This allows a latest platform color to be used, but if running on an older platform it will fallback to a previous version.
The function returns a `ColorValue`.
On iOS the values of `name` is one of the iOS [UI Element](https://developer.apple.com/documentation/uikit/uicolor/ui_element_colors) or [Standard Color](https://developer.apple.com/documentation/uikit/uicolor/standard_colors) names such as `labelColor` or `systemFillColor`.
On Android the `name` values are the same [app resource](https://developer.android.com/guide/topics/resources/providing-resources) path strings that can be expressed in XML:
XML Resource:
`@ [<package_name>:]<resource_type>/<resource_name>`
Style reference from current theme:
`?[<package_name>:][<resource_type>/]<resource_name>`
For example:
- `?android:colorError`
- `?android:attr/colorError`
- `?attr/colorPrimary`
- `?colorPrimaryDark`
- `android:color/holo_purple`
- `color/catalyst_redbox_background`
On iOS another type of system dynamic color can be created using the `IOSDynamicColor({dark: <color>, light:<color>})` method. The arguments are a tuple containing custom colors for light and dark themes. Such dynamic colors are useful for branding colors or other app specific colors that still respond automatically to system setting changes.
Example: `<View style={{ backgroundColor: IOSDynamicColor({light: 'black', dark: 'white'}) }}/>`
Other platforms could create platform specific functions similar to `IOSDynamicColor` per the needs of those platforms. For example, macOS has a similar dynamic color type that could be implemented via a `MacDynamicColor`. On Windows custom brushes that tint or otherwise modify a system brush could be created using a platform specific method.
## Changelog
[General] [Added] - Added PlatformColor implementations for iOS and Android
Pull Request resolved: https://github.com/facebook/react-native/pull/27908
Test Plan:
The changes have been tested using the RNTester test app for iOS and Android. On iOS a set of XCTestCase's were added to the Unit Tests.
<img width="924" alt="PlatformColor-ios-android" src="https://user-images.githubusercontent.com/30053638/73472497-ff183a80-433f-11ea-90d8-2b04338bbe79.png">
In addition `PlatformColor` support has been added to other out-of-tree platforms such as macOS and Windows has been implemented using these changes:
react-native for macOS branch: https://github.com/microsoft/react-native/compare/master...tom-un:tomun/platformcolors
react-native for Windows branch: https://github.com/microsoft/react-native-windows/compare/master...tom-un:tomun/platformcolors
iOS
|Light|Dark|
|{F229354502}|{F229354515}|
Android
|Light|Dark|
|{F230114392}|{F230114490}|
{F230122700}
Reviewed By: hramos
Differential Revision: D19837753
Pulled By: TheSavior
fbshipit-source-id: 82ca70d40802f3b24591bfd4b94b61f3c38ba829
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:
Some props must have their default values set by native. To be able to support this, we have to introduce a null as a supported default value for some types. In this diff I'm adding support for null default values for float props. An example of this to be useful is `ReactDrawerLayoutManager`:
```
Override
public void setDrawerWidth(ReactDrawerLayout view, Nullable Float width) {
int widthInPx =
width == null
? LayoutParams.MATCH_PARENT
: Math.round(PixelUtil.toPixelFromDIP(width));
view.setDrawerWidth(widthInPx);
}
```
We need to be able to generate an interface method, that accepts a boxed `Float` value instead of the primitive `float` so that the native code can decide what value to use by default (`LayoutParams.MATCH_PARENT` in this case).
Reviewed By: rickhanlonii
Differential Revision: D17343172
fbshipit-source-id: 7662a4e0e495f58d05a92892f063535a359d09ae
Summary: Some props must have their default values set by native. To be able to support this, we have to introduce a `null` as a supported default value for some types. In this diff I'm adding support for `null` default values for boolean props. Check D17260168 for the example of the usage of the nullable boolean values.
Reviewed By: rickhanlonii, TheSavior
Differential Revision: D17258234
fbshipit-source-id: 63b7864be97856704d5964230526f23c0e395a67
Summary:
## Overview
This diff adds flow parser support for number unions as Int32Enums
The following will be supported as an Int32 enum:
```
interval?: WithDefault<0 | 15 | 30 | 60, 0>,
```
## Number type issues
We assume that all number enums are ints (so far there's not been a valid use case for unions of floats).
If we think there would be a use case for float unions we would need to update this to something like:
```
// Int32
intervalInt?: WithDefault<Int32Enum<0 | 15 | 30 | 60>, 0>,
// Float
intervalInt?: WithDefault<FloatEnum<0.0 | 15.1 | 30.2 | 60.3>, 0.0>,
```
My recommendation is that we default number unions to ints and if a use case arises later for floats, we would add the Float support as:
```
// Int32
intervalInt?: WithDefault<0 | 15 | 30 | 60, 0>,
// Float
intervalInt?: WithDefault<FloatEnum<0.0 | 15.1 | 30.2 | 60.3>, 0.0>,
```
Reviewed By: JoshuaGross
Differential Revision: D17161701
fbshipit-source-id: 4b016eee45bf28bf505afd14a6c1aeea6ca8c04f
Summary:
Fix flow test case input in react-native-codegen package that has syntax errors.
Missing ";" after export type,
Missing ";" or "," after interface/object type member signature,
Missing ":" in method signature,
etc
## Changelog
[General] [Fixed] - Fix flow test case input in react-native-codegen package
Pull Request resolved: https://github.com/facebook/react-native/pull/26316
Test Plan: Parsed files using flow parser, but some test cases are intended to have syntax error, in this case I fixed unexpected ones.
Reviewed By: rickhanlonii
Differential Revision: D17194969
Pulled By: osdnk
fbshipit-source-id: 262d0af4d9e7e74f7ba3eb30c4fd9753c08f3bf7
Summary:
The types we were using before weren't very strict and it had been on my list to fix this. I *think* this is the right type. With Flow's type first project having these exported types will be necessary anyways so we can just use that for the ref.
Changelog:
[Internal]
Reviewed By: JoshuaGross
Differential Revision: D16930573
fbshipit-source-id: 05c1e097794633a2cefa7384c9d81ab15a63d8af
Summary: Give a more explicit message about why `number` isn't supported
Reviewed By: rickhanlonii
Differential Revision: D16926698
fbshipit-source-id: 292cb13aa11205e1350209178bde1977a2a7ad4c
Riccardo Cipolleschi
Rujin Cao
Pieter Vanderwerff
George Zahariev
Andres Suarez
Pieter De Baets
Charles Dudley
Evan Yeung
Tim Yung
Andrei Shikov
Luna Wei
Ramanpreet Nara
João Vieira
Michael Bolin
Tom Underhill
Eli White
Brian Solon
Samuel Susla
Oleksandr Melnykov
Rick Hanlon
Zihan Chen (MSFT)
Logan Daniels
Joshua Gross
