@sesamehr/react-design-system 2.0.0-beta.1 → 2.0.0-beta.11

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

@@ -4,10 +4,4 @@ export interface ComboboxContentProps extends Omit<React.ComponentPropsWithoutRe
     sideOffset?: number;
     align?: 'start' | 'center' | 'end';
 }
-/**
- * ComboboxContent — the popover surface and the scrollable list in one.
- * `@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.
- */
 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/ComboboxItemEdit.d.ts

@@ -0,0 +1,124 @@
+export interface ComboboxItemEditPreview {
+    /**
+     * Enter the editing state. Pass it straight to the control that starts the
+     * edit — `onClick={edit}` — so it receives the event and can stop it.
+     */
+    edit: (event?: {
+        stopPropagation: () => void;
+    }) => void;
+}
+export interface ComboboxItemEditField {
+    /** The text as it currently stands. */
+    value: string | undefined;
+    /** Report a keystroke from the field. */
+    setValue: (value: string | undefined) => void;
+    /** Save, and leave the editing state. */
+    commit: () => void;
+    /** Put the text back as it was, and leave the editing state. */
+    cancel: () => void;
+}
+export interface ComboboxItemEditProps extends Omit<React.HTMLAttributes<HTMLDivElement>, 'children' | 'onChange'> {
+    /**
+     * The text being edited. Pass it one way — `value={label}` — and let
+     * `onCommit` write the new one back: it seeds the draft and re-seeds it
+     * whenever it changes, so the caller never holds the draft and the field
+     * inside `field` never has a second copy of it to disagree with. Add
+     * `onValueChange` for a caller who wants every keystroke.
+     */
+    value?: string;
+    /** The starting text when nothing is passed for `value`. */
+    defaultValue?: string;
+    /** Every keystroke, for a caller controlling the draft. */
+    onValueChange?: (value: string | undefined) => void;
+    /** The edit was saved. Carries the text as it now stands. */
+    onCommit?: (value: string | undefined) => void;
+    /** The edit was abandoned; the draft has already been put back. */
+    onCancel?: () => void;
+    /** The row while it is being edited. */
+    field?: (context: ComboboxItemEditField) => React.ReactNode;
+    /** The row the rest of the time. */
+    children?: (context: ComboboxItemEditPreview) => React.ReactNode;
+}
+/**
+ * An option that can be renamed without leaving the list: the row shows its
+ * normal content until the caller's own control asks to edit it, then hands the
+ * row over to the caller's own field. Port of
+ * `core/src/Forms/Inputs/Combobox/ComboboxItemEdit`.
+ *
+ * It holds no strings and draws no buttons — the design system ships neither.
+ * What it owns is the part a caller cannot get right from outside: a list whose
+ * every reflex is to select the row and close, aimed at a field that needs the
+ * click, the keystroke and the `Escape` for itself.
+ *
+ * ```tsx
+ * <OxComboboxItem value="other">
+ *   <OxComboboxItemEdit
+ *     value={label}
+ *     onCommit={next => setLabel(next ?? '')}
+ *     field={({ value, setValue, commit }) => (
+ *       <>
+ *         <OxInputText size="sm" field={value} onFieldChange={setValue} />
+ *         <OxButton variant="ghost" onClick={commit}>…</OxButton>
+ *       </>
+ *     )}
+ *   >
+ *     {({ edit }) => (
+ *       <>
+ *         {label}
+ *         <OxButton variant="ghost" onClick={edit}>…</OxButton>
+ *       </>
+ *     )}
+ *   </OxComboboxItemEdit>
+ * </OxComboboxItem>
+ * ```
+ *
+ * Both states live here rather than behind the caller's own conditional for one
+ * reason worth the extra render prop: the control that *starts* the edit is
+ * itself inside the row, so its click selects the option and shuts the popover
+ * unless it is stopped. `edit` stops it. A caller assembling the two states
+ * themselves has to know that, and the version that does not know it looks
+ * exactly right until it is clicked.
+ *
+ * ### What is taken away from the list while editing, and by whom
+ *
+ * The Vue half is fighting reka; this one is fighting cmdk, and the two land on
+ * very nearly the same list:
+ *
+ * - **The click.** cmdk's `CommandItem` calls `onSelect` on `click`, and a
+ *   single-select combobox turns a selection into `setOpen(false)`. Clicking
+ *   into the field is a click on the row, so the popover closed under the
+ *   cursor that opened it.
+ * - **`Enter`.** cmdk's `Command` dispatches a select on the highlighted row,
+ *   which is the same close by another route. Here it is what saves the edit.
+ * - **`ArrowUp` / `ArrowDown` / `Home` / `End`.** All four are
+ *   `preventDefault()`ed by `Command`, so the caret could not be moved.
+ * - **`pointermove`.** `CommandItem` moves the highlight onto the row under the
+ *   cursor.
+ * - **`Space`** is in the list for the Vue half's sake — reka's `ListboxItem`
+ *   selects on it *with `prevent`*, so a name with two words in it could not be
+ *   typed. cmdk leaves the space bar alone; stopping it here costs nothing and
+ *   keeps one list of claimed keys instead of two that drift.
+ *
+ * `Escape` is deliberately absent and is answered in `ComboboxContent`. See
+ * `useComboboxEditing` for why it cannot be answered here.
+ *
+ * ### Focus
+ *
+ * Nothing in this half steals focus the way reka's listbox can, so there is no
+ * equivalent of the `focusable` flag the Vue port suspends and restores:
+ * Radix's popover is non-modal and `onOpenAutoFocus` is already prevented,
+ * cmdk's highlight is an `aria-activedescendant` rather than a real focus move,
+ * and its one refocusing path fires only when the active element is cmdk's own
+ * input or root — never a field inside a row. What is left is the same on both
+ * sides: take focus on entering the edit, hand it back to the combobox's own
+ * field on leaving.
+ *
+ * **One thing here has no Vue counterpart.** cmdk re-sorts the option elements
+ * by moving the DOM nodes themselves whenever the search term changes, and a
+ * focused field inside a row that gets reparented loses focus. Typing in the
+ * combobox's own search box while a row edit is open is therefore not the same
+ * experience in the two packages. Editing is reached by clicking a control in
+ * the row, which leaves the search box unfocused, so it takes a deliberate
+ * detour to hit.
+ */
+export declare const ComboboxItemEdit: import('react').ForwardRefExoticComponent<ComboboxItemEditProps & import('react').RefAttributes<HTMLDivElement>>;