Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52244
The ArrayType props converts to std::vector. This prompted the need for `toDynamic(const T&)` conversion functions as this breaks to potential reliance on all type instances having a `toDynamic()` function available. This includes:
- array of arrays types
- array of objects types
- object with arrays
The ArrayType conversion uses the availability of the `toDynamic` conversion methods for all supported types to convert the values stored by the `std::vector` to `folly::dynamic` values to be stored on a `folly::dynamic::array`.
The diff removes unnecessary conversion methods implemented previously for the core components prop diffing. These are now handled by the generic `toDynamic(const std::vector<T>&)` conversion method.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D77234065
fbshipit-source-id: 97a3b175ff07fe4a6de3adb14ee6cb42db1a2cfe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52243
Building on the availability of `toDynamic` conversion methods for all supported property types, this diff adds support for diffing of `ObjectType` props.
The template adds the generation of a default comparator for the generated C++ struct. The struct also gains a `toDynamic` conversion method that will convert each property of the object type to a `folly::dynamic` value.
Primitive types make use of the implicit conversion supported by `folly::dynamic`, all other types are converted using `toDynamic`.
The `toDynamic` logic is implemented as a method defined on the struct to avoid increased binary size when required multiple times by the prop diffing implementation.
The external `toDynamic` conversion function calls the struct method directly. This enables support for converting object types using object types within their props.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D77234064
fbshipit-source-id: 21deb3104303aa374fb65b969af57a6aca6db38c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52242
Codegen supports `DimensionType` props which represents a YGValue. This diff adds a conversion to `folly::dynamic` supporting all the existing value types `YGValue` can represent.
This completes codegen support for all allowed `ReservedPropTypeAnnotation` prop types.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D77234061
fbshipit-source-id: 6c3aef5e3ab0459d8a68ebd8efaccfecb83b0b08
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52241
Add support for converting string and int32 enum types to `folly::dynamic` and generating the correct property diffing for it conditionally adding the prop value to the prop diff result.
This diff updates the template to convert the enum back to the original string representation provided from the JS side based on the current generated C++ enum value.
The string enum re-uses the existing `toString` conversion. The number enum generates the switch-case mapping required to map back the C++ enum value to the original value assigned to it.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D77234070
fbshipit-source-id: 8c669d5b2e21bd6022c6ba36149465495e4d4bf3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52239
Add `toDynamic` conversion function for `EdgeInset` which allowed for removing the custom conversion implemented for the `ViewProps`.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D77234069
fbshipit-source-id: 3aecad8a6d78468f0056167fa1523ccdfb68f369
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52238
Add prop diffing codegen for `PointPrimitive` prop type by adding a `toDynamic` conversion for the struct and the prop diffing conditional result update.
The addition of the `toDynamic` function will allow for converting the type when used in array and object types.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D77234062
fbshipit-source-id: d0f52e8fd78ac7712925ea2a47cdd0fe3392d5b0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52237
For array props conversion following later in this stack, each type should have a toDynamic conversion available that can be called upon to convert all supported types to a `folly::dynamic` result.
This diff adds the toDynamic conversion function for `ImageSource`
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D77234063
fbshipit-source-id: 392cbaf172595936f7f66faa824900dadd58bdcf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51650
This diff adds support to diff props with Point type
changelog: [internal] internal
Reviewed By: mlord93
Differential Revision: D75469451
fbshipit-source-id: a6844b691d8e32326d04c2bd51e6509980feb611
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51642
This diff asserts that ImageRequest won't be used as prop type
changelog: [internal] internal
Reviewed By: mlord93
Differential Revision: D75469453
fbshipit-source-id: e9e46bc8806e00c104b76825445fe72779106220
Summary:
codegen generates type alias for array enum props with uint32_t which cause wrong overloaded fromRawValue to call at runtime eventually app to terminate
more detailed info at issue https://github.com/facebook/react-native/issues/43821
## Changelog:
[Internal] [Fixed] - Codegen for array enum props
Pull Request resolved: https://github.com/facebook/react-native/pull/44123
Test Plan: TODO
Reviewed By: cipolleschi
Differential Revision: D56414554
Pulled By: dmytrorykun
fbshipit-source-id: 0ec1b65951bc16ff58dd2b119c97a4e3fac2b161
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42956
In the component codegen system, when the header prefix is an empty string, we generate includes using angle brackets, like this:
```
#include <EventEmitter.h>
```
This fails to compile in buck.
If we instead generate includes using quotations, buck compiles again.
```
#include "EventEmitter.h"
```
So, changes: if the headerPrefix is an empty string, generate includes using quotes.
This is a followup to D51811596.
Changelog: [Internal]
Reviewed By: fkgozali, dmytrorykun
Differential Revision: D53487111
fbshipit-source-id: e90a8b9fd4f8a2a93a0f4ad0ed989af26ad122c5
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: 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:
The props generator assumes that Props are used only on iOS. (i.e: the generator doesn't generate the props code if the iOS platform is excluded). However, Props are also used on Android. So, this diff makes us generate Props for all platforms.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D34559900
fbshipit-source-id: 0c25835dd57aa55a094152c147a9f952b9bc6850
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:
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:
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:
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:
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:
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:
This one is fun.
# What?
Previously, the codegen'd constructor for a prop value in CPP was defined like so: `value(convertRawProp(rawProps, "value", sourceProps.value, value))`.
The fourth argument there is the default value of the result of `convertRawProps`. What that is saying is: the default value of `value` is `value` - the default value is itself.
The assumption was that because value is defined as `T value{someDefaultValue}` in the struct, in other words, because it has a default value in the `.h` file, that it will /start out/ being equal to `someDefaultValue`, and then be overridden later optionally, or be set to itself, which should be `someDefaultValue`.
However, that is not how initialization of class members in C++ constructors work. If a class member is in the member initializer list, [then the default value is not set](https://en.cppreference.com/w/cpp/language/initializer_list). That means that if the `defaultValue` as passed is /ever/ used, we incur undefined behavior.
# When is the defaultValue used?
The defaultValue is only used when no prop or a null value is sent from JS to C++: https://our.intern.facebook.com/intern/diffusion/FBS/browse/master/xplat/js/react-native-github/ReactCommon/fabric/core/propsConversions.h?commit=becfded106d706e6028e705d7883483051061e9f&lines=60
In most cases, the `sourceProps.value` is actually used as a fallback (the previous props value). The first time props are ever constructed, `sourceProps` should have valid values since it goes through a different path where only the defaultValues from props.h are used.
# Why wasn't this crashing before?
Most codegen'd properties are ints, floats, doubles, and bools. They might get wacky values, but they won't crash. I wouldn't be surprised if this diff solves some subtle visual or layout bugs, but I have no evidence of this yet.
# How do non-codegen'd props.cpp initialize default values?
Same as this diff does: defaultValue should be explicit everywhere: https://our.intern.facebook.com/intern/diffusion/FBS/browse/master/xplat/js/react-native-github/ReactCommon/fabric/components/scrollview/ScrollViewProps.cpp?commit=2813789c292dfdf1220b88f203af6b33ba9e42de&lines=51
# So... what have we learned?
C++ is tricky!
Reviewed By: yungsters, shergin
Differential Revision: D16955421
fbshipit-source-id: 75bb3f22822299e17df1c36abecdb6ce49012406
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: Code generators for modules and components don't have a lot of in common so there's no point to keepo them in the same directory and mix their files.
Reviewed By: rickhanlonii
Differential Revision: D16183434
fbshipit-source-id: b6ee32c6b223e8d6e4bc843b2e111598bee94dc5
Nick Lefever
David Vacca
Nizam
Ramanpreet Nara
Dmitry Rykun
Christoph Purrer
Moti Zilberman
Pieter Vanderwerff
Ramanpreet Nara
Nicola Corti
Andres Suarez
Tim Yung
Joshua Gross
Daniel Sainati
Erich Graham
Kevin Gozali
David Vacca
João Vieira
George Zahariev
Michael Bolin
Samuel Susla
Rick Hanlon
Michał Osadnik