@12-apps/ui 3.0.0 → 3.2.0

package/components-catalog.md

@@ -311,6 +311,14 @@ Components for user input and form interactions.
 **Location**: `src/components/form/Calendar`
 **Docs**: `src/components/form/Calendar/Calendar.md`
 
+### DateRangePicker
+**Purpose**: Pick a range of days three ways over one value — calendar, quick ranges, typed dates
+**Use Cases**: Report periods, analytics filters, booking windows, any from/to a reader edits
+**Features**: Range `Calendar` reused (not forked), quick-range column (today, yesterday, this week, last 7/30/365 days, this month, this quarter, this year) with `aria-pressed`, masked `dd/mm/aaaa` fields, `timeZone`-aware "today", a `maxRangeDays` cap that disables over-cap options WITH the reason instead of clamping, overridable copy, stacks on narrow screens
+**Types**: `DateRangeDraft`, `DayWindow`, `DateRangeStatus`, `QuickRange`
+**Location**: `src/components/form/DateRangePicker`
+**Docs**: `src/components/form/DateRangePicker/DateRangePicker.md`
+
 ### Checkbox
 **Purpose**: Toggle selection checkbox
 **Use Cases**: Multi-select, boolean options, agreements

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@12-apps/ui",
-  "version": "3.0.0",
+  "version": "3.2.0",
   "license": "MIT",
   "packageManager": "pnpm@9.0.0",
   "type": "module",
@@ -84,6 +84,7 @@
     "./form/CodeEditor": "./src/components/form/CodeEditor/index.ts",
     "./form/Command": "./src/components/form/Command/index.ts",
     "./form/CreatableSelect": "./src/components/form/CreatableSelect/index.ts",
+    "./form/DateRangePicker": "./src/components/form/DateRangePicker/index.ts",
     "./form/Form": "./src/components/form/Form/index.ts",
     "./form/HeaderButton": "./src/components/form/HeaderButton/index.ts",
     "./form/total-form": "./src/components/form/total-form/index.ts",

package/src/components/data-display/DataViews/data-views-day-input.tsx

@@ -70,6 +70,36 @@ export function maskBrDate(raw: string): string {
   return `${digits.slice(0, 2)}/${digits.slice(2, 4)}/${digits.slice(4)}`;
 }
 
+/**
+ * What has to land on the `<input>` itself rather than on the `TextField`.
+ *
+ * Anything `TextField` does not recognise is spread onto its root `FormControl`
+ * div. `inputMode` went up there once: the attribute sat on a non-editable
+ * wrapper, meant nothing, and the phone went on offering the letter keyboard
+ * for a field that only takes digits (the `dd/mm/aaaa` hint under a QWERTY
+ * layout). Only the `<input>` this reaches decides which keypad opens — and the
+ * same is true of `aria-describedby`, which on the wrapper points at a
+ * description no screen reader will read out for the field.
+ *
+ * `numeric` and not `tel`: both raise a keypad, but the phone one is a dialler
+ * with `+ * #` on it — keys that cannot occur in a date. A paste carrying
+ * separators still lands, because the MASK is what filters the text; the keypad
+ * only narrows what a thumb can reach for.
+ *
+ * Autofill off for the same reason: the browser's saved-value strip covers the
+ * keypad to suggest names and addresses, none of which are a date, and none of
+ * which the mask would keep.
+ */
+function dayInputProps(testId: string, describedBy: string | undefined) {
+  return {
+    'data-testid': testId,
+    maxLength: 10,
+    inputMode: 'numeric' as const,
+    autoComplete: 'off',
+    ...(describedBy ? { 'aria-describedby': describedBy } : {}),
+  };
+}
+
 /**
  * One end of a day window. The BOUND stays `AAAA-MM-DD` — the form the backend's
  * inclusive day comparison already speaks, and the form the chip label reads —
@@ -80,12 +110,23 @@ export function DayBoundInput({
   value,
   onChange,
   testId,
+  error = false,
+  describedBy,
 }: {
   label: string;
   /** The applied bound, `AAAA-MM-DD`, or undefined when this end is open. */
   value: string | undefined;
   onChange: (bound: string | undefined) => void;
   testId: string;
