Summary:
So I was adding a new HTTPCookie prop to our WebView native component and found that my build was [failing](https://www.internalfb.com/diff/D32602297?dst_version_fbid=338931330931416) due to "redefinition of `value`". Looks like we use the name of the prop as a variable name during codegen, and this can conflict with some other hardcoded variable names. Rather than try and come up with a better prop name, I figured we can just append some string to our codegen name to reduce the chance for conflicts.
Changelog:
[Internal][Changed] - Change codegen variable naming to prevent conflicts to prop names
Reviewed By: JoshuaGross
Differential Revision: D32967807
fbshipit-source-id: 1b3631ec783b229eddfd3c801ffbb397910fc882
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:
Currently, we don't have a way to extend RCTFabricComponentsPlugins in OSS. This diff adds a codegen to generate ThirdpartyFabricComponentsProviderwhich will be used to extend RCTFabricComponentsPlugins.
It works almost exactly the same as RCTFabricComponentsPlugins, and in the future we might want to consider merging them together.
Changelog: [internal]
Reviewed By: hramos
Differential Revision: D32128760
fbshipit-source-id: b4f3a082f94c3053251cc6a0323c488f649deaa9
Summary:
**Motivation:** Readability. It was hard to tell how componentName, paperComponentName, and paperComponentNameDepreacted produced the NativeComponentRegistry.get call.
Changelog: [Internal]
Reviewed By: philIip
Differential Revision: D32108276
fbshipit-source-id: ea7c9fe4dc50cdd6fec94b5cd25f7bbcfb451ef6
Summary:
## Rationale
**Disclaimer**: This is an incremental step towards more maintainable/readable react-native-codegen generators. In the future, we may want to replace these templates/string concat logic with *something better*. But until we decide what that *something better* is, let's at least get rid of all this gross string find/replace.
Benefits of using Function templates over String.prototype.replace.
- **Self-documenting**: Template Functions enumerate/describe their exact data dependencies in their signature. You no longer have to read the template implementation to see what data you need to pass into the template.
- **Improved Readability**: JavaScript syntax highlighting makes it really easy to see where/how the data is inserted into the templates. Also template variables used be prefixed/suffixed with ::, which made things really confusing in C++ code (e.g: wtf is `::_CLASSNAME_::EventEmitter::::_EVENT_NAME_::`?).
- **Simpler Interpolation**: Don't have to worry about .replaceAll vs .replace, or calling these replace functions with regexes or strings.
- **Template Type-safety**: Ensure that the correct data types are passed to the component templates (e.g: flow will complain if you accidentally pass null/undefined when a template expects a string).
- **Template Type-safety**: Ensure that we don't pass in extra data to templates (this diff catches/fixes instances of this error). Ensure that we don't forget to pass in data to the template.
- etc.
After this diff, both our Component and NativeModule generators will be using template functions. This string find/replace exists no more in react-native-codegen.
This is also a very surface-level change. I made no efforts to simplify these templates. Let's take a look at that later, as necessary.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D32021441
fbshipit-source-id: f8f27069bcbf9d66dcafb7d1411da1f938eb6dcd
Summary:
I had to make this change when enabling Fabric in OSS. Without the full path, it can't find the modules like processColor within node_modules.
Changelog: Internal
Reviewed By: motiz88
Differential Revision: D31300424
fbshipit-source-id: 59b82470ec1ce63b63704931786e22b98f4bf046
Summary:
Changelog: [Internal]
Some environments that use codegen don't have Haste enabled, breaking the `require('NativeComponentRegistry')` call in generated view configs. Here we change it to reference an explicit path relative to `react-native`.
Reviewed By: JoshuaGross
Differential Revision: D31166063
fbshipit-source-id: cebc23d0d95b5cde76d0f8473eabc03ca82a862e
Summary:
If I understand the code correctly, component.extendsProps is expected to have more than 1 entry. I encounter a bug where it was an empty and produced an broken Props.h file while testing out in OSS.
```
// Example of the broken file.
class RNTMyNativeViewProps final : {
public:
```
In this diff, it makes it clear that the function has failed so that the codegen fails when the input is wrong.
There is probably an upstream problem that we should warn about, but this diff is just to make sure this method fails loudly.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D30847173
fbshipit-source-id: 34c894f0a7bb81e132b6ed44f51d0f92ed9a5a20
Summary:
See previous diffs for context. This updates all of the relevant props structs.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D29855426
fbshipit-source-id: 30177c3380ef82ecf8f2a4321f128cfbe8a576e0
Summary:
This pre-suppresses the 153 error diff ahead of its release, since it is large.
Changelog: [Internal]
Reviewed By: mroch
Differential Revision: D28754374
fbshipit-source-id: 1806f53bc7d804644d434583a2dcd6da63d00328
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/31543
Changelog:
[iOS][Added] - Description
When compiling iOS apps with flag `-Wnullability-completeness` (like Lightspeed app and soon Instagram), Objective-C headers are required to either have full *explicit* nullability annotations on all members of its public API, or none at all; partially annotated headers will fail to build that module.
RN native modules are currently generated with *partial* annotations. This works today because most apps are not compiled with `-Wnullability-completeness` turned on. But when we flip the switch for Instagram, the app doesn't build due to importing these RN partially annotated modules.
JavsScript Flow types are implied nonnull, and the current RN codegen translates Flow's [maybe/optional](https://flow.org/en/docs/types/maybe/) type to Obj-C `_Nullable` annotation, and everything else without an explicit Obj-C annotation. However this creates a mismatch with the Obj-C type system, where the implied default is *unannotated*, which is handled differently from nonnull when built with the nullability compiler flags.
There is a simple Obj-C macro that automatically adds *explicit nonnull* annotations to all members in a header: `NS_ASSUME_NONNULL_BEGIN` / `NS_ASSUME_NONNULL_END`. If we add this to *all* RN-generated headers, however, we run into issues:
1) We may erroneously assume any previously-unannotated header was meant to be nonnull and cause future bugs
2) Another compiler flag (`-Wnullable-to-nonnull-conversion`) statically analyzes Obj-C implementation code to prevent us from ever passing null to one of these headers. Much existing Obj-C code will break here, and it's ambiguous if these are true or false positives because of the first point.
Instead, in this diff we add a new BUCK flag `ios_assume_nonnull` to let module authors opt into automatic nonnull for unannotated members so that Obj-C headers are generated correctly in alignment with Flow's type system. We can migrate all libraries individually as needed and eventually make this the RN native codegen default.
Reviewed By: RSNara
Differential Revision: D28396446
fbshipit-source-id: ad3a3a97ab19183df4ef504b1c3140596c8f69ca
Summary:
This should ensure that nothing is stripped at compile-time.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26094738
fbshipit-source-id: 8dd62c289deafdcceb3de4b09c12132aaceafa94
Summary:
To ensure these Pojos don't get dead code eliminated, this diff adds a DoNotStrip annotation to each Props pojo object.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26041103
fbshipit-source-id: 02031f39f5fc5ef1bb9f11b729e68437bfe95452
Summary:
The Pojo data structure now keeps a flag `isRoot`, so that we can customize code-generation for the Props pojo vs its helper pojos.
In the following diff (i.e: D26041103), we'll add a DoNotStrip annotation to the props pojo. That doesn't need to exist on the helper pojos, because they'll all be referenced in the root props pojo.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26041102
fbshipit-source-id: ae2e1ba346d038853b5ff30cd5524a809ef97053
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:
For core components, we can start using the codegen output during build time instead of the checked in files in: https://github.com/facebook/react-native/tree/master/ReactAndroid/src/main/java/com/facebook/react/viewmanagers
Note: Some files seemed to be handwritten, so this only removed those that use codegen.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D25453157
fbshipit-source-id: f7eabddfd3fd668bef0c4aef3fddcb38c8b046a0
Summary:
Some of the existing files under uimanager/ are self contained and used by the component codegen output. This commit split out those files into a dedicated uimanager/interfaces/ dir/target so that more targets can depend on it without causing dep cycle.
Also, the component codegen output doesn't need LayoutShadowNode at all, so this removed the import.
This will allow us to combine the Java codegen output for TM spec and Fabric components, simplifying build and dependency management (not in this commit yet).
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D25451409
fbshipit-source-id: 827545a3d78ebed1815cf9e52da2fa896b012aa1
Summary:
This commit:
* Generate Fabric component Java files along side Java NativeModule specs, when `USE_FABRIC=1` is set
* Adjust the component codegen to place output files in a subdir based on package name
* Adjust existing Buck targets to filter the right nativemodule vs component java files (this avoids duplicated symbols)
* Compiles the Java output during build time on RNTester/ReactAndroid (Gradle)
Not in this commit:
* Fabric C++ files
* Removing checked-in generated component files.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25416614
fbshipit-source-id: fd670ead2198c9b5a65812c692b7aed9f3d7cd58
Summary:
Changes `react-native/babel-plugin-codegen` to generate calls to `NativeComponentRegistry` instead of `registerGeneratedViewConfig`.
The only notable changes in behavior from this will be:
1. In bridgeless mode, all components using `codegenNativeComponent` will no longer access `UIManager`.
2. In bridge mode, all components using `codegenNativeComponent` will no longer verify equivalence in production. Only in `__DEV__`. (This may improve performance slightly.)
This also changes the `ViewConfig` to be lazily allocated and drops support for `__INTERNAL_VIEW_CONFIG`, which we no longer need.
Changelog:
[Internal]
Reviewed By: JoshuaGross
Differential Revision: D25135881
fbshipit-source-id: ca2191872c02622ab2279b808102eeb1f664d207
Summary:
## Changes
{| ... |} -> { ... }
**Motivation:** In Flow, object literals are exact by default. So, there's no need for the pipes. Also: Now, the syntax for object literals is consistent across react-native-codegen.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D24774771
fbshipit-source-id: 24ceb6f5876122aa8ad9e08c7e903215864ad6f5
Summary:
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:
For now, separate the definition of `modules` generator per platform to avoid file output collision. Additionally:
* For Android, produce files under java/ (plus nested subdirs based on packageName) and jni/ (for C++ files) - JavaPoet version already does it
* Allow configuring packageName for Android - JavaPoet version has this
* Avoid tmp directory dance in the CLI script, given the proper modules separation
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D24410864
fbshipit-source-id: 9bd6bc1d65bec037bfca32ec478f3af50d72e927
Summary:
NOTE: Flow and Jest won't pass on this diff. Sandcastle, should, however, be green on D24236405 (i.e: the tip of this stack).
Changelog: [Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: PeteTheHeat
Differential Revision: D24236504
fbshipit-source-id: 0ca70101a855fb713fa15ed63849b138eb73dc6c
Summary:
NOTE: Flow and Jest won't pass on this diff. Sandcastle, should, however, be green on D24236405 (i.e: the tip of this stack).
## Changes
Previously, the "Module" schema could either contain a `components` property, or a `nativeModules` property. The existence of the `components` property was used to determine (1) if the generators would run and (2) filter schemas on which the generators would run. Now, we simply check whether the type of the "Module" schema is `Component`.
Changelog: [Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: PeteTheHeat
Differential Revision: D24236508
fbshipit-source-id: 68cb3f25178b6757c9a4aee767bb6173db4932a6
Summary:
NOTE: Flow and Jest won't pass on this diff. Sandcastle, should, however, be green on D24236405 (i.e: the tip of this stack).
Changelog: [Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: PeteTheHeat
Differential Revision: D24236502
fbshipit-source-id: 288c6d9588bde177732fe8165d3374eeacad999d
Summary:
This diff moves fabric C++ code from ReactCommon/fabric to ReactCommon/react/renderer
As part of this diff I also refactored components, codegen and callsites on CatalystApp, FB4A and venice
Script: P137350694
changelog: [internal] internal refactor
Reviewed By: fkgozali
Differential Revision: D22852139
fbshipit-source-id: f85310ba858b6afd81abfd9cbe6d70b28eca7415
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:
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:
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
Alex Koller
Ramanpreet Nara
Evan Yeung
Sota Ogo
Tim Yung
Moti Zilberman
Joshua Gross
Daniel Sainati
Erich Graham
Kevin Gozali
Christoph Nakazawa
Nat Mote
David Vacca
Lulu Wu
João Vieira
George Zahariev
Michael Bolin
Eli White