fix: Deprecate old datetime picker #265
Conversation
WalkthroughThis pull request introduces significant changes to date handling across the application. The primary modifications involve removing the Changes
Possibly related PRs
Suggested reviewers
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
packages/ui/src/datetime-picker.tsx (1)
661-670: LGTM! Well-implemented locale-aware hour format detection.The
getHourCyclefunction elegantly determines the hour format using the browser's Intl API, providing a good user experience by respecting system preferences.Consider caching the result to avoid repeated calculations, as system preferences rarely change during a session.
apps/webservice/src/app/[workspaceSlug]/(app)/_components/release-condition/ReleaseCreatedAtConditionRender.tsx (1)
12-13: Consider adding date validation.While the current implementation is clean, consider adding validation to handle potential invalid date inputs gracefully.
const setDate = (value: Date) => - onChange({ ...condition, value: value.toISOString() }); + onChange({ + ...condition, + value: value instanceof Date && !isNaN(value.getTime()) + ? value.toISOString() + : condition.value + });apps/webservice/src/app/[workspaceSlug]/(app)/_components/resource-condition/ResourceCreatedAtConditionRender.tsx (1)
12-13: Consider adding Date object validation.The
setDatefunction assumes the input is always a valid Date object. Consider adding validation to handle potential edge cases.const setDate = (value: Date) => - onChange({ ...condition, value: value.toISOString() }); + onChange({ + ...condition, + value: value && !isNaN(value.getTime()) + ? value.toISOString() + : null + });
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (14)
apps/webservice/package.json(0 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/_components/environment-drawer/Overview.tsx(0 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/_components/environment-policy-drawer/RolloutAndTiming.tsx(2 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/_components/filter/DateConditionRender.tsx(3 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/_components/job-condition/JobCreatedAtConditionRender.tsx(1 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/_components/release-condition/ReleaseCreatedAtConditionRender.tsx(1 hunks)apps/webservice/src/app/[workspaceSlug]/(app)/_components/resource-condition/ResourceCreatedAtConditionRender.tsx(1 hunks)packages/ui/src/date-time-picker/calendar.tsx(0 hunks)packages/ui/src/date-time-picker/date-field.tsx(0 hunks)packages/ui/src/date-time-picker/date-segment.tsx(0 hunks)packages/ui/src/date-time-picker/date-time-picker.tsx(0 hunks)packages/ui/src/date-time-picker/time-field.tsx(0 hunks)packages/ui/src/date-time-picker/useForwardedRef.tsx(0 hunks)packages/ui/src/datetime-picker.tsx(2 hunks)
💤 Files with no reviewable changes (8)
- apps/webservice/package.json
- apps/webservice/src/app/[workspaceSlug]/(app)/_components/environment-drawer/Overview.tsx
- packages/ui/src/date-time-picker/useForwardedRef.tsx
- packages/ui/src/date-time-picker/date-segment.tsx
- packages/ui/src/date-time-picker/date-time-picker.tsx
- packages/ui/src/date-time-picker/time-field.tsx
- packages/ui/src/date-time-picker/date-field.tsx
- packages/ui/src/date-time-picker/calendar.tsx
🧰 Additional context used
📓 Path-based instructions (6)
apps/webservice/src/app/[workspaceSlug]/(app)/_components/resource-condition/ResourceCreatedAtConditionRender.tsx (1)
Pattern **/*.{ts,tsx}: Note on Error Handling:
Avoid strict enforcement of try/catch blocks. Code may use early returns, Promise chains (.then().catch()), or other patterns for error handling. These are acceptable as long as they maintain clarity and predictability.
apps/webservice/src/app/[workspaceSlug]/(app)/_components/job-condition/JobCreatedAtConditionRender.tsx (1)
Pattern **/*.{ts,tsx}: Note on Error Handling:
Avoid strict enforcement of try/catch blocks. Code may use early returns, Promise chains (.then().catch()), or other patterns for error handling. These are acceptable as long as they maintain clarity and predictability.
apps/webservice/src/app/[workspaceSlug]/(app)/_components/environment-policy-drawer/RolloutAndTiming.tsx (1)
Pattern **/*.{ts,tsx}: Note on Error Handling:
Avoid strict enforcement of try/catch blocks. Code may use early returns, Promise chains (.then().catch()), or other patterns for error handling. These are acceptable as long as they maintain clarity and predictability.
packages/ui/src/datetime-picker.tsx (1)
Pattern **/*.{ts,tsx}: Note on Error Handling:
Avoid strict enforcement of try/catch blocks. Code may use early returns, Promise chains (.then().catch()), or other patterns for error handling. These are acceptable as long as they maintain clarity and predictability.
apps/webservice/src/app/[workspaceSlug]/(app)/_components/filter/DateConditionRender.tsx (1)
Pattern **/*.{ts,tsx}: Note on Error Handling:
Avoid strict enforcement of try/catch blocks. Code may use early returns, Promise chains (.then().catch()), or other patterns for error handling. These are acceptable as long as they maintain clarity and predictability.
apps/webservice/src/app/[workspaceSlug]/(app)/_components/release-condition/ReleaseCreatedAtConditionRender.tsx (1)
Pattern **/*.{ts,tsx}: Note on Error Handling:
Avoid strict enforcement of try/catch blocks. Code may use early returns, Promise chains (.then().catch()), or other patterns for error handling. These are acceptable as long as they maintain clarity and predictability.
🔇 Additional comments (8)
apps/webservice/src/app/[workspaceSlug]/(app)/_components/filter/DateConditionRender.tsx (2)
15-15: LGTM! Type simplification improves code clarity.
The change from DateValue to Date type simplifies the interface by using standard JavaScript Date objects.
56-60: LGTM! DateTimePicker implementation is properly configured.
The component is correctly configured with:
- Direct Date object handling
- Minute-level granularity for precise filtering
- Proper styling with rounded corners
packages/ui/src/datetime-picker.tsx (1)
752-752: LGTM! Proper integration of the hour cycle detection.
The hour cycle detection is correctly integrated into the component's logic.
apps/webservice/src/app/[workspaceSlug]/(app)/_components/job-condition/JobCreatedAtConditionRender.tsx (1)
12-13: LGTM! Consider documenting timezone behavior.
The simplified date handling implementation looks good. However, since toISOString() always converts to UTC, it would be helpful to document this behavior for maintainability.
Let's verify that this date handling approach is consistent across other condition components:
✅ Verification successful
Date handling is consistent across components
The verification shows that the date handling approach using toISOString() is consistently implemented across all date-related condition components:
JobCreatedAtConditionRender.tsxReleaseCreatedAtConditionRender.tsxResourceCreatedAtConditionRender.tsx
All components use the same pattern:
const setDate = (value: Date) =>
onChange({ ...condition, value: value.toISOString() });No remaining DateValue usages were found, confirming the complete migration to the new date handling approach.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for consistent date handling across condition components
# Expected: All condition components should use similar date handling approach
# Search for date handling in condition components
rg -A 3 "setDate.*=.*\(.*Date\)" "apps/webservice/src/app/**/condition"
# Search for any remaining DateValue usage that might need updating
rg "DateValue" "apps/webservice/src/app/**/condition"
Length of output: 281
Script:
#!/bin/bash
# Let's try searching in the entire repository for condition components and date handling
# First, find the condition components
fd "Condition.*\.tsx$" apps/webservice
# Then, search for date handling patterns in the codebase
rg -A 3 "setDate.*=.*\(.*Date\)" apps/webservice
# Search for any remaining DateValue usage
rg "DateValue" apps/webservice
Length of output: 5488
apps/webservice/src/app/[workspaceSlug]/(app)/_components/release-condition/ReleaseCreatedAtConditionRender.tsx (1)
12-13: Verify timezone handling with the simplified date conversion.
The change to use Date.toISOString() looks good and aligns with the removal of @internationalized/date. However, we should verify that this doesn't affect timezone-sensitive operations elsewhere in the application.
✅ Verification successful
Based on the results, I can now generate the final response:
The timezone handling is safe with the simplified date conversion
The codebase shows a clear separation of concerns for timezone handling:
- UI components use
Intl.DateTimeFormatfor display formatting - Server-side (in
job.ts) explicitly handles timezone conversions where needed - The
toISOString()usage in this component is appropriate as it's used for data storage/transmission, not display
The change aligns with the codebase's pattern where:
- ISO strings are used for data persistence/transmission
- Explicit timezone conversions happen at the database layer
- Display formatting is handled by the UI layer using proper localization
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for timezone-dependent code that might be affected by this change
# Look for timezone-related code in the codebase
rg -A 3 "timezone|getTimezoneOffset|Intl\.DateTimeFormat|toLocaleString"
# Look for other uses of toISOString to ensure consistent date handling
ast-grep --pattern 'toISOString()'
Length of output: 2061
apps/webservice/src/app/[workspaceSlug]/(app)/_components/resource-condition/ResourceCreatedAtConditionRender.tsx (1)
12-13: Verify timezone handling implications.
The simplified date handling looks good, but we should verify that removing explicit timezone handling doesn't affect date accuracy across different timezones.
✅ Verification successful
Based on the shell script results, I can now generate the final response:
Date handling implementation is consistent and safe
The codebase shows a consistent pattern of date handling:
- All components use
toISOString()for storing dates, ensuring UTC timezone consistency - Timezone-aware display is handled properly through:
date-fnsfor formatting dates in the UI- Explicit timezone handling where needed (e.g.,
JobHistoryChart.tsxuses browser's timezone) - Server-side timezone conversion in the API (packages/api/src/router/job.ts)
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for timezone-related code and date handling patterns
# to ensure consistency across the application
# Check for other date handling implementations
rg -A 3 "toISOString\(\)" --type ts
# Look for timezone-specific handling
rg "timezone|getTimezoneOffset" --type ts
# Check for date-fns or similar utility usage
ast-grep --pattern 'import { $_ } from "date-fns"'
Length of output: 9818
apps/webservice/src/app/[workspaceSlug]/(app)/_components/environment-policy-drawer/RolloutAndTiming.tsx (2)
10-10: LGTM: Import path updated
The import path change aligns with the PR objective of deprecating the old datetime picker.
121-124:
Verify the onChange handler implementation
The onChange handlers for both DateTimePicker components might unintentionally overwrite the entire value object. The current implementation passes the new date directly to onChange, which could lose other fields like policyId and recurrence.
Consider updating the onChange handlers to preserve other fields:
<DateTimePicker
value={value.startTime}
- onChange={onChange}
+ onChange={(newDate) => onChange({ ...value, startTime: newDate })}
granularity="minute"
className="w-60"
/>
...
<DateTimePicker
value={value.endTime}
- onChange={onChange}
+ onChange={(newDate) => onChange({ ...value, endTime: newDate })}
granularity="minute"
className="w-60"
/>Let's verify the impact of removing timezone handling:
Also applies to: 128-131
Summary by CodeRabbit
DateTimePickerto dynamically determine time format based on user locale.