@sesamehr/react-design-system 2.0.0-beta.5 → 2.0.0-beta.7

package/dist/Forms/Field/useFieldGroup.d.ts

@@ -0,0 +1,108 @@
+/**
+ * What a `<OxFieldGroup>` hands to the label, the control and the message
+ * inside it.
+ *
+ * `FieldGroup` already paints its children through custom properties
+ * (`--message-text-color`, `--controller-border-color`), and that stays: it is
+ * what lets a consumer's own control inherit the error colour with no prop
+ * drilling. A custom property cannot carry an `id` or an `aria-invalid`,
+ * though, so the accessible half needs a real context beside it.
+ *
+ * Every piece is optional. A control used on its own — no `FieldGroup`
+ * anywhere above it — gets an empty attribute bag and renders exactly as it
+ * did before, which is why `useFieldGroup` returns `undefined` instead of
+ * throwing the way `useInputPassword` does. There, a subcomponent outside its
+ * root is meaningless; here, a bare `<OxInputText>` is a perfectly good input.
+ *
+ * Nothing emits an IDREF that points at nothing. `aria-describedby` waits for
+ * a message to mount, `aria-labelledby` for a label, and `<label htmlFor>` for
+ * a control to claim the id — a reference to an element that is not there is
+ * worse than no reference, because some readers then announce nothing at all
+ * rather than falling back.
+ */
+export type FieldVariant = 'default' | 'error' | 'success' | 'warning';
+/** The parts of the group that announce themselves so an IDREF never dangles. */
+type FieldPart = 'label' | 'message';
+export interface FieldGroupContextValue {
+    /**
+     * Id on the `<label>`. A composite control — one with several focusable
+     * children, where `htmlFor` has no single target — names itself by pointing
+     * `aria-labelledby` here.
+     */
+    labelId: string;
+    /** Id on the message, and what a control points `aria-describedby` at. */
+    messageId: string;
+    /** What `<label htmlFor>` points at, once a control has claimed it. */
+    controlId: string | undefined;
+    variant: FieldVariant;
+    hasLabel: boolean;
+    hasMessage: boolean;
+    /** Announce a part as mounted. Returns the call that takes it back. */
+    register: (_part: FieldPart) => () => void;
+    /**
+     * Offer an id as the one the label names. The first control to ask gets it;
+     * a second is refused, because one label names one thing.
+     */
+    claimControl: (_id: string) => () => void;
+}
+export interface FieldControlAttrs {
+    id?: string;
+    'aria-invalid'?: true;
+    'aria-describedby'?: string;
+}
+export interface FieldControlGroupAttrs {
+    'aria-labelledby'?: string;
+    'aria-invalid'?: true;
+    'aria-describedby'?: string;
+}
+export interface FieldLabelAttrs {
+    id?: string;
+    htmlFor?: string;
+}
+export declare const FieldGroupContext: import('react').Context<FieldGroupContextValue | null>;
+/**
+ * The surrounding field, or `undefined` when there is none.
+ *
+ * Deliberately not a throwing `useXxx`: the context is optional, so its
+ * absence is not an error.
+ */
+export declare function useFieldGroup(): FieldGroupContextValue | undefined;
+/**
+ * Wiring for a control the `<label>` can point `htmlFor` at — anything
+ * labelable: `input`, `textarea`, `select`, and the `button`s Radix renders
+ * for a checkbox, a switch or a select trigger.
+ *
+ * Spread it *before* `{...props}` so the caller's attributes win over it, and
+ * hand it the caller's own `id`: that is what makes an explicit `id` survive,
+ * with the label following it there rather than staying on the generated one.
+ * Vue's half reads the id out of `useAttrs()` instead — React has no such
+ * channel, so the prop has to be passed in.
+ */
+export declare function useFieldControl(id?: string): FieldControlAttrs;
+/**
+ * Wiring for a composite — `OxRadioGroup`, `OxInputOtp` — where "put the id on
+ * the control" has no single answer because there are several focusable
+ * elements and one id cannot be on all of them.
+ *
+ * It names itself with `aria-labelledby` instead, so the element it goes on
+ * needs a role that takes a name from the author: Radix gives its radio group
+ * `role="radiogroup"`, and anything else has to say `role="group"` itself. On
+ * a plain `<div>` the name is dropped on the floor.
+ */
+export declare function useFieldControlGroup(): FieldControlGroupAttrs;
+/** Wiring for a `<label>` inside the group: its own id, and what it names. */
+export declare function useFieldLabel(): FieldLabelAttrs;
+/**
+ * Wiring for the message: the id a control describes itself with, and the
+ * group's variant so it does not have to be written on both.
+ */
+export declare function useFieldMessage(): {
+    id?: string;
+    variant?: FieldVariant;
+};
+/**
+ * The state a `<OxFieldGroup>` owns. Split out of the component so the ids and
+ * the bookkeeping live next to the hooks that read them.
+ */
+export declare function useProvideFieldGroup(variant: FieldVariant): FieldGroupContextValue;
+export {};

