Forms & inputExplore · Adapt · Compose
Calendar
A calendar component that allows users to select a date or a range of dates — aligned with the structure and examples on ui.shadcn.com (Radix docs). Make the expected input clear before someone interacts, and keep the current value, help text and validation feedback connected. Explore the live examples, inspect their source and choose the composition that fits your interface before connecting it to your application's data.
The examples use @/components/kamod-ui/calendar in a Preact project. Follow the live result and its source together: compare supported options in the API reference, refine presentation with the component styles guide, and use shared theme tokens for consistent colors and surfaces. Preserve keyboard behavior and meaningful labels as you replace the sample content.
In this guide 7 sections
Installation
Add @kamod-ch/ui to your app and import Calendar. This implementation mirrors the shadcn/ui Calendar **API surface** (modes, captions, disabled, modifiers, week numbers, RTL) without bundling react-day-picker; see [React DayPicker](https://react-day-picker.js.org/) for the upstream reference behaviour.
pnpm add @kamod-ch/uiThe @/components/kamod-ui/… imports in these examples refer to local source files. Configure that alias when copying source, or use the corresponding exports from @kamod-ch/ui when installing the package. Connect the global theme CSS and Tailwind source detection before your first render.
Usage
Import Calendar from @/components/kamod-ui/calendar, then control selected/onSelect in mode="single" or pass a DateRange in mode="range". The shadcn Calendar wraps React DayPicker; Kamod provides a lightweight grid with a parallel prop surface for demos and composition. Build a date picker with Popover and Button (see /docs/date-picker/installation in this app). If the highlighted day shifts vs your timezone, pass timeZone from Intl.DateTimeFormat().resolvedOptions().timeZone on the client (useEffect), as documented on ui.shadcn.com. For a tighter layout (e.g. narrow popovers), pass size="sm".
import { Calendar } from "@/components/kamod-ui/calendar";Choose a complete composition from the examples below; required child components and props vary by pattern.
Component examples & variants
Explore Calendar in different contexts, from the starting pattern to the compositions below. Begin with Demo, then compare the examples that match your content, state and layout. These are working patterns to adapt, not a list of interchangeable variant values: check the API reference before using a prop or combining behaviors. Look at the surrounding labels, supporting text and spacing as well as the component itself.
Read the result and its implementation together. Use each showcase’s Code view to inspect imports and composition, or its Prompt view to prepare a setup or adaptation brief. Try the narrow preview and local theme controls before connecting real data, and use Reset to return an example to its initial state. Keep layout changes in class utilities where appropriate; follow the component styles guide for hierarchy and the theming guide for shared surfaces and colors. The accessibility notes explain what to preserve when making those changes.
Demo
Top-of-page example with captionLayout="dropdown" — same role as the live preview on ui.shadcn.com.
"use client"
import { Calendar } from "@/components/kamod-ui/calendar"
import { useState } from "preact/hooks"
export function CalendarDemo() {
const [date, setDate] = useState<Date | undefined>(new Date())
return (
<Calendar
mode="single"
selected={date}
onSelect={(d) => setDate(d as Date)}
class="rounded-lg border"
captionLayout="dropdown"
/>
)
}Selected Date (With TimeZone)
Pass timeZone so captions align with the user’s zone; detect it client-side to avoid SSR hydration mismatches (see shadcn note on the same page).
Basic
A basic calendar. We use class="rounded-lg border" like the shadcn examples.
Range Calendar
Use mode="range" with two months and an optional disabled predicate — matches the Range Calendar + disabled snippet on ui.shadcn.com.
Month and Year Selector
Use captionLayout="dropdown" for month and year <select> controls, with ghost prev/next icons on the sides (same chrome as ui.shadcn.com). Month labels follow locale (e.g. März → Mär in de-DE).
Presets
Controlled month / onMonthChange with preset buttons and fixedWeeks for a stable six-row grid.
Date and Time Picker
Calendar plus time fields in the card footer (composition pattern from ui.shadcn.com).
Booked dates
disabled with modifiers and modifiersClassNames for strike-through booked days.
Custom Cell Size
Responsive [--cell-size:…] and dayAddon for secondary labels (e.g. prices). The code tab also shows fixed rem / spacing-token variants from the shadcn page.
Week Numbers
Use showWeekNumber to show ISO week indices (zero-padded), in line with the shadcn example.
Props and data
Configure Calendar using the contracts below. Read the documented options alongside the source definitions to understand which values your application supplies and which details the component owns. Start with a prop or helper, then follow its type link to inspect the declaration without leaving the page.
Props, slots and variants for this component.
TypeScript source at build time. Props inherited through HTMLAttributes, Omit or variant helpers remain references in those declarations; their fields are not flattened here. Match the reference to your installed version, and check a package’s exports before writing an import type. A type exported by a source file is not necessarily re-exported by @kamod-ch/ui.TypeScriptComponent props
? means a field can be omitted; it does not promise a fallback value. Existing documented defaults remain alongside the descriptions. For callbacks, check the argument and return types before connecting your own state or services.Calendar
Calendar component props and accepted values.
| Prop / type | Description |
|---|---|
mode | Documented mode option for Calendar. Check its type alongside the usage examples before supplying a value. Documented default |
selected | Documented selected option for Calendar. Check its type alongside the usage examples before supplying a value. Documented default |
onSelect | Documented onSelect option for Calendar. Check its type alongside the usage examples before supplying a value. Documented default |
value / onValueChange | Documented value / onValueChange option for Calendar. Check its type alongside the usage examples before supplying a value. Documented default |
defaultMonth | Documented defaultMonth option for Calendar. Check its type alongside the usage examples before supplying a value. Documented default |
month / onMonthChange | Documented month / onMonthChange option for Calendar. Check its type alongside the usage examples before supplying a value. Documented default |
numberOfMonths | Documented numberOfMonths option for Calendar. Check its type alongside the usage examples before supplying a value. Documented default |
captionLayout | Documented captionLayout option for Calendar. Check its type alongside the usage examples before supplying a value. Documented default |
size | Visual density; `sm` fits popovers and tight layouts. Documented default |
dir | Documented dir option for Calendar. Check its type alongside the usage examples before supplying a value. Documented default |
showOutsideDays | Show days from adjacent months. Documented default |
fixedWeeks | Pad to six week rows. Documented default |
disabled | Documented disabled option for Calendar. Check its type alongside the usage examples before supplying a value. Documented default |
showWeekNumber | Extra week-index column (ISO week of row start). Documented default |
modifiers | Named date sets for styling via `modifiersClassNames`. Documented default |
modifiersClassNames | Tailwind / arbitrary classes keyed like `modifiers` (e.g. booked). Documented default |
locale | BCP 47 locale for captions and weekday labels. Documented default |
timeZone | Passed to `Intl` where supported; selection still uses local `Date` (use noon-normalized dates to avoid TZ drift). Documented default |
dayAddon | Extra label under the day number (e.g. prices). Omit or return `undefined` for outside days if desired. Documented default |
class | Documented class option for Calendar. Check its type alongside the usage examples before supplying a value. Documented default |
Data type reference
Expand a card to inspect and copy the exact declaration. The code header identifies its repository file; follow imported or inherited types in the implementation source when you need the complete dependency chain. Required-field summaries cover fields declared directly in that type. Source-only helpers and inferred schema outputs describe the local implementation, not additional props you can pass to every component.
DateRangeCalendarModeCalendarSizeCalendarDisabledPropCalendarPropsMonthCaptionPropsdisplayMonth, captionLayout, dir, size, onPrev, onNext, onPickMonthYearDualMonthCaptionPropsfirstMonth, secondMonth, dir, size, onPrev, onNextMonthGridPropsyear, month, mode, showOutsideDays, fixedWeeks, showWeekNumber, isDisabled, modifierClassesFor, hasDayAddon, size, onDayClickCalendarDateTimePanelPropsAccessibility
Build the complete interaction, including the parts outside Calendar. The notes below distinguish the current implementation from the labels, content and behavior your application supplies. Start with the live preview, check the props and data reference, and test the finished composition with real content rather than assuming that an unchanged visual example covers every use case.
Built-in behavior and defaults
Calendar provides day buttons and named previous/next-month controls; dropdown captions label month and year selectors. Those visible controls are useful building blocks, but a button calendar should not be assumed to implement every ARIA date-grid keyboard convention.
Labels and relationships
Explain what date is being selected and the allowed date range. Make the displayed month, selected day and unavailable dates understandable beyond their color. When a day number is ambiguous, verify the rendered button name supplies enough date context.
Keyboard and focus
Check how Tab reaches days and month controls in the current variant before documenting shortcuts. Keep month changes and selection predictable. A disabled day needs an explanation when the reason cannot be understood from the surrounding booking or scheduling instructions.
States and integration details
Do not assume locale formatting also changes every accessible label. Review weekday names, date order and navigation labels after localization. Keep a text-entry alternative for workflows where traversing a large date range is burdensome.
Verify the complete interaction
Check behavior as well as markup. Work through these scenarios in the application where the component will be used. Automated checks can help find structural problems; also review the reading experience with a screen reader, keyboard focus and the actual feedback from your application.
- Choose a date using only the keyboard, including crossing month and year boundaries.
- Read selected, today and unavailable states with assistive technology rather than relying on visual styling.
- Test localized labels, long month names, text zoom and touch use with the exact calendar variant.
Recheck the result after changing theme tokens, translations or class overrides. Include text enlargement, narrow layouts and reduced-motion settings where animation is present. Inspect the component source when a behavior differs from your expectation; a role or state attribute does not implement keyboard interaction by itself.
For background, read the WAI-ARIA authoring guidance and keyboard interface guidance. These explain the patterns; verify browser and assistive-technology behavior for the implementation and audience you actually support.
Build it into your interface
Use the Calendar examples as a starting point, then review the behavior in the context of your own screen. Layout, state and content should work together.
Connect the behavior
Choose where the value lives before wiring up validation. Use the documented change callback, preserve the field name when submitting a native form, and associate help or error text with the control. A placeholder supplements a label; it does not replace one.
Copy the composition, then connect its intent. Replace sample records and callbacks with your own data flow. For options such as value, defaultValue, open or onChange, use only those documented in this component's API; different components expose different contracts.
Give each piece of state one owner. Keep a temporary selection inside the interface when nothing else needs it; lift shared values into a parent when other controls depend on them. Read the prop reference before combining controlled values with defaults. A default normally initializes a control; it is not a substitute for updating its current value.
Connect requests in an event handler or your application’s data layer, never as a side effect of rendering. Keep pending, completed and failed outcomes distinct, preserve useful input after an error, and offer a clear recovery action. If the integration subscribes to an external source, remove that subscription when its owner unmounts; cancel or ignore obsolete requests so an earlier response cannot replace newer results.
Start with the live preview, then exercise the same interaction with your actual data. The type definitions describe accepted values; they do not implement persistence, navigation or server-side validation for you. Keep those responsibilities in the application that composes the UI.
Refine the presentation
Let a parent own the surrounding spacing. Keep related elements together with gap and use semantic surface/foreground pairs so the composition follows the active theme. The wrapper below changes the surrounding layout without assuming extra props on Calendar.
import type { ComponentChildren } from "preact";
export function ExampleSurface({ children }: { children: ComponentChildren }) {
return (
<div class="grid min-w-0 gap-4 rounded-lg border border-border bg-card p-4 text-card-foreground sm:p-6">
{children}
</div>
);
}Put the chosen example inside ExampleSurface, then refine supported variants and sizes using the API above. For application-wide changes, adjust theme tokens instead of repeating fixed colors. See Component styles for hierarchy, density and focus treatments.
Review the complete interaction
- Try an empty value, a valid value and a rejected value; keep the correction visible beside the field.
- Navigate using only the keyboard and verify the label identifies the focused control.
- Check disabled and read-only behavior separately where supported; they communicate different intentions.
The preview's narrow control changes its container width. Also resize the browser when checking viewport-based Tailwind utilities such as sm: and md:, and test overlays in the full page where their portals render.
Compose a complete interface
Calendar is one part of the interaction. Choose companion components for the information or actions that still need a place on the screen. The references below are suggestions to compose deliberately, not extra dependencies you must add to every example.
Keep one source of truth for the operation and let each component communicate a different part of it. For example, waiting, no results and failure need different explanations. Avoid showing contradictory states together, and keep recovery actions close to the message that explains them.
Start with the smallest composition that explains the task. Browse the component library for individual controls or the block collections for complete layouts. Reuse shared theme tokens so these pieces feel consistent in light and dark mode.
Sources & design references
Follow Calendar from its implementation to the ideas behind your own composition. Start with the local API, explore a visual direction, then bring the result back to your app’s shared styles.
Bring it back to your app
A reference becomes useful when it fits your real content. Work through these decisions in order:
- Keep the behavior grounded. Start with the interactive examples, then connect your data and callbacks using the integration guidance. Preserve labels, keyboard access and disabled states as you change the presentation.
- Make the styling repeatable. Use the styles guide for local
classadjustments and theming documentation for shared color decisions. Keep semantic surface and foreground pairs together in both light and dark mode. - Check the complete screen. See how components combine in the block collections, then try long labels, loading states and narrow layouts in your own composition. The Theme Toggle guide helps you expose a scheme switch in the finished interface.