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
Summary: Param of function can be optional and it should have impact on native code. Inspired by old codegen
Reviewed By: RSNara
Differential Revision: D16763884
fbshipit-source-id: dab50275f902dbe4af25824bb6128d3b37fc43cd
Summary:
This diff adds support to the flow parser to parse object props to the codegen schema
This handles required and optional props, as well as required and optional object properties, WithDefault, enums, etc. Basically everything is supported that is supported at the top level
Reviewed By: TheSavior, osdnk
Differential Revision: D16759198
fbshipit-source-id: 6f501f4738f84f20a940235ba74f7bae93e64eef
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:
This diff adds snapshot updates for the new object props test fixtures whose implementation does not need to change (e.g. event emitter files will not change when object props are implemented). This is for easier reviewability in later diffs.
Notes that in the files that will change, we're temporarily filtering the OBJECT_PROPS test fixture
Reviewed By: TheSavior
Differential Revision: D16759124
fbshipit-source-id: 8aae063614f762c8bd7bf092b0d274804c38dd14
Summary: This diff adds ObjectTypeAnnotation to the codegen schema, throwing for the missing implementation sites added in the next diffs for easier review-ability. Also adds a schema fixture that is flow checked for review, but does not export it because the tests would fail
Reviewed By: TheSavior
Differential Revision: D16759109
fbshipit-source-id: 75c93623e8c1ae2003c7cc638e8e3447f0e7aa38
Summary:
This diff introduces an interface `ViewManagerDelegate` and its base implementation `BaseViewManagerDelegate`, which is used as a parent class for all view manager delegates generated by the JS codegen. Before the changes in this diff, generated delegates didn't support setting the base view properties such as background color, rotation, opacity, etc. Now it's possible to do by using `BaseViewManagerDelegate.setProperty(...)`, and since all generated delegates extend BaseViewManagerDelegate, they can just call `super.setProperty(...)` for properties they don't want to handle.
This diff also introduced a new method `ViewManager.getDelegate()`. This will allow view managers to return an instance of the delegate generated by JS and ensure that the view properties are set in a type-safe manner. If this method returns null (it does by default), we fall back to the default implementation of setting view properties using Java-generated `$$PropsSetter`
classes.
This is an example of an interface class generated by JS:
```
public interface RCTAxialGradientViewViewManagerInterface<T extends View> {
void setColors(T view, Nullable ReadableArray value);
void setLocations(T view, Nullable ReadableArray value);
void setEndX(T view, Float value);
void setEndY(T view, Float value);
void setStartX(T view, Float value);
void setStartY(T view, Float value);
}
```
This is an example of a delegate class generated by JS:
```
public class RCTAxialGradientViewManagerDelegate<T extends View, U extends BaseViewManager<T, ? extends LayoutShadowNode> & RCTAxialGradientViewManagerInterface<T>> extends BaseViewManagerDelegate<T, U> {
public RCTAxialGradientViewManagerDelegate(U viewManager) {
super(viewManager);
}
Override
public void setProperty(T view, String propName, Nullable Object value) {
switch (propName) {
case "colors":
mViewManager.setColors(view, (ReadableArray) value);
break;
case "locations":
mViewManager.setLocations(view, (ReadableArray) value);
break;
case "endX":
mViewManager.setEndX(view, value == null ? Float.NaN : ((Double) value).floatValue());
break;
case "endY":
mViewManager.setEndY(view, value == null ? Float.NaN : ((Double) value).floatValue());
break;
case "startX":
mViewManager.setStartX(view, value == null ? Float.NaN : ((Double) value).floatValue());
break;
case "startY":
mViewManager.setStartY(view, value == null ? Float.NaN : ((Double) value).floatValue());
break;
default:
super.setProperty(view, propName, value);
}
}
}
```
NOTE: What if a view manager, for instance ReactAxialGradientManager, wanted to add support for the borderRadius prop? In the old Java codegen, it would just need to create a method and annotate it with ReactProp (name = ViewProps.BORDER_RADIUS) and $$PropsSetter would call this method when a property with this name must be set. With the new JS codegen, borderRadius is a part of the basic view props, so setBorderRadius is not generated as a part of the ViewManagerInterface, so it’s not possible to set this value. I see two options: 1) add a method boolean setProperty (String propName, Object value) and let the view manager handle it in a non-type safe way (return true if it’s been handled). 2) Generate BaseViewManagerInterface which will include all basic view props and make BaseViewManager implement this interface, leaving all methods empty so that it stays compatible with the current implementation. Override these methods in a view manager that needs to handle a specific property in a custom way (so we would override setBorderRadius in ReactAxialGradientManager).
Reviewed By: mdvacca
Differential Revision: D16667686
fbshipit-source-id: 06a15a92f8af55640b7a53c5a34f40366d1be2a8
Summary:
Need to add explicit type annotations in these areas to unblock types-first architecture for Flow. These are locations the codemod could not automatically handle.
I'll call out areas I need a close eye on in the comments.
Reviewed By: panagosg7
Differential Revision: D16659053
fbshipit-source-id: 167dd2abe093019b128676426374c1c62cf71e7f
Summary:
If was breaking in cases like
```
export { x as default }
```
Reviewed By: RSNara
Differential Revision: D16689606
fbshipit-source-id: 2583c73c5ac06ea0fa8666d219e739e68fc75b12
Summary: It should always be a pointer, sorry!
Reviewed By: RSNara
Differential Revision: D16689608
fbshipit-source-id: f67d2606b5bdc169d312c1c75748c390ee5e56ed
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:
We don't want to make our codegen breaking if type is not existing. In order to it we can always fallback to Object. That's how it currently works in old codegen
#Facebook
Thare're few places in our internal code where we use `Map` or tuple in these cases
Reviewed By: RSNara
Differential Revision: D16687360
fbshipit-source-id: bf8aafd3254fc7e18ad0d58ad1a29e2beeb15bf0
Summary: Retuned value can be nullable and it need to be handled
Reviewed By: RSNara
Differential Revision: D16687359
fbshipit-source-id: 7869c4e2b1da69b680b6eade3c88e0558077b705
Summary: Add handling of `$ReadOnly`, $ReadOnlyArray`. Drop handling of params for callback (does not impact native generated node) and promises' types (does not impact native generated node). Remove typo from native codegen.
Reviewed By: RSNara
Differential Revision: D16686886
fbshipit-source-id: 26345978bbbba0cee14d00e7b5b9e5017c89a46c
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:
This uses a new helper called `dispatchCommand` that now exists on the renderer. This was added to the renderer here: https://github.com/facebook/react/pull/16085
In Paper it calls UIManager.dispatchViewManagerCommand and in Fabric it calls the c++ Fabric UIManager
Reviewed By: rickhanlonii
Differential Revision: D16578708
fbshipit-source-id: 30f9468a7fd48afb506c0ee49a460b949bc863a1
Summary: This gives a better error message when people use nullable refs for the flow type.
Reviewed By: mdvacca
Differential Revision: D16627409
fbshipit-source-id: 9ab1533b41a5a21e7557c0836feefff680e8018c
Summary: Cpp and Objcpp should not be in the same rules since codegen has different purposes. I split them into into two rules and update tests for new names.
Reviewed By: TheSavior
Differential Revision: D16599257
fbshipit-source-id: 3a8be8c0e289825f9d5db831cc2eec3d2bf9728d
Summary: In this diff I add handling optional values in constants object. Behaviour is slightly different when it comes to string, objects etc., so I add tests for every of these cases.
Reviewed By: RSNara
Differential Revision: D16599254
fbshipit-source-id: 380c5235fefeb70a521733369011e0051e18859a
Summary:
Original commit changeset: 34a8f8395ca7
The problem with the original commit was the usage of optional chaining. This diff removes the usage of optional chaining with good old fashioned null checks.
Reviewed By: rickhanlonii
Differential Revision: D16593623
fbshipit-source-id: d24cc40c85de9a2e712e5de19e9deb196003ccf2
Summary:
This diff contains bunch of minor and straightforward fixes which need to be shipped together. They are all related to integrating objCpp codegen and compiling examples.
#Facebook
I explain in comments my thoughts
Reviewed By: RSNara
Differential Revision: D16520560
fbshipit-source-id: 15392017a92f5a7ec5da71b552ec6c6904625a86
Summary: This test didn't get updated to run over all the fixtures like the others
Reviewed By: JoshuaGross
Differential Revision: D16501494
fbshipit-source-id: 4a68d60819701a9de7f1da22a66ccf807cc4490f
Summary:
We want to enable codegenNativeCommands to have a runtime fallback that will work if the babel transform is not enabled. For example, in open source until we turn it on everywhere. By listing the supported commands, we can create the necessary functions at runtime to support what we need.
A follow up diff will add that runtime behavior to codegenNativeCommands.
Reviewed By: JoshuaGross
Differential Revision: D16573450
fbshipit-source-id: 189754a567a3a5ccd34629a8dfedf808e6824e82
Summary: This name was incorrect and didn't exist
Reviewed By: JoshuaGross
Differential Revision: D16528973
fbshipit-source-id: 92b874a2b023ff89ddc4312477ab8c91c0ef2cf6
Summary: Add a test to ensure that the generated code is syntactically valid and compiles.
Reviewed By: JoshuaGross, osdnk
Differential Revision: D16518542
fbshipit-source-id: d4fadaeb29194ca38c8a99874ab304a464632894
Summary: Support command arguments that are strings
Reviewed By: JoshuaGross
Differential Revision: D16509728
fbshipit-source-id: 003aba66231d204071d043c01cb0781150d0edb9
Summary: I want a fixture with all the types, so refactoring this so future diffs in the stack are cleaner
Reviewed By: JoshuaGross
Differential Revision: D16509803
fbshipit-source-id: 1f4873701a8ff842f50976377003e1abff187278
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
Summary:
Changelog:
[General] [Changed] - Include only Java classes in zip archive of generated files for JS codegen
This diff adds one more Buck rule to copy only Java files to a temporary dir, so that the zip_rule will only package the Java classes and skip C++ files. It makes the generated code more organized and decreases the time to create the ZIP-archive.
Reviewed By: rickhanlonii
Differential Revision: D16540781
fbshipit-source-id: cbc99b5fe28b6af5375a88652cefb30e672ed527
Summary: In this this diff I follow with codegening constants structs.
Reviewed By: RSNara
Differential Revision: D16496128
fbshipit-source-id: e4140d97b378985502911b8dcd1723f153dabf00
Summary:
Changes the java props class and file names to include "ViewManager" as in:
- ExampleViewManagerInterface
- ExampleViewManagerDelegate
Reviewed By: JoshuaGross, makovkastar
Differential Revision: D16418965
fbshipit-source-id: f8b2f8fe4145c0ada9dc7c5234fcc41935783374
Michał Osadnik
Oleksandr Melnykov
Joshua Gross
Rick Hanlon
Logan Daniels
Kevin Gozali
Eli White
Jason Carreiro