rich-react-component 0.3.0 → 0.3.2

package/README.md

@@ -83,7 +83,7 @@ import { RemoteComboBox } from "rich-react-component";
 
 ## What's in each layer
 
-**Base** (55 components) — form fields (`Input`, `NumberInput`, `PasswordInput`, `FileInput`, `CheckBox`, `Switch`, `RadioGroup`, `Select`, `MultiSelect`, `DatePicker`, `TimePicker`, `DateTimePicker`, `ComboBox`, `AutoComplete`, `FormField`), feedback (`Modal`, `Toast`, `Confirm`, `Alert`, `Spinner`, `Badge`, `Skeleton`), data display (`DataGrid`, `Pagination`, `Avatar`, `Tag`, `Rating`, `ProgressBar`, `ListItem`, `Sparkline`, `Statistic`), navigation (`Breadcrumb`, `Menu`, `Stepper`, `Tabs`, `Navbar`, `Sidebar`, `PageHeader`), layout (`Card`, `Divider`, `Stack`, `Flex`, `Container`, `Row`, `Col`), typography (`Text`), and more (`Button`, `IconButton`, `Tooltip`, `Popover`, `Accordion`, `Icon`).
+**Base** (57 components) — form fields (`Input`, `NumberInput`, `PasswordInput`, `FileInput`, `CheckBox`, `Switch`, `RadioGroup`, `Select`, `MultiSelect`, `DatePicker`, `TimePicker`, `DateTimePicker`, `ComboBox`, `AutoComplete`, `FormField`), feedback (`Modal`, `Toast`, `Confirm`, `Alert`, `Spinner`, `Badge`, `Skeleton`), data display (`DataGrid`, `Pagination`, `Avatar`, `Tag`, `Rating`, `ProgressBar`, `ListItem`, `Sparkline`, `Statistic`), navigation (`Breadcrumb`, `Menu`, `Stepper`, `Tabs`, `Navbar`, `Sidebar`, `PageHeader`), layout (`Card`, `Divider`, `Stack`, `Flex`, `Container`, `Row`, `Col`), typography (`Text`), and more (`Button`, `IconButton`, `Tooltip`, `Popover`, `Accordion`, `Icon`, `RichComponentBase`, `ContextMenu`).
 
 `DataGrid` columns are declarative by default (`{ field: "conversion", header: "CONV.", align: "end" }`) — `render` stays available as the escape hatch for genuinely custom cells, and `format`/`formatter` cover the common presentation cases (`dataGridFormatters` exports the built-in `text`/`date`/`currency`/`boolean` set). `Card` accepts `title`/`subtitle`/`icon`/`avatar`/`actions`/`loading` directly, with `header` remaining as the raw escape hatch. `Tabs` supports `variant` (`default`/`underline`/`pill`/`card`/`button`), `orientation`, `size`, `stretch`, and per-item `icon`/`badge`, with roving-tabindex keyboard navigation.
 
@@ -97,6 +97,45 @@ import { RemoteComboBox } from "rich-react-component";
 - **Headless engine** — `useSmartField` / `useSmartAction` resolve one field/action's metadata (visibility, validation, localized label, resolved request params); `useSmartDependencies` tracks `dependsOn` and reports which field needs fresh metadata when a value it depends on changes.
 - **Components** — `SmartField` / `SmartAction` resolve one piece of metadata into UI; `SmartForm` / `SmartActions` are thin iteration helpers over a whole `SmartFormMetadata` — no field-value ownership, no business-rule evaluation, no layout decisions.
 
