Updating an event from single to multiservice and vice versa

A wedding can either be made up separate services (e.g. dinner, reception, ceremony), or not. The wedding couple decide whether they want to break down an event into services or not. Should the wedding couple choose to have multiple services, they can also decide that when a guest RSVPs, should they RSVP per service, or simply say yes or no to attending the event.

e.g. wedding event with many services (firestore/events/:eventId):

interface IEvent {
  id: string;
  name: string;
  description?: string
  multipleServiceRSVP: boolean;
  services: {
    [serviceId: string]: { name: string; date: Date; ... }
  }
}

This would allow the services to be listed on an invite. The use of multipleServiceRSVP determines whether the front should display UI for RSVPing to the event as a whole, or RSVPing per service.

e.g. wedding event no services (firestore/events/:eventId):

interface IEvent {
  id: string;
  name: string;
  description?: string
}

no services present, it will use the description to describe the event and how things would unfold. RSVPing also means that RSVPs would be treated as coming to the event, true or false

The document responsible for recording the invite is (firestore/eventGuests/:eventGuestId):

interface IEventGuest {
  id: string;
  guestId: string;
  eventId: string;
  weddingId: string;
  rsvp: boolean | {
    [serviceId: string]:  boolean;
  }
}

boolean | { [serviceId: string]: boolean; } is what records an RSVP as attending a non-multiservice event or attending specific services. If an eventGuest is marked as rsvp: true, but if the event changes to multiservice, the rsvp data for the guest will be incorrect.

What can be done to tackle this inconsistency?

So after some thought, I've come to a possible solution and conclusion.

Remove services Firstly remove the notion of services from events, and treat an event as if it were a service. The motive for services within an event was so that an invite can display a breakdown of the activities that would occur at an Event. So at the very heart of it, the breakdown of activities are in fact events, that are grouped together on an invitation.
```
interface IEvent {
id: string;
name: string;
description?: string
}
```
Use an Invitation for displaying multiple events to a guest For occasions like a bridal shower or pre-wedding gathering that require breaking down into different events/activities, create a separate Event for each activity, then create an Invitation that will display each event. This may seem like the problem is just shift from "events and services", to "invitation and events", but the key difference is an invitation cannot exist without an event. _The invitation will be created with some sort of page builder in the future._
```
interface IInvitation {
id: string;
events: string[];
//...
}
```

Wedding events will be given an object property main: true to avoid being fetched with other events

interface IEvent {
id: string;
name: string;
description?: string;
main?: true //<----- this denotes that this event belongs to the main day and shouldnt be queried with other events
}

Due to the introduction of firestore collectionGroups each event will have its own subCollection of EventGuest so RSVPs are saved against an event lowering the chances of redundant data. However an important note is that the wedding document firestore().doc('weddings/id') will also have its own subcollection for EventGuests.
```
interface IWedding {
//...
/* this determines whether rsvp for the wedding should be read
from eventGuests below, or directly from each event */
allowRsvpPerEvent: boolean;
eventGuests: IEventGuest[]
}
```

dmbrowne / wedding-planner

Updating an event from single to multiservice and vice versa #1