@50arms/ui 0.0.0-stage → 35.2.0

package/dist/types/components/PaginationBar.d.ts

@@ -0,0 +1,31 @@
+export type PaginationBarMode = "numbered" | "simple";
+export interface PaginationBarProps {
+    /** 1-based current page. */
+    page: number;
+    /** Rows per page. Should be one of `pageSizeOptions`. */
+    pageSize: number;
+    /** The sizes offered in the per-page popover, in the order shown. */
+    pageSizeOptions: readonly number[];
+    /** Total matching items across every page — drives the range text and page count. */
+    total: number;
+    onPageChange: (page: number) => void;
+    onPageSizeChange: (size: number) => void;
+    /**
+     * `"simple"`: ‹ Page N of M › — fixed width regardless of how many pages
+     * exist, and the shape guaranteed to fit a narrow bar unaided.
+     * `"numbered"`: the numbered-window `Pagination` control, for a list long
+     * enough that jumping past adjacent pages is worth the room it costs.
+     * @default "simple"
+     */
+    mode?: PaginationBarMode;
+    /** Names the bar for assistive tech, e.g. "Cards" or "Dispatches". */
+    label: string;
+    className?: string;
+}
+/**
+ * Range text + a popover-based per-page picker + page navigation, always on
+ * one row. See the file banner above for the reasoning behind the popover
+ * and the `mode` split — this replaces both of gpt-manager's pre-existing,
+ * differently-shaped hand-rolled footers.
+ */
+export declare function PaginationBar({ page, pageSize, pageSizeOptions, total, onPageChange, onPageSizeChange, mode, label, className, }: PaginationBarProps): import("react").JSX.Element;

package/dist/types/components/Panel.d.ts

@@ -0,0 +1,94 @@
+import { type ReactNode, type Ref } from "react";
+import { type Breakpoint } from "../lib/use-media-query";
+export type PanelDirection = "horizontal" | "vertical";
+/** What a group turns into below its narrow breakpoint. */
+export type PanelNarrowMode = "tabs" | "stack";
+type Sizes = Record<string, number>;
+export interface PanelGroupProps {
+    children: ReactNode;
+    direction?: PanelDirection;
+    /**
+     * Below this width the group stops being a splitter. `narrowMode` decides
+     * what it becomes; either way splitters are not rendered and stored sizes are
+     * ignored until the width comes back.
+     *
+     * A SPLITTER IS A POINTER AFFORDANCE, and phone width has neither the room
+     * nor the precision for it. Left as a splitter, a two-pane chat at 375px
+     * gives each pane about 170px: prose wraps one word per line and the buttons
+     * inside it collide. That is not a narrower version of the layout, it is a
+     * broken one.
+     *
+     * Defaults to `md` (768px) — a portrait tablet is the last width where two
+     * panes and a splitter between them still leave each pane a readable column.
+     * Pass `false` for a group that genuinely must stay split at every width.
+     */
+    narrowBelow?: Breakpoint | false;
+    /**
+     * What the group becomes below `narrowBelow`.
+     *
+     * TABS is the default, for panes a person moves BETWEEN — a conversation and
+     * the thing it is about. Only one of those is being read at any moment, so
+     * giving the active one the whole screen and charging a tap to switch costs
+     * nothing and keeps both reachable at a fixed place on screen.
+     *
+     * STACK is for panes read TOGETHER, where scrolling out of one and into the
+     * next is the point. Tabs there hide half the content behind a control the
+     * reader has no reason to expect, and the two halves can no longer be
+     * compared at all.
+     */
+    narrowMode?: PanelNarrowMode;
+    /**
+     * Remembers this group's layout under `danxbot-<persistId>`.
+     *
+     * A layout stored against a different set of panels is DISCARDED, not merged:
+     * ids are compared as a set on mount, and any mismatch falls back to the
+     * defaults and clears the entry. Merging would produce a broken layout that
+     * survives every refresh, because it keeps getting written back — the one
+     * failure a person cannot fix by dragging.
+     */
+    persistId?: string;
+    onLayout?: (sizes: Sizes) => void;
+    className?: string;
+    ref?: Ref<HTMLDivElement>;
+}
+export declare function PanelGroup({ children, direction, narrowBelow, narrowMode, persistId, onLayout, className, ref, }: PanelGroupProps): import("react").JSX.Element;
+export interface PanelProps {
+    children: ReactNode;
+    /** Stable identity — the key its size persists under. Required precisely so
+        a remembered layout can be matched against the panels that exist now. */
+    id: string;
+    /** The panel's name on its tab, once the group is narrow enough to show one.
+        Falls back to `id`, which is readable often enough to be a useful default
+        and obviously wrong when it is not. */
+    label?: string;
+    /** Percent of the group. Omitted panels split whatever is left over. */
+    defaultSize?: number;
+    minSize?: number;
+    maxSize?: number;
+    collapsible?: boolean;
+    collapsedSize?: number;
+    className?: string;
+    ref?: Ref<HTMLDivElement>;
+}
+export declare function Panel({ children, id, label, defaultSize, minSize, maxSize, collapsible, collapsedSize, className, ref, }: PanelProps): import("react").JSX.Element;
+export interface PanelResizerProps {
+    /** Names the splitter for screen readers — "Sidebar width", not "separator". */
+    label: string;
+    /** Percent moved per arrow key. */
+    step?: number;
+    /** Shows a grip so the splitter reads as draggable rather than decorative. */
+    withGrip?: boolean;
+    disabled?: boolean;
+    className?: string;
+    ref?: Ref<HTMLDivElement>;
+}
+/**
+ * The draggable divider.
+ *
+ * `role="separator"` with `tabindex="0"` is the WAI-ARIA window splitter: the
+ * one case where a separator is interactive. Keyboard support is not a bonus
+ * here — a pointer-only splitter is unusable for anyone who cannot drag, and
+ * "drag" is the entire interaction.
+ */
+export declare function PanelResizer({ label, step, withGrip, disabled, className, ref, }: PanelResizerProps): import("react").JSX.Element | null;
+export {};