package/dist/Forms/Inputs/Calendar/Calendar.d.ts

@@ -0,0 +1,55 @@
+import { CalendarDayState } from './CalendarDay.tsx';
+import { CalendarConstraints } from './constraints.ts';
+import { CalendarNav } from './nav.ts';
+/** One day. Falls back to `OxCalendarDay`. */
+type DayRenderer = (props: {
+    date: Date;
+    state: CalendarDayState;
+}) => React.ReactNode;
+/**
+ * A month of days, and nothing around it. Mirrors `@sesame/orxata-core`
+ * Calendar.
+ *
+ * `Calendar` speaks `Date`. A `Date` at the boundary means the calendar day
+ * formed by its local year, month and day: the time is ignored on the way in,
+ * and is local midnight on the way out.
+ *
+ * There is no month title and no navigation — `header` is not called until you
+ * pass one, and is handed everything a header needs. The shared, opinionated
+ * one belongs a layer up, in `DatePicker`.
+ *
+ * Not `OxCalendarDate`, which also ships: that is a `<time>` chip showing a day
+ * and an abbreviated month, not a grid.
+ */
+export interface CalendarProps extends Pick<React.HTMLAttributes<HTMLDivElement>, 'className'> {
+    /** The selected day, or `undefined` for none. Controlled. */
+    value?: Date;
+    /** The initially selected day, for the uncontrolled case. */
+    defaultValue?: Date;
+    onValueChange?: (value: Date | undefined) => void;
+    /** How many month grids to render. */
+    months?: number;
+    /** What can be picked, and where navigation stops. */
+    constraints?: CalendarConstraints;
+    /**
+     * Empty by default. Receives the visible month and the navigation state,
+     * because without those nobody could build a header at all.
+     */
+    header?: (nav: CalendarNav) => React.ReactNode;
+    /**
+     * One month's name, above its grid. Falls back to the month and year from
+     * `Intl`, and only renders when `months` is more than one — a lone month is
+     * named by `header`, and naming it twice is worse than not at all.
+     */
+    month?: (props: {
+        month: Date;
+    }) => React.ReactNode;
+    /** One day. Falls back to `OxCalendarDay`. */
+    day?: DayRenderer;
+    dataTestid: string;
+}
+export declare const Calendar: {
+    ({ className, value, defaultValue, onValueChange, months, month: renderMonth, constraints, header, day, dataTestid, }: CalendarProps): import("react/jsx-runtime").JSX.Element;
+    displayName: string;
+};
+export {};

package/dist/Forms/Inputs/Calendar/CalendarDay.d.ts

@@ -0,0 +1,37 @@
+/**
+ * The five booleans are what `Calendar` hands to the `day` render prop, and
+ * they are the `data-*` vocabulary this emits. `range` is `CalendarRange`'s
+ * alone.
+ */
+export interface CalendarDayState {
+    selected: boolean;
+    today: boolean;
+    disabled: boolean;
+    outside: boolean;
+    focused: boolean;
+    range?: 'start' | 'middle' | 'end';
+}
+export interface CalendarDayProps extends React.ButtonHTMLAttributes<HTMLButtonElement> {
+    /**
+     * Partial so a single state can be shown on its own, which is what the guide
+     * does. Inside a calendar the render prop always supplies all of it.
+     */
+    state?: Partial<CalendarDayState>;
+}
+/**
+ * One day in a calendar grid: a button that shows its number and paints the
+ * state it is told about. Mirrors `@sesame/orxata-core` CalendarDay.
+ *
+ * Not `OxCalendarDate`, which also ships and which the name invites confusing
+ * this with. That one is a `<time>` chip showing a day and an abbreviated
+ * month — no button, no selection, no keyboard. This one is the cell.
+ *
+ * It is **told** its state and never reads it from context, so it renders on
+ * its own — the guide shows the states as a legend, outside any calendar — and
+ * so that it is assembled the same way as its Vue original.
+ *
+ * `disabled` is applied before the prop spread on purpose: `DayPicker` passes
+ * its own, leaving a focused-but-disabled day focusable with `aria-disabled`
+ * instead, and its answer has to win over the one derived from `state`.
+ */
+export declare const CalendarDay: import('react').ForwardRefExoticComponent<CalendarDayProps & import('react').RefAttributes<HTMLButtonElement>>;

package/dist/Forms/Inputs/Calendar/CalendarRange.d.ts

@@ -0,0 +1,56 @@
+import { CalendarDayState } from './CalendarDay.tsx';
+import { CalendarConstraints } from './constraints.ts';
+import { CalendarNav } from './nav.ts';
+/** One day. Falls back to `OxCalendarDay`. */
+type DayRenderer = (props: {
+    date: Date;
+    state: CalendarDayState;
+}) => React.ReactNode;
+/**
+ * `start` and `end`, not `from` and `to` — those two words are already the
+ * navigation bounds in `constraints`, and one word meaning two things inside
+ * the same component is the confusion this naming was chosen to avoid.
+ */
+export interface CalendarDateRange {
+    start?: Date;
+    end?: Date;
+}
+/**
+ * A month of days where two clicks pick a span. Mirrors `@sesame/orxata-core`
+ * CalendarRange. A sibling of `Calendar` with its own API, not a part of it.
+ *
+ * Same date contract: a `Date` at the boundary means the calendar day formed by
+ * its local year, month and day.
+ */
+export interface CalendarRangeProps extends Pick<React.HTMLAttributes<HTMLDivElement>, 'className'> {
+    /** The selected span. Either end may be absent while one is being picked. */
+    value?: CalendarDateRange;
+    /** The initially selected span, for the uncontrolled case. */
+    defaultValue?: CalendarDateRange;
+    onValueChange?: (value: CalendarDateRange) => void;
+    /** How many month grids to render. */
+    months?: number;
+    /** What can be picked, and where navigation stops. */
+    constraints?: CalendarConstraints;
+    /**
+     * Empty by default. Receives the visible month and the navigation state,
+     * because without those nobody could build a header at all.
+     */
+    header?: (nav: CalendarNav) => React.ReactNode;
+    /**
+     * One month's name, above its grid. Falls back to the month and year from
+     * `Intl`, and only renders at all when there is more than one grid — a lone
+     * month is named by `header`, and naming it twice is worse than not at all.
+     */
+    month?: (props: {
+        month: Date;
+    }) => React.ReactNode;
+    /** One day. Falls back to `OxCalendarDay`. */
+    day?: DayRenderer;
+    dataTestid: string;
+}
+export declare const CalendarRange: {
+    ({ className, value, defaultValue, onValueChange, months, month: renderMonth, constraints, header, day, dataTestid, }: CalendarRangeProps): import("react/jsx-runtime").JSX.Element;
+    displayName: string;
+};
+export {};

package/dist/Forms/Inputs/Calendar/constraints.d.ts

