ionbase-ui 0.59.0 → 0.69.0

package/dist/components/iso-date.d.ts

@@ -0,0 +1,53 @@
+import { CalendarDate } from '@internationalized/date';
+import type { DateValue } from '@internationalized/date';
+/**
+ * A calendar date as `YYYY-MM-DD` — no time, no timezone, no offset.
+ *
+ * This is an alias for `string`, so it documents rather than enforces. The
+ * runtime enforcement is in `toCalendarDate`, which throws on a malformed
+ * value instead of silently rendering an empty field.
+ */
+export type IsoDate = string;
+/**
+ * ISO string in, `CalendarDate` out. Throws on anything else.
+ *
+ * THROWING IS THE POINT. The tempting alternative is to return `null` for an
+ * unparseable value, and the first version did. A caller who passed a
+ * `Date`, a timestamp or `'04/12/2026'` then got a date picker that rendered
+ * perfectly with nothing in it, and no indication anywhere that the value it
+ * was handed had been dropped on the floor. An exception names the prop and the
+ * value, which is the difference between a five-second fix and an afternoon.
+ *
+ * `parseDate` is also stricter than it looks: it rejects `2026-02-30` and
+ * `2026-13-01`, so a date that is well-formed but does not exist fails here
+ * too rather than being quietly rounded into a neighbouring month.
+ */
+export declare function toCalendarDate(value: IsoDate | null | undefined, prop: string): CalendarDate | null;
+/**
+ * `CalendarDate` out, ISO string back.
+ *
+ * `toString()` is NOT used, and this is not a stylistic preference. A value
+ * that came from a non-Gregorian calendar stringifies WITH its calendar
+ * annotation — `2569-05-30[u-ca-buddhist]` — which is a correct ISO 8601-2
+ * string and is not what any caller expecting `YYYY-MM-DD` will do anything
+ * sensible with. Building the string from the parts of the Gregorian
+ * projection is what keeps the wire format one shape in every locale.
+ *
+ * The projection to Gregorian happens here rather than being assumed. In
+ * practice react-aria hands back the calendar it was given — `useCalendarState`
+ * converts through `toCalendar` on the way out — so a Gregorian value in is a
+ * Gregorian value out, and this is a no-op. It is written anyway because the
+ * one path where it is NOT a no-op is an unavailable-date predicate being
+ * offered a cell from the DISPLAY calendar, which is the reader's, not ours.
+ */
+export declare function toIso(date: DateValue): IsoDate;
+/**
+ * Wraps an `isDateUnavailable` predicate so the caller receives an ISO string
+ * rather than a `CalendarDate`.
+ *
+ * Returned as `undefined` when there is no predicate, rather than as a function
+ * that always returns false. react-aria checks for the prop's presence in more
+ * than one place, and a no-op function is present.
+ */
+export declare function wrapUnavailable(fn: ((date: IsoDate) => boolean) | undefined): ((date: DateValue) => boolean) | undefined;
+//# sourceMappingURL=iso-date.d.ts.map

package/dist/components/iso-date.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"iso-date.d.ts","sourceRoot":"","sources":["../../src/components/iso-date.ts"],"names":[],"mappings":"AAmCA,OAAO,EACL,YAAY,EAIb,MAAM,yBAAyB,CAAC;AACjC,OAAO,KAAK,EAAE,SAAS,EAAE,MAAM,yBAAyB,CAAC;AAEzD;;;;;;GAMG;AACH,MAAM,MAAM,OAAO,GAAG,MAAM,CAAC;AAK7B;;;;;;;;;;;;;GAaG;AACH,wBAAgB,cAAc,CAC5B,KAAK,EAAE,OAAO,GAAG,IAAI,GAAG,SAAS,EACjC,IAAI,EAAE,MAAM,GACX,YAAY,GAAG,IAAI,CAerB;AAED;;;;;;;;;;;;;;;;GAgBG;AACH,wBAAgB,KAAK,CAAC,IAAI,EAAE,SAAS,GAAG,OAAO,CAO9C;AAED;;;;;;;GAOG;AACH,wBAAgB,eAAe,CAC7B,EAAE,EAAE,CAAC,CAAC,IAAI,EAAE,OAAO,KAAK,OAAO,CAAC,GAAG,SAAS,GAC3C,CAAC,CAAC,IAAI,EAAE,SAAS,KAAK,OAAO,CAAC,GAAG,SAAS,CAG5C"}