package/dist/types/components/PasswordInput.d.ts

@@ -0,0 +1,7 @@
+import { type InputProps } from "./Input";
+export interface PasswordInputProps extends Omit<InputProps, "type" | "trailing"> {
+    /** Hides the show/hide toggle entirely — for a field where the operator
+     *  should never be able to reveal what they typed (rare; default `true`). */
+    revealable?: boolean;
+}
+export declare function PasswordInput({ revealable, autoComplete, ...props }: PasswordInputProps): import("react").JSX.Element;

package/dist/types/components/PasswordRequirements.d.ts

@@ -0,0 +1,11 @@
+import type { Ref } from "react";
+export interface PasswordRequirementRule {
+    label: string;
+    met: boolean;
+}
+export interface PasswordRequirementsProps {
+    rules: PasswordRequirementRule[];
+    className?: string;
+    ref?: Ref<HTMLUListElement>;
+}
+export declare function PasswordRequirements({ rules, className, ref }: PasswordRequirementsProps): import("react").JSX.Element | null;

package/dist/types/components/PatchDiff.d.ts

@@ -0,0 +1,38 @@
+export type PatchDiffStatus = "added" | "modified" | "removed" | "renamed";
+export interface PatchDiffProps {
+    /** The file's path after the change. */
+    path: string;
+    status: PatchDiffStatus;
+    /** A renamed file's path before the change. */
+    previousPath?: string;
+    additions: number;
+    deletions: number;
+    /** The unified-diff hunks for this file (no `diff --git` / `---` / `+++` header lines). Omit with `unavailable`. */
+    patch?: string;
+    /** Why there is no patch to draw (the host's reason, in the caller's words). Mutually exclusive with `patch`. */
+    unavailable?: string;
+    /** Whether the file starts open. Default closed. */
+    defaultOpen?: boolean;
+    className?: string;
+}
+type PatchLineKind = "unchanged" | "added" | "removed";
+interface PatchLine {
+    kind: PatchLineKind;
+    /** Old-side line number; null for an added line. */
+    oldNumber: number | null;
+    /** New-side line number; null for a removed line. */
+    newNumber: number | null;
+    text: string;
+}
+type PatchRow = PatchLine | {
+    kind: "gap";
+    hidden: number;
+} | {
+    kind: "note";
+    text: string;
+};
+/** The rows of a patch: every hunk's lines, with a gap row where the patch skips unchanged old-side lines. */
+export declare function parsePatch(patch: string): PatchRow[];
+/** One changed file: a collapsible header and, when open, its hunks (or why there are none). */
+export declare function PatchDiff({ path, status, previousPath, additions, deletions, patch, unavailable, defaultOpen, className }: PatchDiffProps): import("react").JSX.Element;
+export {};

