Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hook up fabric view component codegen #7759

Merged
16 commits merged into from
May 12, 2021
Merged

Conversation

acoates-ms
Copy link
Contributor

@acoates-ms acoates-ms commented May 11, 2021

This PR hooks up a basic ActivityIndicatorViewComponent. This is the first view component implemented that uses codegen in core, so this PR also adds the logic to run codegen for view components.

Microsoft Reviewers: Open in CodeFlow

@acoates-ms acoates-ms requested a review from a team as a code owner May 11, 2021 23:47
@acoates-ms acoates-ms added the Area: Fabric Support Facebook Fabric label May 11, 2021
#include "ViewComponentView.h"

#pragma warning(push)
#pragma warning(disable : 4244 4305)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

note 4244 is sdl, is this one that's already being fixed in core?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes there is already a PR out for this one.

@@ -0,0 +1,30 @@

/**
* Copyright (c) Facebook, Inc. and its affiliates.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This file is codegen'd. Given that this same codegen is going to be used for external components, I'll look at creating a PR in core to adjust this comment.
I agree it doesn't make sense to generate this:
facebook/react-native#31516

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks. Separately, if this file is codegen'd, shouldn't be named .g.h?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The name of the file is similarly picked by the facebook codegen.
https://github.com/facebook/react-native/blob/b2dbde36b8f9cb69b1a1f9061c7f19c895d0c317/packages/react-native-codegen/src/generators/components/GenerateComponentDescriptorH.js#L52
Maybe we should look into seeing if thats something they'd be interested in changing.

Comment on lines +19 to +29
struct OnRequestClose {

};

struct OnShow {

};

struct OnDismiss {

};
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

are these structs and the other ones what we'd call event args? If so, can they be named accordingly? e.g. RequestCloseEventArgs

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a window-ism. These are xplat classes from FB's codegen. If/when we do a higher level winrt projection of these we'd want to use that naming convention.

progressImage(convertRawProp(rawProps, "progressImage", sourceProps.progressImage, {})),
trackImage(convertRawProp(rawProps, "trackImage", sourceProps.trackImage, {}))
{}
AndroidSwipeRefreshLayoutProps::AndroidSwipeRefreshLayoutProps(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this right? should we have android properties in RNW? is there something that can be queried to filter out platform-specific apis?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a property on the original definition of the component. Ex: RCTInputAccessoryView is marked as not being supported in android. Using that would be annoying though, since we'd need to update / fork core in order to mark things as being / not being supported in windows.
https://github.com/facebook/react-native/blob/b2dbde36b8f9cb69b1a1f9061c7f19c895d0c317/Libraries/Components/TextInput/RCTInputAccessoryViewNativeComponent.js#L25

I'm assuming that all these extra props classes etc will be stripped from the final ship dll since they are not referenced anywhere.

enum ModalHostViewSupportedOrientations const rhs) {
lhs = lhs | static_cast<ModalHostViewSupportedOrientationsMask>(rhs);
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

note you can do this with DEFINE_ENUM_FLAG_OPERATORS

alternately, consider just having the one set of operators with

SafeAreaViewProps(const SafeAreaViewProps &sourceProps, const RawProps &rawProps);

#pragma mark - Props

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what are these pragmas? it doesn't look like msvc understands it?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if this should be #pragma region. Google says this may be ObjC specific.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, pragma region/endregion would be understood by VS/msvc

@@ -151,31 +162,70 @@ function generate(
*/

const generateNM2 = createNM2Generator({namespace: argv.namespace});
const generatorPropsH = require('react-native-tscodegen/lib/rncodegen/src/generators/components/GeneratePropsH')
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI that we're still on an older version of tscodegen/codegen. Zihan published a new version, with some possible changes, but I hadn't pulled it into RNW yet.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah. I keep wondering if we are going to need to pull tscodegen into rnw repo. Right now it seems to be ok with the older version. but it does worry me.

Do we have RN-core publishing the codegen pacakge in daily builds?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope. Original plan was for me to hookup nightlies for monorepo packages, but code stopped being pulled into separate packages so the urgency dropped off. There is a ready-made tscodegen that is newer than what we have rn though.

@@ -466,6 +467,11 @@
<ClCompile Include="$(ReactNativeDir)\ReactCommon\react\renderer\textlayoutmanager\TextMeasureCache.cpp" />
<ClCompile Include="$(ReactNativeDir)\ReactCommon\react\renderer\uimanager\UIManager.cpp" />
<ClCompile Include="$(ReactNativeDir)\ReactCommon\react\renderer\uimanager\UIManagerBinding.cpp" DisableSpecificWarnings="4389;4715;%(DisableSpecificWarnings)" />
<ClCompile Include="$(ReactNativeWindowsDir)codegen\react\components\rnwcore\Props.cpp" >
<ObjectFileName>$(IntDir)\codegenRnwCoreProps.obj</ObjectFileName>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OOC, why do we change the object file output for this translation unit?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't like having two cpp files with the same name. -- There is another Props.cpp in "$(ReactNativeDir)\ReactCommon\react\renderer\core\Props.cpp"

@acoates-ms acoates-ms added the AutoMerge Causes a PR to be automatically merged once all requirements are passed (label drives bot activity) label May 12, 2021
@ghost
Copy link

ghost commented May 12, 2021

Hello @acoates-ms!

Because this pull request has the AutoMerge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

@ghost ghost merged commit 36e48e2 into microsoft:master May 12, 2021
@acoates-ms acoates-ms deleted the activityind branch May 12, 2021 22:57
@jonthysell jonthysell added the New Architecture Broad category for issues that apply to the RN "new" architecture of Turbo Modules + Fabric label Mar 7, 2024
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: Fabric Support Facebook Fabric AutoMerge Causes a PR to be automatically merged once all requirements are passed (label drives bot activity) New Architecture Broad category for issues that apply to the RN "new" architecture of Turbo Modules + Fabric
Projects
Status: No status
Development

Successfully merging this pull request may close these issues.

4 participants