Table of Contents
Table of Contents | ||
---|---|---|
|
...
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
...
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
...
Create a new
useState
(inside theuse-redeem-promo-code-checkout.ts
) that will be used to show the modal or notOur 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
andonCancelSwitchOffers
props that already exists (cart-promo-codes.tsx
, conditioned by our flag too). Our hook (use-redeem-promo-code-checkout.ts
) should expose this tooFor the
onCancelSwitchOffers
our internal logic will only set the state to show the replace modal to false and nothing moreFor 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
directlyHere 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 fromapplyOfferAtCheckout
. This is important because we can’t let the cart entries empty during the removal. This suggested order will ensure thatPS: 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
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