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

Separate Phone and Address settings #1025

Merged
merged 19 commits into from
Sep 30, 2021
Merged

Conversation

tomalec
Copy link
Member

@tomalec tomalec commented Sep 24, 2021

Changes proposed in this Pull Request:

  • Add placeholder mixin, (659d29d)
    to make it easier to add preloaders more subtle than spinners.
    (Copied the code from woocommerce/woocommerce-admin@9f68059/packages/style-build/abstracts/_mixins.scss#L22-L35)

  • Add support for custom appearance to AccountCard (a7286c2)
    So we could provide any title when needed.

  • Split EditContactInformation, (568bb3e, e836e5e)
    into EditPhoneNumber and EditStoreAddress.

  • Separate preview mode of StoreAddressCard and PhoneNumberCard into separate components. (c21c74c, bc3b635, 55f63d0, 8f349e7)
    Extract shared code into ContactInformationPreviewCard.
    Simplify the logic. Change "Edit" to internal link.

  • This PR changes "Edit" buttons to be regular links, so they could be ctrl + clicked, and navigated with browser built-in features.

Addresses #962 (comment)

Screenshots:

loading

Detailed test instructions:

Happy path

  1. Go to the settings page /wp-admin/admin.php?page=wc-admin&path=%2Fgoogle%2Fsettings
  2. Wait for the phone number and address to load correctly
  3. Check that the page looks like in the designs
  4. Click the "Edit" button by the "Phone number"
  5. Go back to 1., Click the "Edit" button by the "Store address"

Missing contact info.

This is quite hard to achieve with newly created accounts. Ideally, you should have an old account w/o a store/phone address.

Different store address
  1. Go to Woo settings /wp-admin/admin.php?page=wc-settings
  2. Change the address to something else than the current one.
  3. Go to the settings page /wp-admin/admin.php?page=wc-admin&path=%2Fgoogle%2Fsettings
  4. You should eventually see the warning about the missing store address.

address warning

Mocked missing phone number
  1. Change /js/src/data/actions.js#L521 to data: { ...data, phone_number: '' },`.
  2. npm run dev
  3. Go to the settings page /wp-admin/admin.php?page=wc-admin&path=%2Fgoogle%2Fsettings
  4. You should eventually see the warning about the missing phone number.
    phone warning

Changelog entry

Split contact information settings page to phone and address settings.

Additional notes

  • <ContactInformationPreviewCard> sets aria-busy only on the preloader, I think it should be set on the entire card, but I'm not sure how to achieve it given we don't have the reference to the Card's container DOM element, and React does not expose something like the native ElementInternals.

To be done later, in separate PRs

into `EditPhoneNumber` and `EditStoreAddress`.

Addresses #962 (comment)
to simplify the logic, change "Edit" to internal link.
So we could provide any title when needed.
when the data is missing. So they could show links to separated pages.

Adjust `StoreAddressCardPreview` to show profiled warning.
To be shared with `PhoneNumberCard` preview.
Show a warning when the address is different than the WC one.
@tomalec tomalec marked this pull request as ready for review September 27, 2021 16:25
@tomalec tomalec self-assigned this Sep 27, 2021
@tomalec tomalec requested a review from a team September 27, 2021 16:25
@tomalec tomalec changed the title WIP: Separate Phone and Address settings Separate Phone and Address settings Sep 27, 2021
Base automatically changed from feature/962-integrate-phone-verifi-api to develop September 28, 2021 03:28
isSecondary
iconSize={ 16 }
iconPosition="right"
href={ editHref }
Copy link
Member

Choose a reason for hiding this comment

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

💅
It provides better accessibility but makes browser load the next page from the HTML document. Maybe it could take the same way as the "View Reports" button.

<Link href={ getNewPath( null, '/google/reports' ) }>
<Button isPrimary>View Reports</Button>
</Link>

Copy link
Member Author

@tomalec tomalec Sep 28, 2021

Choose a reason for hiding this comment

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

Thanks for catching this!

It seems to be linked to a more generic problem. Another one in the batch of WC vs WP Links.
I created an issue in WC-admin repo.

To me <Link><Button> still has a serious A11Y issue, with being seen as "Edit - button" instead of "Edit - visited link".
I'll create an issue in our repo as well, to solve it somehow for all internal button links.
#1027

Copy link
Member Author

Choose a reason for hiding this comment

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

<Link>Button> -> <a><button> is also an invalid HTML, so I'd leave it as is, and try to fix it sooner than later in #1027, by cloning wc-admins wcAdminLinkHandler to AppButton.

Copy link
Member

Choose a reason for hiding this comment

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

try to fix it sooner than later in #1027, by cloning wc-admins wcAdminLinkHandler to AppButton.

Thanks! I also think it's feasible.

@@ -10,7 +10,8 @@ export const subpaths = {
editFreeListings: '/free-listings/edit',
editCampaign: '/campaigns/edit',
createCampaign: '/campaigns/create',
editContactInformation: '/edit-contact-information',
Copy link
Member

Choose a reason for hiding this comment

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

Sorry🙏 , I forgot to list a corresponding URL reference. It needs to change as well.

protected function get_contact_information_setup_url(): string {
return admin_url( 'admin.php?page=wc-admin&path=/google/settings&subpath=/edit-contact-information' );
}

Copy link
Member Author

Choose a reason for hiding this comment

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

Ah, sorry, I got it on my paper to do list, but forgot about it.

I think, the best we can do now, given, there is no single contact information page, is to point merchants to the overall settings page.

Copy link
Member Author

Choose a reason for hiding this comment

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

Or do you think we should have two separate notes now?

Copy link
Member

Choose a reason for hiding this comment

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

I think, the best we can do now, given, there is no single contact information page, is to point merchants to the overall settings page.

I was thinking about it in the same way.

Or do you think we should have two separate notes now?

I think this would be adjusted later. According to Figma, after the phone verification state being available from Google end, there will be a new notification box and dedicated account issue that point to the edit phone number subpage in Settings.

href={ editHref }
text={ __( 'Edit', 'google-listings-and-ads' ) }
eventName={ editEventName }
eventProps={ { path: getPath(), subpath } }
Copy link
Member

Choose a reason for hiding this comment

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

📝 +❔
<ContactInformationPreviewCard> is only used in the main settings page after this PR. The subpath is always undefined here. And it also depends on whether the relevant #1025 (comment) has further adjustment. Maybe there's no need to have this tracking event prop.

Copy link
Member Author

Choose a reason for hiding this comment

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

My mental model was that ContactInformationPreviewCard is a component, which means it should not impose, or be aware apriori, where/at what URL it will be used.

Therefore it should assume it could be used anywhere on a shallow or deep page.


BTW, I was thinking that maybe we should add this path, [subpath] props on a generic level to all props, as we already have it or context on the majority of events.
IMHO, it's quite easy to get and gives quite detailed information to a tracks consumer.

Copy link
Member

Choose a reason for hiding this comment

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

My mental model was that ContactInformationPreviewCard is a component, which means it should not impose, or be aware apriori, where/at what URL it will be used.

Therefore it should assume it could be used anywhere on a shallow or deep page.

Got it.

What I thought before was that it might always be undefined under the use cases we known and if there are any further adjustments from the #1025 (comment). So it could be a bit strange to just look at the code if the "always be undefined" happened.

Considering that a component shouldn't be imposed where it will be used, I thought there's a common way that merges a react prop eventProps given from consumer sides.

But we can get the clue of subpath from the tracking README and have the subsequence adjustments - 54aea65 and 1db2271. I think it should be ok for now.

Copy link
Member Author

Choose a reason for hiding this comment

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

Also, if we would have solved routing in a sense that path could be as well /settings, /settings/store-address, /settings/store-address/coordinates, without the need of separate query param for every level, the problem would be solved without a need of picking those props in all the places.

Copy link
Member Author

Choose a reason for hiding this comment

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

I made a proposal/POC/RFC at #1031

@tomalec tomalec added the type: technical debt - external devX This issue/PR suffers from the ergonomics of external tools/dependencies label Sep 28, 2021
@tomalec
Copy link
Member Author

tomalec commented Sep 29, 2021

@eason9487 I addressed or commented on all your comments, could you take this PR for another round?

@tomalec tomalec requested a review from eason9487 September 29, 2021 18:22
Add the actual code and tracking readme changes, as the changes made before in
54aea65
changed only JSDoc.

Addresses #1025 (comment).
Copy link
Member

@eason9487 eason9487 left a comment

Choose a reason for hiding this comment

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

Tested locally and works well. LGTM.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: technical debt - external devX This issue/PR suffers from the ergonomics of external tools/dependencies
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants