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