[PWA-245] Shipping Information (Authenticated)

[tjwiebell]

Description

As an authenticated user, during checkout my saved profile information should be auto-populated during the checkout process. Information including:

• Edit contact info: should prepopulate with saved info
• Edit shipping address (display of addresses in address book and entering a new address and applying the change)
• default address book should be selected for shipping address
• If no address exists within address book (or default is selected) then standard shipping form fields should display
  Important:

Do not display temp data from shipping estimate fields. Compare gql response to MOCKED_ADDRESS to verify.

Notes

Notes from a team discussion on the use cases associated with this issue - for your reference Tommy Wiebell

• If the shopper does not have a default address saved, the "add default address" button would take them directly to the address form in a dialog and right back to the checkout review page once they were done adding the address

• All addresses added will be saved to the address book by default and the shopper will be able to remove them from the address book in the account section if they so choose

• In the case that saved addresses exist, and the shopper goes from the edit link > list of addresses and adds a new one, they will go directly back to the checkout review screen after adding a new address and bypass the list of addresses, since we think it is safe to assume that they meant to use the address they just added to checkout with

• The list of addresses would be presented in a "tab" and the 'add new address' form in a "dialog"
  On mobile, it needs to be apparent that the 'add new address' form is an overlay on the addresses list "tab"

Related Issue

• [PWA-245] Shipping Information (Authenticated)

Acceptance

Verification Stakeholders

Specification

Verification Steps

Going to outline all the different flows that will need to be tested. Can flesh out more details if it isn't clear what needs to be entered.

1. Guest Entry / Edit (verify no regressions)
2. Authenticated User - No Default Address: Form displays inline similar to Guest. New message block about entry being automatically added to book and saved as default. There should be no checkbox to not proceed that way.
3. Authenticated User - With Default Address: Default is auto selected and proceed to shipping method step.
4. Authenticated Edit Flow: Now takes you too full screen page for Address Book

Address Book Flows

1. Edit Address: Similar to Guest edit, new set as default checkbox, no email field, no messages. Edit addresses, flag one as new default, verify information is persisted on save.
2. Add Address: Similar to above but new address. Verify both add as default, and add in general.
3. Select Address: Select a new address and hit Apply. Verify view goes back to checkout with selected address applied.

Screenshots / Screen Captures (if appropriate)

Checklist

• I have updated the documentation accordingly, if necessary.
• I have added tests to cover my changes, if necessary.

[PWAStudioBot]

	Messages
📖	Access a deployed version of this PR here. Make sure to wait for the "pwa-pull-request-deploy" job to complete.
📖	DangerCI Failures related to missing labels/description/linked issues/etc will persist until the next push or next nightly build run (assuming they are fixed).
📖	Associated JIRA tickets: PWA-245.

Generated by 🚫 dangerJS against 9c8790f

[sirugh]

How did this work :o

[tjwiebell]

undefined is a perfectly valid key I guess 🤷‍♂️

[soumya-ashok]

@tjwiebell Had a look, great work overall! If we could make the following changes, it would be great!

• For a 1st time auth user without a saved shipping address the header text “Review and Place Order” should be changed to the greeting “Welcome first name!”. For subsequent auth experiences, "Review and Place Order" will work as a heading since that reflects what they need to do given that checkout is using saved information.
• For a 1st time auth user, both email and name associated with the shipping address can't be modified - they will always belong to the account holder, let's show those as "locked" / disabled fields with the inputs visible
• On the shipping address card in checkout, the pencil icon and edit text are a unit, so if we could remove the underline treatment on the text it will look less like that's the only clickable item, and seem more like a button
• Once the edit link on a card on the checkout page is clicked, it would be nice to indicate that the addresses content is a "tab" and that their original checkout context is still there - is there an animation or effect like a slide over or something do-able?
• When the user lands on the addresses list page, the current selection will have the darker outline and shadow with the edit icon visible
• The edit (pencil) icon only displays once the card is selected - so tap/click to select card and then tap/click pencil icon to edit
• If we can add an animation to the card when it receives data updates, that would be provide visual feedback on the change - both within the address view and on the checkout page
• It should not be possible to uncheck the "default address" checkbox in the address edit form - rather, if the default checkbox on a second address is checked, that is assigned as the default. It can only be a change of assignment, not a removal.
• In the new address form, the only pre-fill is Country because we're presuming that to be the major use-case. Name fields should be empty.
• When a new address is added, the selected state should be on the address just added, and not continue to be on the previous selection
• For the 4 states of the address card, here are some suggested treatments
  • Base/static - as it is now
  • Hover - the drop-shadow appears
  • Selected - the darker outline appears along with the drop-shadow
  • Focused (keyboard) - Whatever is browser default / best practice is

Question - if a new default address is assigned, should that become the 1st card on the addresses page? I'm inclined to think it should.

[sirugh]

For a 1st time auth user, both email and name associated with the shipping address can't be modified - they will always belong to the account holder