@@ -0,0 +1,19 @@
+/**
+ * What can be picked, and where navigation stops.
+ *
+ * Grouped on purpose: the three fields are one concept, and the range-length
+ * pair `CalendarRange` will eventually want has to fit here without a redesign.
+ *
+ * The bounds are `from` / `to`, not `min` / `max`. In `react-day-picker` those
+ * two words already mean the minimum and maximum *number of days* a range may
+ * span, which is the length limit this will grow. Keeping them free avoids the
+ * collision instead of explaining it forever.
+ */
+export interface CalendarConstraints {
+    /** The earliest month the calendar will navigate to. */
+    from?: Date;
+    /** The latest month the calendar will navigate to. */
+    to?: Date;
+    /** Called per day. Return `true` to make it unpickable. */
+    isDisabled?: (date: Date) => boolean;
+}

package/dist/Forms/Inputs/Calendar/date.d.ts

@@ -0,0 +1,28 @@
+/**
+ * Mirrors `@sesame/orxata-core`'s `date.ts`. Internal — none of this is
+ * exported from the package.
+ *
+ * The Vue half also converts between the `Date` a caller speaks and the
+ * `CalendarDate` reka needs; `react-day-picker` speaks `Date` throughout, so
+ * only the part both sides need lives here.
+ */
+/**
+ * Whether `day` only appears in `month`'s grid as padding, while the month it
+ * actually belongs to has a grid of its own on screen.
+ *
+ * Every grid pads its first and last weeks with days of the neighbouring
+ * months, so with `months: 2` the 4th of April is drawn twice: once in April's
+ * grid, which owns it, and once in the tail of March's. Both copies read the
+ * same selection, so a range ending on the 4th was painted as ending in two
+ * places at once.
+ *
+ * The rule is contextual, not per-grid — "a day another visible grid owns" —
+ * which is why the visible months have to be passed in rather than inferred
+ * from `month` alone. March's *leading* days from February stay drawn when
+ * February is not on screen, and disappear when it is.
+ *
+ * With a single grid nothing else is visible to own the day, so this is always
+ * `false` and every outside day is drawn exactly as before. That is the whole
+ * reason the behaviour needs no prop: it follows from how many months are up.
+ */
+export declare function isDrawnByAnotherMonth(day: Date, month: Date, visible: readonly Date[]): boolean;

package/dist/Forms/Inputs/Calendar/index.d.ts

@@ -0,0 +1,21 @@
+import { VariantProps } from 'class-variance-authority';
+export { Calendar, type CalendarProps } from './Calendar.tsx';
+export { CalendarRange, type CalendarRangeProps, type CalendarDateRange, } from './CalendarRange.tsx';
+export { CalendarDay, type CalendarDayProps, type CalendarDayState, } from './CalendarDay.tsx';
+export type { CalendarConstraints } from './constraints.ts';
+export type { CalendarNav } from './nav.ts';
+/**
+ * Only the range position varies here. The other five states — selected,
+ * today, disabled, focused, outside — are `data-*` attributes rather than
+ * classes, because those five are the vocabulary a caller writes their own CSS
+ * against and a parallel set of class names would be a second spelling of the
+ * same thing.
+ *
+ * The range position is not in that vocabulary: it is `CalendarRange`'s alone,
+ * and `react-day-picker` and reka disagree about what to call it, so it stays
+ * ours and stays a class.
+ */
+export declare const calendarDayVariants: (props?: ({
+    range?: "end" | "start" | "middle" | null | undefined;
+} & import('class-variance-authority/types').ClassProp) | undefined) => string;
+export type CalendarDayVariants = VariantProps<typeof calendarDayVariants>;

package/dist/Forms/Inputs/Calendar/nav.d.ts