+## Context menu
+
+`RichComponentBase` attaches a declarative context menu to any component in the
+package. The menu is written as a child component — never as a prop, a metadata
+array or a callback-returned object — and the behavior lives in that one place,
+so no component carries a copy of it and none gained a `contextMenu` prop.
+
+```tsx
+<RichComponentBase>
+  <ContextMenu>
+    <ContextMenu.Label>Actions</ContextMenu.Label>
+    <ContextMenu.Item icon={<Icon name="bi bi-pencil" />} onSelect={handleEdit}>Düzenle</ContextMenu.Item>
+    <ContextMenu.Separator />
+    <ContextMenu.SubMenu label="Export">
+      <ContextMenu.Item onSelect={exportPdf}>PDF</ContextMenu.Item>
+      <ContextMenu.Item onSelect={exportExcel}>Excel</ContextMenu.Item>
+    </ContextMenu.SubMenu>
+    <ContextMenu.Item danger onSelect={handleDelete}>Sil</ContextMenu.Item>
+  </ContextMenu>
+
+  <Button>İşlem</Button>
+</RichComponentBase>
+```
+
+- **No DOM tax.** With a single host-element child (`<div>`, `<table>`, …) the
+  trigger is attached to that element and nothing is added. Otherwise the content
+  is wrapped in a `display: contents` element, which generates no layout box, so
+  flex/grid placement, sizing and positioning are unchanged. `trigger="child"`
+  forces the no-DOM path; `as` picks the wrapper element (`as="tbody"`).
+- **Transparent without a menu.** No `<ContextMenu>` child means no listeners and
+  no interception — the browser's own menu is untouched. The same holds for a
+  `disabled` or effectively empty declaration.
+- **Composes, never replaces.** A consumer's own `onContextMenu` runs first; if it
+  calls `preventDefault()`, the base stands down. `className`, `style`, refs and
+  accessibility props are merged, not overwritten.
+- **Real keyboard support.** Context Menu key and Shift + F10 open it; arrows,
+  Home/End, Enter/Space, Arrow Right/Left for submenus and Escape all work, with
+  focus moved on open and restored on close.
+
 ## Sidebar
 
 One recursive navigation tree with a single authoritative expansion state and a

package/dist/base/ContextMenu.d.ts

@@ -0,0 +1,87 @@
+import { ReactElement, ReactNode } from 'react';
+import { ContextMenuPoint } from './contextMenuPosition';
+/**
+ * Declarative context menu.
+ *
+ * `<ContextMenu>` is a *declaration*, not page content: on its own it renders
+ * nothing at all. `RichComponentBase` lifts the declaration out of its
+ * children and re-renders it inside a surface context when the user invokes
+ * the menu, which is why a stray `<ContextMenu>` anywhere else in a tree can
+ * never leak markup into the page.
+ *
+ * Layer: Base. It performs no HTTP and knows nothing about metadata, so
+ * Remote and Smart can compose it without inverting the dependency direction.
+ */
+export type ContextMenuCloseReason = "select" | "escape" | "dismiss";
+export interface ContextMenuSurfaceValue {
+    /** Viewport coordinates the menu was invoked at. */
+    point: ContextMenuPoint;
+    /** Changes on every invocation, so a repeated right-click re-measures. */
+    openId: number;
+    close: (reason: ContextMenuCloseReason) => void;
+}
+/**
+ * Internal wiring between `RichComponentBase` and the surface. Deliberately
+ * not part of the package's public exports — open/close state and positioning
+ * are implementation details, not API.
+ */
+export declare const ContextMenuSurfaceContext: import('react').Context<ContextMenuSurfaceValue | null>;
+export interface ContextMenuProps {
+    children?: ReactNode;
+    /**
+     * Leaves the browser's own context menu intact without removing the
+     * declaration — the menu is switched off, not deleted.
+     */
+    disabled?: boolean;
+    /** Accessible name for the surface, when the rows alone are not enough. */
+    "aria-label"?: string;
+    className?: string;
+}
+export interface ContextMenuItemProps {
+    children?: ReactNode;
+    /** Optional stable identifier; emitted as the row's DOM id. */
+    id?: string;
+    disabled?: boolean;
+    /** Not rendered at all, and so skipped by keyboard navigation. */
+    hidden?: boolean;
+    /** Destructive emphasis — the same semantic name `Menu`'s item model uses. */
+    danger?: boolean;
+    /** Icon content, e.g. `<Icon name="bi bi-pencil" />`. No icon set is bundled. */
+    icon?: ReactNode;
+    /** Accessible name, for a row whose visible text is not sufficient. */
+    "aria-label"?: string;
+    className?: string;
+    onSelect?: () => void | Promise<void>;
+}
+export interface ContextMenuLabelProps {
+    children?: ReactNode;
+    className?: string;
+}
+export interface ContextMenuSeparatorProps {
+    className?: string;
+}
+export interface ContextMenuSubMenuProps {
+    /** Visible text of the row that opens the submenu. */
+    label: ReactNode;
+    children?: ReactNode;
+    id?: string;
+    disabled?: boolean;
+    hidden?: boolean;
+    icon?: ReactNode;
+    /** Accessible name, for a trigger whose visible text is not sufficient. */
+    "aria-label"?: string;
+    className?: string;
+}
+export interface ContextMenuComponent {
+    (props: ContextMenuProps): ReactElement | null;
+    Item: (props: ContextMenuItemProps) => ReactElement | null;
+    Separator: (props: ContextMenuSeparatorProps) => ReactElement;
+    Label: (props: ContextMenuLabelProps) => ReactElement;
+    SubMenu: (props: ContextMenuSubMenuProps) => ReactElement | null;
+}
+/**
+ * The compound is annotated explicitly rather than inferred from
+ * `Object.assign`, so the generated declaration file names only exported
+ * types and never a private local one.
+ */
+export declare const ContextMenu: ContextMenuComponent;

