Non-Booked Slots

[fadwamahmoud]

Data Model

Add one more BookingsSubCollection : nonBookedSlots

interface CustomerBookings extends CustomerBase {
  /**
   * Slots the customer has booked, keyed by slot id and containing `date` and `bookedInterval`
   */
  bookedSlots?: {
    [slotId: string]: CustomerBookingEntry;
  };
 /**
   * Slots the customer hasn't booked but attended, keyed by slot id and containing `date` and `bookedInterval`
   */
 nonBookedSlots?: {
    [slotId: string]: CustomerBookingEntry;
  };
}

Data Triggers

createAttendedSlotOnAttendance

Listens to organizations/{organization}/attendnace/{slotId}
Checks if bookedInterval = null
Writes to organizations/{organization}/bookings/{secretKey}/nonBookedSlots/{slotId}

Selectors

getNonBookedSlots

returns state.firestore.data.nonBookedSlots

Views

Inside calendar view we can add another tab for non-booked slots*

Another Solution

Change CustomerBookingEntry to account for whether or not the slot was booked and create a selector for booked: false entries

 interface CustomerBookingEntry {
  /**
   * ISO date of the booked slot (used for easier querying from store)
   */
  date: string;
  /**
   * Booked interval for particular slot
   */
  interval: string;
  /**
   * Optional personal notes for a particular booking
   */
  bookingNotes?: string;
    /**
   * Whether or not slot had been booked
   */
  booked: boolean;
}

Possible Enhancements

We could create an attendance subCollection keyed by customerId which keeps track of all the customers attendance for booked and nonBooked slots.

*: Customers could view their attendance on a separate tab which would include all attended slots; booked or not.

[delasous]

Hey, sorry for delay in feedback. Like I mentioned, I was trying to decide if one or the other of the above suggestions would make it easier for me to write logic for the "attendance variance" queries/selectors. I've decided that it doesn't, as I can use the existing Attendance collection data for my purposes.

My vote would be for the first solution, and I will throw two suggestions into the ring:

1. Renaming nonBookedSlots to attendedSlots subcollection, as this is how I am working with logic for "Attendance Variance": for a given period of time, an athlete has total booked hours, total attended hours, and the delta will be shown on the table.
2. Showing both "booked" and "attended" slots in the same Calendar View, and changing the Calendar InvtervalCard variant to indicate the difference (e.g by colour / opacity, minus the "cancel" button, and/or removing "notes" textarea). These IntervalCards are really only going to be as a past marker, they won't be engaged with in the same way upcoming cards will.

[ikusteu]

For data model, I would also go with the first solution. I was going to suggest we put them in the same document (with bookedInterval and attendedInterval), but this opens a door to infinite data trigger calls if we're not careful (update to bookedSlots updates attendance and attendance, if booking not null, updates bookedSlots). The aforementioned reasoning applies to second solution as well and we don't really want that.

I definitely agree with renaming nonBookedSlots to attendedSlots as the former is a bit misleading (@silviot's slotsByDay still, to this day, haunt my dreams like the eyeless corinthian)

So to summarise, I would go with the bookedSlots (as they are) + attendedSlots collections in bookings/{secretKey}, have the documents of both have the same interface (CustomerBookingEntry), with the only difference that the attendedSlots documents wouldn't have bookingNotes (for reasons @delasous mentioned).

As for the UI, I agree with @delasous' reasoning and would be happy to go over the current structure (of CalendarCard component) and provide some suggestions on how to easily go about creating an empty variation (maybe even use the plain IntervalCard, idk. Buut...I think that can be done later as you already have enough on your plate with the firestore work.

The enhancement...I don't really see what we gain from it, but let's keep it an open discussion.