Summary:
**Motivation:**
Match the old codegen's behavior when generating structs for type alias derived objects.
**Problem description:**
Take, for example, the following spec:
```
export type MyTypeAlias = { /* ... */ }
export interface Spec extends TurboModule {
// ...
+myMethod: (paramName: MyTypeAlias) => void;
// ...
}
```
The codegen needs to generate a struct to expose the properties of the type alias object. The codegen was producing the following output:
```
- (void)myMethod:(JS::MyModule::SpecMyMethodParamName &)paramName;
```
...which does not match the output from the original codegen:
```
- (void)myMethod:(JS::MyModule::MyTypeAlias &)paramName;
```
The original codegen generates a struct using the type alias name, while the new codegen was generating a struct that uses a combination of the property and parameter names.
Now that type alias names are exposed in the schema, the new codegen can match the original codegen's behavior.
**De-duplication of structs:**
Prior to these changes, type aliases were expanded into regular object types. This meant that any spec that used a type alias more than once would lead to redundant structs getting created. With these changes, we only generate the one struct per type alias, matching the old codegen.
**Expansion of type aliases:**
A new type was introduced in D22200700 (https://github.com/facebook/react-native/commit/e261f022fe6a7653b79330f878fed143725f5324), TypeAliasTypeAnnotation:
```
export type TypeAliasTypeAnnotation = $ReadOnly<{|
type: 'TypeAliasTypeAnnotation',
name: string,
|}>;
```
This type may now appear in several locations where a `{| type: 'ObjectTypeAnnotation', properties: [] |}` otherwise would have been used. A `getTypeAliasTypeAnnotation` function is introduced which, given an alias name and an array of aliases provided by the module, will produce the actual object type annotation for the given property parameter.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D22244323
fbshipit-source-id: 125fbf0d6d887bd05a99bf8b81b30bdda4f1682b
Summary:
The current parser behavior flattens out any object type aliases into ObjectTypeAnnotations. Generators can treat these as regular objects and generate the applicable native code. This, however, can lead to repetition whenever an object type alias is re-used in the same native module.
I propose we treat these as a special case, using a TypeAliasTypeAnnotation to denote them as type aliases. Generators can look up the actual signature for a given object alias by referring to the "aliases" array that is provided in the schema.
**Proposed schema change:**
Adds an "aliases" key to each module in the schema:
```
export type NativeModuleShape = $ReadOnly<{|
properties: $ReadOnlyArray<NativeModuleMethodTypeShape>,
aliases: $ReadOnlyArray<{|
name: string,
typeAnnotation:
| $ReadOnly<{|
type: 'ObjectTypeAnnotation',
properties: $ReadOnlyArray<ObjectParamTypeAnnotation>,
|}>
| $ReadOnly<TypeAliasTypeAnnotation>,
|}>,
|}>;
```
Example:
```
{
modules: {
SampleTurboModule: {
nativeModules: {
SampleTurboModule: {
aliases: [],
properties: [],
},
},
},
},
}
```
Method parameters will now support the new 'TypeAliasTypeAnnotation' wherever a param might have used a 'ObjectTypeAnnotation':
```
export type TypeAliasTypeAnnotation = $ReadOnly<{|
type: 'TypeAliasTypeAnnotation',
name: string,
|}>;
```
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D22200700
fbshipit-source-id: 15684620783c752f2fb482ba4b88d1fd1cc07540
Summary:
Moving property handling functions to their own properties.js file. No changes other than adding types to params.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D22208243
fbshipit-source-id: 4a7d2c6e19c151954da793d399af9a256a4a40b7
Summary:
Move to Utils for reuse, and change parameter to take a property object.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D22146669
fbshipit-source-id: e028821cdb11361a45226de0247aa4551b5ade1d
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:
Restore legacy support for mixed union types.
These are not type safe and modules should use a different type, but we have a precedent for supporting these in the existing Linking native module. The new codegen will generate native code for these, and show a warning to encourage use of a better type.
Generate native code for elements in arrays of objects.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D21848260
fbshipit-source-id: 0b8cbf25e7a02791b4d77e349227a2b0744854f4
Summary:
When a property returns an array type, use the actual element type when generating structs and inlines.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D21651351
fbshipit-source-id: 14cadf209c38a301c9c65fcaadd8a292c1936349
Summary:
Handle properties named 'id' as a special case.
An example of a native module that ran afoul of this is `ExceptionsManager`.
Observe how the ExceptionsManager spec at `Libraries/Core/NativeExceptionsManager.js` defines the ExceptionData type as containing an `id` property:
```
export type ExceptionData = {
message: string,
originalMessage: ?string,
name: ?string,
componentStack: ?string,
stack: Array<StackFrame>,
id: number,
isFatal: boolean,
// flowlint-next-line unclear-type:off
extraData?: Object,
...
};
```
Prior to this change, the generated code would redefine id in the SpecReportExceptionData struct...
```
namespace JS {
namespace NativeExceptionsManager {
struct SpecReportExceptionData {
// ...redacted...
double id() const; <---
// ...redacted...
SpecReportExceptionData(NSDictionary *const v) : _v(v) {}
private:
NSDictionary *_v;
};
}
}
```
...which would result in a build time error:
```
inline double JS::NativeExceptionsManager::SpecReportExceptionData::id() const
{
id const p = _v[@"id"];
^--- build time error here
return RCTBridgingToDouble(p);
}
```
Comparing the above example with the currently checked in `FBReactNativeSpec.h`, I see the expected output should be:
```
namespace JS {
namespace NativeExceptionsManager {
struct SpecReportExceptionData {
// ...redacted...
double id_() const;
// ...redacted...
SpecReportExceptionData(NSDictionary *const v) : _v(v) {}
private:
NSDictionary *_v;
};
}
}
```
...and...
```
inline double JS::NativeExceptionsManager::SpecReportExceptionData::id_() const
{
id const p = _v[@"id"];
return RCTBridgingToDouble(p);
}
```
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D21395463
fbshipit-source-id: e412648013ff9f70ebd294b6f5f81f1faccb4604
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:
Import folly to handle optionals (`folly::Optional<__type__>`)
Sort modules and indent generated code to match output from the old codegen. While not strictly necessary as these are generated files that should not be edited by hand, I found that matching the old codegen in this regard made it less of a chore when it came to comparing the output of both codebases.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D21395231
fbshipit-source-id: 289d617d7a2d93724456c80afea57a49c108cb9b
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:
Adds support for `RootTag` in the new codegen for NativeModules/TurboModules.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D21160788
fbshipit-source-id: 952189f6e8bc8fde8b403d4c0e77b5d66b3f03e4
Summary:
Adds a `RootTag` parser test for the new codegen for NativeModules/TurboModules.
I'm doing this in a prerequisite commit in order to make the diff of the diff clearer when I implement proper support for `RootTag`.
This also fixes some of the minor typos and mistakes that I noticed. I also wanted to land these benign snapshot changes independent of the upcoming behavior changes.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D21160792
fbshipit-source-id: 5f29f34035da30d7afa2369dbc19e95954553e88
Summary:
Straightforward rename to clarify the purpose of this type.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D21160791
fbshipit-source-id: 422d09243edda0660815eb2f0ce51f7e56134983
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:
Pull Request resolved: https://github.com/facebook/react-native/pull/28719
The Buck dependencies for the schema rule is missing the source files for the new codegen (and specifically, the parser).
Changelog:
[Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: cpojer
Differential Revision: D21162993
fbshipit-source-id: 4addb6f257134e245a5d86dd427ee2536ed6d658
Summary:
## Summary
Please check out D21035208.
## Changes
- `ObjCTurboModule::ObjCTurboModule` changed to accept a bag of arguments `const ObjCTurboModule::InitParams` instead of an argument list.
- TurboModule iOS codegen scripts updated to generated `ObjCTurboModule` subclasses that accept a `const ObjCTurboModule::InitParams` object in their constructor, and forward it to `ObjCTurboModule::ObjCTurboModule`.
- All manually checked in code-generated ObjC++ classes (i.e: RCTNativeSampleTurboModule, RCTTestModule, FBReactNativeSpec) are updated.
## Rationale
This way, the code-gen can remain constant while we add, remove, or modify the arguments passed to ObjCTurboModule.
## Commands run
```
function update-codegen() {
pushd ~/fbsource && js1 build oss-native-modules-specs -p ios && js1 build oss-native-modules-specs -p android && popd;
}
> update-codegen
```
Changelog:
[iOS][Changed] Update ObjCTurboModule to use ObjCTurboModule::InitParams
Reviewed By: PeteTheHeat
Differential Revision: D21036266
fbshipit-source-id: 6584b0838dca082a69e8c14c7ca50c3568b95086
Summary:
This is necessary to integrate TurboModule async method dispatch with the bridge's `onBatchComplete` event. See D20717931 for more details.
This diff is similar to D20480971.
**Note:** This stack doesn't really make any functional changes, since the native CallInvoker is `nullptr` right now.
Changelog:
[Internal]
Reviewed By: fkgozali
Differential Revision: D20809199
fbshipit-source-id: bf465a3a51bdddb8b56d1e696ca510fdf071f9ec
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:
Previously, I had logic inside `RCTTurboModuleManager` to attach the `id<RCTTurboModulePerformanceLogger>` to the `ObjCTurboModule` object
```
/**
* By default, all TurboModules are long-lived.
* Additionally, if a TurboModule with the name `name` isn't found, then we
* trigger an assertion failure.
*/
auto turboModule = [strongSelf provideTurboModule:moduleName];
/**
* TODO(T63718299): Move this setter into the ObjCTurboModule constructor
*/
if (performanceLogger) {
if (auto objCTurboModule = std::dynamic_pointer_cast<facebook::react::ObjCTurboModule>(turboModule)) {
objCTurboModule->setRCTTurboModulePerformanceLogger(performanceLogger);
};
}
```
This diff removes that logic in `RCTTurboModuleManager`, and it also removes `ObjCTurboModule::setRCTTurboModulePerformanceLogger`. Henceforth, we'll instead pass the `id<RCTTurboModulePerformanceLogger>` into `ObjCTurboModule`'s constructor. I've made all the necessary changes to the codegen scripts in this diff as well.
This should also resolve T63903079 by simply eliminating the code that's crashing production FB apps.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D20480971
fbshipit-source-id: c3899981f880aa5d1354b5c3f4018c8fd57c3bae
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:
In codegen we generate structs that represents events. These structs are later dispatched by generated `EventEmitter`.
They had unpleasant naming, for example `SliderOnValueChangeStruct`. This diff changes the code generated so it becomes `SliderEventEmitter::OnValueChange`, this better expresses the relationship of the two classes.
Changelog: [Internal]
Motivation: Better express relationship between EventEmitter and classes that represent events.
Reviewed By: rickhanlonii, shergin
Differential Revision: D19373850
fbshipit-source-id: a5eea085013dbc119169e2b06ba9f9fe44c7fcd9
Summary:
We are rolling out exact-by-default syntax to xplat/js.
I had to manually move around some comments to preserve proper placement.
Changelog: [Internal]
Reviewed By: jbrown215
Differential Revision: D18633611
fbshipit-source-id: 48f7468dcc55b1d00985419d035a61c6820b3abe
Summary:
Changelog: [Internal]
Reverting the import to the previous local module style since importing from react-native seems to introduce some perf regression. We'll revisit this later in the future.
Reviewed By: yungsters
Differential Revision: D18383893
fbshipit-source-id: f11d46a4545768f39199fd6fd22fcf14905d0a74
Summary:
still some generated files in www that need to land before we can release 0.111 here.
drop-conflicts
Changelog: [Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: dsainati1
Differential Revision: D18278838
fbshipit-source-id: b20c3fefb3aab7c5fb614b33d846c7548184f49a
Summary:
Changelog: [Internal]
Moved the imports for `TurboModuleRegistry` and `TurboModule` from `react-native`. This was a jscodeshift with the script: P120688078
Reviewed By: yungsters
Differential Revision: D18262538
fbshipit-source-id: 48fac15229c897408928511c5ecbb42f17ec7b42
Summary:
1. Generated `RCTComponentViewHelpers.h` file was not being exported.
2. argument declaration was within `if RCT_DEBUG` directive which meant in production it was stripped.
changelog: [internal]
Reviewed By: TheSavior
Differential Revision: D18266846
fbshipit-source-id: 4c13b8ee9cf4cb3b7486ba7cfef0c64bc46b2360
Summary:
Currently we generate Java ViewManager interfaces and C++ classes for iOS regardless whether the component is supported on platform or it isn't. This adds an option to exclude either iOS to Android in order to avoid this.
Changelog: In codegen it is now possible to exclude one or the other platform
Reviewed By: rickhanlonii
Differential Revision: D18217185
fbshipit-source-id: 1c569b92c92a5b991c96b0abdff6b8ed395e449f
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:
## Motivation
The concept behind JSCallInvoker doesn't necessarily have to apply only to the JS thread. On Android, we need to re-use this abstraction to allow execution of async method calls on the NativeModules thread.
Reviewed By: PeteTheHeat
Differential Revision: D17377313
fbshipit-source-id: 3d9075cbfce0b908d800a366947cfd16a3013d1c
Summary:
I noticed two syntax errors in code gen while using it. This fixes them.
One of them is missing semicolon, the other one is name mismatch.
Reviewed By: TheSavior
Differential Revision: D17226188
fbshipit-source-id: 880dbf4c9b22efa7754de6413d01c04e7abbe411
Summary: This diff adds support for generating native code for arrays of arrays of objects
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D16936272
fbshipit-source-id: 1543f8c1d5d9d4db28e4c7841ff7184ca0e417b3
Summary:
This diff adds a fixture for supporting arrays of arrays of objects, eventually parsable as:
`$ReadOnlyArray<$ReadOnlyArray<$ReadOnly<{|foo: string|}>>`
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D16936233
fbshipit-source-id: 14143522d82ad7d42e81605bb701890ca2731bed
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
Héctor Ramos
Tim Yung
Lulu Wu
João Vieira
Ramanpreet Nara
George Zahariev
Michael Bolin
Eli White
Tom Underhill
Samuel Susla
Panagiotis Vekris
Kevin Gozali
Jordan Brown
Andres Suarez
Brian Solon
Oleksandr Melnykov
Rick Hanlon
