DatePicker

Usage

Standalone labelled date field — e.g. a sales-filter From/To pair. The value contract is ISO yyyy-mm-dd in and out; pass max (or min) to guard a range against another field.

import { DatePicker } from '@epasslive/design-system'

export function SalesFilter({ fromIso, toIso, setFromIso }: {
  fromIso: string
  toIso: string
  setFromIso: (iso: string) => void
}) {
  return (
    <DatePicker
      id="sales-from"
      label="From"
      value={fromIso}
      onChange={setFromIso}
      max={toIso}
    />
  )
}

DatePicker vs Input type="date"

• Standalone labelled date field (filters, settings, simple forms) → DatePicker: label/error/hint wiring, ISO normalization (accepts string | Date, emits yyyy-mm-dd), size presets, combobox semantics.
• Dense composite form row already converting values via toLocalInput/fromLocalInput helpers → Input type="date" is acceptable (the helpers already speak yyyy-mm-dd).
• A bare styled <input type="date"> is always a violation — never introduce a third pattern.

Accessibility

• The input carries role="combobox" + aria-haspopup="dialog", mirroring the browser’s native date-input exposure; the popup itself is the browser UA widget — keyboard navigation and popup semantics are delegated to it.
• aria-invalid when error is set; error and hint messages are wired through aria-describedby.
• Known wiring defects (documented; fix tracked in the component hardening pass): the visible label lacks htmlFor; the id fallback is the literal "datepicker" so multiple unlabeled pickers collide; when error suppresses hint, aria-describedby still references the missing hint id. Until fixed, pass an explicit unique id and always pass label (or ariaLabel).

Props