Summary: This diff adds more advanced support for Int32 enums by allowing them as object properties in props
Reviewed By: JoshuaGross
Differential Revision: D17161656
fbshipit-source-id: d4377d95961554c83b60ed929f6279291c2d1104
Summary: This diff adds the snapshots for the new Int32 fixture and renames the ENUM_ fixture to STRING_ENUM
Reviewed By: JoshuaGross
Differential Revision: D17158033
fbshipit-source-id: 405b1da5ede16410434a9097ef256f99e4115533
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:
Fix flow test case input in react-native-codegen package that has syntax errors.
Missing ";" after export type,
Missing ";" or "," after interface/object type member signature,
Missing ":" in method signature,
etc
## Changelog
[General] [Fixed] - Fix flow test case input in react-native-codegen package
Pull Request resolved: https://github.com/facebook/react-native/pull/26316
Test Plan: Parsed files using flow parser, but some test cases are intended to have syntax error, in this case I fixed unexpected ones.
Reviewed By: rickhanlonii
Differential Revision: D17194969
Pulled By: osdnk
fbshipit-source-id: 262d0af4d9e7e74f7ba3eb30c4fd9753c08f3bf7
Summary:
Our JS codegen assumes that all Android view managers extend `BaseViewManager` which allows generated delegates to set base view props using `BaseViewManagerDelegate`, see and example of the generated delegate for `FbReactTTRCStepRenderFlagManager`:
```
public class TTRCStepRenderFlagManagerDelegate<T extends View, U extends BaseViewManager<T, ? extends LayoutShadowNode> & TTRCStepRenderFlagManagerInterface<T>>{
public TTRCStepRenderFlagManagerDelegate(U viewManager) {
super(viewManager);
}
Override
public void setProperty(T view, String propName, Nullable Object value) {
switch (propName) {
case "traceId":
mViewManager.setTraceId(view, value == null ? null : (String) value);
break;
case "stepName":
mViewManager.setStepName(view, value == null ? null : (String) value);
break;
default:
super.setProperty(view, propName, value);
}
}
}
```
The problem is that `FbReactTTRCStepRenderFlagManager` doesn't extend `BaseViewManager`, but `ViewManager`, which means that we cannot use it with the generated delegate. We cannot use `ViewManager` instead of `BaseViewManager` in our JS codegen either, otherwise we will not be able to set base view props.
This diff makes it possible for delegates generated by JS to be used by Android view managers that do not extend `BaseViewManager`. By having a `BaseViewManagerInterface` we will be able to introduce a no-op base view manager implementation and wrap our original view manager in it so that we can pass as a constructor parameter to `BaseViewManagerDelegate`.
See an example of this approach for `FbReactTTRCStepRenderFlagManager`:
```
public class FbReactTTRCStepRenderFlagManager extends ViewManager<FbReactTTRCStepRenderFlag, ReactShadowNodeImpl> implements TTRCStepRenderFlagManagerInterface<FbReactTTRCStepRenderFlag> {
private final ViewManagerDelegate<FbReactTTRCStepRenderFlag> mDelegate;
public FbReactTTRCStepRenderFlagManager() {
mDelegate = new TTRCStepRenderFlagManagerDelegate<>(new ViewManagerWrapper(this));
}
...
private static class ViewManagerWrapper extends BaseViewManagerAdapter<FbReactTTRCStepRenderFlag> implements TTRCStepRenderFlagManagerInterface<FbReactTTRCStepRenderFlag> {
private final TTRCStepRenderFlagManagerInterface<FbReactTTRCStepRenderFlag> mViewManager;
private FbReactTTRCStepRenderFlagManagerAdapter(TTRCStepRenderFlagManagerInterface<FbReactTTRCStepRenderFlag> viewManager) {
mViewManager = viewManager;
}
Override
public void setTraceId(FbReactTTRCStepRenderFlag view, Nullable String traceId) {
mViewManager.setTraceId(view, traceId);
}
Override
public void setStepName(FbReactTTRCStepRenderFlag view, Nullable String stepName) {
mViewManager.setStepName(view, stepName);
}
}
}
```
Reviewed By: mdvacca
Differential Revision: D16984121
fbshipit-source-id: ea2761dda68a96ff3ba6ac64153bc4e56e396774
Summary: This diff removes the 'RCT' prefix (if it's present) from the names of the generated Java classes. The motivation is that we don't want to have any Java files having this prefix in the RN Android codebase.
Reviewed By: JoshuaGross
Differential Revision: D17123804
fbshipit-source-id: 31905d3141e0f58ea47cdbdb0cf77d2d105de9a9
Summary:
** Summary of failures encountered during the build **
Rule //fbandroid/java/com/facebook/catalyst/launcher:app_prod_debug FAILED because Command failed with exit code 1.
stderr: /java/InterfaceOnlyNativeComponentViewManagerDelegate.java:18: error: reference to setAccessibilityHint is ambiguous
mViewManager.setAccessibilityHint(view, value == null ? "" : (String) value);
^
both method setAccessibilityHint(T,java.lang.String) in com.facebook.react.uimanager.BaseViewManagerInterface and method setAccessibilityHint(T,java.lang.String) in com.facebook.react.viewmanagers.InterfaceOnlyNativeComponentViewManagerInterface match
/java/StringPropNativeComponentViewManagerDelegate.java:18: error: reference to setAccessibilityHint is ambiguous
mViewManager.setAccessibilityHint(view, value == null ? "" : (String) value);
^
both method setAccessibilityHint(T,java.lang.String) in com.facebook.react.uimanager.BaseViewManagerInterface and method setAccessibilityHint(T,java.lang.String) in com.facebook.react.viewmanagers.StringPropNativeComponentViewManagerInterface match
/java/StringPropNativeComponentViewManagerDelegate.java:21: error: reference to setAccessibilityRole is ambiguous
mViewManager.setAccessibilityRole(view, value == null ? null : (String) value);
^
both method setAccessibilityRole(T,java.lang.String) in com.facebook.react.uimanager.BaseViewManagerInterface and method setAccessibilityRole(T,java.lang.String) in com.facebook.react.viewmanagers.StringPropNativeComponentViewManagerInterface match
Errors: 3. Warnings: 0.
When running <javac_jar>.
When building rule //xplat/js/react-native-github/packages/react-native-codegen:generated_components_java-codegen_testsAndroid.
```
Reviewed By: mdvacca
Differential Revision: D17107929
fbshipit-source-id: 32bc553d450628c530e22cb13f305e3a3e0f45cd
Summary: This diff adds a missing copyright header and the `generated` annotation to the Java files generated by the JS codegen. Since we are going to check in the generated classes for the OSS components, we need to make sure the Lint formatter doesn't complain about formatting issues in those files.
Reviewed By: fkgozali
Differential Revision: D17101946
fbshipit-source-id: 1361a294b8c1538c0ea346b43ef623e843d7038d
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:
The types we were using before weren't very strict and it had been on my list to fix this. I *think* this is the right type. With Flow's type first project having these exported types will be necessary anyways so we can just use that for the ref.
Changelog:
[Internal]
Reviewed By: JoshuaGross
Differential Revision: D16930573
fbshipit-source-id: 05c1e097794633a2cefa7384c9d81ab15a63d8af
Summary:
add script which proves that new codegen gives a similar code as old one.
How it works?
While creating a rule, it generates file which is bash script returning 1 or 0 depending if result of new and old codegen are the same (it's done by redirecting output of buck's cmd).
How js script works:
1. remove empty lines
2. remove comments
3. remove imports
4. sort lines (cause order of structs might be different so let's sort everything!)
5. remove namespaces (I grouped them in new codegen)
Reviewed By: RSNara
Differential Revision: D16827988
fbshipit-source-id: 0432144161e2dcf8ed4cbe2eeea712d062e3721d
Summary: Give a more explicit message about why `number` isn't supported
Reviewed By: rickhanlonii
Differential Revision: D16926698
fbshipit-source-id: 292cb13aa11205e1350209178bde1977a2a7ad4c
Summary: Fixes an issue where we weren't traversing all the way into object properties to find imports we may need
Reviewed By: TheSavior
Differential Revision: D16896674
fbshipit-source-id: f95a4f84e51265962ddfd2aeea9da717df033879
Summary: Adds support for generating structs for object properties that are objects or arrays
Reviewed By: TheSavior
Differential Revision: D16896143
fbshipit-source-id: 6682d047e218fc774c8d0593dc2c66fe73615be7
Summary: Adds a broken fixture for arrays nested inside of objects (fixed in the next diffs)
Reviewed By: TheSavior
Differential Revision: D16896138
fbshipit-source-id: 355a71352a78ca076c1de56304908e664772c200
Summary: Adds a fixture for generating nested array objects (fix is on the next diff)
Reviewed By: TheSavior
Differential Revision: D16858626
fbshipit-source-id: c9543f4f8ecc073fd840edd94d47bdc911eaa69e
Summary: ReadableArray doesn't have a .getFloat, so casting double to floats instead. This is consistent with how the prop conversion happens as well.
Reviewed By: makovkastar
Differential Revision: D16897600
fbshipit-source-id: e8c76558f030d291960b5790a262fa49a9f358e7
Summary: Adding this fixture in a standalone diff so it is easier to see the change on the next one.
Reviewed By: JoshuaGross
Differential Revision: D16852439
fbshipit-source-id: 3f167509b78ebb95f31e44fbf40e9551d4a5500b
Summary: The codegen has a bug with arrays that have objects that contain native primitives. This diff adds a fixture to demonstrate that bug. I don't change any behavior in this diff. This is just to make the change in the next diff easier to read.
Reviewed By: JoshuaGross
Differential Revision: D16846290
fbshipit-source-id: 06f477b9e3b77cbc1faee11c78d031b45c094d31
Summary: We weren't adding the local imports recursively as well. This is a similar change as was made when creating the CppHelpers.getImports in D16759170.
Reviewed By: rickhanlonii, JoshuaGross
Differential Revision: D16840667
fbshipit-source-id: 1090a774c9e96798d5900bc0b4bf1be29b3ba090
Summary: The new support for ReadOnlyArray needs to call this new function for spreads too.
Reviewed By: JoshuaGross
Differential Revision: D16823796
fbshipit-source-id: 9de94b41cdead7ce5238c77a9e39b5daf760dfe2
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: Split buck rules for component and modules for our further convenience
Reviewed By: rickhanlonii
Differential Revision: D16803703
fbshipit-source-id: c01fb97875b43be4020edd054cad538ec8ed6861
Summary:
We're currently not supporting this kind of params
```
+sample(string):void
````
and here's special exception for it.
Reviewed By: RSNara
Differential Revision: D16708583
fbshipit-source-id: 809f9808b77108857c8363536b896089e9cb957f
Summary: Adds e2e tests for the array of object prop types in the codegen
Reviewed By: rubennorte, motiz88
Differential Revision: D16814301
fbshipit-source-id: 613f32a888451c0c1b7359133b7bf88878e36916
Summary: This diff adds a super call to `BaseViewManagerDelegate` if the current delegate doesn't have any props. We still want to set base view props, so we need `BaseViewManagerDelegate` to take care of this.
Reviewed By: rickhanlonii
Differential Revision: D16806648
fbshipit-source-id: 61963f2211cc7b2e7f5822c48bb0a7f50d909221
Summary: There are a couple of cases where props can conflict which would cause undefined behavior. We'll throw to protect against that. Now that we support type spread this is more possible without someone realizing.
Reviewed By: JoshuaGross
Differential Revision: D16813884
fbshipit-source-id: 1a8fce365ab315198abdff0de6006cfe34e84fb9
Summary: Apparently I missed one more edge case. Thanks Josh for flagging!
Reviewed By: JoshuaGross
Differential Revision: D16813354
fbshipit-source-id: 6b59bc7b18184e3aa437c3b038ffd22b0fc0ba6a
Summary: We want to be able to spread props at any level, not just the top level
Reviewed By: JoshuaGross
Differential Revision: D16812884
fbshipit-source-id: 2e710141f833a7cc7ea25a91a1523a5c43b4e02c
Summary: We want to be able to spread types that are defined in the same file.
Reviewed By: JoshuaGross
Differential Revision: D16812171
fbshipit-source-id: 7cda9869ea25f0357b3f8a3b28443407b219f04b
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: Old codegen was omitting `getConstants` if it was empty. So do our. There's no point in providing this getter in this case.
Reviewed By: RSNara
Differential Revision: D16762230
fbshipit-source-id: 721df13a00848d23108329b152115c0f0aee8eb9
Summary: `setMethodArgConversionSelector` is method for provinding generated structs for methods' params. It was exactly how in old codegen.
Reviewed By: RSNara
Differential Revision: D16784403
fbshipit-source-id: d35bc8160be62385527299a6b8e68c1159002853
Summary: It was a mistake. We should obtain value by proper key always. Previously by a mistake I hardcoded 'a'. I wasn't break anything because it wasn't used in Internationalization. However, it was a bug
Reviewed By: RSNara
Differential Revision: D16782132
fbshipit-source-id: 59f7910f2be7753c07f16f00a201de856d57e29e
Summary:
It was mistake which I fix here. Type of param in protocols should be generated struct.
See generated struct in snap. It's exactly how it was in previous codegen
Reviewed By: RSNara
Differential Revision: D16770579
fbshipit-source-id: dac9c15c5d91a41ab2d06aea416f64bd7deb4476
Summary: Property should be marked as optional not only when value is optional, but also key.
Reviewed By: RSNara
Differential Revision: D16764332
fbshipit-source-id: d56944ef263da3aa1fce3482151c761574a83be6
Summary: RTCConvert was previously imported on each protocol. It was redundant. It's enough to import it once per file
Reviewed By: RSNara
Differential Revision: D16764834
fbshipit-source-id: 9e5dcd52e38dfefa675e3e2c9f2a8f414da1a02c
Rick Hanlon
Zihan Chen (MSFT)
Oleksandr Melnykov
Logan Daniels
Joshua Gross
Eli White
Michał Osadnik