package/dist/base/DataGrid.d.ts

@@ -1,4 +1,5 @@
 import { ReactNode } from 'react';
+import { GridResponsiveOptions } from './dataGridResponsive';
 export type DataGridAlign = "start" | "center" | "end";
 /**
  * Closed, finite formatter set — the same contract the Smart layer's
@@ -34,6 +35,17 @@ export type DataGridSort = {
     key: string;
     direction: "asc" | "desc";
 };
+/**
+ * A column's identity as the grid resolves it: `key ?? field ?? header`.
+ *
+ * The row's own field names are offered as suggestions — they are what most
+ * columns are keyed by — while an explicit `key` (a `render`-only column, a
+ * command column) is still accepted. `string & {}` is what keeps the literal
+ * suggestions from collapsing into bare `string`.
+ */
+export type DataGridColumnKey<TRow> = (keyof TRow & string) | (string & {});
+/** Responsive options for one grid, keyed by that grid's column identities. */
+export type DataGridResponsiveOptions<TRow> = GridResponsiveOptions<DataGridColumnKey<TRow>>;
 export interface DataGridProps<TRow> {
     columns: DataGridColumn<TRow>[];
     rows: TRow[];
@@ -57,6 +69,20 @@ export interface DataGridProps<TRow> {
     pageSize?: number;
     totalCount?: number;
     onPageChange?: (page: number) => void;
+    /**
+     * Progressive column reduction for narrow containers. Presence of this
+     * object is what enables the behavior — there is no second boolean to
+     * disagree with it. Omitted (the default), the grid is byte-for-byte what it
+     * was: every column stays in the row and a wide table scrolls horizontally
+     * inside its own container.
+     *
+     * Enabled, columns leave the tabular layout one at a time as the *grid's own
+     * container* gets too narrow for them, in the order of `columns`, and come
+     * back in the exact reverse order as it widens. `primaryColumn` always stays.
+     * With no `columns` list, every eligible data column is processed in declared
+     * order with `"Responsive"` behavior, so nothing is hidden by default.
+     */
+    responsive?: DataGridResponsiveOptions<TRow>;
 }
 /**
  * Intentionally focused first iteration (doc section 10/18): columns, rows,
@@ -64,4 +90,4 @@ export interface DataGridProps<TRow> {
  * No built-in filtering UI, column resize/reorder, or virtualization yet —
  * those are future extensions, not implemented speculatively.
  */
-export declare function DataGrid<TRow>({ columns, rows, rowKey, loading, error, emptyText, className, selectedRowKeys, onSelectionChange, sort, onSortChange, page, pageSize, totalCount, onPageChange, }: DataGridProps<TRow>): import("react").JSX.Element;
+export declare function DataGrid<TRow>({ columns, rows, rowKey, loading, error, emptyText, className, selectedRowKeys, onSelectionChange, sort, onSortChange, page, pageSize, totalCount, onPageChange, responsive, }: DataGridProps<TRow>): import("react").JSX.Element;

package/dist/base/RichComponentBase.d.ts

@@ -0,0 +1,12 @@
+import { HTMLAttributes, ReactHTML, ReactNode } from 'react';
+/** How the context-menu trigger is attached to the visible content. */
+export type RichComponentBaseTrigger = "auto" | "child" | "wrapper";
+export interface RichComponentBaseProps extends Omit<HTMLAttributes<HTMLElement>, "children"> {
+    /** A single optional `<ContextMenu>` declaration plus the visible content. */
+    children?: ReactNode;
+    /** See the component doc comment. Defaults to `"auto"`. */
+    trigger?: RichComponentBaseTrigger;
+    /** Wrapper element used by the wrapper path. Defaults to `"div"`. */
+    as?: keyof ReactHTML;
+}
+export declare const RichComponentBase: import('react').ForwardRefExoticComponent<RichComponentBaseProps & import('react').RefAttributes<HTMLElement>>;

package/dist/base/contextMenuModel.d.ts

@@ -0,0 +1,49 @@
+import { ReactElement, ReactNode } from 'react';
+/**
+ * Identification of the declarative context-menu nodes.
+ *
+ * Recognition is by component *identity*, recorded in a module-private
+ * WeakMap that is written once while this module initializes and never
+ * mutated afterwards. Deliberately not `displayName`, not `Component.name`
+ * and not a string on `props`: those are all rewritten or dropped by a
+ * minifier, which would make the whole feature fail only in a production
+ * bundle. A WeakMap keyed on the component reference survives minification
+ * for exactly the same reason `type === Component` does, and needs no type
+ * assertion to read back.
+ */
+export type ContextMenuNodeKind = "menu" | "item" | "label" | "separator" | "submenu";
+/** Records what a component is. Called once per component at module scope. */
+export declare function markContextMenuNode<TComponent extends object>(component: TComponent, kind: ContextMenuNodeKind): TComponent;
+/** The kind of a rendered node, or `undefined` for anything this module did not mark. */
+export declare function contextMenuNodeKind(node: ReactNode): ContextMenuNodeKind | undefined;
+/**
+ * Flattens the direct children of a node one fragment level at a time.
+ *
+ * Fragments are handled deliberately rather than by accident: a
+ * `<>{menu}{content}</>` child must not hide the menu declaration from the
+ * partition below, and its visible children must not be dropped either.
+ */
+export declare function flattenMenuChildren(children: ReactNode): ReactNode[];
+export interface RichComponentBaseChildren {
+    /** The single `<ContextMenu>` declaration, if one was supplied. */
+    menu?: ReactElement;
+    /** Everything else, rendered as ordinary page content. */
+    content: ReactNode[];
+}
+/**
+ * Splits `RichComponentBase`'s children into the menu declaration and the
+ * visible content. A second `<ContextMenu>` is ignored rather than rendered,
+ * so a stray declaration can never leak into the page as content.
+ */
+export declare function partitionRichComponentBaseChildren(children: ReactNode): RichComponentBaseChildren;
+/**
+ * Whether a declaration would put at least one selectable row on screen.
+ *
+ * This is what decides if the browser's own context menu is suppressed, so it
+ * is answered from the declaration *before* anything is rendered. Labels and
+ * separators do not count — a surface made only of those is "effectively
+ * empty" and must leave native behavior alone. Anything this module did not
+ * mark (a consumer's own wrapper component, arbitrary markup) counts as
+ * content: guessing it away would silently disable a menu that does render.
+ */
+export declare function contextMenuHasContent(children: ReactNode): boolean;

package/dist/base/contextMenuPosition.d.ts

@@ -0,0 +1,41 @@
+/**
+ * Pure viewport placement math for the context menu surface.
+ *
+ * Kept free of React and of the DOM (the caller measures and passes plain
+ * numbers) so the flip/clamp rules are unit-testable on their own, the same
+ * split `sidebarModel.ts` uses for the Sidebar's navigation model.
+ */
+export interface ContextMenuPoint {
+    x: number;
+    y: number;
+}
+export interface ContextMenuSize {
+    width: number;
+    height: number;
+}
+export interface ContextMenuViewport {
+    width: number;
+    height: number;
+}
+/** Rect of a submenu's trigger row, in viewport coordinates. */
+export interface ContextMenuTriggerBox {
+    left: number;
+    right: number;
+    top: number;
+    bottom: number;
+}
+/** Breathing room kept between the surface and the viewport edge. */
+export declare const CONTEXT_MENU_VIEWPORT_MARGIN = 8;
+/**
+ * Places the root surface at the pointer. Flips to the opposite side of the
+ * pointer when the preferred side would overflow, then clamps, so a menu that
+ * is simply larger than the viewport still starts inside it rather than
+ * scrolling the page.
+ */
+export declare function placeContextMenuAtPoint(point: ContextMenuPoint, size: ContextMenuSize, viewport: ContextMenuViewport, margin?: number): ContextMenuPoint;
+/**
+ * Places a submenu beside its trigger row: flush to the trigger's right edge
+ * by default so the pointer can travel into it without crossing a gap, and
+ * mirrored to the left when that would overflow.
+ */
+export declare function placeSubMenuBeside(trigger: ContextMenuTriggerBox, size: ContextMenuSize, viewport: ContextMenuViewport, margin?: number): ContextMenuPoint;

package/dist/base/dataGridResponsive.d.ts

@@ -0,0 +1,169 @@
+import { RefObject } from 'react';
+/**
+ * Responsive column model for grid-like components.
+ *
+ * The problem: when a grid's *actual available width* is too small for its
+ * visible columns, rows stop being readable. The answer here is an ordered
+ * list of rules that progressively take columns out of the tabular layout —
+ * either relocating them into the row's own label/value detail area
+ * (`"Responsive"`) or dropping them entirely (`"Hide"`) — while one primary
+ * column always stays in the normal row.
+ *
+ * This module owns the whole algorithm: column classification, primary-column
+ * resolution, rule normalization, development-time validation and the
+ * width-driven fit loop. `DataGrid` is its only consumer, and `RemoteDataGrid`
+ * and the Smart `dataGridResolver` inherit the behavior by composing
+ * `DataGrid` — the algorithm exists exactly once.
+ *
+ * It is deliberately React-only-at-the-edges: everything above
+ * `useResponsiveColumnFit` is a pure function of a structural column model,
+ * so it is unit-testable without rendering a grid, and it never imports the
+ * grid itself (no cycle, and the grid stays the sole owner of its column type).
+ */
+/**
+ * What happens to a column when the grid runs out of room for it.
+ *
+ * - `"Responsive"` — leaves the tabular row and is shown as a label/value pair
+ *   in that same row's detail area.
+ * - `"Hide"` — leaves the tabular row and is not shown anywhere.
+ *
+ * Capitalized, unlike this library's other string unions (`"asc"`, `"text"`,
+ * `"auto"`, …), because these two are a specified external contract. One
+ * representation only: the lower-case spellings are deliberately *not*
+ * accepted, so there is never a second competing form of the same concept.
+ */
+export type ResponsiveColumnBehavior = "Responsive" | "Hide";
+/**
+ * One entry of the ordered rule list. Position in the array is the priority —
+ * there is no separate priority number to keep in sync with it.
+ */
+export interface ResponsiveColumnRule<TField> {
+    field: TField;
+    behavior: ResponsiveColumnBehavior;
+}
+export interface GridResponsiveOptions<TField> {
+    /**
+     * The column that carries the row's identity in a narrow layout. It always
+     * stays in the tabular row: it is never relocated to the detail area and
+     * never removed by a `"Hide"` rule.
+     */
+    primaryColumn?: TField;
+    /**
+     * Ordered rules. The first is processed first as width shrinks, and the last
+     * processed is the first restored as width grows. Columns not listed here
+     * are still handled — see `buildResponsiveColumnPlan`.
+     */
+    columns?: readonly ResponsiveColumnRule<TField>[];
+}
+/**
+ * The parts of a grid column this model needs, as a structural shape.
+ *
+ * `isData` / `isUtility` / `isTextual` are classifications the grid derives
+ * from its own column type, so this module never has to know what a
+ * `DataGridColumn` is.
+ */
+export interface ResponsiveColumnModel {
+    /** The grid's own column identity. */
+    key: string;
+    /** Reads a value out of the row (as opposed to a command/action column). */
+    isData: boolean;
+    /** A command/action/control column: renders arbitrary content, reads no value. */
+    isUtility: boolean;
+    /** A data column whose value is textual, so it reads well as a row title. */
+    isTextual: boolean;
+}
+export type ResponsiveProblemKind = "unknown-column" | "duplicate-rule" | "primary-column-rule" | "invalid-behavior" | "utility-column-responsive" | "invalid-primary-column";
+/** One development-time diagnostic, in the same shape the demo registry uses. */
+export interface ResponsiveProblem {
+    kind: ResponsiveProblemKind;
+    detail: string;
+}
+/** A rule after validation, addressed by the grid's resolved column key. */
+export interface NormalizedResponsiveRule {
+    key: string;
+    behavior: ResponsiveColumnBehavior;
+}
+export interface ResponsiveColumnPlan {
+    /** Resolved primary column, or `undefined` when no column is eligible. */
+    primaryKey: string | undefined;
+    /** The single ordered list the fit loop walks. */
+    rules: readonly NormalizedResponsiveRule[];
+    problems: readonly ResponsiveProblem[];
+}
+/**
+ * Deterministic resolution, in order:
+ *
+ * 1. the configured `primaryColumn`, when it names an eligible column;
+ * 2. otherwise the first textual data column in declared column order;
+ * 3. otherwise the first data column in declared column order;
+ * 4. otherwise `undefined` — the grid keeps its existing behavior.
+ *
+ * Utility columns (selection, row number, expanders, actions, command and
+ * drag-handle columns) are never chosen automatically, and a configured one is
+ * rejected: a checkbox or a button is not a row's identity.
+ *
+ * A configured column that is absent from the current column set — because it
+ * was filtered out upstream by a column chooser, by a permission check or by
+ * Smart metadata — cannot be the *visible* primary column, so resolution falls
+ * through to the automatic rules. Nothing about the upstream decision is
+ * touched or written back.
+ */
+export declare function resolvePrimaryColumnKey(columns: readonly ResponsiveColumnModel[], configured: string | undefined): string | undefined;
+/**
+ * Turns the configured options into one ordered, validated rule list.
+ *
+ * Configured rules come first, in their declared order. Every remaining
+ * eligible data column is then appended in *declared column order* with the
+ * default `"Responsive"` behavior, so responsive layout works without asking
+ * a consumer to describe every column — and nothing is hidden by default.
+ *
+ * Skipped, each with a diagnostic: a rule for an unknown column, a duplicate
+ * rule, a rule for the primary column, a rule with an invalid behavior, and a
+ * `"Responsive"` rule for a utility column (an action cell has no meaningful
+ * label/value form). A `"Hide"` rule for a utility column is honored — that is
+ * an explicit instruction to drop a control when space runs out, not a silent
+ * loss of data. Utility columns are never added by default.
+ */
+export declare function buildResponsiveColumnPlan(columns: readonly ResponsiveColumnModel[], options: GridResponsiveOptions<string> | undefined): ResponsiveColumnPlan;
+/**
+ * A stable string identity for one plan. Used to reset the fit loop and to
+ * report diagnostics once per configuration rather than once per render or —
+ * far worse — once per resize.
+ */
+export declare function responsivePlanSignature(plan: ResponsiveColumnPlan): string;
+export interface ResponsiveColumnFitOptions {
+    enabled: boolean;
+    /** The grid's own scroll container — the element whose width actually matters. */
+    containerRef: RefObject<HTMLElement | null>;
+    ruleCount: number;
+    /** Resets the loop when the columns or the rules themselves change. */
+    signature: string;
+}
+/**
+ * How many rules are currently applied.
+ *
+ * Overflow is read from the grid's existing scroll container
+ * (`scrollWidth` vs `clientWidth`) rather than from a re-implementation of
+ * column sizing, so the browser's own table layout — fixed, minimum and
+ * maximum column widths, measured content, `white-space` — remains the single
+ * sizing authority. Two DOM reads per pass, independent of row count: the
+ * algorithm is O(1) in rows and never scans cells.
+ *
+ * Shrinking applies one more rule per pass and records the width at which the
+ * previous count did not fit. Growing releases one rule per pass, but only
+ * once the container is wider than that recorded width plus the hysteresis, so
+ * a restore that would immediately overflow again is not attempted. Passes are
+ * capped per width, so a pathological layout cannot loop forever.
+ */
+export declare function useResponsiveColumnFit({ enabled, containerRef, ruleCount, signature, }: ResponsiveColumnFitOptions): number;
+/**
+ * Reports configuration problems once per configuration.
+ *
+ * Follows the library's existing development-time validation convention
+ * (`useControllableState`, `Sidebar`): `NODE_ENV`-guarded, `console.error`
+ * with the `[react-components]` prefix, from an effect keyed on a stable
+ * signature — so it never throws during render and never logs on resize.
+ * Production fails safe: the malformed rule is skipped, and no data is hidden
+ * because of it.
+ */
+export declare function useResponsivePlanDiagnostics(plan: ResponsiveColumnPlan, signature: string): void;

package/dist/base/index.d.ts

@@ -17,6 +17,12 @@ export * from './AutoComplete';
 export * from './FormField';
 export * from './Modal';
 export * from './DataGrid';
+/**
+ * Responsive column model shared by every grid-like component. Exported from
+ * the Base layer so Remote and Smart grids inherit it by composition rather
+ * than by a second implementation.
+ */
+export type { GridResponsiveOptions, ResponsiveColumnBehavior, ResponsiveColumnRule, } from './dataGridResponsive';
 export * from './Pagination';
 export * from './Button';
 export * from './Spinner';
@@ -57,6 +63,15 @@ export { AppearanceProvider, useAppearance, createAppearanceInitScript, THEME_MO
 export type { AppearanceContextValue, AppearanceInitScriptOptions, AppearanceProviderProps, AppearanceSettings, AppearanceStorage, ResolvedTheme, SidebarPresentation, SidebarTone, ThemeMode, } from './Appearance';
 export * from './appearanceSchemes';
 export * from './AppearanceMenu';
+/**
+ * Context menu system. `RichComponentBase` and the `ContextMenu` compound are
+ * the whole public surface — the surface context, the positioning helpers and
+ * the node-kind model behind them stay internal.
+ */
+export { RichComponentBase } from './RichComponentBase';
+export type { RichComponentBaseProps, RichComponentBaseTrigger } from './RichComponentBase';
+export { ContextMenu } from './ContextMenu';
+export type { ContextMenuComponent, ContextMenuItemProps, ContextMenuLabelProps, ContextMenuProps, ContextMenuSeparatorProps, ContextMenuSubMenuProps, } from './ContextMenu';
 export { Popup } from './shared/Popup';
 export type { PopupProps } from './shared/Popup';
 export { Label } from './shared/Label';

package/dist/base/shared/Portal.d.ts

@@ -0,0 +1,20 @@
+import { ReactNode } from 'react';
+export interface PortalProps {
+    children: ReactNode;
+    /** Defaults to `document.body` once mounted on the client. */
+    container?: Element | null;
+}
+/**
+ * Minimal SSR-safe portal.
+ *
+ * The repository had no portal infrastructure before this (Popup positions
+ * itself with plain CSS and Modal renders in place, both of which say so in
+ * their own doc comments), so this is the smallest primitive that lets an
+ * overlay escape an ancestor's `overflow`/`transform` clipping.
+ *
+ * `document` is never touched during module initialization or during render:
+ * the host is resolved in an effect, so a server render produces nothing and
+ * the first client render is identical to it. Intentionally internal — it is
+ * plumbing for the context menu surface, not a second public overlay API.
+ */
+export declare function Portal({ children, container }: PortalProps): import('react').ReactPortal | null;

package/dist/base/shared/composeRefs.d.ts

@@ -0,0 +1,3 @@
+import { Ref } from 'react';
+/** Fans one element out to every supplied ref, ignoring the empty ones. */
+export declare function composeRefs<T>(...refs: Array<Ref<T> | undefined | null>): Ref<T>;

package/dist/base/shared/useElementResize.d.ts

@@ -0,0 +1,16 @@
+import { RefObject } from 'react';
+/**
+ * Calls `onResize` whenever the observed element's box changes.
+ *
+ * The element's *own* box, not the viewport: a grid can sit in a narrow
+ * dashboard panel, a modal, a split view or a resizable container, and a
+ * global breakpoint knows nothing about any of those.
+ *
+ * `ResizeObserver` is used when the environment has it, and only then; the
+ * window-resize listener is a fallback for environments without it, so a
+ * modern browser never gets a permanent global listener per grid. Nothing is
+ * touched during module initialization or during render, so importing this on
+ * a server is inert, and the observer is disconnected on cleanup — which is
+ * also what makes it safe under React Strict Mode's double mount.
+ */
+export declare function useElementResize(ref: RefObject<Element | null>, enabled: boolean, onResize: () => void): void;

package/dist/base/shared/useIsomorphicLayoutEffect.d.ts

@@ -0,0 +1,12 @@
+import { useEffect } from 'react';
+/**
+ * `useLayoutEffect` in the browser, `useEffect` on the server.
+ *
+ * Measurement has to happen after layout but before paint, which is what
+ * `useLayoutEffect` is for — but React warns when it runs during server
+ * rendering, where there is no layout to read. The `typeof window` test never
+ * touches a browser global (it cannot throw) and is evaluated once, so the
+ * choice is constant for the lifetime of the module and the rules of hooks
+ * still hold.
+ */
+export declare const useIsomorphicLayoutEffect: typeof useEffect;