The following details quoted are from: TRX-397 - Getting issue details... STATUS . To have the more updated details check on the Jira.

Context

In Portugal and Spain, many restaurants have a break in their delivery schedule during the day (for example delivery available from 12.00-16.00 and 18.30-23.30). In a previous task we worked to account for that by repurposing the dinner time open and dinner time close fields in Sanity. Now the logic is:
A. Store only has delivery time open and delivery time close fields set = continuous delivery service within these times
B. Store has delivery time open, delivery time close and dinner time open, dinner time close set = restaurant has two separate delivery blocks with dinner time open, dinner time close being the later one
We now need to display these information to the guest in the FE. We currently only display the delivery time open and delivery time close timestamps in the FE under restaurant information

Acceptance Criteria - Whitelabel

- The new delivery times and different blocks need to be displayed in the FE of our platform for the guest to know and see when delivery is available.
- Ability to Configure by brand & market if we should display the field dinner time open and dinner time close as additional slots in the FE to the guest. Field example (also see the SQL file screenshot below):
- dinnerFriOpen
- dinnerFriClose
- MDM fields are Dinner time open, dinner time close and being used in Sanity as additional time slot under delivery hours (see image below):
- If a store has only delivery time open, delivery time close set, we can display the information as they are right now
- If a store has delivery time open, delivery time close, dinner time open, dinner time close set in the system, we need to display both slots to the guest in the FE
- Designs: Guest App
- The fulfillment service that determines whether delivery is available should take the additional delivery slot hours into consideration while evaluating hours of operation.
- See this conversation for more details: https://rbidigital.slack.com/archives/C05HM8CUBL4/p1691058316671209?thread_ts=1690986623.895639&cid=C05HM8CUBL4

The Sanity solution is already implemented on the following ticket: TRX-309 - Getting issue details... STATUS

Frontend analysis and task breakdown

Figma: https://www.figma.com/file/RtD0UFtwuwXx14lbLCAPlr/Burger-King?type=design&node-id=4356%3A127400&mode=design&t=G1LocWNVCgiHSTg3-1

Reinforcing the Acceptance Criteria

If a store has only delivery time open AND delivery time close set (the default infos, without the additional time slot)
- Display the information as they are right now (in the image above the “Take Away” info)
If a store has delivery time open AND delivery time close AND dinner time open AND dinner time close (in the end, this means that we’ll need all four infos)
- Display both slots (breaking time) to the guest in the FE (the “Delivery Hours” section in the image above)
We’ll always show the information with high priority on the Store Locator page. As the Figma example the “Take Away/Dine in Hours” will decide what will be shown: ← Validate this with Simon/Intl
We’ll keep the logic made for restaurants that closes after midnight ← Validate this with Simon/Intl
Do we’ll need to consider other open/close rules? ← Validate this with Simon/Intl

Tasks breakdown

Did research in the code and discovered that we had an implementation regarding this on this PR: https://github.com/rbilabs/intl-whitelabel-app/pull/1686 but reverted here. By the revert description, the cause was “We need to revert this because of a mistake in the requirements.”

We have the option to bring the reverted PR back or work again on the same adjust:

The following solutions and tasks are based on the solution proposed by Odang, Kristoforus. Kudos to him.

Task 1: Generate missing Sanity Graphql and add additional info on `mergeRestaurantData`

In the revert PR, some of the types from the generated command were kept but we’ll need to have that again so will be good if we run the yarn apollo:generate again to see if we'll have any change and to add again what's missing.

Add new additional information to the RestaurantFragment

src/queries/sanity/restaurant.graphql - Add additional delivery information

fragment RestaurantFragment on Restaurant {
  _id
  environment
  chaseMerchantId
  deliveryHours {
    ...HoursFragment
    sunAdditionalTimeSlot {
      close
      open
    }
    monAdditionalTimeSlot {
      close
      open
    }
    tueAdditionalTimeSlot {
      close
      open
    }
    wedAdditionalTimeSlot {
      close
      open
    }
    thrAdditionalTimeSlot {
      close
      open
    }
    friAdditionalTimeSlot {
      close
      open
    }
    satAdditionalTimeSlot {
      close
      open
    }
... // rest of the file

Add a new type additionalHours on some files

Adding new types

Create a new file on src/utils/restaurant/types.ts:

export enum HourOfOperationType {
  CURBSIDE = 'curbsideHours',
  DELIVERY = 'deliveryHours',
  DINING_ROOM = 'diningRoomHours',
  DRIVE_THRU = 'driveThruHours',
}

src/types/store.d.ts:

export interface IStore {
  // ... rest of the file
  additionalHours: Record<HourOfOperationType, IStoreHoursOfOperation>;
  // ... rest of the file
};

src/state/store/hooks/utils.ts:

export const initialStoreProxyState: StoreProxy = {
  // ... rest of the file
  additionalHours: null,
  // ... rest of the file
};

src/fixtures/order.ts:

export const mockStore = {
  // ... rest of the file
  additionalHours: {} as Record<HourOfOperationType, IStoreHoursOfOperation>,
  // ... rest of the file
};

src/fixtures/store.ts:

export default (opts: Partial<IStore> = {}): IStore => {
  // ... rest of the file
 
  return {
    // ... rest of the file
    additionalHours: {} as Record<HourOfOperationType, IStoreHoursOfOperation>,
    ...opts,
  };
};

Add the new informations on mergeRestaurantData function

src/utils/restaurant/index.ts - Adding new information

export const mergeRestaurantData = ({
  rbiRestaurant,
  sanityStore,
}: IMergeRestaurantData): IStore & { available: boolean } => {
  return {
    // ... rest of the file    
    additionalHours: our new code here
  };
};

This method will be responsible for letting us get the needed data to be shown on the FE side. We can format/adjust the data from Sanity to what we want/need for the rest of the solution.

In Odang’s code, he create a placeholder to help standardize the information for the other hours information. Feel free to analyze this

Task 2: Extend Hours comp to receive the new additional information

Now that we can get with success the data from Sanity (implemented on task 1) we need to pass this down to the three components.

Pass the info to <Hours> comp (use inside StoreInfoModalcomp)

src/components/store-info-modal/index.tsx

export const StoreInfoModal = ({
  store,
}: IStoreInfoModalProps) => {
  // ... rest of the file

  return (
    <>
      // ... rest of the file
      {storeHoursBreakdown.map(
        ([shouldShow, messageId, hours = messageId]: [boolean, string, string]) =>
          shouldShow && (
            <Hours
              key={messageId}
              title={formatMessage({ id: messageId })}
              hours={store[hours]}
              additionalHours={store.additionalHours[hours]} // new line
            />
          )
      )}
      // ... rest of the file
    </>
  );
};

Add the new param to <Hours> comp and get the additional info for the current day

src/components/store-info-modal/index.tsx

const Hours = ({ title, hours, additionalHours }: IHoursProps) => {
  // ... rest of the file
  const additionalOpeningHours = additionalHours
    ? additionalHours[`${abbreviatedDay}Open`]
    : '';
  const additionalClosingHours = additionalHours
    ? additionalHours[`${abbreviatedDay}Close`]
    : '';
  const isAdditionalHoursAvailable = additionalOpeningHours && additionalClosingHours;
  
  // ... rest of the file
});

Task 3: Show the new information on the interface

Add the new infos on the <Hours> comp used inside src/components/store-info-modal/index.tsx. I’ll let this be free for those who implement this. You can also take a look at Odang’s code

Task 4: Pass the new information through our `<StoreStatus>` comp and add new logic on the `useStoreStatus` hook

… Work in progres …

Additional delivery Breaking Time hours (WIP)