feat(date): Temporal polyfill integration#2532
Draft
epr3 wants to merge 28 commits into
Draft
Conversation
Contributor
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
📝 WalkthroughWalkthroughThis pull request implements comprehensive Temporal API integration across the entire date/time picker ecosystem, replacing all Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~75 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
✨ Finishing Touches🧪 Generate unit tests (beta)
|
commit: |
15 tasks
Collaborator
Author
|
@coderabbitai review |
Contributor
✅ Actions performedReview triggered.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 16
Note
Due to the large number of review comments, Critical, Major severity comments were prioritized as inline comments.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (11)
packages/core/src/YearRangePicker/YearRangePicker.test.ts (2)
382-383:⚠️ Potential issue | 🟡 MinorSame
DateValuetype reference issue as noted above.The
isYearDisabledcallback also usesDateValuetype. This should be updated toTemporalDatefor consistency with the migration.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/core/src/YearRangePicker/YearRangePicker.test.ts` around lines 382 - 383, The test's isYearDisabled callback in YearRangePicker.test.ts incorrectly types its parameter as DateValue; update the parameter type to TemporalDate to match the migration (i.e., change the isYearDisabled: (date: DateValue) => ... signature to use TemporalDate) so the test uses the correct TemporalDate type for year checks.
273-276:⚠️ Potential issue | 🔴 CriticalReplace
DateValuewithTemporalDatein callback parameter types.The
isYearUnavailableandisYearDisabledcallbacks use the undefined typeDateValue, which is no longer exported. Replace withTemporalDateto align with the migration.Affected lines
- Line 273:
isYearUnavailable: (date: DateValue) =>- Line 382:
isYearDisabled: (date: DateValue) =>🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/core/src/YearRangePicker/YearRangePicker.test.ts` around lines 273 - 276, The callbacks isYearUnavailable and isYearDisabled use the removed DateValue type; update their parameter types to TemporalDate (e.g., change isYearUnavailable: (date: DateValue) => ... to isYearUnavailable: (date: TemporalDate) => ... and likewise for isYearDisabled) so the tests compile against the migrated type export; ensure any imports or type references in YearRangePicker.test.ts that referenced DateValue are updated or removed accordingly.packages/core/src/Calendar/CalendarPrev.vue (1)
23-28:⚠️ Potential issue | 🟠 MajorRemove unused
stepdefault and reorder variable declarations.The
step: 'month'default is dead code —stepis neither declared inCalendarPrevPropsnor used anywhere in the component. Remove it from line 23.Additionally,
rootContext(line 28) is used in thedisabledcomputed (line 26) but declared after it. Reorder to declarerootContextbeforedisabledfor clarity:Suggested reordering
const props = withDefaults(defineProps<CalendarPrevProps>(), { as: 'button' }) defineSlots<CalendarPrevSlot>() const rootContext = injectCalendarRootContext() const disabled = computed(() => rootContext.disabled.value || rootContext.isPrevButtonDisabled(props.prevPage))🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/core/src/Calendar/CalendarPrev.vue` around lines 23 - 28, Remove the dead default step value from the withDefaults call (remove step: 'month' so the props default only includes as: 'button') and move the rootContext declaration before the disabled computed; specifically, call injectCalendarRootContext() to assign rootContext prior to using it in the computed(() => ...) for disabled so that rootContext.disabled.value and rootContext.isPrevButtonDisabled(props.prevPage) reference an already-declared variable.packages/core/src/Calendar/CalendarNext.vue (1)
23-28:⚠️ Potential issue | 🟡 MinorRemove the
step: 'month'default fromwithDefaults—stepis not defined inCalendarNextPropsand is never used in the component.The code order (accessing
rootContextindisabledbefore declaringrootContext) is not a runtime error because the computed function is deferred until accessed, sorootContextwill already exist by execution time.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/core/src/Calendar/CalendarNext.vue` around lines 23 - 28, Remove the unnecessary default `step: 'month'` from the withDefaults call because `step` is not part of CalendarNextProps and is unused; update the line with withDefaults(defineProps<CalendarNextProps>(), { ... }) to only include valid defaults (e.g., keep `as: 'button'`) and ensure props is used unchanged elsewhere; no change needed to the computed `disabled` or the `rootContext` initialization other than ensuring you reference injectCalendarRootContext() by name when locating the code to edit.docs/components/examples/DatePickerSelection/index.vue (1)
91-110:⚠️ Potential issue | 🟠 Major
Last quarterresolves to the current quarter on quarter-end months.
Math.floor(currentMonth / 3)makes March/June/September/December fall into the next bucket, so this example returns Jan-Mar in March, Apr-Jun in June, etc. Derive the start of the current quarter first, then subtract three months.🐛 Proposed fix
- const currentMonth = now.month - const currentQuarter = Math.floor(currentMonth / 3) - - // If we're in the first quarter, we need to go back to last year - let startOfLastQuarter - if (currentQuarter === 0) { - startOfLastQuarter = now - .subtract({ years: 1 }) - .set({ month: 10, day: 1 }) // October 1st of previous year - } - else { - // Otherwise, just go back 3 months from the start of current quarter - startOfLastQuarter = now - .set({ month: currentQuarter * 3 - 2, day: 1 }) - } + const startOfCurrentQuarter = now.set({ + month: now.month - ((now.month - 1) % 3), + day: 1, + }) + const startOfLastQuarter = startOfCurrentQuarter.subtract({ months: 3 })🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/components/examples/DatePickerSelection/index.vue` around lines 91 - 110, The current logic computes currentQuarter incorrectly (making quarter-end months fall into the next quarter); instead derive the start of the current quarter from now (use currentMonth to compute startOfCurrentQuarter), set its month/day to the first day of that quarter, then compute startOfLastQuarter by subtracting 3 months from startOfCurrentQuarter so year rollovers are handled automatically; update the block that sets startOfLastQuarter (and keep endOfLastQuarter as startOfLastQuarter.add({ months: 3 }).subtract({ days: 1 })) replacing the Math.floor(currentMonth / 3) logic in the action for the "Last quarter" example (referencing getToday, currentMonth, startOfCurrentQuarter, startOfLastQuarter, endOfLastQuarter).packages/core/src/RangeCalendar/RangeCalendar.test.ts (1)
208-225:⚠️ Potential issue | 🟠 MajorRestore the preserved-end assertion in this controlled-range test.
Line 225 only proves that some days stayed selected. It no longer verifies the behavior named by the test—keeping the externally controlled end after editing the start—so that regression can now slip through unnoticed. The new
anypayload here also drops the stricter guard the file added elsewhere.Suggested fix
- 'onUpdate:modelValue': (data: any) => { + 'onUpdate:modelValue': (data) => { + if (!isDateRange(data)) + return rerender({ calendarProps: { modelValue: { start: data.start ?? controlledRange.start, end: data.end ?? preservedEnd, }, }, }) }, @@ - expect(getSelectedDays(calendar).length).toBeGreaterThan(0) + expect(getByTestId('date-1-24')).toHaveAttribute('data-selection-start') + expect(getByTestId('date-1-28')).toHaveAttribute('data-selection-end') + expect(getByTestId('date-1-25')).toHaveAttribute('data-selected') + expect(getByTestId('date-1-27')).toHaveAttribute('data-selected')🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/core/src/RangeCalendar/RangeCalendar.test.ts` around lines 208 - 225, The test's assertion that the externally controlled end remains preserved was removed; restore an explicit assertion that preservedEnd is still present after clicking the start. In the onUpdate:modelValue handler (the anonymous listener in this test), tighten the payload typing instead of using any (ensure the handler expects an object with optional start and end) and after the user.click(twentyFourthDay) add an assertion verifying the calendar's model still uses preservedEnd (e.g., compare the resolved end value to preservedEnd via getSelectedDays or the calendarProps/modelValue), keeping the existing check that the clicked date is marked as data-selection-start.packages/core/src/RangeCalendar/RangeCalendarCellTrigger.vue (1)
208-238:⚠️ Potential issue | 🟠 MajorAdd an escape hatch when
shiftFocus()keeps encountering disabled days.This path still recurses until it finds an enabled candidate. If
isDateDisabledblocks every day in that direction and there is nominValue/maxValueboundary to stop it, a single Arrow key press can recurse and keep paging indefinitely. The month/year pickers in this PR added a recursion cap; the day-grid path needs the same safeguard.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/core/src/RangeCalendar/RangeCalendarCellTrigger.vue` around lines 208 - 238, The shiftFocus function can recurse indefinitely when every candidate day is disabled; add a recursion cap by extending shiftFocus to accept an attempts/count parameter (default 0) and increment it on each recursive call; if attempts exceeds a reasonable limit (e.g. 50) return early to bail out. Update the two recursive calls—when paging via nextTick and when recursing past a disabled candidate (the calls to shiftFocus(day, add) and shiftFocus(candidateDayValue, add))—to pass attempts + 1, and leave other logic (min/max checks, next/prev page via rootContext.nextPage()/prevPage(), and checks like rootContext.isNextButtonDisabled()/isPrevButtonDisabled()) unchanged.packages/core/src/TimeField/TimeField.test.ts (1)
601-614:⚠️ Potential issue | 🟡 MinorTest expectation contradicts the test name: cycling from 11 PM to 12 AM should result in AM, not PM.
The test name correctly states the expected behavior ("transitions from PM to AM"), but line 613 expects the dayPeriod to be
PM. When the hour cycles from 23 (11 PM) upward, it wraps to 0 (12 AM), which according to the dayPeriod calculation (hours 0–11 = AM, hours 12–23 = PM) should always beAM.Corrected expectation
expect(hour).toHaveTextContent('12') - expect(getByTestId('dayPeriod')).toHaveTextContent('PM') + expect(getByTestId('dayPeriod')).toHaveTextContent('AM')🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/core/src/TimeField/TimeField.test.ts` around lines 601 - 614, The test "transitions from PM to AM when cycling from 11 PM to 12 AM" has an incorrect expectation: after simulating an arrow-up from 23:30 the day period should be AM, not PM. Update the assertion in the TimeField.test block (the test using setup with modelValue Temporal.PlainTime.from({ hour: 23, minute: 30 })) that checks getByTestId('dayPeriod') to expect 'AM' instead of 'PM' so the test name and assertion align.packages/core/src/DateField/DateFieldRoot.vue (1)
313-314:⚠️ Potential issue | 🟠 MajorHTML
input[type="date"]expects string values formaxandmin.The
:max="maxValue"and:min="minValue"bindings passTemporalDateobjects, but the HTML<input type="date">element expects ISO date strings (e.g.,"2024-07-10"). This could cause the browser to ignore these constraints or produce unexpected behavior.🐛 Proposed fix
<VisuallyHidden :id="id" as="input" type="date" feature="focusable" tabindex="-1" :value="modelValue ? modelValue.toString() : ''" :name="name" :disabled="disabled" :required="required" - :max="maxValue" - :min="minValue" + :max="maxValue?.toString()" + :min="minValue?.toString()" `@focus`="Array.from(segmentElements)?.[0]?.focus()" />🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/core/src/DateField/DateFieldRoot.vue` around lines 313 - 314, The input[type="date"] bindings :max="maxValue" and :min="minValue" are passing TemporalDate objects; convert them to ISO date strings before binding so the browser recognizes the constraints. Update DateFieldRoot.vue to provide string-safe attributes (e.g., create computed props like maxAttr/minAttr or adjust existing maxValue/minValue getters) that return maxValue?.toString() and minValue?.toString() (or pass through if already a string) and use those computed values in the input's :max and :min bindings to guard against null/undefined and non-string types.packages/core/src/TimeRangeField/TimeRangeFieldRoot.vue (1)
217-226:⚠️ Potential issue | 🟡 Minor
areAllDaysBetweenValidis inappropriate for validating same-day time ranges.This function is designed to validate intermediate days between two dates. When both start and end times fall on the same day (as they will after
convertValuenormalizes them to today), the function skips validation entirely and returnstrue. The function explicitly begins checking from the day after the start date, so for same-day ranges, no validation occurs.For time range validation within a single day, a different approach is needed that checks time-specific unavailability rather than day-level availability.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/core/src/TimeRangeField/TimeRangeFieldRoot.vue` around lines 217 - 226, The current call to areAllDaysBetweenValid only checks intermediate days and will skip validation for same-day ranges; update the conditional around propsIsTimeUnavailable (using convertedModelValue.start and convertedModelValue.end) to detect when start and end are the same calendar day and, in that case, perform a time-granular validation (e.g., a new helper or inline loop) that checks the specific time interval against propsIsTimeUnavailable rather than calling areAllDaysBetweenValid; keep using areAllDaysBetweenValid for multi-day ranges. Ensure the same-day branch inspects times between convertedModelValue.start and convertedModelValue.end and returns true when any unavailable time is found (matching the existing control flow).packages/core/src/Calendar/CalendarRoot.vue (1)
277-293:⚠️ Potential issue | 🟠 MajorNormalize a seeded single value before handling multiple selection.
In multiple mode, this branch only handles
undefinedand arrays. A valid uncontrolled state is still a singleTemporalDatehere (multiple+defaultValue), so the second click becomes a no-op because neither branch runs.Suggested fix
- else if (Array.isArray(modelValue.value)) { - const index = modelValue.value.findIndex(date => isSameDay(date, value)) + else { + const modelValueArray = Array.isArray(modelValue.value) + ? modelValue.value + : [modelValue.value] + const index = modelValueArray.findIndex(date => isSameDay(date, value)) if (index === -1) { - modelValue.value = [...modelValue.value, value] + modelValue.value = [...modelValueArray, value] } else if (!preventDeselect.value) { - const next = modelValue.value.filter(date => !isSameDay(date, value)) + const next = modelValueArray.filter(date => !isSameDay(date, value)) if (!next.length) { placeholder.value = value modelValue.value = undefined return } modelValue.value = next } }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/core/src/Calendar/CalendarRoot.vue` around lines 277 - 293, The multiple-selection branch doesn't handle the case where modelValue.value is a single TemporalDate (seeded uncontrolled default), so normalize that single value into an array before the array-specific logic runs: in the block handling multiple selections, detect when modelValue.value exists but is not an array and replace it with [modelValue.value] (preserving placeholder/other state), then proceed with the existing Array.isArray(modelValue.value) logic (including isSameDay checks, preventDeselect handling, and clearing placeholder when removing the last item) so subsequent clicks behave correctly.
🟡 Minor comments (5)
packages/core/src/date/calendar.ts-299-300 (1)
299-300:⚠️ Potential issue | 🟡 MinorRemove unused variables
explicitFirstDayandfirstDayMap(lines 299-300).Both variables are defined but never used. Additionally, there's a type mismatch: the parameter
firstDayOfWeekis typed asDayOfWeek(an object), but test cases pass string values like'mon'and'sun'. The type casting and map definition suggest incomplete code that should be cleaned up.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/core/src/date/calendar.ts` around lines 299 - 300, Remove the unused variables explicitFirstDay and firstDayMap and fix the typing for the firstDayOfWeek parameter: delete the two declarations (explicitFirstDay and firstDayMap) and change the type of firstDayOfWeek where it's declared to accept the string values used in tests (e.g., use firstDayOfWeek: DayOfWeek | string or a string literal union like 'sun'|'mon'|...); ensure any conversion logic that relied on firstDayMap is implemented where needed or callers are adjusted to pass the correct type. References: explicitFirstDay, firstDayMap, firstDayOfWeek, DayOfWeek.docs/content/docs/components/year-picker.md-35-35 (1)
35-35:⚠️ Potential issue | 🟡 MinorAdd a direct link for “Temporal proposal docs”.
Line 35 references docs without a URL, so readers can’t navigate directly. This phrasing is repeated in related pages, so applying the same fix there will prevent drift.
🛠 Suggested doc tweak
-We recommend reading the Temporal proposal docs to understand the model and immutability semantics used by Reka UI date-related components. +We recommend reading the [Temporal proposal docs](https://tc39.es/proposal-temporal/docs/) to understand the model and immutability semantics used by Reka UI date-related components.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/content/docs/components/year-picker.md` at line 35, Add a direct hyperlink for the phrase "Temporal proposal docs" in the sentence "We recommend reading the Temporal proposal docs to understand the model and immutability semantics used by Reka UI date-related components." Replace the plain text with an inline link to the official Temporal proposal (e.g., https://github.com/tc39/proposal-temporal) and ensure the link opens in a new tab if your markdown renderer supports it; also apply the same quick edit to other pages that repeat this sentence to keep documentation consistent.docs/content/docs/guides/dates.md-34-35 (1)
34-35:⚠️ Potential issue | 🟡 MinorDocumentation inconsistency:
TimeValuetype mapping appears incorrect.The documentation states
TimeValue → PlainTime, but inpackages/core/src/shared/date/comparators.ts,TimeValueis defined asTemporalDateTime. This discrepancy could confuse users. Please verify and align the documentation with the actual type definition.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/content/docs/guides/dates.md` around lines 34 - 35, The docs mapping is inconsistent with the code: change the documentation entry that currently reads "TimeValue → PlainTime" to "TimeValue → TemporalDateTime" to match the type alias in comparators.ts (TimeValue and TemporalDateTime); also scan the dates guide for any other references to TimeValue or PlainTime and update them to TemporalDateTime so the docs and the actual type definition stay aligned.packages/core/src/DateField/DateFieldRoot.vue-130-133 (1)
130-133:⚠️ Potential issue | 🟡 MinorType cast drops
undefinedfrom union.The cast
as Ref<TemporalDate>loses theundefinedpossibility frommodelValue. Based on usage in the component (e.g.,if (!modelValue.value)checks), this should beas Ref<TemporalDate | undefined>.🐛 Proposed fix
const modelValue = useVModel(props, 'modelValue', emits, { defaultValue: defaultValue.value, passive: (props.modelValue === undefined) as false, -}) as Ref<TemporalDate> +}) as Ref<TemporalDate | undefined>🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/core/src/DateField/DateFieldRoot.vue` around lines 130 - 133, The current cast on the modelValue returned from useVModel (const modelValue = useVModel(...) as Ref<TemporalDate>) incorrectly drops undefined from the type; change the assertion to preserve optionality (use Ref<TemporalDate | undefined>) so downstream checks like if (!modelValue.value) remain correct; update the cast on modelValue (and any related type annotations) to Ref<TemporalDate | undefined> while keeping the existing defaultValue and passive arguments to useVModel.packages/core/src/YearPicker/useYearPicker.ts-71-79 (1)
71-79:⚠️ Potential issue | 🟡 MinorFix BCE era detection in year heading formatter.
The Temporal era property returns
'gregory-inverse'for BCE dates in the Gregorian calendar, not'bce'. The current checkprops.placeholder.value.era?.toLowerCase() === 'bc'will never match, causing BCE year headings to skip the era label. Change the comparison to check for'gregory-inverse'.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/core/src/YearPicker/useYearPicker.ts` around lines 71 - 79, The headingFormatOptions computed currently checks props.placeholder.value.era for 'bc' which never matches; update the conditional in useYearPicker's headingFormatOptions to test for 'gregory-inverse' (e.g., props.placeholder.value.era === 'gregory-inverse') so BCE Gregorian dates set options.era = 'short' for the correct Temporal era value; keep the rest of the computed logic unchanged.
🧹 Nitpick comments (18)
packages/core/src/date/calendar.ts (1)
17-32: Consider adding explicit type annotations and avoidingany.The
normalizeTemporalDatefunction usesanycast which reduces type safety. While the duck-typing approach is pragmatic for handling various input shapes, consider using a more explicit union type or type guard.-function normalizeTemporalDate(dateObj: TemporalDate): TemporalDate { - const value = dateObj as any - - if (value && typeof value.with === 'function' && typeof value.add === 'function') - return value as TemporalDate +function normalizeTemporalDate(dateObj: TemporalDate | { year: number; month: number; day?: number }): TemporalDate { + if ('with' in dateObj && typeof dateObj.with === 'function' && 'add' in dateObj && typeof dateObj.add === 'function') + return dateObj as TemporalDate🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/core/src/date/calendar.ts` around lines 17 - 32, The function normalizeTemporalDate currently uses an any cast which weakens type safety; change its signature to accept a safer input type (e.g., unknown or a new union type like TemporalLike = Temporal.PlainDate | { year:number; month:number; day?:number } | { with: Function; add: Function } | string) and add one or two small type‑guard helpers (e.g., isTemporalObjectWithMethods(value): value is Temporal.PlainDate and isYearMonthDay(value): value is {year:number; month:number; day?:number}) to replace the any usage; update the function to use those guards (and strong parameter/return annotations) instead of casting to any so the checks are type‑checked and the return type remains Temporal.PlainDate.docs/content/docs/components/time-field.md (1)
34-34: Add a hyperlink to the Temporal documentation.The recommendation to read the Temporal proposal docs would be more useful with an actual link. Consider adding a hyperlink similar to how the polyfill link is provided on line 32.
📝 Suggested improvement
-We recommend reading the Temporal proposal docs to understand the model and immutability semantics used by Reka UI date-related components. +We recommend reading the [Temporal proposal docs](https://tc39.es/proposal-temporal/docs/) to understand the model and immutability semantics used by Reka UI date-related components.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/content/docs/components/time-field.md` at line 34, Update the sentence "We recommend reading the Temporal proposal docs to understand the model and immutability semantics used by Reka UI date-related components." to include a hyperlink to the Temporal proposal (e.g., the official TC39 Temporal docs or proposal page), following the same markdown style used for the polyfill link on the nearby line; ensure the anchor text mentions "Temporal proposal docs" and the link opens the official Temporal documentation URL.packages/core/src/Calendar/story/CalendarChromatic.story.vue (1)
90-91: Redundant type annotations in prop callbacks.The type annotations
(date: TemporalDate)in the inline arrow functions are unnecessary since thepagingfunction already has proper typing and TypeScript can infer the parameter types from the prop definitions.♻️ Suggested simplification
- :next-page="(date: TemporalDate) => paging(date, 1)" - :prev-page="(date: TemporalDate) => paging(date, -1)" + :next-page="(date) => paging(date, 1)" + :prev-page="(date) => paging(date, -1)"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/core/src/Calendar/story/CalendarChromatic.story.vue` around lines 90 - 91, The inline arrow callbacks for the props :next-page and :prev-page include redundant parameter type annotations "(date: TemporalDate)"; remove the explicit "(date: TemporalDate)" so TypeScript can infer the type from the paging function and the prop definitions — change the callbacks to use date => paging(date, 1) and date => paging(date, -1) (referencing the paging function and the next-page/prev-page props) to simplify the code and eliminate unnecessary type verbosity.packages/core/src/temporal/index.ts (1)
1-15: Consider re-exporting types for a unified import path.The module provides a convenient re-export of
Temporal, but consumers still need to import types likeTemporalDatefrom@/temporal/typesseparately. For better developer ergonomics, consider also re-exporting the types from this module.📦 Suggested improvement
import { Temporal } from 'temporal-polyfill' export { Temporal } +export * from './types'🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/core/src/temporal/index.ts` around lines 1 - 15, This module only re-exports the Temporal runtime but not the related type aliases, forcing consumers to import types separately; update the file that exports Temporal (the current module exporting Temporal) to also re-export the type definitions (use export type) for the commonly used symbols such as TemporalDate, TemporalPlainDate, TemporalZonedDateTime (or the set of types defined in your local types module) from the existing types module so consumers can import both runtime and types from this single module while preserving tree-shaking.docs/content/docs/components/range-calendar.md (1)
34-34: Add a direct link to the Temporal docs in the recommendation sentence.This improves discoverability for readers following the migration guidance.
Suggested docs tweak
-We recommend reading the Temporal proposal docs to understand the model and immutability semantics used by Reka UI date-related components. +We recommend reading the [Temporal proposal docs](https://tc39.es/proposal-temporal/docs/) to understand the model and immutability semantics used by Reka UI date-related components.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/content/docs/components/range-calendar.md` at line 34, Update the sentence "We recommend reading the Temporal proposal docs to understand the model and immutability semantics used by Reka UI date-related components." to include a direct, inline link to the Temporal proposal (e.g., the official Temporal proposal or MDN Temporal docs) so readers can click through immediately; edit the text in docs/content/docs/components/range-calendar.md replacing the plain mention of "Temporal proposal docs" with a hyperlink to the chosen Temporal documentation URL.docs/content/docs/components/year-range-picker.md (1)
32-34: Same suggestion: add a direct link to Temporal documentation.For consistency with other component docs and improved developer experience, consider adding a hyperlink to the Temporal proposal documentation here as well.
📚 Suggested improvement
-We recommend reading the Temporal proposal docs to understand the model and immutability semantics used by Reka UI date-related components. +We recommend reading the [Temporal proposal docs](https://tc39.es/proposal-temporal/docs/) to understand the model and immutability semantics used by Reka UI date-related components.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/content/docs/components/year-range-picker.md` around lines 32 - 34, Update the paragraph that currently reads "We recommend reading the Temporal proposal docs to understand the model and immutability semantics used by Reka UI date-related components" to include a direct hyperlink to the Temporal proposal documentation (for example: https://tc39.es/proposal-temporal/ or the docs page https://tc39.es/proposal-temporal/docs/), so users can click through immediately; find that sentence in year-range-picker.md and replace it with the same sentence but with the Temporal proposal docs text wrapped as a link.docs/content/docs/components/calendar.md (1)
32-34: Consider adding a direct link to the Temporal documentation.The recommendation to read "Temporal proposal docs" would be more actionable with a hyperlink. This would improve developer experience by providing a clear path to the referenced documentation.
📚 Suggested improvement
-We recommend reading the Temporal proposal docs to understand the model and immutability semantics used by Reka UI date-related components. +We recommend reading the [Temporal proposal docs](https://tc39.es/proposal-temporal/docs/) to understand the model and immutability semantics used by Reka UI date-related components.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/content/docs/components/calendar.md` around lines 32 - 34, Replace the plain text "Temporal proposal docs" in the paragraph that mentions Temporal with a direct hyperlink to the official Temporal specification (for example https://tc39.es/proposal-temporal/) so readers can click through immediately; update the sentence that currently reads "We recommend reading the Temporal proposal docs to understand the model and immutability semantics used by Reka UI date-related components." to include the hyperlink on "Temporal proposal docs".packages/core/src/DateRangePicker/DateRangePicker.test.ts (1)
71-115: Add an edit-path assertion for datetime/zoned ranges.These cases only verify initial rendering. A single
start-hour/end-minuteedit would lock in the Temporal datetime path and would have caught same-day short-circuit regressions in the picker wrapper.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/core/src/DateRangePicker/DateRangePicker.test.ts` around lines 71 - 115, The tests for CalendarDateTime and ZonedDateTime only check initial rendering; add an edit-path assertion by simulating a user edit on a time segment (e.g., use userEvent.type or fireEvent.change on getByTestId('start-hour') or 'end-minute' in both tests that call setup with modelValue calendarDateTime and zonedDateTime) and then assert the component remained on the datetime edit path (for example: the time segment elements like 'start-hour'/'start-minute'/'start-second' are still present and reflect the edited value), ensuring the picker did not short-circuit to a date-only path after the edit.packages/core/src/DatePicker/DatePicker.test.ts (1)
167-178: Consider usingsubtractfor decrement operations.While
add({ [unit]: -1 })is valid Temporal API, usingsubtract({ [unit]: 1 })is more idiomatic and matches the approach used inTimeField.test.tsline 185.♻️ Optional: Use subtract for decrements
function cycle(segment: DateFields | TimeFields) { const unitMap = { year: 'years', month: 'months', day: 'days', hour: 'hours', minute: 'minutes', second: 'seconds', } const unit = unitMap[segment] - return String(zonedDateTime.add({ [unit]: -1 })[segment]) + return String(zonedDateTime.subtract({ [unit]: 1 })[segment]) }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/core/src/DatePicker/DatePicker.test.ts` around lines 167 - 178, The test helper function cycle currently decrements the zonedDateTime by calling zonedDateTime.add({ [unit]: -1 }); change this to the idiomatic Temporal.subtract call: use zonedDateTime.subtract({ [unit]: 1 }) inside the cycle function (keep the existing unitMap and return expression) so the decrement matches the approach used in TimeField.test.ts and improves readability.packages/core/src/temporal/types.ts (1)
12-16: Consider renamingTemporalDateTimefor clarity.The name
TemporalDateTimesuggests a date+time combination, but the union includesTemporal.PlainTimewhich only has time components (no date). Consider a name likeTemporalTimeValueorTemporalWithTimeto better reflect that this represents "any Temporal type with time properties."🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/core/src/temporal/types.ts` around lines 12 - 16, Rename the confusing type TemporalDateTime to a clearer name (e.g., TemporalTimeValue or TemporalWithTime) because the union includes Temporal.PlainTime (time-only) as well as Temporal.PlainDateTime and Temporal.ZonedDateTime; update the type declaration (formerly TemporalDateTime) and replace all references/usages across the codebase to the new name so imports/exports remain consistent, and adjust any JSDoc/comments mentioning TemporalDateTime to reflect the new identifier.packages/core/src/shared/date/comparators.ts (1)
17-18: Unusedlocaleparameter inGetDefaultDateProps.The
localeparameter is defined in the type but is no longer used in the function body after the migration (it was previously used withDateFormatter/createCalendar). Consider removing it if it's no longer needed to avoid confusion.♻️ Proposed fix
type GetDefaultDateProps = { defaultValue?: TemporalDate | TemporalDate[] | undefined defaultPlaceholder?: TemporalDate | undefined granularity?: Granularity - locale?: string }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/core/src/shared/date/comparators.ts` around lines 17 - 18, GetDefaultDateProps currently declares a locale parameter that is never used; remove the unused locale from the GetDefaultDateProps function signature and its associated type definition (and any returned object properties) to avoid confusion, or alternatively reintroduce its use if intended; locate the GetDefaultDateProps function and its type in comparators.ts and either delete the locale parameter and any references to it, or wire it back into the date formatting/calendar creation logic (e.g., DateFormatter/createCalendar) so the parameter is actually consumed.packages/core/src/shared/useDateFormatter.ts (1)
40-55: DuplicatetoDatehelper exists inparser.ts.This
toDatefunction has nearly identical logic to the one inpackages/core/src/shared/date/parser.ts. Consider extracting this to a shared utility (e.g., in@/temporal/comparatorsor a new@/temporal/utils) to avoid code duplication and ensure consistent behavior.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/core/src/shared/useDateFormatter.ts` around lines 40 - 55, Extract the duplicated toDate logic into a shared utility function (e.g., create a new exported function toDate in a temporal utils module) and have both packages/core/src/shared/useDateFormatter.ts and packages/core/src/shared/date/parser.ts import and call that single toDate; preserve the current behavior/signature (accepts TemporalDate and optional timeZone defaulting to Temporal.Now.timeZoneId(), handles isZonedDateTime, Temporal.PlainDateTime, and other Temporal types with plainTime midnight), export the utility from the new module (or from an existing `@/temporal/`* module) and replace the local toDate implementations with imports of that shared function so behavior remains identical and duplication is removed.packages/core/src/shared/date/parser.ts (1)
200-209:getTimeFieldValuereturnsnullfordayPeriodbut callers may not expect this.The function handles
hour,minute, andsecondbut returnsnullfor any otherTimeSegmentPartincludingdayPeriod. While Line 23-24 handlesdayPeriodseparately before calling this function, consider adding a comment or making the contract explicit to prevent future misuse.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/core/src/shared/date/parser.ts` around lines 200 - 209, getTimeFieldValue currently only returns numeric time parts and returns null for other TimeSegmentPart values (including 'dayPeriod'), which can be surprising to callers; update the function contract so it's explicit: either narrow the input type to exclude 'dayPeriod' (e.g., accept only 'hour' | 'minute' | 'second') or add a concise doc comment above getTimeFieldValue stating it only handles numeric fields and will return null for non-numeric parts like 'dayPeriod' (and prefer to keep existing behavior), and ensure any callers relying on numeric values validate dayPeriod before calling (e.g., in the code that handles dayPeriod separately). Include the symbol getTimeFieldValue and the union member 'dayPeriod' in your change so readers can find and understand the intended usage.packages/core/src/Calendar/CalendarCellTrigger.vue (1)
135-136: Long line reduces readability; consider extracting boundary checks.This compound condition on a single line is hard to parse. Extracting the min/max boundary checks into separate variables or a helper would improve maintainability.
♻️ Suggested refactor
function shiftFocus(day: TemporalDate, add: number) { const candidateDayValue = day.add({ days: add }) + const candidatePlain = toPlainDate(candidateDayValue) + const isBelowMin = rootContext.minValue.value && Temporal.PlainDate.compare(candidatePlain, toPlainDate(rootContext.minValue.value)) < 0 + const isAboveMax = rootContext.maxValue.value && Temporal.PlainDate.compare(candidatePlain, toPlainDate(rootContext.maxValue.value)) > 0 - if ((rootContext.minValue.value && Temporal.PlainDate.compare(toPlainDate(candidateDayValue), toPlainDate(rootContext.minValue.value)) < 0) || (rootContext.maxValue.value && Temporal.PlainDate.compare(toPlainDate(candidateDayValue), toPlainDate(rootContext.maxValue.value)) > 0)) + if (isBelowMin || isAboveMax) return🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/core/src/Calendar/CalendarCellTrigger.vue` around lines 135 - 136, The long compound boundary check should be split for readability: compute two descriptive booleans (e.g., isBeforeMin and isAfterMax) using toPlainDate(candidateDayValue) compared with toPlainDate(rootContext.minValue.value) and toPlainDate(rootContext.maxValue.value) via Temporal.PlainDate.compare, or move that logic into a small helper like isOutOfBounds(candidateDayValue, rootContext). Replace the single-line if with a simple if (isBeforeMin || isAfterMax) return, referencing candidateDayValue, rootContext.minValue, rootContext.maxValue, toPlainDate and Temporal.PlainDate.compare to locate the code in CalendarCellTrigger.vue.packages/core/src/DateRangePicker/DateRangePickerRoot.vue (1)
205-206: Consider simplifying the object spread.The destructuring
{ start: date.start, end: date.end }could be simplified to justdatesinceDateRangealready has this shape.♻️ Minor simplification
onDateChange(date: DateRange) { - modelValue.value = { start: date.start, end: date.end } + modelValue.value = date },🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/core/src/DateRangePicker/DateRangePickerRoot.vue` around lines 205 - 206, The assignment in onDateChange currently reconstructs the DateRange by writing { start: date.start, end: date.end }; simplify this by assigning the DateRange directly to modelValue.value (i.e., set modelValue.value to date) in the onDateChange handler to avoid redundant destructuring and preserve the DateRange shape.packages/core/src/DatePicker/DatePickerRoot.vue (1)
180-189: Simplify redundant null coalescing.At line 182,
date ?? undefinedis redundant sincedateis already typed asTemporalDate | undefined.♻️ Minor cleanup
onDateChange(date: TemporalDate | undefined) { if (!date || !modelValue.value) { - modelValue.value = date ?? undefined + modelValue.value = date }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/core/src/DatePicker/DatePickerRoot.vue` around lines 180 - 189, In onDateChange, simplify the redundant null coalescing by assigning date directly instead of using "date ?? undefined": replace the assignment to modelValue.value in the first branch so it sets modelValue.value = date; keep the existing logic and references to modelValue, preventDeselect, and toPlainDate unchanged.packages/core/src/shared/date/useDateField.ts (1)
398-413: Verify fallback behavior indateTimeValueIncrementation.The fallback at lines 411-412 uses
dayoperations but this code path is reached whenpartis'minute'or'second'and the dateRef doesn't have anhourproperty. This appears to be unreachable dead code since:
- If
part === 'minute', theminuteSecondIncrementationfunction should be called instead- If
part === 'second', same appliesHowever, if somehow reached, it would return incorrect values. Consider removing this fallback or throwing an error for unexpected parts.
🔧 Suggested improvement
- const next = dateRef.with({ day: prevValue ?? dateRef.day }).add({ days: sign }) - return next.day + throw new Error(`Unexpected part: ${part}`)🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/core/src/shared/date/useDateField.ts` around lines 398 - 413, The fallback branch in dateTimeValueIncrementation currently uses day arithmetic (returning next.day) for cases where part is 'minute' or 'second' but dateRef lacks an hour, which is unreachable and can produce incorrect values; update dateTimeValueIncrementation to either remove this day-based fallback or replace it with an explicit error for unexpected parts, and ensure minuteSecondIncrementation is always routed for 'minute'/'second' cases; locate the logic inside dateTimeValueIncrementation that checks part and dateRef.hour and either delete the final day-based fallback block or throw a clear exception mentioning the unexpected part, so incorrect values are not returned silently.packages/core/src/Calendar/useCalendar.ts (1)
39-54:toDatehelper correctly handles Temporal conversion.The implementation properly handles all three Temporal date types with appropriate timezone handling. This is similar to the helper in
useDateField.ts- consider extracting to a shared utility to avoid duplication.♻️ Consider extracting to shared utility
Both
useDateField.tsanduseCalendar.tsdefine similartoDatehelpers. Consider extracting to@/temporal/comparatorsor a dedicated conversion utility to maintain DRY principles.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/core/src/Calendar/useCalendar.ts` around lines 39 - 54, The toDate implementation in useCalendar.ts duplicates logic found in useDateField.ts; extract the conversion into a shared utility (e.g., create a new function exported from a module like "@/temporal/toDate" or "@/temporal/comparators") and replace the local toDate in both useCalendar.ts and useDateField.ts with an import of that utility; ensure the exported function preserves the same signature (toDate(dateValue: TemporalDate, timeZone?: string)), update imports in both files to use the new module, and remove the duplicated helper definitions so only the shared implementation is maintained.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 805359e5-2323-4227-9462-02bb79acf3c1
⛔ Files ignored due to path filters (2)
playground/nuxt/pnpm-lock.yamlis excluded by!**/pnpm-lock.yamlpnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (144)
docs/components/demo/Calendar/tailwind/index.vuedocs/components/demo/CalendarSelect/css/index.vuedocs/components/demo/CalendarSelect/tailwind/index.vuedocs/components/demo/CalendarSwipe/css/index.vuedocs/components/demo/CalendarSwipe/tailwind/index.vuedocs/components/demo/CalendarYearIncrement/css/index.vuedocs/components/demo/CalendarYearIncrement/tailwind/index.vuedocs/components/demo/MonthPicker/css/index.vuedocs/components/demo/MonthPicker/tailwind/index.vuedocs/components/demo/MonthRangePicker/css/index.vuedocs/components/demo/MonthRangePicker/tailwind/index.vuedocs/components/demo/RangeCalendar/tailwind/index.vuedocs/components/demo/YearPicker/css/index.vuedocs/components/demo/YearPicker/tailwind/index.vuedocs/components/demo/YearRangePicker/css/index.vuedocs/components/demo/YearRangePicker/tailwind/index.vuedocs/components/examples/DatePickerSelection/index.vuedocs/components/examples/DatePickerViewSwitching/index.vuedocs/content/docs/components/calendar.mddocs/content/docs/components/date-field.mddocs/content/docs/components/date-picker.mddocs/content/docs/components/date-range-field.mddocs/content/docs/components/date-range-picker.mddocs/content/docs/components/month-picker.mddocs/content/docs/components/month-range-picker.mddocs/content/docs/components/range-calendar.mddocs/content/docs/components/time-field.mddocs/content/docs/components/time-range-field.mddocs/content/docs/components/year-picker.mddocs/content/docs/components/year-range-picker.mddocs/content/docs/guides/dates.mddocs/content/docs/guides/migration.mddocs/content/docs/utilities/use-date-formatter.mddocs/package.jsonpackages/core/package.jsonpackages/core/src/Calendar/Calendar.test.tspackages/core/src/Calendar/CalendarCell.vuepackages/core/src/Calendar/CalendarCellTrigger.vuepackages/core/src/Calendar/CalendarNext.vuepackages/core/src/Calendar/CalendarPrev.vuepackages/core/src/Calendar/CalendarRoot.vuepackages/core/src/Calendar/story/CalendarChromatic.story.vuepackages/core/src/Calendar/story/CalendarFixedWeeksForLocales.story.vuepackages/core/src/Calendar/story/CalendarLocales.story.vuepackages/core/src/Calendar/story/CalendarMultiple.story.vuepackages/core/src/Calendar/story/CalendarPopover.story.vuepackages/core/src/Calendar/story/CalendarSelect.story.vuepackages/core/src/Calendar/story/CalendarValidation.story.vuepackages/core/src/Calendar/story/CalendarYearIncrement.story.vuepackages/core/src/Calendar/story/_Calendar.vuepackages/core/src/Calendar/story/_CalendarMultiple.vuepackages/core/src/Calendar/useCalendar.tspackages/core/src/DateField/DateField.test.tspackages/core/src/DateField/DateFieldRoot.vuepackages/core/src/DateField/story/DateFieldChromatic.story.vuepackages/core/src/DateField/story/_DateField.vuepackages/core/src/DatePicker/DatePicker.test.tspackages/core/src/DatePicker/DatePickerCalendar.vuepackages/core/src/DatePicker/DatePickerField.vuepackages/core/src/DatePicker/DatePickerRoot.vuepackages/core/src/DatePicker/story/DatePickerChromatic.story.vuepackages/core/src/DatePicker/story/DatePickerValidation.story.vuepackages/core/src/DatePicker/story/_DatePicker.vuepackages/core/src/DateRangeField/DateRangeField.test.tspackages/core/src/DateRangeField/DateRangeFieldRoot.vuepackages/core/src/DateRangeField/story/DateRangeFieldChromatic.story.vuepackages/core/src/DateRangeField/story/DateRangeFieldGranular.story.vuepackages/core/src/DateRangeField/story/DateRangeFieldValidation.story.vuepackages/core/src/DateRangeField/story/_DateRangeField.vuepackages/core/src/DateRangePicker/DateRangePicker.test.tspackages/core/src/DateRangePicker/DateRangePickerCalendar.vuepackages/core/src/DateRangePicker/DateRangePickerField.vuepackages/core/src/DateRangePicker/DateRangePickerRoot.vuepackages/core/src/DateRangePicker/story/DateRangePickerChromatic.story.vuepackages/core/src/DateRangePicker/story/DateRangePickerValidation.story.vuepackages/core/src/DateRangePicker/story/_DateRangePicker.vuepackages/core/src/MonthPicker/MonthPicker.test.tspackages/core/src/MonthPicker/MonthPickerCell.vuepackages/core/src/MonthPicker/MonthPickerCellTrigger.vuepackages/core/src/MonthPicker/MonthPickerNext.vuepackages/core/src/MonthPicker/MonthPickerPrev.vuepackages/core/src/MonthPicker/MonthPickerRoot.vuepackages/core/src/MonthPicker/story/_MonthPicker.vuepackages/core/src/MonthPicker/useMonthPicker.tspackages/core/src/MonthRangePicker/MonthRangePicker.test.tspackages/core/src/MonthRangePicker/MonthRangePickerCell.vuepackages/core/src/MonthRangePicker/MonthRangePickerCellTrigger.vuepackages/core/src/MonthRangePicker/MonthRangePickerNext.vuepackages/core/src/MonthRangePicker/MonthRangePickerPrev.vuepackages/core/src/MonthRangePicker/MonthRangePickerRoot.vuepackages/core/src/MonthRangePicker/useRangeMonthPicker.tspackages/core/src/RangeCalendar/RangeCalendar.test.tspackages/core/src/RangeCalendar/RangeCalendarCell.vuepackages/core/src/RangeCalendar/RangeCalendarCellTrigger.vuepackages/core/src/RangeCalendar/RangeCalendarNext.vuepackages/core/src/RangeCalendar/RangeCalendarPrev.vuepackages/core/src/RangeCalendar/RangeCalendarRoot.vuepackages/core/src/RangeCalendar/story/RangeCalendarChromatic.story.vuepackages/core/src/RangeCalendar/story/RangeCalendarMultiple.story.vuepackages/core/src/RangeCalendar/story/RangeCalendarPopover.story.vuepackages/core/src/RangeCalendar/story/RangeCalendarValidation.story.vuepackages/core/src/RangeCalendar/story/_RangeCalendar.vuepackages/core/src/RangeCalendar/useRangeCalendar.tspackages/core/src/TimeField/TimeField.test.tspackages/core/src/TimeField/TimeFieldRoot.vuepackages/core/src/TimeField/story/TimeFieldChromatic.story.vuepackages/core/src/TimeRangeField/TimeRangeField.test.tspackages/core/src/TimeRangeField/TimeRangeFieldRoot.vuepackages/core/src/TimeRangeField/story/TimeRangeFieldChromatic.story.vuepackages/core/src/TimeRangeField/story/TimeRangeFieldGranular.story.vuepackages/core/src/TimeRangeField/story/TimeRangeFieldValidation.story.vuepackages/core/src/YearPicker/YearPicker.test.tspackages/core/src/YearPicker/YearPickerCell.vuepackages/core/src/YearPicker/YearPickerCellTrigger.vuepackages/core/src/YearPicker/YearPickerNext.vuepackages/core/src/YearPicker/YearPickerPrev.vuepackages/core/src/YearPicker/YearPickerRoot.vuepackages/core/src/YearPicker/story/_YearPicker.vuepackages/core/src/YearPicker/useYearPicker.tspackages/core/src/YearRangePicker/YearRangePicker.test.tspackages/core/src/YearRangePicker/YearRangePickerCell.vuepackages/core/src/YearRangePicker/YearRangePickerCellTrigger.vuepackages/core/src/YearRangePicker/YearRangePickerNext.vuepackages/core/src/YearRangePicker/YearRangePickerPrev.vuepackages/core/src/YearRangePicker/YearRangePickerRoot.vuepackages/core/src/YearRangePicker/useRangeYearPicker.tspackages/core/src/date/calendar.test.tspackages/core/src/date/calendar.tspackages/core/src/date/comparators.tspackages/core/src/date/types.tspackages/core/src/index.tspackages/core/src/shared/date/comparators.tspackages/core/src/shared/date/index.tspackages/core/src/shared/date/parser.tspackages/core/src/shared/date/types.tspackages/core/src/shared/date/useDateField.tspackages/core/src/shared/index.tspackages/core/src/shared/useDateFormatter.tspackages/core/src/temporal/calendar.tspackages/core/src/temporal/comparators.tspackages/core/src/temporal/index.tspackages/core/src/temporal/types.tspackages/core/vitest.setup.tsplayground/nuxt/package.json
💤 Files with no reviewable changes (1)
- playground/nuxt/package.json
|
@zernonia my apologies for the ping, feel free to ignore if busy, but would really appreciate iterating on this issue, as |
epr3
force-pushed
the
feat-2183-temporal-integration
branch
2 times, most recently
from
9d8e72f to
3556749
Compare
Collaborator
Author
|
@coderabbitai review |
Contributor
✅ Actions performedReview triggered.
|
Temporal date objects don't expose .era as a property for era detection. Switch to Intl.DateTimeFormat.formatToParts() with era: 'short' and inspect the 'era' part to decide when to enable era formatting. Also normalize iso8601 calendar to gregory in MonthPicker and YearPicker headingFormatOptions for consistency.
Move validation inside strict-bound loop so endDate is never checked and start===end returns true. Add regression tests.
Migrate all DateValue type annotations to TemporalDate to align with temporal integration and fix compilation errors.
…check ISO today breaks non-ISO calendar year comparison; convert via toCalendar using placeholder's calendarId before isSameYear check
Normalized modelValue to array in onYearChange multiple branch to fix ignored clicks when multiple=true and modelValue is a single TemporalDate.
Array may contain undefined when modelValue is single date wrapped. Filter fixes type-check and build.
Add operational guidance files for each workspace to standardize development workflows, verification commands, and cross-package sync rules.
Updates eslint 10.0.3→10.3.0, vite 8.0.0→8.0.10, esbuild 0.27→0.28, antfu-eslint-config 7.7.2→8.2.0, vue-tsc 2.2.12→3.2.6, size-limit 12.x added. Lockfile sync after dependency upgrades.
DateValue was legacy alias. TemporalDate is canonical type now.
epr3
force-pushed
the
feat-2183-temporal-integration
branch
from
78773b9 to
28c44d9
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
🔗 Linked issue
#2183
❓ Type of change
📚 Description
Resolves #2183 . Details in the issue.
📸 Screenshots (if appropriate)
📝 Checklist
Summary by CodeRabbit
Refactor
Documentation
Chores