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:
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:
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:
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
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:
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: 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:
Adds schema to allow for Int32Enums in the codegen.
All of the non-schema updates here are flow fixes, the code there is implemented in the next diffs
Reviewed By: JoshuaGross
Differential Revision: D17158026
fbshipit-source-id: b5a6871225771c3c97a43a901d5f8e51c44f35c8
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: Support a prop-type `Double`, in addition to `Float`, for flow typing and codegen of components.
Reviewed By: TheSavior
Differential Revision: D16812812
fbshipit-source-id: b5588b3218636283a4e9c5d17212dd0b92986eb9
Summary: We'll need this helper in the prop files now so let's move it over to the generic cpp helpers
Reviewed By: TheSavior
Differential Revision: D16759164
fbshipit-source-id: 8765ffee3bd8219b5f0dc8677362ec45f0a8e2c5
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
Ramanpreet Nara
David Vacca
Tim Yung
Michael Bolin
Samuel Susla
Oleksandr Melnykov
Rick Hanlon
Logan Daniels
Joshua Gross
Min ho Kim
Michał Osadnik