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:

Current problem at checkout page solution demonstration:

Offer replaced without warning.mp4

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:

We should reuse this code
We can parametrize the current code to accept the desired:
- Title
- Message
- Buttons text (the yes/no at the print above)
- We can also show the close button if we want

From the design perspective we only need to decide how this modal will be:

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

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.

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

We need to adjust in a way that we can receive the following through params:

Heading text
Body text
Confirm and cancel labels
PS: the interface will need to be adjusted with this new props

Tip: I can se two options here:

The values 100% through params when CBA/legacy flow and when Loyalty flow (our flow)
The values that already exists could be the default value if nothings was passed as the texts are generic already

DOD-LIKE

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__)

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

Proposed changes:

Create a new useState (inside the use-redeem-promo-code-checkout.ts) that will be used to show the modal or not
- Our hook should return now this state
- We’ll need to condition the showConfirmSwitchOffersDialog prop to consider our new state based if our flag is on (enableLoyaltyOfferPromoCodeAtCheckout)
Create new methods that we’ll be used on onConfirmSwitchOffers and onCancelSwitchOffers props that already exists (cart-promo-codes.tsx, conditioned by our flag too). Our hook (use-redeem-promo-code-checkout.ts) should expose this too
- For the onCancelSwitchOffers our internal logic will only set the state to show the replace modal to false and nothing more
- For the onConfirmSwitchOffers the function that will be passed here will be responsible for the main logic: replace the offer. With that in mind:
  - Adjust the if state at applyOfferAtCheckout to:
    - Not call the removeFromCart directly
    - Here we set the modal replace (new state created at the first bullet) to true
    - Add a return statement below this state to prevent this code from running
  - Create a new function that will be used in the onConfirmSwitchOffers. There we can have the following logic:
    - First we apply the new offer at the cart
    - If the new offer was applied with success then we remove the old offer (the replaced one) using the removeFromCart that we removed/move from applyOfferAtCheckout. This is important because we can’t let the cart entries empty during the removal. This suggested order will ensure that
    - PS: It’s important to validate some things:
      - Check if the loading state is working accordingly during this new replace process
Adjust the legacy /offers legacy modal to have the yes/no button and hide the X button at the top
Adjust the title of the checkout modal to be equal the legacy /offers modal