Conversation
0d97ed3 to
10528f7
Compare
| friendsAttending: [], | ||
| isRsvped: false, | ||
| isSaved: false, | ||
| isRsvped: overrides.isRsvped ?? false, |
There was a problem hiding this comment.
This looks like it can make the same event report different state depending on which tab it came from. For example, an event that's both saved and RSVP'd gets isRsvped: true in the RSVP list but isSaved: false, while the Saved list gets the opposite. Current staging already enriches My Events from the user's actual save/RSVP state (along with tags/friends), so can we preserve that enrichment here instead of overriding one flag per list?
| }).format(new Date()); | ||
| } | ||
|
|
||
| function EventCard({ event }: { event: FeedEvent }) { |
There was a problem hiding this comment.
Can we keep using the shared EventCard here rather than introducing a separate My Events card? Current staging already supports the My Events layout through the shared card, which keeps save/RSVP behavior and event data consistent across Explore, Event Detail, and My Events. This version also falls back to a free food tag when there are no tags and generates placeholder attendee avatars, so the UI can display data that isn't actually true for the event.
| const next = !isRsvped; | ||
| setIsRsvped(next); | ||
| startTransition(async () => { | ||
| const result = await toggleRsvp(event.id); |
There was a problem hiding this comment.
This optimistically flips isRsvped before the server request, but there's no failure handling. If toggleRsvp rejects, the UI stays flipped even though the DB didn't change. Can we either roll the optimistic update back in a catch, or reuse the existing shared My Events/EventCard mutation flow from staging that already keeps the UI consistent on failures?
angelina-ji
left a comment
angelina-ji
left a comment
There was a problem hiding this comment.
The MVP direction makes sense, but there are a few correctness regressions from current staging that we should fix before merging. In particular, My Events can report inconsistent saved/RSVP state, this reintroduces a separate event-card implementation with placeholder data, and RSVP failures can leave the client out of sync with the DB. I left comments inline. Also, can we remove the accidental apps/TheForum-clean gitlink and generated tsconfig.tsbuildinfo from this PR before merging?
2 participants
Summary
This PR refocuses My Events on the MVP: students can track the events they care about, without exposing organizer/event-management flows.
It prioritizes saved and RSVP'd events, hides the created-event experience from the main MVP path, and keeps saved/RSVP state consistent with Explore and Event Detail.
Checklist
My Events prioritizes saved events and RSVP'd events
Created events are hidden or visually deprioritized for MVP
Empty states are clearer for users with no saved/RSVP'd items
Saved/RSVP state matches Explore and Event Detail behavior
Event cards reflect real saved/RSVP state instead of stale/mock UI
QA covers save/RSVP consistency and empty states
QA Notes
Seed a user with saved events and confirm they appear in My Events
Seed a user with RSVP'd events and confirm they appear in My RSVPs
Save an event from Event Detail and confirm it appears in My Events
RSVP to an event from Event Detail and confirm it appears in My Events
Test the empty state for a user with no saved/RSVP'd events
Confirm saved and RSVP states are consistent across Explore, Event Detail, and My Events
Demo video
https://drive.google.com/file/d/18iJnM72uIzEBL565pBkXMyZrJ4O1PZw1/view?usp=sharing
Notes
Created-event UI was intentionally removed or deprioritized to keep the MVP focused on student event tracking.
This does not introduce organizer/event-management flows into My Events.