Is that really true for name? What if I want to ship to someone else?

I also find it odd that we display the email field for a user that is auth'd as it has no bearing on the cart and doesn't provide any info to them aside from where they might expect to get a receipt.

[soumya-ashok]

For a 1st time auth user, both email and name associated with the shipping address can't be modified - they will always belong to the account holder

Is that really true for name? What if I want to ship to someone else?

My understanding is that in Magento the name associated with the first default address for an auth'ed user is always the name on the Account, same for email. This is the use case where they have an account but do not yet have a default shipping address entered and this is the 1st time they are going through checkout after having created an account.

I also find it odd that we display the email field for a user that is auth'd as it has no bearing on the cart and doesn't provide any info to them aside from where they might expect to get a receipt.

We are repurposing the shipping address form from guest checkout, and are using it here to simply reiterate where the order confirmation is going to go by keeping it visible.

[revanth0212]

Nice work @tjwiebell

Here is a suggestion about the Form component. Let me know if that works.

Your current implementation of the Shipping Information component is similar to this:

  <ShippingInformation>
    <EditForm>
      <useEditForm />
      <Form>
        <Field />
        <Field />
        <Cancel />
        <Submit />
      </Form>
    </EditForm>
  </ShippingInformation>

The EditForm component and the useEditForm talon contain all the logic to handle 4 similar but different situations:

1. Guest User Address (Add/Edit)
2. Auth User Address (Add/Edit)

Each of those has differences in how the to submit is handled and what is shown for the Submit / Cancel buttons.

Due to this the talon and the component may feel bloated for a new developer when looked at.

So I was thinking about separating concerns into their own components and talons and having the EditForm handle only the presentation of the form in each of those situations. Precisely this is what I am proposing:

  <EditForm>
    <Form>
      <Field />
      <Field />
    </Form>
  </EditForm>

  <ShippingInformation>

    <GuestUserForm>
      <useGuestEditForm />
      <EditForm />
      <Cancel />
      <Submit />
    </GuestUserForm>

    <AuthUserEditForm>
      <useGuestEditForm />
      <EditForm />
      <Cancel />
      <Submit />
    </AuthUserEditForm>

    <AuthUserAddForm>
      <useGuestEditForm />
      <EditForm />
      <Cancel />
      <Add />
    </AuthUserAddForm>

  </ShippingInformation>

This is just a crude idea. Maybe you can move both the auth experiences into a single component/talon but the idea is to make the talon implementation simple and easy to change using extensions in the future.

Let me know what you think.

[revanth0212]

Is there any other way to handle this? Once we have Auth Payment Information, we will have to add another ternary operator to support this.

[tjwiebell]

My use case was just the two states so the toggle made sense. This change makes sense in the scope of Auth Payment if that will be another "tab", but I'm not familiar with that scope. There's been very little direction period about this new tab pattern, so best we get a full design before putting too much work into it.

[sirugh]

You changed the definition name but not the export - I still think could be clarified by renaming it away from default but I'll leave it up to you.

[tjwiebell]

In the scope of shippingInformation, this mutation is only ever used to set the default address on the cart, so I've renamed to setDefaultAddressOnCartMutation in defaf9f.

[dpatil-magento]

For a 1st time auth user, both email and name associated with the shipping address can't be modified - they will always belong to the account holder

Is that really true for name? What if I want to ship to someone else?

My understanding is that in Magento the name associated with the first default address for an auth'ed user is always the name on the Account, same for email. This is the use case where they have an account but do not yet have a default shipping address entered and this is the 1st time they are going through checkout after having created an account.

@soumya-ashok What If first time auth user is sending it as gift to some other address? ( Just making sure these kind of flows are considered :) )

[soumya-ashok]

@dpatil-magento - Even if the auth user is sending it as a gift, the account email is the one that receives the order confirmation as far as I understand.
They are able to add any shipping address anytime within the auth experience, first time or subsequent. If they enter someone else's address the first time, we would end up with that being saved as the default.
Is your point that the name fields should remain enabled even if the email isn't?
I feel like someone who would create an account without going through guest checkout to buy a gift for someone else is an edge case.

[dpatil-magento]

@dpatil-magento - Even if the auth user is sending it as a gift, the account email is the one that receives the order confirmation as far as I understand.
They are able to add any shipping address anytime within the auth experience, first time or subsequent. If they enter someone else's address the first time, we would end up with that being saved as the default.
Is your point that the name fields should remain enabled even if the email isn't?
I feel like someone who would create an account without going through guest checkout to buy a gift for someone else is an edge case.

@soumya-ashok Yes, just first and last name fields! But agree, it's a edge case for sure.

[soumya-ashok]

@dpatil-magento The reason I wanted to block the name fields from being edited is that the first address would be saved as their default and it seems at odds for that to be someone else's because it assumes that the default is the one they'd ship to most frequently. My preference since it is an edge case is to leave this as-is for now.