[feature] Checkout Page Price Adjustments

[sirugh]

Description

This PR uses the Cart page adjustments features (minus shipping estimator). Infact without the styling changes to the PR that is the only thing to point out - there is a Checkout Page specific Price Adjustments component since the Cart page adjustments component had the estimator.

So the major changes to this PR are styling updates. You can find reference to the specific changes in the JIRA issue.

Related Issue

Closes PWA-248.

Acceptance

Verification Stakeholders

Specification

Verification Steps

1. Add item to cart and go to /cart page. Go through price adjustments entering coupon code, gift card, and selecting some gift options. Changes to the price should update the summary.
2. Proceed to Checkout and then fill out the form to get to the third step, Payment Information.
3. Before clicking "review order", verify that the adjustments sections have carried over information from the cart page.
4. Go to local storage and delete apollo-cache-persist and refresh the checkout page.
5. Proceed through the form but don't click review order yet.
6. Enter adjustments like you did on the cart page. They should apply and update the price summary.

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

Generated by 🚫 dangerJS against 23a60b1

[soumya-ashok]

@sirugh Had a look at the work, it looks good overall. Had a couple of points to raise.

1. The delay between clicking the "remove" link on a coupon code and/or gift card and actual removal from the UI is significant, so much so that I thought the links were not functional.
2. For a coupon code that isn't valid, the current message we see is "An error occurred. Please try again". I'm not sure if an error actually occurred or if this is just the default message we get back. It would be preferable if it could say "The coupon code you entered is invalid" or similar.
3. Once a gift card has been applied, the entry remains in the field. I feel like the field should be cleared once the applied gift card appears below it. In this case I had checked the balance and applied it so there was nothing more I could do with it except to remove it.

4. I think people will understand why the coupon code field goes away after one is applied, but should we include a short line of text under the "Coupon Code" title to say that only one can be applied? I don't really want to clutter this up, but wanted to float the question.

[sirugh]

@soumya-ashok thanks for your feedback! To preface my response it seems like the backend we are using for CI is extremely slow right now, much more so than what I experienced during development. I'll have to check with @dpatil-magento to see what's happening.

The delay between clicking the "remove" link on a coupon code and/or gift card and actual removal from the UI is significant, so much so that I thought the links were not functional.

I looked into this. For gift cards we disable other interactions such as clicking "review order" or clicking "remove" on the same or other gift cards. For coupon we only disable the "review order" button but we don't disable the "remove" button for the coupon you have attempted to remove. Additionally we don't show loading spinners but we do change button backgrounds and text colors when a button is disabled. If you look closely when clicking "remove" on gift cards you can see the difference. If the disabled change is not enough of an indicator we should investigate a stylistic update for the entire application.

TL;DR - I'll make sure we disable the "remove" button on coupons when the mutation is in flight. We can modify the 'disable' styles for buttons/text for the entire app but we should do so in a different ticket/story.

For a coupon code that isn't valid, the current message we see is "An error occurred. Please try again". I'm not sure if an error actually occurred or if this is just the default message we get back. It would be preferable if it could say "The coupon code you entered is invalid" or similar.

Looks like graphql does provide a message for us: "The coupon code isn't valid. Verify the code and try again." So I'll display that message if the server response contains it to indicate that the coupon code is not valid. For other errors are you OK with the default messaging of "An error occurred. Please try again." or do you want something else? Please let me know :)

Once a gift card has been applied, the entry remains in the field. I feel like the field should be cleared once the applied gift card appears below it. In this case I had checked the balance and applied it so there was nothing more I could do with it except to remove it.

Ah I must have crossed some wires. I'll clear it after apply but not after "check balance".

I think people will understand why the coupon code field goes away after one is applied, but should we include a short line of text under the "Coupon Code" title to say that only one can be applied? I don't really want to clutter this up, but wanted to float the question.

I think it'll be self explanatory when they apply the coupon. Once the user realizes only one can be applied they can easily click "remove" and then apply a different coupon if they want. Maybe do some UAT on these options for the next UI iteration.

To summarize this all, my main asks are:

a) Let's open a ticket for text/button disabled styles to better indicate loading state.
b) What messaging do you want for the default coupon code error?
c) Can we do UAT on the "helper text" below coupon code title?

[soumya-ashok]

@sirugh

a) Let's open a ticket for text/button disabled styles to better indicate loading state

My feedback was not regarding the disabled styles actually. It is that when I click the remove button, things don't look like they registered a change. They disable after a couple of seconds of delay, but by then I've tried to click the button again because I thought nothing happened the first time. Does that paint a clearer picture? I tried to get a screen-grab for you but it won't accept my coupon code :(

b) What messaging do you want for the default coupon code error?

For coupon codes, this text works fine - "The coupon code isn't valid. Verify the code and try again."
On your question about all the other error messages, I suppose that depends on where they show up? I'd prefer for the error text to be as clear and specific to the use case as possible where we can do that. If we do need a super generic message, I can come up with one.

c) Can we do UAT on the "helper text" below coupon code title?

Yes, we could. We can leave it the way it is for now.

[sirugh]

@soumya-ashok and I spoke on bluejeans - I fixed the remove button to properly grey out/show disabled state when clicked. I also updated the invalid coupon message.

[soumya-ashok]

@sirugh All changes are UX approved

Note: If the entered gift card is invalid, we will not be clearing the input field because the user may have made a minor error in typing the number out. However, once the card has been entered and is valid, the input field will be cleared.

[tjwiebell]

Minor suggestions for cleanup that appear to have been there before you touched things. Willing to consider them optional, nice work 👍

[tjwiebell]

😎