@danxbot/ui 3.9.0 → 3.9.1

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

@@ -54,8 +54,16 @@ export interface DataTableProps<TData> {
      * styling the table picked — `cn` is tailwind-merge, and the last conflicting
      * utility wins. That is deliberate: a tint that loses to the zebra fill is a
      * tint nobody sees. It also means a background handed over here REPLACES the
-     * row's hover fill, so pass the hover with it (`bg-warning-subtle
-     * hover:bg-warning-subtle-hover`) if the row should still respond.
+     * row's hover fill, so pass the hover with it (`bg-danger-subtle
+     * hover:bg-danger-subtle-hover`) if the row should still respond.
+     *
+     * THAT EXAMPLE USED TO NAME `warning`, WHICH HAS NO HOVER STEP. `-subtle`
+     * exists for every semantic family; `-subtle-hover` exists for `accent` and
+     * `danger` only. A consumer following the old wording got a hover class that
+     * compiled to nothing — no rule, no fill, no error anywhere, which is the
+     * same silent-nothing failure the theme bridge in `postbuild-css.mjs` exists
+     * to prevent one level up. Pick a family that has the step, or supply the
+     * hover colour yourself. `token-parity.test.ts` now sweeps this docblock.
      *
      * `index` is the row's position in `data`, not on the current page — the same
      * number `getRowId` receives, so the two never disagree about which row is

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

@@ -64,10 +64,31 @@ export declare function Toolbar({ className, children, ref, ...props }: ToolbarP
 export declare function ToolbarSeparator({ className }: {
     className?: string;
 }): import("react").JSX.Element;
-export interface ToolbarButtonProps extends Omit<BaseToolbar.Button.Props, "className" | "nativeButton">, Pick<ButtonProps, "variant" | "size" | "iconOnly"> {
+type ToolbarButtonBase = Omit<BaseToolbar.Button.Props, "className" | "nativeButton" | "render"> & {
     className?: string;
     ref?: Ref<HTMLButtonElement>;
-}
+};
+/**
+ * TWO FORMS, AND THE TYPE REFUSES TO MIX THEM.
+ *
+ * Either this renders its own `<button>` and wears `buttonVariants` — in which
+ * case `variant` / `size` / `iconOnly` choose which row of that table — or it
+ * renders somebody else's control through `render`, in which case that control
+ * already carries a variant table and this one must not add a second. The two
+ * are mutually exclusive rather than merely discouraged, because a `render`
+ * plus a `size` is not a preference somebody expressed: it is two size classes
+ * in one attribute with no rule for which wins. See `ToolbarButton`'s own doc
+ * for the measurement.
+ */
+export type ToolbarButtonProps = (ToolbarButtonBase & Pick<ButtonProps, "variant" | "size" | "iconOnly"> & {
+    /** The styled form owns the element, so there is nothing to render into. */
+    render?: undefined;
+}) | (ToolbarButtonBase & {
+    render: NonNullable<BaseToolbar.Button.Props["render"]>;
+    variant?: never;
+    size?: never;
+    iconOnly?: never;
+});
 /**
  * A button that is part of the toolbar's rotation.
  *
@@ -85,8 +106,23 @@ export interface ToolbarButtonProps extends Omit<BaseToolbar.Button.Props, "clas
  * ANYTHING ALREADY BUILT ON `Button` GOES IN THROUGH `render`, which is what
  * keeps this from becoming a second button component:
  * `<ToolbarButton render={<IconButton icon={…} label="Bold" />} />` registers
- * exactly the same, keeps the tooltip and the `disabledReason`, and never
- * duplicates a variant table.
+ * exactly the same and keeps the tooltip and the `disabledReason`.
+ *
+ * THAT PATH APPLIES NO VARIANT TABLE AT ALL, and the type enforces it —
+ * `variant`, `size` and `iconOnly` are not accepted beside `render`. Base UI's
+ * render slot CONCATENATES `className`; it does not run `cn`. So a recipe
+ * applied here landed in the same attribute as the rendered component's own,
+ * and which one won was decided by Tailwind's emission order rather than by
+ * either component. It measured fine while the two happened to agree — a
+ * default `render={<IconButton/>}` came out 36×36, identical to a standalone
+ * one, while carrying both `aspect-square` and `px-3.5` — and broke visibly the
+ * moment they disagreed: `<ToolbarButton size="lg" render={<IconButton
+ * size="sm" …/>} />` carried `h-control-lg` AND `h-control-sm` and rendered
+ * 48 × 36 with 24px of padding, a squashed oval neither component asked for.
+ *
+ * Unrepresentable beats documented, and it is free to do NOW: nothing has
+ * adopted the pair yet, so narrowing the type costs nothing that removing the
+ * props after adoption would have cost.
  */
 export declare function ToolbarButton({ variant, size, iconOnly, className, children, ref, ...props }: ToolbarButtonProps): import("react").JSX.Element;
 export interface ToolbarInputProps extends Omit<InputProps, "ref">, Pick<BaseToolbar.Input.Props, "focusableWhenDisabled"> {

package/dist/types/components/chat/Attachment.d.ts

@@ -1,5 +1,6 @@
 import { type ReactNode, type Ref } from "react";
 import type { ChatFile } from "./types";
+import type { IconName } from "../Icon";
 export type AttachmentLayout = "tile" | "row";
 export interface AttachmentProps {
     file: ChatFile;
@@ -24,6 +25,13 @@ export interface AttachmentProps {
      * It goes inside the cluster, above the full-card preview trigger — rendered
      * anywhere else it would sit UNDER that trigger and never receive a click.
      * Keep it to a control or two: this is a corner of a tile, not a menu bar.
+     *
+     * FILL IT WITH `AttachmentAction`, which is exported for exactly this. The
+     * built-in download and remove are that component, so anything else lands in
+     * the cluster at a different size and, on a tile, without the hover fade the
+     * two beside it have. Any node is accepted — the slot has no opinion — but
+     * "matches the built-ins" is a real requirement and there is no way to hit it
+     * by hand. Pass `tinted` when `layout` is `"tile"`.
      */
     action?: ReactNode;
     onRemove?: (file: ChatFile) => void;
@@ -36,6 +44,45 @@ export interface AttachmentProps {
     ref?: Ref<HTMLDivElement>;
 }
 export declare function Attachment({ file, layout, meta, action, onRemove, onPreview, onDownload, selected, disabled, className, ref, }: AttachmentProps): import("react").JSX.Element;
+export interface AttachmentActionProps {
+    icon: IconName;
+    /** The accessible name AND the tooltip. Include the file: "Extract report.pdf". */
+    label: string;
+    onClick: () => void;
+    disabled?: boolean;
+    /**
+     * On a tile the buttons sit over imagery, so they need their own ground —
+     * and they FADE IN on hover rather than sitting permanently over the picture.
+     *
+     * Pass `layout === "tile"`. Getting it wrong is not a style preference: a
+     * tinted control on a row is dark-on-dark, and an untinted one on a tile is
+     * a grey glyph over an arbitrary photograph.
+     */
+    tinted?: boolean;
+}
+/**
+ * One control in an attachment's action cluster.
+ *
+ * THE CONTROL `Attachment.action` IS MEANT TO BE FILLED WITH, and until now it
+ * was module-private — so the slot existed with nothing in the library that
+ * fits it. A consumer's own `IconButton` is a different size and a different
+ * resting state, and on a tile it does not fade in on `group-hover/attachment`
+ * with the built-in download and remove beside it, so the one control the
+ * consumer added was the one that looked wrong.
+ *
+ * It is deliberately NOT `IconButton`: `size-6` rather than a control height,
+ * no ripple, no `disabledReason`, and a tinted variant that only means anything
+ * inside `.group/attachment`. That is a corner-of-a-tile control, not a general
+ * one, and generalising it would give the cluster two different buttons again.
+ *
+ *   <Attachment
+ *     file={file}
+ *     layout="tile"
+ *     action={<AttachmentAction icon="sparkles" label={`Extract ${file.name}`}
+ *                               onClick={() => extract(file)} tinted />}
+ *   />
+ */
+export declare function AttachmentAction({ icon, label, onClick, disabled, tinted, }: AttachmentActionProps): import("react").JSX.Element;
 export interface AttachmentPreviewProps {
     file: ChatFile | null;
     onOpenChange: (open: boolean) => void;

package/dist/types/index.d.ts

@@ -85,7 +85,7 @@ export { Message, MessagePartView, ToolCall, ChatMarker, type MessageProps, type
 export { MessageScroller, type MessageScrollerProps, } from "./components/chat/MessageScroller";
 export { Composer, type ComposerProps } from "./components/chat/Composer";
 export { Markdown, CodeBlock, type MarkdownProps, type CodeBlockProps } from "./components/chat/Markdown";
-export { Attachment, AttachmentList, AttachmentPreview, type AttachmentProps, type AttachmentListProps, type AttachmentPreviewProps, type AttachmentLayout, } from "./components/chat/Attachment";
+export { Attachment, AttachmentAction, AttachmentList, AttachmentPreview, type AttachmentProps, type AttachmentActionProps, type AttachmentListProps, type AttachmentPreviewProps, type AttachmentLayout, } from "./components/chat/Attachment";
 export { ModelSelector, type ModelSelectorProps, type ChatModel, } from "./components/chat/ModelSelector";
 export { EffortControl, DEFAULT_EFFORT_LEVELS, type EffortControlProps, type EffortLevel, } from "./components/chat/EffortControl";
 export { ContextMeter, ChatStatus, type ContextMeterProps, type ContextSegment, type UsageLimit, type ChatStatusProps, } from "./components/chat/ContextMeter";

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@danxbot/ui",
-  "version": "3.9.0",
+  "version": "3.9.1",
   "type": "module",
   "description": "Danxbot — a domain-agnostic React design system with motion as a first-class primitive.",
   "license": "MIT",
@@ -66,7 +66,7 @@
     "build:types": "tsc -p tsconfig.build.json",
     "build:demo": "vite build",
     "build": "npm run build:lib && npm run build:demo",
-    "verify": "npm run typecheck && npm run test && npm run build && npm run typecheck:previews && npm run audit:previews && npm run audit:visual-stale",
+    "verify": "npm run typecheck && npm run build && npm run test && npm run typecheck:previews && npm run audit:previews && npm run audit:visual-stale",
     "audit:visual-stale": "node scripts/audit-visual-stale.mjs",
     "preview": "vite preview",
     "preview:built": "vite preview --outDir demo-dist --port 5801 --strictPort",