DatePicker

The trigger is a Select's trigger, the panel is a Select's panel, and the grid is a Calendar — all three by construction rather than by resemblance. A select and a date field in one form cannot drift apart, and a calendar in a picker cannot differ from one on a page.

What this component adds is the wiring, and it is worth naming because each piece is a place two things could otherwise disagree:

• the chosen day read into the field through Intl,
• a panel that closes when a day is pressed,
• one set of bounds, which the field, the grid and the chevrons all read.

DatePicker.Calendar takes the Calendar's props minus the ones the picker already owns — value, bounds, locale, first day, variant, disabled — because two sources for one of them would be two answers to one question.

width defaults to trigger with a minWidth of seven cells — the Calendar's own 7 × cell at the picker's size.

So a narrow field opens a panel exactly seven cells wide, and a wide field opens one as wide as itself: the panel belongs to the field, and a month grid squeezed under a narrow one would crush its columns or clip a week. DatePicker.Calendar fills the panel (width: 100%) so a wide one spreads its cells rather than leaving a gap beside them.

Override it like any anchored surface: width="content-fit" for the compact seven-cell panel whatever the field, width={320} for a fixed one, or your own minWidth.

minWidth is maxWidth's mirror — a floor under the resolved width, on DatePicker.Content and Select.Content, and the screen edge still overrides it.

<DatePicker variant="ghost" calendarVariant="primary" />

A quiet trigger over an emphatic chosen day is the ordinary case, so variant dresses the field and calendarVariant dresses the grid. color reaches both — the field's fill and the chosen day's disc are the same brand.

The picker owns the value; the calendar owns the month it is showing. Opening the panel a second time after paging leaves you where you were, and choosing a day in another month still works — paging is not choosing, which calendar.md argues at length.

DatePicker.Calendar is a Calendar, so its year → month → day walk composes here exactly as it does on a page: pass the children, hold view, and mount Calendar.YearPicker / Calendar.MonthPicker in the grid's place.

const [view, setView] = useState<CalendarView>('grid')

<DatePicker onOpenChange={open => { if (!open) setView('grid') }}>
  {/* trigger, overlay … */}
  <DatePicker.Content>
    <DatePicker.Calendar view={view} onViewChange={setView}>
      <Calendar.Header>
        <Calendar.PreviousButton />
        <PressableFeedback onPress={() => setView(v => (v === 'grid' ? 'year' : 'grid'))}>
          <Calendar.Title />
        </PressableFeedback>
        <Calendar.NextButton />
      </Calendar.Header>
      {view === 'year' ? (
        <Calendar.YearPicker />
      ) : view === 'month' ? (
        <Calendar.MonthPicker />
      ) : (
        <>
          <Calendar.Weekdays />
          <Calendar.Grid />
        </>
      )}
    </DatePicker.Calendar>
  </DatePicker.Content>
</DatePicker>

view is the Calendar's, not the picker's — resetting it to 'grid' on close is what makes the panel open on the month every time.

On by default: a picker whose only job is one date has been answered the moment a day is pressed, and a panel that stayed open would need a second control to say so.

closeOnSelect={false} for a picker inside a form that confirms — where the caller writes their own footer under the grid through DatePicker.Calendar's children.

<DatePicker formatOptions={{ dateStyle: 'full' }} />

Anything Intl.DateTimeFormat takes. dateStyle: 'medium' by default — "6 sept. 2026" — because a field is a line on a form and the long form is a sentence.

It changes how the field reads the day and nothing else: the value is a Date at midnight local time either way. A Hermes build with no ICU falls back to the ISO day, which is unambiguous everywhere even where it is nobody's habit.