@@ -0,0 +1,34 @@
+/**
+ * What a calendar hands to whoever draws its header.
+ *
+ * `Calendar` and `CalendarRange` render no header of their own, so this is the
+ * whole of what a header can be built from — a type rather than an inline
+ * literal because `DatePickerHeader` takes it as one prop, and a header that
+ * cannot name its own argument is one every caller has to retype.
+ */
+export interface CalendarNav {
+    /** The first month on screen. */
+    month: Date;
+    /**
+     * How many month grids are on screen, which is what a step moves by. A header
+     * that names only `month` names one of several and is wrong about the rest.
+     */
+    months: number;
+    /** Page one screenful back, or forward. A screenful is `months` months. */
+    goToPrev: () => void;
+    goToNext: () => void;
+    canGoPrev: boolean;
+    canGoNext: boolean;
+    /**
+     * Jump to the month a `Date` falls in, however far away it is.
+     *
+     * Stepping cannot express "the same month next year" — twelve calls to
+     * `goToNext` only land there when `months` divides twelve, and in React they
+     * do not compound at all, since each one is computed from the month of the
+     * render that produced them. Anything that moves by more than a page needs
+     * this: `OxDatePickerMonthSelect` and `OxDatePickerYearSelect`, and any month
+     * or year list a caller builds instead. It outlived the header's year arrows,
+     * which were the first thing to need it.
+     */
+    goTo: (month: Date) => void;
+}

package/dist/Forms/Inputs/Calendar/testids.d.ts

@@ -0,0 +1,28 @@
+/**
+ * Test ids are derived from the root's, so `months: 12` still produces twelve
+ * distinct `day-12`s — the month precedes them.
+ *
+ * The month is numeric, not a name: a name derived from `Intl` becomes
+ * `month-marzo` the moment the locale changes, and takes every test with it.
+ *
+ *   calendar-for-vacations                       ← root, supplied by the caller
+ *   calendar-for-vacations-month-2026-03         ← each month grid
+ *   calendar-for-vacations-month-2026-03-day-12  ← each cell
+ */
+/** Built from the local parts, for the same reason `date.ts` is. */
+export declare const monthTestid: (root: string, month: Date) => string;
+/**
+ * `undefined` for a day borrowed from the neighbouring month, which is why the
+ * `outside` argument is not optional — the caller has to have answered it.
+ *
+ * Such a day is drawn in a grid it does not belong to, purely as padding.
+ * Giving it an id would either collide with the id of the grid that owns it, or
+ * mean an id that does not say which grid it came from. Neither is worth it for
+ * a day that is decoration — a test that wants the 1st of April pins April.
+ *
+ * It is only drawn at all while the month that owns it has no grid on screen:
+ * see `isDrawnByAnotherMonth`. So the `outside` argument stays required, and
+ * stays the caller's to answer — the id is about which grid a day belongs to,
+ * which is a different question from whether the day is drawn.
+ */
+export declare const dayTestid: (monthId: string, day: Date, outside: boolean) => string | undefined;

package/dist/Forms/Inputs/Calendar/useCalendarLocale.d.ts

@@ -0,0 +1,40 @@
+/** Sunday through Saturday, the numbering both primitives take. */
+export type WeekStart = 0 | 1 | 2 | 3 | 4 | 5 | 6;
+/**
+ * Derived from the locale rather than taken as a prop. A prop would let an
+ * application put Monday first while every date it formats says otherwise, and
+ * the locale already carries the answer for every region ICU knows.
+ */
+export declare const weekStartsOnFor: (locale: string) => WeekStart;
+/**
+ * How a weekday is abbreviated above its column.
+ *
+ * The design draws two letters — `Su Mo Tu` — and `Intl` has no two-letter
+ * weekday: `narrow` is one character, `short` is the locale's own abbreviation
+ * (`Sun`, `dom`, `Mo.`), `long` is the whole word. `short` is the nearest of
+ * the three and the only one that is still the locale's, so it is what both
+ * packages ask for. Trimming `short` to two characters would match the English
+ * mock and produce nonsense everywhere the abbreviation is not built that way,
+ * which is most places — and it would be this package inventing a format rather
+ * than reading one, which is the line the no-strings rule draws.
+ *
+ * Named here rather than written at each call site because reka takes it as a
+ * `weekdayFormat` prop and `react-day-picker` takes it as a formatter we write
+ * ourselves: two spellings of one decision, which is exactly the kind of thing
+ * that drifts.
+ */
+export declare const WEEKDAY_FORMAT = "short";
+/**
+ * The locale the calendar formats in, and the week start that follows from it.
+ *
+ * `useLocale()` yields `undefined` when nothing provided one, which every other
+ * component hands straight to `Intl` to mean "follow the runtime".
+ * `react-day-picker` instead needs a `date-fns` locale *object*, and the one it
+ * falls back to is `en-US` — so the month names would disagree with the rest of
+ * the page. Resolving the runtime's own locale here, and formatting through
+ * `Intl`, keeps them in step without shipping a locale table.
+ */
+export declare const useCalendarLocale: () => {
+    locale: string;
+    weekStartsOn: WeekStart;
+};

