Table of Contents

...

• 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

...

• 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:

...

From the design perspective we only need to decide who 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 at 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

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 keep 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

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