+  /**
+   * Paint the field as rejected. It only ever writes a real day by itself, so
+   * this is for a caller judging the PAIR: a window whose end precedes its
+   * start is two valid days and one impossible period, and the field it was
+   * typed into is the only place to say which half is being complained about.
+   */
+  error?: boolean;
+  /** Id of the element carrying that complaint, so it is read WITH the field. */
+  describedBy?: string;
 }): React.JSX.Element {
   const applied = value ?? '';
   const [text, setText] = useState(() => isoToBr(applied));
@@ -104,6 +145,7 @@ export function DayBoundInput({
       size="small"
       type="text"
       label={label}
+      error={error}
       // The mask IS the placeholder, so the expected order is on screen before
       // the first keystroke rather than discovered by getting it wrong.
       placeholder="dd/mm/aaaa"
@@ -124,28 +166,7 @@ export function DayBoundInput({
       onBlur={() => setText(isoToBr(applied))}
       // The placeholder occupies the space an un-shrunk label would render into.
       InputLabelProps={{ shrink: true }}
-      // `inputMode` HAS to be here rather than on the TextField. Anything
-      // TextField does not recognise is spread onto its root `FormControl` div,
-      // and `inputMode` is not in that list — so passing it up there put the
-      // attribute on a non-editable wrapper, where it means nothing, and the
-      // phone went on offering the letter keyboard for a field that only takes
-      // digits (the `dd/mm/aaaa` hint sitting under a QWERTY layout). Only the
-      // `<input>` this reaches decides which keypad opens.
-      //
-      // `numeric` and not `tel`: both raise a keypad, but the phone one is a
-      // dialler with `+ * #` on it — keys that cannot occur in a date. A paste
-      // carrying separators still lands, because the MASK is what filters the
-      // text; the keypad only narrows what a thumb can reach for.
-      //
-      // Autofill off for the same reason: the browser's saved-value strip
-      // covers the keypad to suggest names and addresses, none of which are a
-      // date, and none of which the mask would keep.
-      inputProps={{
-        'data-testid': testId,
-        maxLength: 10,
-        inputMode: 'numeric',
-        autoComplete: 'off',
-      }}
+      inputProps={dayInputProps(testId, describedBy)}
       sx={{ width: 165 }}
     />
   );

package/src/components/form/DateRangePicker/DateRangePicker.dates.ts

@@ -0,0 +1,149 @@
+/**
+ * Civil-day arithmetic for the range picker.
+ *
+ * Two representations meet here and the boundary between them is the whole
+ * point of the file:
+ *
+ *  - `AAAA-MM-DD` — what the picker's value, the quick ranges and any caller
+ *    speak. A day with no instant attached, so it cannot drift.
+ *  - a LOCAL `Date` at NOON — what `Calendar` deals in. Noon (not midnight) is
+ *    `Calendar.dates.normalizeDate`'s own rule: a daylight-saving jump at
+ *    midnight can move a date across a day boundary, and midday never can.
+ *
+ * The arithmetic itself is `Calendar.dates`' — `addDays` and `startOfWeek` are
+ * imported rather than re-written, so a week here starts on the same day the
+ * grid draws it.
+ *
+ * ONE thing needs a time zone: which day is today. Everything after that is
+ * calendar arithmetic that has no clock in it.
+ */
+import { addDays, startOfWeek } from '../Calendar/Calendar.dates';
+
+import type { DayString, WeekStart } from './DateRangePicker.types';
+
+const NOON = 12;
+const MS_PER_DAY = 86_400_000;
+const MONTHS_PER_QUARTER = 3;
+const DAY_PATTERN = /^(\d{4})-(\d{2})-(\d{2})$/;
+
+/** `[year, month 1-12, day]`, or null when the text is not a day at all. */
+function dayParts(day: DayString): [number, number, number] | null {
+  const parts = DAY_PATTERN.exec(day);
+  if (!parts) return null;
+  return [Number(parts[1]), Number(parts[2]), Number(parts[3])];
+}
+
+const pad = (value: number): string => String(value).padStart(2, '0');
+
+/** `AAAA-MM-DD` from calendar parts. Month is 1-12. */
+function formatDay(year: number, month: number, day: number): DayString {
+  return `${String(year).padStart(4, '0')}-${pad(month)}-${pad(day)}`;
+}
+
+/** A LOCAL `Date` → the day it falls on, read off the same local getters. */
+export function toDayString(date: Date): DayString {
+  return formatDay(date.getFullYear(), date.getMonth() + 1, date.getDate());
+}
+
+/**
+ * `AAAA-MM-DD` → a LOCAL `Date` at noon, or null when the text is not a real
+ * day.
+ *
+ * Deliberately not `new Date(day)`: the spec reads a bare `AAAA-MM-DD` as UTC
+ * midnight, so west of Greenwich it lands on the day BEFORE and every date in
+ * the picker is off by one. The round-trip check is what rejects `2026-02-31`,
+ * which `Date` would otherwise roll silently into March.
+ */
+export function toLocalDay(day: DayString | null | undefined): Date | null {
+  if (!day) return null;
+  const parts = dayParts(day);
+  if (!parts) return null;
+  const date = new Date(parts[0], parts[1] - 1, parts[2], NOON);
+  return toDayString(date) === day ? date : null;
+}
+
+const civilFormatters = new Map<string, Intl.DateTimeFormat>();
+
+function civilFormatter(timeZone: string): Intl.DateTimeFormat {
+  const cached = civilFormatters.get(timeZone);
+  if (cached) return cached;
+  const created = new Intl.DateTimeFormat('en-US', {
+    timeZone,
+    year: 'numeric',
+    month: '2-digit',
+    day: '2-digit',
+  });
+  civilFormatters.set(timeZone, created);
+  return created;
+}
+
+/**
+ * The civil day `now` falls on, on `timeZone`'s clock (the host's when absent).
+ *
+ * Read through `formatToParts` rather than by adding an offset to an epoch: the
+ * zone database already knows about every transition, and reconstructing one by
+ * hand is how a picker ends up a day out for exactly one week of the year.
+ */
+export function todayIn(timeZone: string | undefined, now: Date): DayString {
+  if (!timeZone) return toDayString(now);
+  const parts = civilFormatter(timeZone).formatToParts(now);
+  const read = (type: Intl.DateTimeFormatPartTypes): string =>
+    parts.find((part) => part.type === type)?.value ?? '';
+  return `${read('year')}-${read('month')}-${read('day')}`;
+}
+
+/** The same day `days` later (or earlier). */
+export function shiftDay(day: DayString, days: number): DayString {
+  const date = toLocalDay(day);
+  return date ? toDayString(addDays(date, days)) : day;
+}
+
+/** The 1st of `day`'s month. */
+export function startOfMonthDay(day: DayString): DayString {
+  const parts = dayParts(day);
+  return parts ? formatDay(parts[0], parts[1], 1) : day;
+}
+
+/**
+ * The 1st of `day`'s CALENDAR quarter — Jan/Apr/Jul/Oct. Fiscal quarters are a
+ * different thing and belong in a caller's own quick range, not in a default.
+ */
+export function startOfQuarterDay(day: DayString): DayString {
+  const parts = dayParts(day);
+  if (!parts) return day;
+  const month = parts[1] - ((parts[1] - 1) % MONTHS_PER_QUARTER);
+  return formatDay(parts[0], month, 1);
+}
+
+/** The 1st of January of `day`'s year. */
+export function startOfYearDay(day: DayString): DayString {
+  const parts = dayParts(day);
+  return parts ? formatDay(parts[0], 1, 1) : day;
+}
+
+/** The first day of `day`'s week, on the same week start the grid uses. */
+export function startOfWeekDay(day: DayString, weekStartsOn: WeekStart): DayString {
+  const date = toLocalDay(day);
+  return date ? toDayString(startOfWeek(date, weekStartsOn)) : day;
+}
+
+/**
+ * How many days a window covers, both ends INCLUDED — so a single day is 1.
+ *
+ * Measured on UTC epochs rather than on the local dates: the difference between
+ * two local noons can be 23 or 25 hours across a transition, and dividing that
+ * by a fixed day length is how a 30-day window starts reporting 29.96.
+ */
+export function dayCount(from: DayString, to: DayString): number {
+  const start = dayParts(from);
+  const end = dayParts(to);
+  if (!start || !end) return 0;
+  const startMs = Date.UTC(start[0], start[1] - 1, start[2]);
+  const endMs = Date.UTC(end[0], end[1] - 1, end[2]);
+  return Math.round((endMs - startMs) / MS_PER_DAY) + 1;
+}
+
+/** `AAAA-MM-DD` sorts lexicographically, so this needs no parsing at all. */
+export function isAfterDay(a: DayString, b: DayString): boolean {
+  return a > b;
+}

package/src/components/form/DateRangePicker/DateRangePicker.hooks.ts

@@ -0,0 +1,87 @@
+/**
+ * Everything the picker derives and every way its range can move, kept out of
+ * the component so that file is a layout and this one is the behaviour — the
+ * same split `Calendar.hooks.ts` uses next door.
+ */
+import { useId, useMemo, useState } from 'react';
+
+import { toDayString, todayIn } from './DateRangePicker.dates';
+import {
+  activeQuickRangeId,
+  defaultMessages,
+  resolveDayRange,
+  resolveQuickRanges,
+} from './DateRangePicker.range';
+import type {
+  DateRangeChangeMeta,
+  DateRangeDraft,
+  DateRangePickerState,
+  UseDateRangePickerArgs,
+} from './DateRangePicker.types';
+
+export function useDateRangePicker({
+  value,
+  onChange,
+  timeZone,
+  now,
+  maxRangeDays,
+  weekStartsOn,
+  quickRanges,
+  messages,
+}: UseDateRangePickerArgs): DateRangePickerState {
+  const statusId = useId();
+  // `Calendar` reads which month to open on from the range it is handed, and
+  // only when it MOUNTS. Bumping this key remounts it, which is how the other
+  // two views move it. It changes for a quick pick and for a typed date and
+  // NEVER for a click inside the grid — a calendar that jumped under the
+  // pointer picking in it would be unusable.
+  const [viewNonce, setViewNonce] = useState(0);
+
+  const copy = useMemo(() => ({ ...defaultMessages(), ...messages }), [messages]);
+  const today = useMemo(() => todayIn(timeZone, now ?? new Date()), [timeZone, now]);
+  const options = useMemo(
+    () => resolveQuickRanges(quickRanges, { today, weekStartsOn }, maxRangeDays),
+    [quickRanges, today, weekStartsOn, maxRangeDays],
+  );
+  const status = useMemo(() => resolveDayRange(value, maxRangeDays), [value, maxRangeDays]);
+
+  const emit = (
+    next: DateRangeDraft,
+    source: DateRangeChangeMeta['source'],
+    quickRangeId?: string,
+  ): void => {
+    onChange(next, {
+      source,
+      ...(quickRangeId ? { quickRangeId } : {}),
+      // Judged here, once. A caller left to re-derive "is this usable" is a
+      // second opinion able to disagree with the message on screen.
+      status: resolveDayRange(next, maxRangeDays),
+    });
+  };
+
+  return {
+    copy,
+    options,
+    activeId: activeQuickRangeId(options, value),
+    status,
+    statusId,
+    viewNonce,
+    pickQuick: (option) => {
+      setViewNonce((nonce) => nonce + 1);
+      emit({ from: option.window.from, to: option.window.to }, 'quick', option.id);
+    },
+    editBound: (which, bound) => {
+      setViewNonce((nonce) => nonce + 1);
+      emit({ ...value, [which]: bound }, which);
+    },
+    pickOnCalendar: (range) => {
+      emit(
+        {
+          from: range.start ? toDayString(range.start) : null,
+          to: range.end ? toDayString(range.end) : null,
+        },
+        'calendar',
+      );
+    },
+  };
+}

package/src/components/form/DateRangePicker/DateRangePicker.md

@@ -0,0 +1,228 @@
+# DateRangePicker
+
+Three views of ONE day range — a range calendar, a quick-pick column, and two
+typed `dd/mm/aaaa` fields. Change any and the other two follow.
+
+## Purpose
+
+A range calendar alone makes "this quarter" cost two clicks, a month of paging
+and a mental note of which day a quarter starts on. A list of presets alone
+cannot express "the 3rd to the 19th". Typed fields alone make you spell out a
+window you can already see. Each of the three is the fastest route to a
+*different* range, so this control offers all three over one value instead of
+picking a favourite.
+
+It is a design-system control and knows nothing about the data behind the
+range. The quick list, the maximum length and the clock "today" is read on are
+all props — a consumer with its own periods passes them rather than teaching
+this component about its domain.
+
+## Not a fork of Calendar
+
+The calendar half **is** [`Calendar`](../Calendar/Calendar.md) in
+`selectionMode="range"`. The hover preview, the keyboard grid, backwards
+selection and the length check all come from there. This component composes it;
+it does not reimplement it.
+
+The typed fields are `DayBoundInput`, the masked `dd/mm/aaaa` field the data
+views already use — imported from inside the package rather than exported,
+because a second masked date field would mean a second set of rules for what
+backspace does.
+
+## Public API
+
+```ts
+interface DateRangePickerProps {
+  value: DateRangeDraft;                    // { from: string | null; to: string | null }
+  onChange: (next: DateRangeDraft, meta: DateRangeChangeMeta) => void;
+  timeZone?: string;                        // IANA zone (or offset) TODAY is read on
+  now?: Date;                               // freeze the clock (stories, tests)
+  maxRangeDays?: number;                    // longest usable range, inclusive days
+  weekStartsOn?: 0 | 1 | 2 | 3 | 4 | 5 | 6; // default 0 (Sunday)
+  quickRanges?: QuickRange[];               // default: the nine below; [] hides the column
+  locale?: string;                          // month names / weekday initials
+  numberOfMonths?: number;                  // default 2
+  messages?: Partial<DateRangePickerMessages>;
+  dataTestId?: string;                      // default 'date-range-picker'
+  className?: string;
+}
+```
+
+### The value is a DRAFT, not a window
+
+`value` is `{ from, to }` with either end possibly `null`, and it accepts a pair
+that is reversed or too long. A control whose value could only hold a legal
+range has nowhere to put a reader who typed the end date first, and has to
+either discard the keystrokes or lie about what is on screen.
+
+Every `onChange` carries the verdict with it:
+
+```ts
+interface DateRangeChangeMeta {
+  source: 'quick' | 'calendar' | 'from' | 'to';
+  quickRangeId?: string;      // set only when source is 'quick'
+  status: DateRangeStatus;    // { ok: true, window, days } | { ok: false, problem, days }
+}
+```
+
+`resolveDayRange(draft, maxRangeDays)` is exported so a caller's confirm button
+reads the SAME verdict rather than re-deriving "is this usable" from the two
+strings and drifting from the message on screen.
+
+`quickRangeId` is what lets a caller express a pick as its own thing. The
+reports surface uses it to apply its real `today` preset when "Hoje" is chosen,
+so the period afterwards reads `Hoje` and not `Personalizado…`.
+
+## Quick ranges
+
+Nine built-ins, all derivable from today and the calendar alone:
+
+| id | window |
+|---|---|
+| `today` | today |
+| `yesterday` | the day before today |
+| `this-week` | the `weekStartsOn` day of this week → today |
+| `last-7-days` | today and the 6 days before it |
+| `this-month` | the 1st of this month → today |
+| `last-30-days` | today and the 29 days before it |
+| `this-quarter` | the 1st of this CALENDAR quarter (Jan/Apr/Jul/Oct) → today |
+| `this-year` | 1 January → today |
+| `last-365-days` | today and the 364 days before it |
+
+"Last N days" **includes** today: on the 10th, "last 7 days" is the 4th through
+the 10th. Quarters are calendar quarters; a fiscal quarter is a caller's own
+`quickRanges` entry, not a variant of this one.
+
+`createQuickRanges({ today: 'Hoje', … })` relabels the built-ins without
+re-deriving their arithmetic — which is how two lists that claim the same thing
+start disagreeing. `quickRanges` replaces the list wholesale; `[]` removes the
+column.
+
+## Time zone
+
+Civil days are zone-free; **which day is today is not**. At 21:30 on 31 July in
+São Paulo it is already 1 August in UTC, so "this month" resolved on the host's
+clock can name a period the reader's store has not reached. `timeZone` is read
+for exactly one thing — today — and every quick range hangs off it.
+
+Absent, the host's own zone is used. That is right for a picker over the
+reader's own data and wrong for one reporting on somewhere else.
+
+## Maximum length
+
+`maxRangeDays` is an inclusive day count and is enforced in three places at
+once:
+
+- a quick range longer than it is `aria-disabled`, keeps its place in the tab
+  order, and renders the reason under its label;
+- the calendar is given the same ceiling, so it cannot close a range over it;
+- a typed pair over it is reported as `problem: 'over-max'` with the reason in
+  the status line.
+
+**Nothing is ever clamped.** Handing back eleven months for a control labelled
+"This year" is worse than refusing: the reader gets a number for a period they
+did not ask for and nothing on screen says so.
+
+## When a typed date commits
+
+The moment it is a **whole, real day** — eight digits naming a date that exists.
+
+- Not on every keystroke: `2026` passes through `0002`, `0020` and `0202`, each
+  a legal year, and committing those sends the calendar to the year 20 while the
+  reader is still typing.
+- Not only on blur: someone who types a date and looks at the calendar to check
+  it would see the old month until they clicked somewhere else.
+- Half-typed text stays in the field and changes nothing; leaving the field
+  discards it and shows what the range actually is.
+- Enter needs no special case — by the time it can be pressed, the date has
+  already committed.
+
+## Which month the calendar shows
+
+`Calendar` reads its opening month from the range it is handed, and only when it
+mounts. The picker remounts it when a **quick pick** or a **typed date** moves
+the range, and never when a day inside the grid is clicked — a calendar that
+jumped under the pointer picking in it would be unusable.
+
+So the grid follows the range's **start**. Picking "This year" in August moves
+it to January, because that is where the range now begins.
+
+## Layout
+
+Calendar first, quick column beside it (`md` and up), fields underneath. Below
+`md` the quick entries wrap and stack under the calendar rather than taking a
+column out of the day grid: at 390px a side column squeezes the grid to about
+half its width and the numbers stop being readable.
+
+There is no `size` prop. The day grid has a fixed metric that a size scale would
+not change, and a prop that only altered the padding of the quick entries would
+be a scale in name only.
+
+## Accessibility
+
+- The quick entries are native `<button>`s with `aria-pressed`; the active one
+  is the entry the draft currently equals. (A listbox with `aria-selected` would
+  model this too — the rule is to pick one and use it for every entry.)
+- Over-cap entries are `aria-disabled`, **not** `disabled`: a disabled button is
+  skipped by the tab order, so the reason under it would be unreachable by
+  exactly the reader most likely to need it. They also carry
+  `aria-describedby` pointing at that reason.
+- The status line is `role="status" aria-live="polite"`, so a refusal is spoken
+  when it appears rather than found by someone who goes looking.
+- Both fields point at that line through `aria-describedby`, and are marked
+  `error` when the PAIR is impossible — never merely incomplete, which would
+  make the first click of a two-click control look like a mistake.
+- Keyboard: the quick column is buttons; the grid is `Calendar`'s own roving
+  focus (arrows, `Home`/`End`, `PageUp`/`PageDown`, Enter/Space).
+
+## Copy
+
+Every string is in `messages` and defaults to English. The summary prints days
+in the same `dd/mm/aaaa` the fields are masked to rather than in the host
+locale's order: one control cannot show the same date two ways, and an `en-US`
+summary reading `08/05` over a field reading `05/08` leaves the reader to work
+out which is lying. Replace `messages.summary` to choose another order.
+
+## Test IDs
+
+All derived from `dataTestId` (default `date-range-picker`):
+
+| id | element |
+|---|---|
+| `{root}` | the container |
+| `{root}-quick-list` | the quick group |
+| `{root}-quick-{quickRangeId}` | one quick entry |
+| `{root}-from`, `{root}-to` | the two `<input>`s |
+| `{root}-status` | the summary / refusal line |
+
+The calendar keeps its own ids (`calendar-container`, `calendar-header`,
+`calendar-date-{day}`). **`calendar-date-{day}` is the day of the month only**,
+so with two months on screen every day appears twice; a test that selects days
+by that id should render `numberOfMonths={1}`.
+
+## Usage
+
+```tsx
+const [range, setRange] = useState<DateRangeDraft>({ from: null, to: null });
+const [status, setStatus] = useState<DateRangeStatus>(resolveDayRange(range));
+
+<DateRangePicker
+  value={range}
+  onChange={(next, meta) => {
+    setRange(next);
+    setStatus(meta.status);
+  }}
+  timeZone="America/Sao_Paulo"
+  maxRangeDays={366}
+  locale="pt-BR"
+  numberOfMonths={1}
+/>
+<Button disabled={!status.ok} onClick={() => status.ok && apply(status.window)}>
+  Aplicar
+</Button>
+```
+
+## Related
+
+- [`Calendar`](../Calendar/Calendar.md) — the range grid this composes
+- `DataViews` — where the masked `dd/mm/aaaa` field comes from