Tags: facebook/astryx
Tags
feat(DateInput): show the browser/OS date picker on touch devices
On a phone, tapping the calendar toggle opened a 320px month grid in a
popover — a desktop control shrunk onto a screen whose platform already
ships a date picker every user knows, with system hit areas, momentum
scrolling, and the OS locale and accessibility settings applied.
DateInput now renders `<input type="date">` when the pointer is coarse, so
iOS raises its wheel and Android its calendar dialog, and the toggle button
asks the engine for that picker (`showPicker()`, falling back to focus for
engines without it). The new `nativePicker` prop takes 'touch' (the default),
'always', or 'never' — every value naming when the native picker appears.
The decision is client-side (`useMediaQuery`, SSR-safe), so the server keeps
rendering the text field; a browser without `type="date"` support keeps it
too. min and max carry over to the native control, and dateConstraints —
which a contiguous native range cannot express — keeps 'touch' on the
Calendar popover ('always' refuses a constrained date on commit and
announces it).
DateInput paints the closed field's text itself, so `format` and
`placeholder` keep applying: the control's own text is made transparent and
ours is drawn over it, pointer-transparent so the tap still raises the
picker. The value the control holds stays ISO — all it accepts, and what the
picker reads and writes. The engine owns that text only while the user is
editing date segments: a picker-only control (the iOS wheel, the Android
dialog) has none, so our text holds even with the picker open and tracks the
wheel live, while a segment-editable desktop control hands its text back on
focus. A keydown does the same, as a backstop for a device whose coarse
pointer misreports it. `numberOfMonths` and `weekStartsOn` still do not
apply — they describe a calendar grid the native picker does not have.
Three things the native control needs to behave like the text field it
replaces, each measured on a real iPhone rather than inferred.
Its intrinsic height comes from its inner edit fields rather than
line-height, so it rendered ~2px taller and its value sat off the text
variant's baseline in the same flex row; it is pinned to one line box
(`1lh`, with a calc() fallback) with `appearance: none` to drop iOS's
button-like chrome.
The element is uncontrolled, with a value React never rewrites after mount.
While the iOS picker sheet is open, ANY programmatic write to the field —
React re-rendering a controlled `value`, or syncing a changed `defaultValue`
— detaches the sheet from it: the wheel and Reset keep moving the sheet's
own highlight, but nothing reaches the input and no event fires, so Reset
appeared to do nothing. A plain input carrying the same CSS has no such
problem, which is what ruled the styling out. External changes are pushed in
by an effect that only writes while the field is unfocused, and edits are
read back through native listeners, because React's synthetic change does
not reliably observe this control.
And clearing does not take focus back in native mode: focusing a date
control is what raises the OS picker, so the usual focus restore popped the
picker the clear tap had just dismissed.
PreviousNext