Table of Contents

Business problem

Today we do not have the correct status for the delivery search and all is considered as “store unavailable” and with that we don’t show the proper status for the user.

Open

Example of store-locator page

The idea is to show now at least 3 status:

• When the store is closed (unavailable)

• When the store is paused (the store will be closed but will reopen soon)

• When the store is unavailable for the selected area

Behaviors and impacts

Today the store-locator page has two modes that are controlled by the enable-delivery-address-on-same-screen flag:

• Delivery on the same page:

  Open

  

• Delivery in modal mode:

   

• The only difference between the two modes is in the visuals. The components and the code will be the same

• To easy tests: add the param to control the flag in the URL ?rbiFeature.enable-delivery-address-on-same-screen=true (or false)

Solution proposals

#Option 1 - Condition the content to be shown

As we saw before the component that holds the information to be shown is the same for the two modes (in page/modal). With that in mind, the easiest to keep the same pattern in the application will be the condition of what will be shown.

Pros

• Code consistency

• Reuse of the solution that will be already ready for the two modes

• Manutenability of the code as the code will be the same for the two modes

Cons

• I don’t see any cons here

#Option 2 - Show the new information in a modal

As we have in the checkout page or other pages, show the new alert/information in a modal.

Pros

• Code isolation as this would be in a new component (that we are creating for the “delivery closed at the moment feature)

Cons

• As we have two modes for the screen this will not be a good approach because of the following:

  • For the “delivery in modal” mode we’ll have an overlap between the modals (one modal over the other), which is not a good thing for the user experience and UI

  • To avoid this overlap we’ll need to condition this modal to be shown only in the “delivery on screen” mode

  • With the second point, we’ll need to have two separate codes to achieve the implementation that we need = bad manutenability and bad reuse of code

Tasks breakdown

The task breakdown will be based on the #Option 1 described above.

PS: the graphql task is on the backend refinement but if needed we can make this here too.

Task 1 - Extend the reducer to deal with the new necessary actions/status

• Adjust the addressReducer to have a new case for the desired new status

• Add new items in the ActionStatus enum and in the AddressModalAction type

Task 2 - Adjust the handleQuoteResult to deal with the new status

• Add a new condition in the handleQuoteResult (src/components/address-modal/index.tsx) to deal with the new status and call the dispatch to update the state used in the reducer

[Will be developed in another task] Task 3 - Refactor the <DeliveryUnavailable /> comp

PS: This task will be implemented in this https://rbictg.atlassian.net/browse/IBFEC-1158 for the “delivery closed at moment” solution. Look at the next “Task 3” below.

The idea is to transform this component into something generic that will handle the display of any error regarding the restaurant status (closed, paused and unavailable) as a dumb/presentation component.

This component is used in the addess-modal comp: src/components/address-modal/index.tsx

Option 1:

• The component will only receive what’s need to show the desired message thought new props:

  • title (string)

  • message (string | JSX.Element)

  • primaryButton (JSX.Element)

  • Adjust any point needed to make the component generic

    • We’ll keep the “Use Different Address” as secondary action button by default

  • Create a new function in the src/components/address-modal/index.tsx comp (as renderDeliveryUnavailable, for example) that will be responsible to render the component passing the correctly values to the new props based on the state.status (using a switch case, for example)

    • We’ll need to adjust the ternary operator in the PageContent render based on the renderDeliveryUnavailable return. If the renderDeliveryUnavailable return null we render the PageContent regular content.

Option 2:

• Pass only the state.status value to the component and adjust the internal code to render what’s need based on this value

DOD-LIKE

• Test the changes in the two modes (delivery on screen/modal) to guarantee that all is good

• Check if any unit test is broken with our new changes

• Test all the needed status to see if all will be rendered correctly

Task 3 - Add a new case for the exhibition delivery paused

In this task we’ll also add new feature flags for the desired status:

• const enableDeliveryPaused = useFlag(LaunchDarklyFlag.ENABLE_DELIVERY_PAUSED)

If Option 1 for the “old” Task 3 above was selected:

• Add the new case in the address modal comp (src/components/address-modal/index.tsx) for delivery paused passing the necessary values in <DeliveryUnavailable /> comp

If Option 2 for the Task 3 above was selected:

• Add a new logic inside the <DeliveryUnavailable /> comp to handle with the delivery paused scenario.