Skip to content

Conversation

@mirmirmirr
Copy link
Member

The main goal of this pull request was to refactor the frontend EventInformation logic to conform with the refactored backend API. The largest changes include adding timeslots data to EventInformation, changing startTime and endTime to work as strings, and making sure all timeslots are in UTC.

Event Timeslots and Data Handling

  • Simplified expandEventRange logic. It now generates timeslots by the local day and then converts to UTC slot lists. This is similar to the previous logic, just more efficient. There were also bugs in the old version. This one fixes them.
  • Integrated timeslots into EventInformation as a persistent state for the reducer to keep track of. This way timeslots are only generated during event editing and passed around. Grid objects now read from the EventInformation timelots to generate.
    • timeslots are stored in UTC and translated whenever they are needed. EventRange data is still referenced in localtime (start date, end date, start time, end time)
  • Updated @/lib/utils/api functions to fit the new API format (with timeslots + the moved is_creator tag)

15 minute intervals and iOS TimePicker

  • Start and end times in EventRange are stored as 24-hour format strings instead of numbers. This is to allow the flexibility for users to choose times in 15 minutes intervals between the hour. Everything other component that edits the start and end times have been updated accordingly to accommodate.
  • Implemented and iOS-like timepicker in editor for time choosing purposes.

Misc Edits

  • Created constants DEFAULT_RANGE_SPECIFIC and DEFAULT_RANGE_WEEKDAY to be used throughout the codebase. There were a couple areas where default ranges were needed, so they're just consolidated here.
  • Created @/lib/utils/date-time-format as a central place for formatting anything related to time, dates, and timezones. These functions are used when converted times from the api, on the dashboard page, and others.
  • When adding availability, the buttons still displayed Update Availability and Cancel Edits even though the user was new. This has been fixed by checking initialData.display_name instead of just initialData.

@mirmirmirr mirmirmirr marked this pull request as ready for review January 9, 2026 19:59
Copilot AI review requested due to automatic review settings January 9, 2026 19:59
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This pull request refactors the event timeslot handling system to align with backend API changes. The main changes include moving timeslot generation to the frontend state, converting time ranges from numeric hours to string-based HH:mm format to support 15-minute intervals, and implementing consistent UTC handling for timeslots.

Key changes:

  • Added timeslots as persistent state in EventInformation, generated during event editing and passed through components
  • Changed time range format from number (hours) to string (HH:mm) to support 15-minute intervals
  • Centralized date/time formatting utilities and default range constants

Reviewed changes

Copilot reviewed 39 out of 40 changed files in this pull request and generated 10 comments.

Show a summary per file
File Description
src/lib/utils/date-time-format.ts New utility for timezone labels, date/time formatting, and 12/24-hour conversions
src/core/event/lib/default-range.ts Centralized default event range constants
src/core/event/lib/expand-event-range.ts New timeslot generation logic that creates UTC slots from event ranges
src/features/event/grid/lib/timeslot-utils.ts Extracted grid coordinate and cell styling utilities
src/lib/utils/api/submit-event.ts Simplified event submission to send timeslots array instead of individual date/time fields
src/lib/utils/api/process-event-data.ts Processes API responses to extract timeslots and convert time strings
src/lib/utils/api/process-dashboard-data.ts Updates dashboard data processing to use string-based times
src/core/event/types.ts Changed timeRange.from/to from number to string type
src/core/event/use-event-info.ts Updated time validation to work with string-based times
src/core/event/reducers/info-reducer.ts Auto-generates timeslots when eventRange changes
src/core/event/reducers/range-reducer.ts Uses default range constants
src/features/event/editor/time-range/time-picker.tsx New iOS-style time picker component
src/features/event/editor/time-range/selector.tsx Refactored time range selection UI with collapsible picker
src/features/event/grid/timeblocks/*.tsx Updated all grid timeblocks to use timeslots from props and utility functions
src/features/event/grid/grid.tsx Accepts timeslots as prop instead of generating internally
src/features/dashboard/components/event.tsx Uses centralized time formatting
src/app/(event)/[event-code]/*.tsx Passes timeslots through to grid components

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 43 out of 44 changed files in this pull request and generated 7 comments.


💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

@mirmirmirr mirmirmirr requested a review from jzgom067 January 10, 2026 01:18
Comment on lines +7 to +18
duration: 60,
timezone: Intl.DateTimeFormat().resolvedOptions().timeZone,
dateRange: {
from: new Date().toISOString(),
to: new Date(Date.now() + 2 * 24 * 60 * 60 * 1000).toISOString(),
},
timeRange: defaultTimeRange,
};

export const DEFAULT_RANGE_WEEKDAY: WeekdayRange = {
type: "weekday" as const,
duration: 30,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The default durations should be set to "None" initially as it was before. It's an advanced option that users should only set if they explicitly want it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The cursor state is rather inconsistent and varies a lot. It can make it difficult to figure out what you're supposed to do on the time picker. This should all be consolidated to the dragging hand on areas that you can drag, and the regular cursor on areas that you can't.

Screen.Recording.2026-01-10.at.5.03.08.PM.mov

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The height of the time picker is much shorter on desktop. Especially with all the empty space between it and the advanced options (even when expanded), I feel like it could be taller so it doesn't feel as cramped.

Desktop:
Image

Mobile:
Image

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

on my laptop screen, it fits perfectly, so i am hesitant to add any more

Screenshot 2026-01-10 at 6 57 38 PM

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It feels restrictive to only allow the user to drag or scroll, a feature from iOS I would like to see here is the ability to click on the other visible times to switch to them.

If we're trying to replicate the design, we have to replicate the functionality so people don't get frustrated when it doesn't work how they think it should.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another feature I would really like is the period switching after the hour moves between AM/PM. It allows me to get exactly what I want with less taps/clicks.

ScreenRecording_01-10-2026.17-39-31_1.mov

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[nitpick] It might also be helpful to put bounds on the times, so it's easy to just drag/scroll all the way in one direction to get the earliest/latest time.

An upper/lower bound based on the other time could also be helpful to avoid invalid time ranges, but I can see a situation where you would want to set a start time past an end time when setting the times in order.

Feel free to make this an issue to worry about later, it's just a convenience thing and perhaps it would be better discussed as a team.

Comment on lines 13 to 14
const startTime = formatApiTime(eventData.start_time, eventData.time_zone);
const endTime = formatApiTime(eventData.end_time, eventData.time_zone);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I should have been clearer about this, but my intention was that these times would be converted to the user's local time zone. This way they can understand the event time range in their context at a glance. This is why they are now returned in UTC.

This could cause times that go from a later time to an earlier, like "11 PM to 2 AM", and that's intentional. Let me know if you hate that idea.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One more note, the if the times carry over into another day then the date range for the event should follow. Make sure that's accounted for.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Create centralized "format date/time range" function Change availability API format to list of timeslots

3 participants