package/dist/types/components/PendingVeil.d.ts

@@ -0,0 +1,8 @@
+/**
+ * DX-6426 - the pending look of a control that is a SET of options (RadioGroup, ToggleGroup): a translucent veil over the whole set with a centred
+ * spinner. A set cannot show the spinner on one option, because while the request is out the controlled value is still the old one, so a spinner
+ * on the checked option would point at the wrong choice. The veil changes no layout. Internal: it is not exported from the package.
+ */
+export declare function PendingVeil({ className }: {
+    className?: string;
+}): import("react").JSX.Element;

package/dist/types/components/Popover.d.ts

@@ -0,0 +1,231 @@
+import { type ReactNode, type Ref, type RefObject } from "react";
+export interface PopoverProps {
+    /** The element that opens the popover. Omit it when `anchor` is given. */
+    trigger?: ReactNode;
+    /**
+     * DXUI-71 — an element the CALLER owns (or a ref to one) to open beside, for
+     * a popover whose target is drawn by another component, so there is no
+     * trigger of our own to render. Passed straight to Base UI's
+     * `Positioner.anchor`. Needs controlled `open` / `onOpenChange`; Escape and
+     * an outside press close it, and focus returns to the anchor. Exclusive with
+     * `trigger`.
+     */
+    anchor?: Element | RefObject<Element | null> | null;
+    /**
+     * Controlled open state — for a caller that must open this popover from
+     * somewhere other than its own trigger (another control elsewhere on the
+     * screen pointing at the same content). `Dialog` and `Menu` already carry
+     * this exact prop; `Popover` was the one overlay a consumer could not drive
+     * externally, which is a real gap rather than a deliberate omission — there
+     * is nothing about a popover's semantics that makes it less legitimate to
+     * open by remote control than a dialog.
+     */
+    open?: boolean;
+    side?: "top" | "bottom" | "left" | "right";
+    align?: "start" | "center" | "end";
+    /** Draws the little pointer at the trigger. Off by default — see below. */
+    arrow?: boolean;
+    /**
+     * The popup's width — any CSS length, e.g. `"30rem"` — as the REAL width of
+     * the popup, not a ceiling: the popup renders at exactly this width unless
+     * the room runs out, so a panel inside it is `w-full min-w-0` and carries no
+     * width of its own.
+     *
+     * A prop rather than a `w-*`/`max-w-*` in `className`, and the difference is
+     * not cosmetic: `className` is merged last and would take the viewport clamp
+     * with it (see THE SIZE CLAMP above). This writes `--dx-popover-w`, which
+     * sits INSIDE the `min()` — so a design size can be as large as it likes and
+     * still cannot render wider than 90vw or than the room the positioner found.
+     * The width includes the popup's padding and border; write it in `rem`
+     * multiplied by `var(--ui-scale)` to scale with the size control as spacing does.
+     *
+     * Unset, the popup is content-sized, capped at the library default of 40rem
+     * at the current `--ui-scale`.
+     */
+    width?: string;
+    className?: string;
+    children: ReactNode;
+    ref?: Ref<HTMLDivElement>;
+    /**
+     * DX-3662 — open the popover on hover, not just on click, WITHOUT a
+     * consumer hand-rolling its own mouseenter/mouseleave state alongside the
+     * trigger's own click-to-open. Forwards straight to Base UI's
+     * `Popover.Trigger` (`openOnHover`/`delay`/`closeDelay` below), which
+     * already coordinates hover, click and touch as ONE state machine
+     * (`useHoverReferenceInteraction` + `useClick`, both reading the same
+     * `openMethod`/`openReason` store) — a real touch tap is tracked as
+     * `openMethod: 'touch'` and is exempted from the hover-close path
+     * (`PopoverTrigger`'s own `enabled` check), so it does not fight a
+     * subsequent tap the way two independently-owned state machines would.
+     * Off by default — every existing click-only popover is unaffected.
+     */
+    openOnHover?: boolean;
+    /**
+     * DXUI-34 — also open when the trigger takes KEYBOARD focus (`:focus-visible`),
+     * so a help icon reached by Tab reads like one hovered. A mouse or touch focus
+     * does not open it (the click that follows would toggle it shut again). Focus
+     * stays on the trigger: the popup is never given initial focus, whatever opened
+     * it, so tabbing onto the trigger is not a change of context. Escape and
+     * clicking outside close it as ever; Tab onward leaves it open until focus
+     * moves and a dismissal event arrives, exactly like a hover-open.
+     * Off by default.
+     */
+    openOnFocus?: boolean;
+    /** Hover-open delay, ms. Matches Base UI's own `restMs` default (`OPEN_DELAY`) when unset. Only meaningful with `openOnHover`. */
+    delay?: number;
+    /** Hover-CLOSE delay, ms — how long the popover survives after the pointer leaves BOTH the trigger and the popup before it closes, so crossing the gap between them doesn't flicker it shut. Only meaningful with `openOnHover`. */
+    closeDelay?: number;
+    /**
+     * DX-3662 review round 3 — whether `trigger` IS a real `<button>` element.
+     * Forwarded straight to Base UI's `Popover.Trigger`, whose `useButton`
+     * hook needs to know: with the default `true`, it expects a genuine
+     * `<button>` in `render` and — in development — logs an error and skips
+     * adding its own keyboard/ARIA handling on any other element, because a
+     * real button already has both natively. A `trigger` that is NOT a
+     * `<button>` (a styled `<span>`, a custom donut, ...) MUST pass `false`
+     * here, or it mounts with a console error and Enter/Space silently do
+     * nothing — Base UI assumed native semantics it was never given.
+     * @default true
+     */
+    nativeButton?: boolean;
+    /**
+     * Render open on mount. Uncontrolled — the popover still closes on its own
+     * afterwards; this only decides the starting state.
+     *
+     * `Menu` already forwarded its open state and consequently had a preview
+     * card showing a real open menu, while these two showed a picture of a
+     * button. Consistency across the three overlays is the point; a static
+     * documentation surface cannot dispatch a click.
+     */
+    defaultOpen?: boolean;
+    /**
+     * Told when the popup opens and when it closes. Uncontrolled still — this
+     * OBSERVES the state Base UI owns rather than taking it over, which is why
+     * there is no `open` prop beside it.
+     *
+     * `Collapsible`, `Dialog` and `Menu` all already carry this exact signature;
+     * the popover was the one overlay a consumer could not hear. The reason to
+     * hear it is almost never styling — it is WORK: a panel whose contents cost
+     * a request must not pay for that request while it is shut, and a page of a
+     * hundred closed popovers that each fetched on mount is a hundred requests
+     * for the one panel somebody eventually opens.
+     */
+    onOpenChange?: (open: boolean) => void;
+    /**
+     * Names the popup for assistive technology.
+     *
+     * Base UI gives the popup `role="dialog"`, and an unlabelled dialog
+     * announces itself as nothing. Declared here rather than left to a caller
+     * passing `aria-labelledby` through: an undeclared prop on a component that
+     * destructures its props is silently DROPPED — it type-checks, renders, and
+     * does nothing, which is how this was shipped once already.
+     */
+    "aria-labelledby"?: string;
+    "aria-label"?: string;
+}
+export declare function Popover({ trigger, anchor, open, side, align, arrow, width, className, children, ref, defaultOpen, onOpenChange, openOnHover, openOnFocus, delay, closeDelay, nativeButton, "aria-labelledby": ariaLabelledBy, "aria-label": ariaLabel, }: PopoverProps): import("react").JSX.Element;
+/** Closes the nearest Popover. */
+export declare function PopoverClose({ children }: {
+    children: ReactNode;
+}): import("react").JSX.Element;
+interface TooltipBaseProps {
+    /** The label. Plain text — anything interactive belongs in a Popover. */
+    content: ReactNode;
+    children: ReactNode;
+    side?: "top" | "bottom" | "left" | "right";
+    className?: string;
+    /**
+     * DX-5327 — `danger` draws the tooltip in the library's danger tokens
+     * (danger text, danger border, danger-tinted surface, arrow included), for a
+     * label that explains a refusal or a failure. `default` is the plain overlay.
+     * @default "default"
+     */
+    tone?: "default" | "danger";
+    /**
+     * Render open on mount, without a hover. For documentation surfaces and
+     * static captures — a tooltip nobody is pointing at is otherwise invisible,
+     * so a preview card of one shows an unexplained button.
+     */
+    defaultOpen?: boolean;
+    /**
+     * Whether the pointer can move off the trigger and onto the popup itself
+     * without the tooltip closing. Base UI calls the underlying prop
+     * `disableHoverablePopup`, worded as the thing being turned OFF; this is
+     * worded as the thing being asked for, because every call site reads as a
+     * question about the popup ("can this be entered?"), never about a flag
+     * named after its own negation.
+     *
+     * DEFAULT FALSE (DX-4349). A tooltip is a label, not a surface (see
+     * `content`: "anything interactive belongs in a Popover"), and a label
+     * that holds itself open under the pointer is a trap wherever marks sit
+     * side by side: the popup is drawn right over the neighbouring marks, so
+     * moving toward the next one lands on the popup, keeps it open and blocks
+     * the mark underneath. Opt IN only for a tooltip whose text a reader must
+     * be able to point into and keep reading (WCAG 1.4.13 "hoverable") and that
+     * sits clear of other controls.
+     * @default false
+     */
+    enterable?: boolean;
+    /**
+     * DXUI-41: whether a press on the trigger closes the tooltip (Base UI's
+     * `closeOnClick`). A trigger whose own tap handler forces the tooltip open
+     * (the controlled pair below) sets this FALSE: the press-close runs after
+     * that handler on the same tap and shuts the tooltip it just opened, so a
+     * touch tap showed nothing.
+     * @default true
+     */
+    closeOnClick?: boolean;
+}
+/**
+ * DX-3014 — the OPT-IN controlled pair, for a caller that needs to force the
+ * tooltip open from an event neither hover nor keyboard focus covers.
+ *
+ * The gap this closes: Base UI opens on hover AND on keyboard focus (a real
+ * Tab keypress), but NOT on a plain `.focus()` call or a touch tap — both
+ * land as an ordinary (non-`:focus-visible`) focus, which the interaction the
+ * library reads for "focus" deliberately excludes (measured directly: a
+ * simulated tap focuses the trigger element but never opens the popup; a real
+ * Tab keypress does). A caller with a genuine touch-reachability requirement
+ * (a segmented-donut status breakdown, e.g.) wires its own tap handler to
+ * `onOpenChange`/`open` instead of fighting the trigger's focus semantics.
+ *
+ * BOTH OR NEITHER: passing only one makes Base UI's `Root` half-controlled
+ * (it would echo state changes nobody reads, or ignore an external open) — a
+ * discriminated union so TypeScript refuses the half-controlled shape at the
+ * call site rather than leaving it a runtime footgun. Omit both (the
+ * default, and every existing call site) for the unchanged uncontrolled
+ * hover/keyboard-focus behaviour.
+ */
+export type TooltipProps = TooltipBaseProps & ({
+    open?: undefined;
+    onOpenChange?: undefined;
+} | {
+    open: boolean;
+    onOpenChange: (open: boolean) => void;
+});
+/**
+ * Hover delay is set once on `TooltipProvider`, not per tooltip — that is where
+ * Base UI keeps it, and it is the right place: the delay only means anything
+ * relative to the OTHER tooltips nearby.
+ */
+export declare function Tooltip({ content, children, side, className, tone, defaultOpen, enterable, closeOnClick, open, onOpenChange }: TooltipProps): import("react").JSX.Element;
+/**
+ * Share hover timing across every tooltip beneath it.
+ *
+ * Wrap the app once. Without it each tooltip keeps its own timer, so moving
+ * between two adjacent icons makes you wait out the full delay twice — the
+ * thing that makes tooltips feel broken in dense toolbars.
+ *
+ * THE DEFAULT IS ZERO. A hover delay exists to stop tooltips firing while the
+ * pointer merely crosses a toolbar on its way somewhere else — but the cost is
+ * paid by everyone who actually wanted the label, every time, and it is the
+ * cost people describe as "the tooltip is slow". These tooltips name controls
+ * that are often icon-only, so the label IS the affordance and withholding it
+ * for 400ms is withholding the interface. The prop remains for anyone who
+ * wants the traditional behaviour back.
+ */
+export declare function TooltipProvider({ children, delay }: {
+    children: ReactNode;
+    delay?: number;
+}): import("react").JSX.Element;
+export {};