package/dist/Forms/Inputs/ChatInput/ChatInput.d.ts

@@ -0,0 +1,68 @@
+import { ReactNode } from 'react';
+import { ChatInputActionLabels, ChatInputState } from './index.ts';
+export interface ChatInputProps extends Omit<React.TextareaHTMLAttributes<HTMLTextAreaElement>, 'value' | 'defaultValue' | 'rows' | 'children' | 'onSubmit'> {
+    /**
+     * What a screen reader announces for the three default action buttons.
+     * Required, and required for the same reason `IconButton`'s `aria-label` is:
+     * a glyph is the whole control, so an unlabelled one announces as "button"
+     * and nothing else — and no default the design system could ship would be in
+     * the reader's language. One object rather than three props so that naming
+     * the buttons costs one line, not three.
+     */
+    actionLabels: ChatInputActionLabels;
+    /**
+     * How tall the surface may grow before it starts to scroll, counted in
+     * lines of text.
+     */
+    maxRows?: number;
+    /** Controlled message. Pair with `onValueChange`; omit for uncontrolled. */
+    value?: string;
+    /** Starting message when uncontrolled. */
+    defaultValue?: string;
+    /** Called on every keystroke with the next message. */
+    onValueChange?: (value: string) => void;
+    /** Enter, or the send button. Never called for an empty or whitespace value. */
+    onSubmit?: (value: string) => void;
+    /** The default add-attachment button was pressed. */
+    onAttach?: () => void;
+    /** The default microphone button was pressed. */
+    onRecord?: () => void;
+    /** The text surface. Falls back to an auto-growing textarea. */
+    children?: ReactNode | ((state: ChatInputState) => ReactNode);
+    /** A full-width band above the text surface. Renders nothing when omitted. */
+    toolbar?: ReactNode | ((state: ChatInputState) => ReactNode);
+    /** Bottom-left corner. Falls back to the add-attachment button. */
+    actionsStart?: ReactNode | ((state: ChatInputState) => ReactNode);
+    /** Bottom-right corner. Falls back to the microphone and send buttons. */
+    actionsEnd?: ReactNode | ((state: ChatInputState) => ReactNode);
+    dataTestid: string;
+}
+/**
+ * The frame around a chat composer: the box, the growth, the keyboard
+ * contract and the two action corners. Deliberately *not* an editor.
+ * Mirrors `@sesame/orxata-core` ChatInput.
+ *
+ * The text surface is `children`, and what it renders by default is a plain
+ * auto-growing `<textarea>` — so `value` is a string, and a consumer who
+ * later needs mentions or rich paste drops their own editor in without the
+ * design system taking a dependency on one. The alternative — building on a
+ * rich-text library — would put ProseMirror in front of every consumer of the
+ * package, turn `value` into HTML, and leave two different integrations to
+ * keep in step across React and Vue, for a design that has no formatting
+ * controls in it.
+ *
+ * `children`, `toolbar`, `actionsStart` and `actionsEnd` each take a node or a
+ * render prop called with `{ empty, submit }`, because the frame is the only
+ * part that knows whether the field is empty. A caller who replaces the send
+ * button keeps the empty-state refusal for free instead of re-deriving it,
+ * which is the way the two can never disagree.
+ *
+ * `className` lands on the root, which is the box; everything else a native
+ * `<textarea>` takes — `placeholder`, `name`, `disabled`, `aria-label` — falls
+ * through to the surface. That is also how every human-readable string
+ * arrives: the design system ships none of its own. Replace `children` and the
+ * fallthrough has nowhere to go — a caller supplying their own surface labels
+ * their own surface. The `ref` is the root, for the same reason `className`
+ * is.
+ */
+export declare const ChatInput: import('react').ForwardRefExoticComponent<ChatInputProps & import('react').RefAttributes<HTMLDivElement>>;

