-
Notifications
You must be signed in to change notification settings - Fork 0
Update for timeslot handling + api changes #121
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: v0.1.3
Are you sure you want to change the base?
Conversation
This reverts commit 984c6f6.
There was a problem hiding this 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
timeslotsas persistent state inEventInformation, generated during event editing and passed through components - Changed time range format from
number(hours) tostring(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.
Co-authored-by: Copilot <[email protected]>
Co-authored-by: Copilot <[email protected]>
There was a problem hiding this 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.
| 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, |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
| const startTime = formatApiTime(eventData.start_time, eventData.time_zone); | ||
| const endTime = formatApiTime(eventData.end_time, eventData.time_zone); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
Co-authored-by: Jack Zgombic <[email protected]>



The main goal of this pull request was to refactor the frontend
EventInformationlogic to conform with the refactored backend API. The largest changes include addingtimeslotsdata toEventInformation, changingstartTimeandendTimeto work asstrings, and making sure all timeslots are in UTC.Event Timeslots and Data Handling
expandEventRangelogic. 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.timeslotsintoEventInformationas a persistent state for the reducer to keep track of. This way timeslots are only generated during event editing and passed around.Gridobjects now read from theEventInformation timelotsto generate.timeslotsare stored in UTC and translated whenever they are needed.EventRangedata is still referenced in localtime (start date, end date, start time, end time)@/lib/utils/apifunctions to fit the new API format (withtimeslots+ the movedis_creatortag)15 minute intervals and iOS TimePicker
EventRangeare stored as 24-hour formatstringsinstead ofnumbers. 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.editorfor time choosing purposes.Misc Edits
DEFAULT_RANGE_SPECIFICandDEFAULT_RANGE_WEEKDAYto be used throughout the codebase. There were a couple areas where default ranges were needed, so they're just consolidated here.@/lib/utils/date-time-formatas 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.Update AvailabilityandCancel Editseven though the user was new. This has been fixed by checkinginitialData.display_nameinstead of justinitialData.