Saltar al contenido
El Muestrario

componente · @solu30/ui-kit/input

SeasonRangeCalendar

El componente, montado

Cargando el componente del paquete instalado…

Cargando el chunk del paquete instalado…

De dónde se importa

import { SeasonRangeCalendar } from '@solu30/ui-kit/input'

Props

17 props declaradas en los tipos de la versión instalada.
PropRequeridaTipoQué hace
rangesColoredRange[]Colored ranges to paint on the grid. First matching range (array order) wins for a given day.
valueopcionalSeasonRangeCalendarValueCurrent from/to selection. Only meaningful in `mode="select"`.
onChangeopcional(value: SeasonRangeCalendarValue) => voidCalled with the new from/to selection when the user clicks a day in `mode="select"`.
mode"select" | "display""select" — user picks `from` then `to` by clicking days. "display" — read-only overview, no click handling.
showLegendopcionalbooleanShow the color-dot legend below the grid. Default true.
initialMonthopcionalnumberMonth (1-12) to display initially. Defaults to the current real-world month.
weekStartsOnopcional0 | 10 = Sunday, 1 = Monday. Default 1.
monthNamesopcionalreadonly string[]12 month labels, Jan → Dec. Defaults to Spanish.
dayNamesopcionalreadonly string[]7 weekday labels, starting at `weekStartsOn`. Defaults to Spanish.
sizeopcional"compact" | "comfortable"`"compact"` — small fixed-size cells (~32px, datepicker-scale), meant to sit inside a form field of ~300-380px. The grid does NOT stretch to fill a wide container. `"comfortable"` — larger cells that stretch to fill the container width (full-width dashboard/overview usage, the original behavior). Default `"compact"`.
selectionColoropcionalstringFill color (hex) for the from→to selection span in `mode="select"`. The two endpoints get a solid fill of this color (with contrast text); days in between get a lighter tint of it. Falls back to the `primary` design token when not provided (no hardcoded default hex).
granularityopcional"day" | "month"`"day"` — pick individual days (default, unchanged behavior). `"month"` — pick whole calendar months instead: a 12-cell grid (Jan-Dec) replaces the day grid, clicking a month sets `from` to its 1st and (on the second click) `to` its last real day (Feb uses the non-leap "02-28"). Switching granularity never rewrites `value` — a day-precision value is shown as "the months it touches" (full/partial coverage) until the user clicks.
dualPaneopcionalboolean`true` — render TWO independent calendars side by side on desktop (`md:` and up): the LEFT one governs `from`'s month/nav, the RIGHT one governs `to`'s. Below the breakpoint falls back to ONE calendar — WITHOUT `activeEndpoint` set, mobile still picks both endpoints from the same yearless grid (legacy behavior, unchanged); WITH `activeEndpoint` set, mobile shows that endpoint's own dated pane instead (bugfix 2026-07-23, ADR-244 — see `activeEndpoint`'s doc). Each pane's grid year follows ITS OWN endpoint: yearless "MM-DD" ⇒ the non-leap reference calendar + wrap navigation (as always, plus a small "repeats every year" badge in the header since ADR-244); dated "YYYY-MM-DD" ⇒ that real year's layout (Feb 28/29, correct first weekday) + navigation that crosses real year boundaries instead of wrapping, PLUS a year `<select>` in the header (ADR-244) for jumping years directly instead of stepping month-by-month. Only applies to `mode="select"` + `granularity="day"` — ignored (single/legacy layout) for `display` mode or `granularity="month"`. Default `false`.
cellChromeopcional"boxed" | "flat"`"boxed"` (default) — every day/month cell renders with a dashed border (when unpainted by any range/selection) plus a subtle hatch background, so the grid reads as discrete boxes — the original, unchanged behavior. `"flat"` — drops that per-cell border/hatch chrome so unpainted cells sit flush with the surface; only hover/selection/context-range fills convey state, which reads as a calendar rather than a spreadsheet in dense dashboard placements. Opt-in only — existing consumers keep `"boxed"` until they explicitly ask for `"flat"`.
activeEndpointopcional"from" | "to"Controlled "which endpoint does the next day-click set" (opt-in, gestorsalon Tarifas 2026-07-19 — Desde/Hasta chips). Affects the SINGLE-calendar day grid (`buildDayCells`/`handleDayClick`) the same way as always — the two independent `dualPane` DESKTOP panes still target `from`/`to` by construction (left pane always writes `from`, right pane always writes `to`) and stay unaffected there. As of the 2026-07-23 bugfix (ADR-244), it ALSO selects which of those two panes `dualPane`'s MOBILE fallback shows (was previously always the plain yearless single calendar, even for a dated/punctual value — see `dualPane`'s doc). `undefined` (default) ⇒ the legacy alternating behavior (click starts a fresh `from`, next click completes `to`) is UNCHANGED — this prop is purely additive. `"from"`/`"to"` ⇒ a day click always overwrites THAT endpoint only, leaving the other one untouched — the consumer (e.g. a "Desde"/"Hasta" chip pair) owns which endpoint is active; this component never flips it on its own.
conflictRangesopcionalColoredRange[]Extra ranges painted as an ALERT ring (ADR-003 `--ui-warning` token, never the range's own `color`) on top of whatever the cell already shows — used to flag days where the in-edit selection overlaps another season, in addition to a text warning shown elsewhere by the consumer. Same shape/invariants as `ranges` (yearless "MM-DD" recurs every year; dated "YYYY-MM-DD" needs a `viewYear` pane to render, same degrade rule as `ranges`) — the CALLER is responsible for resolving a recurring-vs-punctual pair to a shared day-of-year frame (see `findSeasonOverlaps`/`intersectSeasonRanges` in the gestorsalon consumer): this component only paints whatever `conflictRanges` it's given, it does not re-derive cross-year-frame overlap itself. Opt-in — `undefined`/`[]` renders nothing extra (unchanged default behavior).
classNameopcionalstring