package/dist/Forms/Inputs/ChatInput/index.d.ts

@@ -0,0 +1,46 @@
+import { ReactNode } from 'react';
+export { ChatInput } from './ChatInput.tsx';
+export type { ChatInputProps } from './ChatInput.tsx';
+/**
+ * The accessible names for the three default action buttons.
+ *
+ * A separate type rather than an inline literal so the Vue original can hold
+ * the identical shape, and so a caller can keep their copy in one place.
+ *
+ * There is no `cva` here on purpose. `ChatInput` has no variants — the design
+ * draws one box — and an empty variant map would be a thing to keep in step
+ * across two packages in exchange for nothing.
+ */
+export interface ChatInputActionLabels {
+    /** The `+` button that starts an attachment. */
+    attach: string;
+    /** The microphone button. */
+    record: string;
+    /** The send button. */
+    send: string;
+}
+/**
+ * What every slot is handed. The frame is the only part that knows whether
+ * the field is empty, so it passes that down rather than making each caller
+ * re-derive it.
+ */
+export interface ChatInputState {
+    /** The value is blank or nothing but whitespace. */
+    empty: boolean;
+    /**
+     * The whole composer is disabled. Handed over so a replaced action button
+     * goes down with the rest of it instead of staying live beside a field
+     * nobody can type in.
+     */
+    disabled: boolean;
+    /**
+     * Submits, unless `empty` or `disabled`. The same refusal the Enter key and
+     * the send button follow.
+     */
+    submit: () => void;
+}
+/**
+ * A slot: a node, or a render prop — the React translation of Vue's scoped
+ * slot.
+ */
+export type ChatInputSlot = ReactNode | ((state: ChatInputState) => ReactNode);

package/dist/Forms/Inputs/Combobox/ComboboxCancel.d.ts

@@ -0,0 +1,14 @@
+export interface ComboboxCancelProps extends React.ButtonHTMLAttributes<HTMLButtonElement> {
+    dataTestid: string;
+}
+/**
+ * ComboboxCancel — clears the search term without closing the popup.
+ *
+ * Radix ships no combobox at all, so there is no `Cancel` part to wrap: this
+ * reproduces reka's, which renders a `<button type="button" tabindex="-1">` and
+ * empties the filter on click. `tabindex="-1"` is reka's and is kept — the
+ * field's own clear affordances are the keyboard path, and a tab stop between
+ * the input and the trigger would be one more thing to pass through on the way
+ * to the list.
+ */
+export declare const ComboboxCancel: import('react').ForwardRefExoticComponent<ComboboxCancelProps & import('react').RefAttributes<HTMLButtonElement>>;

package/dist/Forms/Inputs/Combobox/ComboboxChipsInput.d.ts

@@ -10,5 +10,9 @@ export interface ComboboxChipsInputProps extends Omit<React.InputHTMLAttributes<
  * ComboboxChipsInput — the search field with the current selection as chips.
  * Multi-select field: renders the selected values as removable chips (read from
  * the shared `multiple` model) alongside the search field.
+ *
+ * The chips stay on one line. Those that do not fit are taken out of flow and
+ * stood in for by a `+N` counter; see `useChipOverflow` for how the line is
+ * measured.
  */
 export declare const ComboboxChipsInput: import('react').ForwardRefExoticComponent<ComboboxChipsInputProps & import('react').RefAttributes<HTMLInputElement>>;

package/dist/Forms/Inputs/Combobox/ComboboxContent.d.ts

@@ -9,5 +9,10 @@ export interface ComboboxContentProps extends Omit<React.ComponentPropsWithoutRe
  * `@radix-ui/react-popover` provides the portal + positioning; `cmdk`'s `Command`
  * provides item filtering. A visually-hidden `CommandInput` receives the shared
  * search string so typing in the anchored input filters the list.
