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:

• 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

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 who 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 at the /offers page to keep the consistency?

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

Tech refinement breakdown

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

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

Task 2: 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

Proposed changes:

• Create a new useState 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). 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. This order will ensure that

      • PS: It’s important to keep some things:

        • Check if the loading state is working accordingly during this new process

DOD-LIKE

• Follow the acceptance criteria and run some manual tests to guarantee that all is working as expected

• You can use new states if necessary but let’s avoid this if unnecessary

• Adjust/add new tests to the frontend/src/state/loyalty/hooks/tests/use-redeem-promo-code-checkout.test.ts