package/dist/components/iso-date.js

@@ -0,0 +1,102 @@
+/*
+ * The ISO boundary. Every conversion between the public API and react-aria's
+ * date objects happens here and nowhere else.
+ *
+ * WHY THE PUBLIC API IS A STRING AND NOT A `CalendarDate`
+ *
+ * react-aria's date hooks speak `@internationalized/date`. Exposing that type
+ * on the props would make it a peer dependency: every consumer would have to
+ * install the package and write `parseDate('2026-04-12')` to pass a literal
+ * date. That is a real cost for a real benefit — non-Gregorian calendar systems
+ * survive the round trip untouched — and the benefit is not the one this system
+ * is optimising for.
+ *
+ * IonBase is written on the premise that the caller is an agent with no
+ * developer reviewing the output. An agent can write `value="2026-04-12"` and
+ * be right; it cannot forget to install a package it was never told about, or
+ * pass a `Date` where a `CalendarDate` was wanted and get a type error it has
+ * no way to act on. `@internationalized/date` stays a dependency of this
+ * package, imported here, and never appears in a consumer's import list.
+ *
+ * WHAT IS GIVEN UP, STATED PLAINLY
+ *
+ * The VALUE is always a Gregorian ISO calendar date. The DISPLAY is not — the
+ * field and the grid are rendered in the user's locale and calendar system via
+ * `createCalendar`, so a Hijri or Buddhist reader sees their own calendar and
+ * the value still comes back as `YYYY-MM-DD`. That is the same split the HTML
+ * `<input type="date">` makes, and it is the one almost every backend wants.
+ *
+ * WHAT THIS IS NOT
+ *
+ * Not a `Date`. `new Date('2026-04-12')` parses as UTC midnight and then prints
+ * as the 11th for anyone west of Greenwich — the single most common date bug
+ * there is. A calendar date has no time and no zone, so it cannot have that
+ * bug, and keeping the string as the wire format is what preserves that.
+ */
+import { CalendarDate, GregorianCalendar, parseDate, toCalendar, } from '@internationalized/date';
+/** Matches exactly `YYYY-MM-DD`. Deliberately not a full ISO 8601 parse. */
+const ISO_DATE = /^\d{4}-\d{2}-\d{2}$/;
+/**
+ * ISO string in, `CalendarDate` out. Throws on anything else.
+ *
+ * THROWING IS THE POINT. The tempting alternative is to return `null` for an
+ * unparseable value, and the first version did. A caller who passed a
+ * `Date`, a timestamp or `'04/12/2026'` then got a date picker that rendered
+ * perfectly with nothing in it, and no indication anywhere that the value it
+ * was handed had been dropped on the floor. An exception names the prop and the
+ * value, which is the difference between a five-second fix and an afternoon.
+ *
+ * `parseDate` is also stricter than it looks: it rejects `2026-02-30` and
+ * `2026-13-01`, so a date that is well-formed but does not exist fails here
+ * too rather than being quietly rounded into a neighbouring month.
+ */
+export function toCalendarDate(value, prop) {
+    if (value == null || value === '')
+        return null;
+    if (typeof value !== 'string' || !ISO_DATE.test(value)) {
+        throw new TypeError(`${prop}: expected a YYYY-MM-DD string, received ${JSON.stringify(value)}. ` +
+            `Date pickers in ionbase-ui take ISO calendar dates, not Date objects or timestamps.`);
+    }
+    try {
+        return parseDate(value);
+    }
+    catch {
+        throw new RangeError(`${prop}: ${JSON.stringify(value)} is well-formed but is not a real date.`);
+    }
+}
+/**
+ * `CalendarDate` out, ISO string back.
+ *
+ * `toString()` is NOT used, and this is not a stylistic preference. A value
+ * that came from a non-Gregorian calendar stringifies WITH its calendar
+ * annotation — `2569-05-30[u-ca-buddhist]` — which is a correct ISO 8601-2
+ * string and is not what any caller expecting `YYYY-MM-DD` will do anything
+ * sensible with. Building the string from the parts of the Gregorian
+ * projection is what keeps the wire format one shape in every locale.
+ *
+ * The projection to Gregorian happens here rather than being assumed. In
+ * practice react-aria hands back the calendar it was given — `useCalendarState`
+ * converts through `toCalendar` on the way out — so a Gregorian value in is a
+ * Gregorian value out, and this is a no-op. It is written anyway because the
+ * one path where it is NOT a no-op is an unavailable-date predicate being
+ * offered a cell from the DISPLAY calendar, which is the reader's, not ours.
+ */
+export function toIso(date) {
+    const g = toCalendar(new CalendarDate(date.calendar, date.era, date.year, date.month, date.day), new GregorianCalendar());
+    const pad = (n, width) => String(n).padStart(width, '0');
+    return `${pad(g.year, 4)}-${pad(g.month, 2)}-${pad(g.day, 2)}`;
+}
+/**
+ * Wraps an `isDateUnavailable` predicate so the caller receives an ISO string
+ * rather than a `CalendarDate`.
+ *
+ * Returned as `undefined` when there is no predicate, rather than as a function
+ * that always returns false. react-aria checks for the prop's presence in more
+ * than one place, and a no-op function is present.
+ */
+export function wrapUnavailable(fn) {
+    if (!fn)
+        return undefined;
+    return (date) => fn(toIso(date));
+}
+//# sourceMappingURL=iso-date.js.map