+ *
+ * `asChild` puts the shared `Surface` where the popover content element would
+ * be, and the shared viewport where cmdk's list would be, so a combobox and a
+ * select are the same card with the same padding by construction rather than
+ * by two stylesheets agreeing.
  */
 export declare const ComboboxContent: import('react').ForwardRefExoticComponent<ComboboxContentProps & import('react').RefAttributes<HTMLDivElement>>;

package/dist/Forms/Inputs/Combobox/ComboboxGroup.d.ts

@@ -1,7 +1,11 @@
 import { CommandGroup } from 'cmdk';
 export interface ComboboxGroupProps extends React.ComponentPropsWithoutRef<typeof CommandGroup> {
-    /** Optional group heading. */
-    label?: string;
+    /**
+     * The group heading. A node rather than a string: it is the caller's word
+     * for their own category, and taking it as text would decide for them that
+     * it can only ever be text.
+     */
+    label?: React.ReactNode;
 }
 /** ComboboxGroup — a labelled set of items. */
 export declare const ComboboxGroup: import('react').ForwardRefExoticComponent<ComboboxGroupProps & import('react').RefAttributes<HTMLDivElement>>;

package/dist/Forms/Inputs/Combobox/ComboboxInput.d.ts

@@ -3,7 +3,12 @@ export interface ComboboxInputProps extends Omit<React.InputHTMLAttributes<HTMLI
     placeholder?: string;
     disabled?: boolean;
     size?: InputSize;
-    /** Formats the selected value shown in the input when not actively searching. */
+    /**
+     * Overrides the text shown for the current selection. The default resolves
+     * the option's own label, so pass this only when the label is not the text:
+     * a name that comes from a server, or an option whose content is an avatar
+     * and two lines where none of them is the useful one.
+     */
     displayValue?: (value: unknown) => string;
     /** Custom trigger content (defaults to a chevron icon). */
     trigger?: React.ReactNode;

package/dist/Forms/Inputs/Combobox/ComboboxItem.d.ts

@@ -6,5 +6,9 @@ export interface ComboboxItemProps extends Omit<React.ComponentPropsWithoutRef<t
 /**
  * ComboboxItem — a selectable option, with its own check indicator.
  * Selecting commits the value through the shared context (toggles for multiple).
+ *
+ * See `SelectItem` for why the row is shared and the primitive wrapping it is
+ * not. The indicator is always passed, even while unchecked, so the space it
+ * needs is reserved once rather than appearing the moment the row is picked.
  */
 export declare const ComboboxItem: import('react').ForwardRefExoticComponent<ComboboxItemProps & import('react').RefAttributes<HTMLDivElement>>;

package/dist/Forms/Inputs/Combobox/context.d.ts

@@ -21,6 +21,13 @@ export interface ComboboxContextValue {
     /** Search string driving cmdk filtering. */
     search: string;
     setSearch: (search: string) => void;
+    /**
+     * The text each option renders, keyed by the value it selects, so the field
+     * can show `Barcelona` rather than `barcelona`. See `useComboboxLabels` for
+     * why it never forgets an entry.
+     */
+    registerLabel: (value: string, label: string) => void;
+    labelFor: (value: string) => string | undefined;
 }
 export declare const ComboboxContext: import('react').Context<ComboboxContextValue | null>;
 export declare function useComboboxContext(): ComboboxContextValue;

package/dist/Forms/Inputs/Combobox/index.d.ts

@@ -1,4 +1,5 @@
 export { Combobox, type ComboboxProps } from './Combobox.tsx';
+export { ComboboxCancel, type ComboboxCancelProps } from './ComboboxCancel.tsx';
 export { ComboboxInput, type ComboboxInputProps } from './ComboboxInput.tsx';
 export { ComboboxChipsInput, type ComboboxChipsInputProps, } from './ComboboxChipsInput.tsx';
 export { ComboboxContent, type ComboboxContentProps, } from './ComboboxContent.tsx';