-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Woo installer: Add email field to address step #59970
Conversation
Link to Calypso live: https://calypso.live?image=registry.a8c.com/calypso/app:build-24538 |
Here is how your PR affects size of JS and CSS bundles shipped to the user's browser: Async-loaded Components (~134 bytes added 📈 [gzipped])
React components that are loaded lazily, when a certain part of UI is displayed for the first time. Legend What is parsed and gzip size?Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory. Generated by performance advisor bot at iscalypsofastyet.com. |
client/signup/steps/woocommerce-install/step-store-address/index.tsx
Outdated
Show resolved
Hide resolved
client/signup/steps/woocommerce-install/step-store-address/index.tsx
Outdated
Show resolved
Hide resolved
@@ -92,6 +110,12 @@ export default function StepStoreAddress( props: WooCommerceInstallProps ): Reac | |||
/> | |||
</CityZipRow> | |||
|
|||
<TextControl | |||
label={ __( 'Email address', 'woocommerce-admin' ) } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I saw you remove the 'woocommerce-admin'
text domain in #59876. Should we do the same here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure that was intentional. 🤔 I'll take a look.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From (shaky) memory the JS translation functions adhere to text domains strictly so we need to remove it in this case to pick up calypso translations. In PHP we have some fallbacks (I think) to handle this sort of code mixing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it! I'll remove here as well.
Co-authored-by: Konstantin Obenland <obenland@automattic.com>
Co-authored-by: Konstantin Obenland <obenland@automattic.com>
@@ -54,6 +55,21 @@ export default function StepStoreAddress( props: WooCommerceInstallProps ): Reac | |||
update( WOOCOMMERCE_DEFAULT_COUNTRY, event.target.value ); | |||
}; | |||
|
|||
// @todo: Add a general hook to get and update multi-option data like the profile. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had a look at this yesterday, was thinking instead of exposing WOOCOMMERCE_ONBOARDING_PROFILE
, exposing WOOCOMMERCE_STORE_EMAIL
at the hook level. Then inside the hook, conditionally managing access to the profile data. This should lead to some simple code in the hook but when trying I ran into issues with the get/update functions leveraging the const/types so that needs breaking first.
Not suggesting we change this now, just dumping some thoughts in case it helps when/if we change this later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@@ -43,6 +43,7 @@ export function getSiteSettingsSaveRequestStatus( state, siteId ) { | |||
woocommerce_store_city?: string; | |||
woocommerce_store_postcode?: string; | |||
woocommerce_default_country?: string; | |||
woocommerce_onboarding_profile?: array; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey! I was working on #72348, which resulted in array
being changed to Array
. I think this caused a cascade of type issues which were unfortunately not caught in this branch!
Firstly, it seems like woocommerce_onboarding_profile
might be an Object, given that it's set to Record<string, unknown>
. But beyond that, I don't think JSDoc/Typescript fully understood the array
type.
The result is that before I made changes in #72348, the return type for the getter function was "any", I think because Typescript couldn't infer the type:
wp-calypso/client/signup/steps/woocommerce-install/hooks/use-site-settings/index.tsx
Lines 56 to 66 in ea8bb7f
function get( option: optionNameType ) { | |
if ( updates[ option ] ) { | |
return updates[ option ]; | |
} | |
if ( ! settings || Object.keys( settings ).length === 0 ) { | |
return ''; | |
} | |
return settings[ option ] || ''; | |
} |
This made all the consuming code compile correctly, but once the JSDoc type gets fixed, Typescript starts inferring the correct return type. Unfortunately, the other types aren't specific enough, so I had to hardcode any
as the return type for the getter.
To fix that, I think a couple things need to happen:
- Array should probably change to Object here, unless it is an array?
- The woocommerce_onboarding_profile needs to be fully typed -- at least the parts of it used in step-store-address.
- The getter needs to conditionally infer the right type. So when onboarding profile is the input, then the type of the profile should be returned, and when the others are the input, then "string" is the return type. (This doesn't happen automatically unfortunately)
Something similar to this:
function get(option: typeof WOOCOMMERCE_ONBOARDING_PROFILE): OnboardingProfile;
function get( option: optionNameType ): string {
if ( updates[ option ] ) {
return updates[ option ];
}
if ( ! settings || Object.keys( settings ).length === 0 ) {
return '';
}
return settings[ option ] || '';
}
unfortunately, OnboardingProfile
does need to be more specific than Record<string, unknown>
, because the consumers need more type info to compile correctly. (Otherwise I would have just added the record type to fix it in that PR!)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't want to get into that myself, since I'm not familiar with the area. Is that something someone in this PR could take a look at?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't want to get into that myself, since I'm not familiar with the area. Is that something someone in this PR could take a look at?
@noahtallen Thanks for letting us know 🙌 How urgent is this fix? Is it blocking a time-sensitive change?
@daledupreez I think Serenity now owns the Woo onboarding flow, is adjusting the types here something you can pick up? Is this code still used?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope, it's not urgent! In the worst case, we just continue not having the right types here. Since (i guess) this has been working in prod for a while, it's not a customer-facing issue. I think the code itself works correctly, it's just that the types don't quite line up.
Changes proposed in this Pull Request
Testing instructions
http://calypso.localhost:3000/start/woocommerce-install/store-address?site=<siteId>
settings
API includes the email in the update to settings.Related to #57423