Table of Contents

...

Problem to be solved

When we bring the loyalty offer promo code flow to the checkout page we forgot to think in the offer replace scenario. In the legacy /offers page when the user tried to apply an offer when already have some offer applied will have this:

...

• Problems showed in the video above:

  • The offer was replaced without warning the user

  • In this case the two offers had the same title and subtitle (please disregard that)

  • The user needs to decide if he wants to replace the offer or not and the user need to know what will happen when he tried to user another promo code

Discovery and solution proposal

Discovery

I discover that the CBA/legacy checkout offers code already has a modal to show when replacing an offer:

...

Considerations

• Today, the primary and secondary buttons are fixed to the code. If we want to not show some of the buttons, we’ll need to condition the code to be more flexible and handle with this

Proposal

With this discover in mind:

...

• Texts in general

• What buttons we’ll have

• We’ll show the close button (X at the top) or not?

• We’ll keep the same texts as we have on the /offers page to keep the consistency?

How will be the design solution

• We’ll adjust the title of the modal that already exists at checkout to be equal to the legacy /offers modal

• We’ll adjust the legacy /offers modal to show the yes/no button to be equal to the modal that we have on the cart page

• We’ll adjust the legacy /offers modal to not show the X close button at the top to be equal to the modal that we have on the cart page

  Image Added

Solution flow

...

Acceptance criteria

• If the user wants to apply a new offer after already having one applied to the cart, we need to show a modal asking for permission to replace the current offer

• If the user clicks at yes/confirm we should replace the current offer with the new one added

• If the user clicks in no/cancel/X at the top we should do nothing. We’ll only close the modal, and the current offer will remain added to the cart as before

• If the user is at the cart in a scenario where he only has the offer at the cart entry (without other items/products) we need to ensure that the user will stay at the cart during the replacement process

• Respect the design UI defined above. This was validated/approved by the design team

• If the user started the flow through the legacy flow but decided to apply another offer at the checkout page the replace logic should work as expected

...

Tech refinement breakdown

In my opinion, as we already have this dialog at the legacy promo code at checkout, we need to reuse it.

Task 1: adjust cart-promo-codes.view.tsx to accept modal values through params

PS: The final solution was more simple than what’s suggested here. I did not need to create new params because I standardize things.

File to be changed: frontend/src/pages/cart/cart-promo-codes/cart-promo-codes.view.tsx

...

• The solution should be reusable and flexible

• We need to ensure that the existent unit tests will not be affected by the changes (available at frontend/src/pages/cart/cart-promo-codes/__tests__)

Task 2: Adjust use-redeem-promo-code-checkout.ts hook to return necessary information for the extended modal

Files to be changed:

• frontend/src/pages/cart/cart-promo-codes/cart-promo-codes.tsx

• frontend/src/state/loyalty/hooks/use-redeem-promo-code-checkout.ts

...