[chore] Checkout Page gql updates

[sirugh]

Description

Some minor refactoring of checkout page in preparation for the team.

Noteable changes:

1. Using a cart query/cache to check empty state.
2. A better loading state experience.
3. Simplifying "current step" state to read from a single, locally stored value.
4. Each step/component is now in charge of its "done editing" state so that they can each query for any existing cart data and display accordingly. For now it is represented as useState.
5. Moves price adjustments and review button within the payment info component.

Related Issue

Closes PWA-395.

Acceptance

Verification Stakeholders

Specification

Verification Steps

1. Add an item and go to checkout page.
2. Refreshing the page should remember the last step you were on. You'll see a weird UX for now because each component is responsible for rendering its "filled/done" state and that is left to later tickets.
3. You should be able to proceed through the steps and "place order".

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-395.

Generated by 🚫 dangerJS against a0b9f37

[jimbo]

Looks good. I'll have to test it out locally a bit later.

[revanth0212]

I love the stepper state but one of the important user flow is failing. Please check my comments.

[revanth0212]

I don't think Apollo Cache is the right place to store this information. For instance,

1. Login and add something to your cart. Go to the checkout page and go to the review step (Step 3).
2. Now logout.
3. As a guest add something to your cart and go to the checkout page. Instead of treating you as a new customer, it will treat you as an existing customer and take you directly to the review step (Step 3) even though you haven't entered the prev step's data.

Either clear the data:

1. when the user logs out
2. when the cartId changes
3. when the user leaves the checkout page

or do not use Apollo's cache, use local state so every time you go to the checkout page, it has to treat you as a new customer even though the component has all the data it needs to render the Step (Assuming that is the intended process).

[sirugh]

I discussed the UX with @soumya-ashok and she said that a user, upon a refresh, should return to the step that they were last on. So we do need some sort of persistence layer that "remembers" where the user was. And that can come from the server or it can come from some local state that is simply persisted after a user proceeds through a step.

As for when to clear the data, I added an unmount effect that should have set the value, but I would also have expected the user logging out to clear the cache entirely. I'm surprised that it persisted the checkout step. I'll add the cartId change suggestion to the effect and I'll test the user log out scenario myself to see what I need to do. Thanks!

[sirugh]

Ok, instead of taking care of this here I think we should try to solve the larger problem of our cache not resetting on logout. I opened https://jira.corp.magento.com/browse/PWA-457 for this.

That said, I don't think your step 3 is actually occurring, or at least I don't see how it did. The checkout page resets the step on unmount so when you left the page to add a new item to your cart the step should have been reset to 1.

[revanth0212]

I am able to reproduce it. Let's deal with this in PWA-457.

[sirugh]

Your video suggests a bug - I'll fix it in the PR if I can.

[revanth0212]

Shouldn't these couple lines of code go into a talon?

And I am not sure if you can replace doneEditing for a data query because the presence of data is not the same as the completion of the step which doneEditing signifies.

For instance, if a logged-in user lands at the checkout page and if you query for the data, you will get it back if the user has default shipping and payment information set for their account. Unless if the data you are talking about is cart scoped in which case, you are fine.

[sirugh]

Shouldn't these couple lines of code go into a talon?

Yep! These were just temporary additions. I assumed whomever took the component ticket would move the logic for this component into a talon.

And I am not sure if you can replace doneEditing for a data query because the presence of data is not the same as the completion of the step which doneEditing signifies.

This state was simply meant to signal whether to render in "edit mode" or in "read only mode". If the cart has payment information already, this component should render as if it was in read only mode. Same for the rest of the components.

[revanth0212]

If the data is cart scoped then we are good.

[tjwiebell]

@sirugh - Ran into two things QA'ing:

1. Price Summary is flowing below the Review Order button

2. Got into a weird state where review and order were showing up at the same time.

• Login with Customer Account and add things to cart (I had two configurables, one simple)
• Go to /checkout and step through to receipt
• Add another item to your cart and go back to /checkout
• Issue: Component in state where review and order were both rendering

[sirugh]

Price Summary is flowing below the Review Order button

The problem is that the "review order" button is a child of the payment information since it cannot be enabled until payment information is completed. The price summary is a sibling to payment information, not a child, so the positioning gets tricky. When we're in desktop view, it doesn't matter, order summary is always on the right. But when we collapse to a single column, how do I control the order of the price summary and the payment info components?

Got into a weird state where review and order were showing up at the same time.

This is because the "done" state is actually up to the components. If you refresh the page or go back to the page I assume that the data has been submitted and the components will render in their correct views ie "edit" or "read only".

To add to this, guest and auth checkout have different flows, which is confusing to develop against.

For a guest, on your first visit to checkout you see a blank form and the shipping info form. If you fill out shipping info, it turns into a "read only" card view and you are shown the next entry form for shipping methods.

For auth, on your first visit to checkout, all of the sections are cards with an "edit" button.

I really wish these two scenarios were not so different for the same page.

[tjwiebell]

QA Approved ✅

Will add acceptance criteria to those component Stories.