Skip to content

refactor(date): delegate to v0 createDate as runtime#22768

Open
johnleider wants to merge 12 commits intonextfrom
feat/v0-date-integration
Open

refactor(date): delegate to v0 createDate as runtime#22768
johnleider wants to merge 12 commits intonextfrom
feat/v0-date-integration

Conversation

@johnleider
Copy link
Copy Markdown
Member

@johnleider johnleider commented Mar 26, 2026

Summary

  • Migrate Vuetify's date system to use @vuetify/v0's createDate() as the runtime
  • Replace VuetifyDateAdapter (native Date) with v0's Vuetify0DateAdapter (Temporal)
  • Add VuetifyDateBridge<T> to translate Vuetify's string|number param types to v0's number
  • Add LegacyDateAdapterCompat<T> for backwards compat with old custom adapters
  • Rewrite StringDateAdapter over v0's Temporal adapter
  • Consolidate two injection symbols (DateOptionsSymbol + DateAdapterSymbol) into single DateSymbol
  • Update framework.ts to use date.install(app) pattern

Closes vuetifyjs/0#111

Breaking Changes

  • Default date type shifts from Date to Temporal.PlainDateTime
  • Custom adapter authors must implement v0's DateAdapter<T> interface (compat shim provided with deprecation warning)
  • DateAdapterSymbol deprecated — use useDate() instead
  • Third-party date lib adapters will come from @vuetify/v0 (once shipped)

Bridge wraps v0 DateAdapter and translates 4 method signatures where
Vuetify passes firstDayOfWeek as a parameter but v0 uses a property:
startOfWeek, getWeekArray, getWeekdays, getWeek.

Preserves calculateWeekWithFirstDayOfYear locally for the getWeek
firstDayOfYear code path which v0 does not support natively.
Wraps Vuetify-style custom adapters (param-based firstDayOfWeek
signatures) to satisfy v0's DateAdapter interface. This is the
reverse of VuetifyDateBridge — together they form the wrapper chain:

  Old custom adapter → LegacyDateAdapterCompat → VuetifyDateBridge → Components

Translated methods forward the firstDayOfWeek property as a parameter.
v0-only methods use optional chaining with unsupported() fallback.
Replace two-symbol injection (DateOptionsSymbol + DateAdapterSymbol)
with single DateSymbol backed by v0's createDate runtime. Detection
logic classifies adapters as v0-native, legacy class, or legacy
instance and wraps appropriately via LegacyDateAdapterCompat.

Default adapter is Vuetify0DateAdapter when none provided.

Locale sync watches Vuetify's locale.current and pushes resolved
locale strings to v0's adapter. Full ~35 entry locale map preserved
and merged with user overrides.

BREAKING CHANGE: DateOptionsSymbol and DateAdapterSymbol are deprecated.
Use DateSymbol and useDate() instead.
…apter

Replaces the old VuetifyDateAdapter (Date-based) delegation with
Vuetify0DateAdapter (Temporal-based). Implements the full v0 DateAdapter<string>
interface with toBase/fromBase boundary conversion pattern.
- Delete old DateAdapter.ts and adapters/vuetify.ts
- Move DateAdapter interface into bridge.ts (only consumer)
- Update index.ts exports: DateSymbol, VuetifyDateBridge, LegacyDateAdapterCompat, StringDateAdapter
- Update framework.ts: use date.install(app) and DateSymbol instead of manual provides
- Update date.ts import: DateAdapter from ./bridge instead of deleted ./DateAdapter
- Bridge: validate firstDayOfWeek, clamp fractional/out-of-range values
- Calendar: normalize isoDate to date-only format (split at T)
- VDatePicker browser tests: use PlainDateTime properties (.day, .year, .month)
- VDatePicker date tests: update range assertions for PlainDateTime model values
Reverts workarounds from v0.1.12 now that v0 derives firstDayOfWeek
and minimalDays from locale. Requires @vuetify/v0 >= 0.1.13.

Also removes toISO().split('T')[0] workaround in calendar.ts since
v0 now returns date-only strings from toISO().
this.base.getNextMonth(this.base.date(date)!)
)
startOfWeek (date: string, firstDayOfWeek?: number): string {
return this.fromBase(this.base.startOfWeek(this.toBase(date), firstDayOfWeek))
Copy link
Copy Markdown
Contributor

@J-Sek J-Sek Apr 2, 2026

Choose a reason for hiding this comment

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

if v0 is not meant to accept firstDayOfWeek, the workaround would be:

withWeekInfoOverride<T> (action: () => T, firstDayOfWeek?: number): T {
  const old = this.base.firstDayOfWeek
  this.base.firstDayOfWeek = firstDayOfWeek ?? this.base.firstDayOfWeek
  const result = action()
  this.base.firstDayOfWeek = old
  return result
}

startOfWeek (date: string, firstDayOfWeek?: number): string {
  const action = () => this.fromBase(this.base.startOfWeek(this.toBase(date)))
  return firstDayOfWeek
    ? this.withWeekInfoOverride(action, firstDayOfWeek)
    : action()
}

endOfWeek (date: string, firstDayOfWeek?: number): string {
  const action = () => this.fromBase(this.base.endOfWeek(this.toBase(date)))
  return this.withWeekInfoOverride(action, firstDayOfWeek) // shorter if it matters
}

// repeat for:
// - getWeek
// - getWeekdays
// - getWeekArray

@johnleider johnleider self-assigned this Apr 3, 2026
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.

3 participants