Add, Edit, and Delete Scheduled Events #30

New issue

Open

opened 2026-05-19 05:03:28 +00:00 by foravo_admin · 0 comments

foravo_admin commented

2026-05-19 05:03:28 +00:00

Owner

Imported from GitHub issue StanfordCS194/spr26-Team-22#53.

Source: https://github.com/StanfordCS194/spr26-Team-22/issues/53
Original author: @nriedman
Original state: open

Summary

We have an Events Dashboard where the user can see events they have scheduled with friends, and track the live status of the events. As of Demo Day 1, this is a read-only view. Ideally, users should be able to add, edit, and delete scheduled events.

Requirements

Add

A UI element in the Events Dashboard that allows the user to add an event (e.g. a "+" button in the navigation bar that triggers a full-screen sheet view).
The user should be able to cancel with no side effects.
Once the user affirms the addition, the local persistent state should be updated to show the new event, and this change should propagate to the dashbaord UI (the state of the new event should be "pending").
The invitee of the event should receive a notification that they have been invited to the event.

Edit

A UI element in the Events Dashboard that allows the user to edit an event (e.g. make each card a button that, on press, opens a full-screen sheet view to edit that event).
The user should be able to cancel with no side effects.
Once the user affirms the edits, the local persistent state should be updated to show the new details.
If necessary, affected remote users should receive notifications regarding the changes.
Decisions need to be made about what happens in the following circumstances w.r.t. the event's state and what messages need to be sent to other users (or if these edits should even be allowed):
- The user changes the name, date, time, or activity?
- The user changes which contact is invited to the event?

Delete

This will be the simplest change. Deletion comes naturally from the List view. Change the UpcomingEventsDashboard to enable swipe-to-delete, and in the onDelete closure remove the event from the ScheduledHangoutRepository. Other system components that need to react to the deleted event (e.g. the component that handles deciding when to send what notifications to other users) can subscribe to ScheduledHangout deletions using the nifty NotificationCenter feature.

Notes

The answers to "What happens after we change an event?" may cause us to reconsider how we surface the API for sending messages and booking events. For example, I can imagine that instead of a InviteService.book(for:) method that is hardcoded to take a Suggestion, we could have an Envrionment-accessible EventActions object that looks like this:

struct EventEdits {
    var title: String
    var scheduledAt: Date
    var notes: String

    init(from event: ScheduledEvent) {
        self.title = event.title
        self.scheduledAt = event.scheduledAt
        self.notes = event.notes
    }
}

@Observable
class EventActions {
    private let inviteService: InviteService
    private let modelContext: ModelContext

    init(inviteService: InviteService, modelContext: ModelContext) {
        self.inviteService = inviteService
        self.modelContext = modelContext
    }

    func addEvent(from suggestion: Suggestion) {
        inviteService.book(suggestion: suggestion)
        inviteService.sendMessage(for: suggestion)
    }

    func deleteEvent(_ event: ScheduledEvent) {
        event.prepareForDeletion(in: modelContext)
    }

    func updateEvent(_ event: ScheduledEvent, with edits: EventEdits) {
        // Free edits — just mutate, SwiftData handles the rest
        event.title = edits.title
        event.notes = edits.notes

        // Side-effecting edits — service needs to know
        if edits.scheduledAt != event.scheduledAt {
            event.scheduledAt = edits.scheduledAt
            inviteService.sendMessage(for: event)  // notify invitee of change
        }
    }
}

Then, instead of each view independently worrying about what how to orchestrate the persistence/remote messaging side-effects of messing with a scheduled hangout, the logic is centralized here and accessible from any View via the Environment. Food for thought!

Imported from GitHub issue `StanfordCS194/spr26-Team-22#53`. Source: https://github.com/StanfordCS194/spr26-Team-22/issues/53 Original author: @nriedman Original state: open  --- ## Summary We have an Events Dashboard where the user can see events they have scheduled with friends, and track the live status of the events. As of Demo Day 1, this is a read-only view. Ideally, users should be able to add, edit, and delete scheduled events. ## Requirements ### Add - A UI element in the Events Dashboard that allows the user to add an event (e.g. a "+" button in the navigation bar that triggers a full-screen sheet view). - The user should be able to cancel with no side effects. - Once the user affirms the addition, the local persistent state should be updated to show the new event, and this change should propagate to the dashbaord UI (the state of the new event should be "pending"). - The invitee of the event should receive a notification that they have been invited to the event. ### Edit - A UI element in the Events Dashboard that allows the user to edit an event (e.g. make each card a button that, on press, opens a full-screen sheet view to edit that event). - The user should be able to cancel with no side effects. - Once the user affirms the edits, the local persistent state should be updated to show the new details. - If necessary, affected remote users should receive notifications regarding the changes. - Decisions need to be made about what happens in the following circumstances w.r.t. the event's state and what messages need to be sent to other users (or if these edits should even be allowed): - The user changes the name, date, time, or activity? - The user changes which contact is invited to the event? ### Delete This will be the simplest change. Deletion comes naturally from the `List` view. Change the `UpcomingEventsDashboard` to enable swipe-to-delete, and in the `onDelete` closure remove the event from the `ScheduledHangoutRepository`. Other system components that need to react to the deleted event (e.g. the component that handles deciding when to send what notifications to other users) can subscribe to `ScheduledHangout` deletions using the nifty [NotificationCenter](https://www.hackingwithswift.com/example-code/system/how-to-post-messages-using-notificationcenter) feature. ## Notes The answers to "What happens after we change an event?" may cause us to reconsider how we surface the API for sending messages and booking events. For example, I can imagine that instead of a `InviteService.book(for:)` method that is hardcoded to take a `Suggestion`, we could have an Envrionment-accessible `EventActions` object that looks like this: ```swift struct EventEdits { var title: String var scheduledAt: Date var notes: String init(from event: ScheduledEvent) { self.title = event.title self.scheduledAt = event.scheduledAt self.notes = event.notes } } @Observable class EventActions { private let inviteService: InviteService private let modelContext: ModelContext init(inviteService: InviteService, modelContext: ModelContext) { self.inviteService = inviteService self.modelContext = modelContext } func addEvent(from suggestion: Suggestion) { inviteService.book(suggestion: suggestion) inviteService.sendMessage(for: suggestion) } func deleteEvent(_ event: ScheduledEvent) { event.prepareForDeletion(in: modelContext) } func updateEvent(_ event: ScheduledEvent, with edits: EventEdits) { // Free edits — just mutate, SwiftData handles the rest event.title = edits.title event.notes = edits.notes // Side-effecting edits — service needs to know if edits.scheduledAt != event.scheduledAt { event.scheduledAt = edits.scheduledAt inviteService.sendMessage(for: event) // notify invitee of change } } } ``` Then, instead of each view independently worrying about what how to orchestrate the persistence/remote messaging side-effects of messing with a scheduled hangout, the logic is centralized here and accessible from any View via the Environment. Food for thought!

foravo_admin added the

enhancement

label

2026-05-19 05:03:28 +00:00