Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53135
Our Codegenerated components are not generating code for `getDebugProps`. This change modifies Codegen to add those functions for all the codegen components.
## Changelog:
[General][Added] - Added getDebugProps to codegen
## Facebook:
`getDebugProps` are required by Fantom to write tests. However, we can't generate these function for third party components, because codegen can generate arbitrary structs and we don't have a generic `toString()` method that can be used or automatically generated by C++.
By generating this function only for Core Components, we can ensure that we can write Fantom tests without breaking all the users of React Native.
Reviewed By: rubennorte
Differential Revision: D79805145
fbshipit-source-id: 0e41c65fc30eaa886a05557ca233fb0a9cb18a71
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41956
By default, generated Cxx sources for components all end up in same directory. However the include declarations in them look like this:
```
#include <react/renderer/components/${libraryName}/ShadowNodes.h>
```
And not like this:
```
#include "ShadowNodes.h"
```
This works fine with Buck because it supports header prefixes.
To get this working with CocoaPods we define additional `HEADER_SEARCH_PATHS` for our `React-Codegen` pod.
This approach will not work if we want to generate code at the library level and check in the artifacts. That's because we don't have control over the Podspec there, and can't inject those additional `HEADER_SEARCH_PATHS`.
This diff adds the `headerPrefix` argument to the codegen entry point. It is `react/renderer/components/${libraryName}` by default, but can become empty if we want to generate code at the library level, and don't want to deal with this nested header structure.
*Note:* `RNCodegen` runs all the generators [in a loop](https://github.com/facebook/react-native/blob/main/packages/react-native-codegen/src/generators/RNCodegen.js#L263-L275), assuming that the all have same function signature So I had to add the `headerPrefix` argument to all the generators, even to the ones that don't really need it.
Changelog: [General][Added] - Introduce "headerPrefix" codegen option.
Reviewed By: zeyap
Differential Revision: D51811596
fbshipit-source-id: c5c3e1e571c7c4ea2f5354eb9a7b0df6b917fc0c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32840Closes#31516
I've cherry-picked the original PR that had merge conficts + updated all
the headers as the one for the TurboModule generators were not handled.
Original Commit Message from acoates
The codegen generates a Facebook copyright notice at the top of the generated files.
While this might make sense on the core files, this codegen will be run on external components too.
The notice also refers to a LICENSE file in the root of this project, which might not be there if this is run on another project.
I did a quick look at some of the codegen that we ship within windows dev tools, and it looks like we normally just have comments
saying the file was codegen'd and so the file shouldn't be manually edited.
Open to suggestions on what the comment header should say.
Changelog:
[General] [Changed] - Do not include Facebook license on users codegen'd code
Reviewed By: ShikaSD
Differential Revision: D33455176
fbshipit-source-id: b247e72efb242e79d99b388c80e4126633e5234d
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:
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:
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:
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).
## 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:
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:
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:
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:
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: I realized my previous diff was incomplete. Adding parsing and generation code for Double for props, commands, and events.
Reviewed By: rickhanlonii
Differential Revision: D16823540
fbshipit-source-id: fbed9897bb84b789c502cf4153e81060590152b8
Summary:
Following our internal discussion we want to change previously used name convention.
Now it looks like:
```
#import <FBReactNativeTestSpec/FBReactNativeTestSpec.h>
```
Name is a param of `rn_codegen` and `rn_library`. Also, I found it the easiest to move replacing `::_IMPORT_::` into buck rule
Reviewed By: fkgozali
Differential Revision: D16646616
fbshipit-source-id: 2c33c5b4d1c42b0e6f5a42d9a318bd8bda9745f4
Summary:
This will provide consistency with the rest of ObjC/ObjC++ files throughout RN codebase, which is also part of the iOS engineering practice to have a prefix.
Highlights:
* This only affects the `protocol` and extern C functions, and the .h output file name
* Other C++ only file/classes are not affected
* The assumption is that the RCT prefix is only for iOS specific files/names. The JS component name should **NOT** have any prefix in the long term (some of them still have RCT prefix in the name, which was an artifact of legacy inconsistency).
* The RCT prefix is not relevant to Java/JNI code, since they have their own convention
Reviewed By: TheSavior, mdvacca
Differential Revision: D16661286
fbshipit-source-id: b8dd75fa7f176d6658183f225b27db017b4b55e7
Summary: Support command arguments that are strings
Reviewed By: JoshuaGross
Differential Revision: D16509728
fbshipit-source-id: 003aba66231d204071d043c01cb0781150d0edb9
Summary:
These functions will be called by components like this:
```
- (void)handleCommand:(NSString const *)commandName args:(NSArray const *)args
{
ViewNativeComponentHandleCommand(self, commandName, args);
}
```
Codegen currently supports commands with ints and bools as arguments. Will add more types in follow up diffs.
Reviewed By: JoshuaGross
Differential Revision: D16509123
fbshipit-source-id: c3071ce3b5da215bb8747216e57026a69a89eff0
Summary: We will be generating protocols for every component even if there are no commands. This is for consistency and our ability to add to them later without changing every native component that doesn't currently have a command. JoshuaGross and I figure this is okay as it appears that empty protocols are very cheap on app size
Reviewed By: zackargyle, JoshuaGross
Differential Revision: D16503773
fbshipit-source-id: 11b78fcd33b68926def909d3ce42f58b9bbee96a
Riccardo Cipolleschi
Dmitry Rykun
Zeya Peng
Moti Zilberman
Nicola Corti
Andres Suarez
Ramanpreet Nara
Erich Graham
Kevin Gozali
David Vacca
João Vieira
Tim Yung
Michael Bolin
Samuel Susla
Joshua Gross
Michał Osadnik
Eli White