Drivn vs shadcn/ui — Calendar Component Compared

shadcn/ui exports a single Calendar component and changes behavior via a mode prop — mode="single", mode="multiple", or mode="range". Drivn exports Calendar for single-date selection and mounts range mode on the same object as Calendar.Range. One dot access, no mode string, no cast. The Calendar docs cover every prop passed through to react-day-picker.

The usage divergence is small per component but compounds across a form with several pickers. A single import line covers both the single and range variants in Drivn, and TypeScript narrows each to the right selected and onSelect pair — a Date | undefined on the root and a DateRange | undefined on Calendar.Range — without you choosing between union types at the call site.

Three variants ship with the Drivn Calendar, and each one is a preset object merged into the react-day-picker props. default adds nothing. weekNumbers sets showWeekNumber to true, turning on the ISO week column that payroll and sprint-planning UIs tend to require. dropdown sets captionLayout to dropdown and swaps in the dropdownOverrides classNames, so the native month and year selects sit invisibly over a styled label with a small chevron beside it. shadcn/ui has no variant layer — the same three shapes exist, but you assemble each one from loose props every time you render a picker.

The dropdown variant carries one extra convenience. fromYear and toYear are plain numbers that Drivn converts into the startMonth and endMonth Date objects react-day-picker expects, defaulting to a forty-year window centered on the current year. shadcn leaves that conversion to you at every call site. Across a codebase with a signup birthday field, a contract end date, and a reporting range built on the Date Picker, the saved lines are minor individually and obvious in aggregate.

Date range selection is one of the most common calendar patterns — think booking flows, reporting periods, leave requests. Both libraries wrap react-day-picker's mode="range", but they surface it differently. shadcn reuses the same Calendar with a different mode string; Drivn mounts it as Calendar.Range, which is a pure TypeScript win because the selected prop narrows to DateRange | undefined automatically.

Drivn's range component also applies a rangeActive class set only once the range spans more than one day — the range_start, range_middle, and range_end cells get bg-primary with rounded-left and rounded-right corners. If you only need single-day selection wrapped in a popover with a formatted input, use the Date Picker component, which composes Calendar with Popover and Input.

Both libraries accept a locale prop from react-day-picker/locale and pass it through to the underlying locale object. Drivn imports it like import { cs } from 'react-day-picker/locale' and passes it to <Calendar locale={cs} />. That applies month names, weekday labels, and first-day-of-week conventions in one line. No extra i18n dependency, no provider, no context — the locale is plain data that travels with the prop.

If you already use a heavier i18n library such as lingui or next-intl in your Next.js app, the Calendar does not read from it. You pass the matching react-day-picker locale for whatever active locale your app has resolved. The installation guide has the full setup — after npx drivn add calendar the component imports are identical between Drivn and shadcn on this axis.