package/dist/components/iso-date.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"iso-date.js","sourceRoot":"","sources":["../../src/components/iso-date.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAkCG;AACH,OAAO,EACL,YAAY,EACZ,iBAAiB,EACjB,SAAS,EACT,UAAU,GACX,MAAM,yBAAyB,CAAC;AAYjC,4EAA4E;AAC5E,MAAM,QAAQ,GAAG,qBAAqB,CAAC;AAEvC;;;;;;;;;;;;;GAaG;AACH,MAAM,UAAU,cAAc,CAC5B,KAAiC,EACjC,IAAY;IAEZ,IAAI,KAAK,IAAI,IAAI,IAAI,KAAK,KAAK,EAAE;QAAE,OAAO,IAAI,CAAC;IAC/C,IAAI,OAAO,KAAK,KAAK,QAAQ,IAAI,CAAC,QAAQ,CAAC,IAAI,CAAC,KAAK,CAAC,EAAE,CAAC;QACvD,MAAM,IAAI,SAAS,CACjB,GAAG,IAAI,4CAA4C,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,IAAI;YAC1E,qFAAqF,CACxF,CAAC;IACJ,CAAC;IACD,IAAI,CAAC;QACH,OAAO,SAAS,CAAC,KAAK,CAAC,CAAC;IAC1B,CAAC;IAAC,MAAM,CAAC;QACP,MAAM,IAAI,UAAU,CAClB,GAAG,IAAI,KAAK,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,yCAAyC,CAC3E,CAAC;IACJ,CAAC;AACH,CAAC;AAED;;;;;;;;;;;;;;;;GAgBG;AACH,MAAM,UAAU,KAAK,CAAC,IAAe;IACnC,MAAM,CAAC,GAAG,UAAU,CAClB,IAAI,YAAY,CAAC,IAAI,CAAC,QAAQ,EAAE,IAAI,CAAC,GAAG,EAAE,IAAI,CAAC,IAAI,EAAE,IAAI,CAAC,KAAK,EAAE,IAAI,CAAC,GAAG,CAAC,EAC1E,IAAI,iBAAiB,EAAE,CACxB,CAAC;IACF,MAAM,GAAG,GAAG,CAAC,CAAS,EAAE,KAAa,EAAE,EAAE,CAAC,MAAM,CAAC,CAAC,CAAC,CAAC,QAAQ,CAAC,KAAK,EAAE,GAAG,CAAC,CAAC;IACzE,OAAO,GAAG,GAAG,CAAC,CAAC,CAAC,IAAI,EAAE,CAAC,CAAC,IAAI,GAAG,CAAC,CAAC,CAAC,KAAK,EAAE,CAAC,CAAC,IAAI,GAAG,CAAC,CAAC,CAAC,GAAG,EAAE,CAAC,CAAC,EAAE,CAAC;AACjE,CAAC;AAED;;;;;;;GAOG;AACH,MAAM,UAAU,eAAe,CAC7B,EAA4C;IAE5C,IAAI,CAAC,EAAE;QAAE,OAAO,SAAS,CAAC;IAC1B,OAAO,CAAC,IAAI,EAAE,EAAE,CAAC,EAAE,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC,CAAC;AACnC,CAAC"}