The following details quoted are from:

...

The Sanity solution is already implemented on the following ticket:

...

Frontend analysis and tasks 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

  • A: We should not touch the highlight information that we have outside as this will always look to the Take Away/Dine in Hours (that don’t have additional slot information)

    

• We’ll keep the logic made for restaurants that closes after midnight ← Validate this with Simon/Intl

  • A: Yes

• Do we’ll need to consider other open/close rules? ← Validate this with Simon/Intl

  • A: The main point is to understand what we’ll have on Sanity. Noting else was mentioned. Logic and Sanity explanation will be below.

• For the feature to work correctly, we need to maintain a correct configuration for each field if not will be difficult to add extra logic to handle “multiple cases”: ← Validate this with Client/intl

  • Bad data (Monday example):

    • Open: 22

    • Breaking time close: 02 (Tuesday hour)

    • Breaking time opens: 05 (Tuesday hour)

    • Closes: 11 (Tuesday hour)

  • Correct data:

    • Open: 05 (Monday hour)

    • Breaking time close: 11 (Monday hour)

    • Breaking time opens: 22 (Monday hour)

    • Closes: 02 (Tuesday hour)

  • The two data are the same and the difference is that the second one (correct data) is a logical approach that facilitates the logic on the FE side.

Output of the analysis of the code and 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 againon the same adjust ← Understand what was this mistake Simon/Intl

• A: We had a meeting with Simon and he explained all the details regarding this implementation. For more details meeting recording: Separate delivery blocks - discovery-20231010_120348-Gravação de Reunião.mp4

...

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

Note: For the Store Locator page we think that will be not necessary to show the information regarding the breaking time hours as this only will work for Delivery Hours. The highlight information will be about the “Take Away/Dine in Hours” meaning that we’ll not need to pass down this info through the components.

Sanity

Task 1 - Fix the wrong texts on Sanity

...

The actual fields are wrong in Sanity. “Opens again at” is equal to breaking time start (restaurant closes) and “Closes” is equal to breaking time ends (restaurant opens).

...

• Additional Time Slot Description → Schroer, Gabriel (Deactivated)

• Opens again at → Schroer, Gabriel (Deactivated)

• Closes → Schroer, Gabriel (Deactivated)

Whitelabel App

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.

...

• Test using a console to see if the new data you be shown

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.

...

• Test using a console to see if the new data you be shown

Task 3 - Show the new additional hour 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

...

• The layout should be as described in Figma

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

Now our highlight feature needs to be adjusted to deal with this new hours information.

...

Option 1 - Keep the code that we have there and add new logic

• We’ll have new validations if we receivebreaking time opening hour AND breaking time closing hour (meaning that we’ll have the four hours). This is a way to deal with it. If we don’t have this information we’ll keep the logic that we have implemented today

  • Open’s at (1 hour to open rule):

    • Time now <=general opening hour OR (Time now >= breaking time closing hour && Time now <= breaking time opening hour)

  • Closed now:

    • Time now >= breaking time closing hour ANDTime now>= general closing hour

    • Time now <=general opening hour (out of the 1 hour to open rule)

    • Time now >= breaking time closing hour ANDTime now<= breaking time opening hour (out of the 1 hour to open rule)

  • Open now:

    • Time now >= general opening hour AND Time now <= breaking time closing hour OR Time now >= breaking time opening hour AND Time now <= general closing hour (out of the 1 hour close rule)

  • Close’s at (1 hour to close rule):

    • Time now>= general opening hour AND Time now <= breaking time closing hour OR Time now >= breaking time opening hour AND Time now <= general closing hour (inside 1 hour close rule)

Option 2 - Break down the getStoreStatus method into other methods

This method already has a high cognitive complexity:

...