@omnitend/dashboard-for-laravel 0.34.0 → 0.35.0

package/dist/components/extended/DXForm.vue.d.ts

@@ -44,12 +44,33 @@ interface Props {
      */
     cardTabs?: boolean;
     /**
-     * Form-wide field layout: "vertical" (default, label above input) or
-     * "horizontal" (label left, input right). Overridable per-field via
-     * `field.layout`. A field with `span: true` always renders full-width,
-     * regardless of layout.
+     * Form-wide field layout:
+     *
+     * - `"vertical"` (default) — label above input, always.
+     * - `"horizontal"` — label left, input right, always.
+     * - `"auto"` — horizontal when the form's **own container** is at least
+     *   `layoutThreshold` px wide, vertical below that. Container-driven, not
+     *   viewport-driven: a page narrowed by the dashboard sidebar, or a form
+     *   inside a modal, stacks even though the window is wide (which no
+     *   Bootstrap media query can see).
+     *
+     * Overridable per-field via `field.layout`. A field with `span: true`
+     * always renders full-width, regardless of layout.
      */
-    layout?: "vertical" | "horizontal";
+    layout?: "vertical" | "horizontal" | "auto";
+    /**
+     * Container width (px) at or above which `layout: "auto"` goes horizontal.
+     * Ignored for the explicit `"vertical"`/`"horizontal"` layouts.
+     *
+     * Default 640, measured rather than guessed: with the default 3-column
+     * label the label's text area is `containerWidth / 4 - 18` px, so 640 gives
+     * it 142px — enough for a ~20-character label ("Unit price (ex VAT)"
+     * measures 128px at the theme's label font) to stay on one line, with the
+     * control column still 474px. Below ~584px that label starts wrapping,
+     * which is the cramped-label symptom this exists to avoid. Raise it if your
+     * labels run longer, or lower `labelCols` instead.
+     */
+    layoutThreshold?: number;
     /**
      * Label column width for horizontal layout (mirrors BFormGroup's
      * `labelCols`/`labelCols*` props). Overridable per-field via
@@ -73,13 +94,14 @@ declare const __VLS_component: import("vue").DefineComponent<__VLS_PublicProps,
     onSubmit?: (() => any) | undefined;
     "onUpdate:activeTab"?: ((value: number) => any) | undefined;
 }>, {
-    layout: "vertical" | "horizontal";
+    layout: "vertical" | "horizontal" | "auto";
     card: boolean;
     submitText: string;
     submitLoadingText: string;
     showSubmit: boolean;
     autoErrorTab: boolean;
     cardTabs: boolean;
+    layoutThreshold: number;
 }, {}, {}, {}, string, import("vue").ComponentProvideOptions, false, {}, any>;
 declare const _default: __VLS_WithSlots<typeof __VLS_component, __VLS_Slots>;
 export default _default;

package/dist/components/extended/DXTable.vue.d.ts

@@ -67,6 +67,21 @@ export interface TableField {
     filter?: FilterType;
     filterOptions?: FilterOption[];
     filterPlaceholder?: string;
+    /**
+     * For a `select` filter on a **client-side** table: derive the dropdown's
+     * options from the distinct values present in the loaded rows. Defaults to
+     * `true` — with no `filterOptions` and no server `filterValues` the
+     * alternative is an empty dropdown, which can only ever be a bug.
+     *
+     * Set `false` to opt out (e.g. a column whose raw values are opaque ids you
+     * would rather label yourself via `filterOptions`).
+     *
+     * Explicit `filterOptions` and server-supplied `filterValues` still WIN, in
+     * that order. Provider/API and Inertia modes ignore this flag: they only
+     * ever hold one page of rows, so there is no complete value set to derive
+     * from (see `getFieldFilterOptions`).
+     */
+    deriveFilterOptions?: boolean;
     /**
      * Fixed width for this column, applied via a `<colgroup>` `<col>`. A number
      * is treated as pixels (`200` → `200px`); a string is used verbatim
@@ -233,6 +248,19 @@ export interface Props<TItem = any> {
      * borderless variant — the same header, filter row, table and pagination
      * rendered directly on the page background (no card border/shadow), for
      * data-heavy admin index pages that read as busy inside a card.
+     *
+     * The table renders FLUSH to the card border (rows and stripes reach the
+     * edge) while the header and pagination stay padded, which requires the card
+     * to clip to its radius (`overflow: hidden`).
+     *
+     * **Consequence for slot content:** anything you render into a slot that
+     * positions itself OUTSIDE the card and does not teleport is clipped at the
+     * card edge. Library components are unaffected — `DDropdown` teleports to
+     * `<body>` by default, and the column-filter menus position themselves
+     * `fixed` — so this only bites a hand-rolled `position: absolute` overlay
+     * (a custom popover in a `cell(<key>)` or `#header` slot). Teleport it, or
+     * use `:card="false"`. Narrowing the clip to the table region is tracked
+     * as #166.
      */
     card?: boolean;
     /**
@@ -253,8 +281,13 @@ export interface Props<TItem = any> {
      * **"horizontal"** to match the Omni Tend form convention (a raw modal form
      * previously fell back to DXForm's vertical default, which looked out of
      * place next to horizontal page forms). Pass `"vertical"` to opt out.
+     *
+     * `"auto"` hands the decision to `DXForm`'s container-width observer, which
+     * measures the FORM rather than the window — so a modal narrowed by its own
+     * breakpoint stacks to vertical even on a wide viewport, where a media query
+     * would still report "plenty of room". See `useContainerWidth`.
      */
-    editLayout?: 'vertical' | 'horizontal';
+    editLayout?: 'vertical' | 'horizontal' | 'auto';
     /**
      * Label column width for the edit modal's horizontal layout, forwarded to
      * `DXForm`'s `labelCols` (a single width or a per-breakpoint object). Only
@@ -390,6 +423,11 @@ declare const _default: <T = any>(__VLS_props: NonNullable<Awaited<typeof __VLS_
     }>): void;
     attrs: any;
     slots: {
+        [x: `head-end(${string})`]: ((props: {
+            field: TableField;
+            label: string;
+        }) => any) | undefined;
+    } & {
         [x: string]: ((props: any) => any) | undefined;
     } & {
         [x: string]: ((props: any) => any) | undefined;

package/dist/components/extended/DXTableEditorModal.vue.d.ts

@@ -27,8 +27,13 @@ interface Props {
     pendingAction: 'save' | 'delete' | null;
     /** Delete endpoint — gates the Delete button. */
     deleteUrl?: string;
-    /** Field layout forwarded to the modal's DXForm (defaults handled upstream). */
-    layout?: 'vertical' | 'horizontal';
+    /**
+     * Field layout forwarded to the modal's DXForm (defaults handled upstream).
+     * Includes `"auto"`, which lets the form stack to vertical when the MODAL is
+     * narrow even though the viewport is wide — the container-query case a
+     * viewport media query cannot see.
+     */
+    layout?: 'vertical' | 'horizontal' | 'auto';
     /** Label column width forwarded to DXForm (horizontal layout). */
     labelCols?: LabelCols;
     /** Wrap the modal form in a card (opt-in — off by default). */

package/dist/composables/useContainerWidth.d.ts

@@ -0,0 +1,96 @@
+/**
+ * useContainerWidth — container-query-style responsiveness for Vue components.
+ *
+ * Bootstrap's breakpoints are **media** queries: they only ever see the WINDOW.
+ * A dashboard page is narrowed by the persistent sidebar (and a form inside a
+ * modal is narrower still), so a component can have very little room while the
+ * viewport is wide — and no media query ever fires. This composable closes that
+ * gap by observing an element's **own rendered width** with a `ResizeObserver`
+ * and exposing it reactively, so the template can pick a layout from the space
+ * it actually has.
+ *
+ * ```ts
+ * const { containerRef, width, isBelow, isNarrowerThan } = useContainerWidth({
+ *   threshold: 640,
+ * });
+ * // <div ref="containerRef"> … </div>
+ * ```
+ *
+ * One observer can drive several independent decisions — `isBelow` uses the
+ * configured `threshold`, and `isNarrowerThan(n)` answers for any other width:
+ *
+ * ```ts
+ * const stacked = computed(() => isNarrowerThan(576));
+ * const hideDetailColumn = computed(() => isNarrowerThan(900));
+ * ```
+ */
+import { type Ref } from "vue";
+/**
+ * What to observe: a template ref, or a getter (so the element can be resolved
+ * lazily / conditionally — e.g. `() => enabled ? el.value : null` to observe
+ * nothing at all).
+ */
+export type ContainerWidthTarget = Ref<HTMLElement | null | undefined> | (() => HTMLElement | null | undefined);
+export interface UseContainerWidthOptions {
+    /**
+     * Width (px) that `isBelow` compares against. Omit if you only need
+     * `width` / `isNarrowerThan`. Pass a getter (`() => props.threshold`) when
+     * it can change at runtime — `isBelow` re-evaluates when it does.
+     */
+    threshold?: number | (() => number | undefined);
+    /**
+     * Hysteresis band (px) applied to `isBelow` only, to stop a layout flipping
+     * back and forth at the boundary. Once `isBelow` is true it stays true
+     * until the width reaches `threshold + hysteresis`.
+     *
+     * Defaults to `0` so `isBelow` means exactly `width < threshold` unless you
+     * ask for otherwise. Opt in whenever the layout you drive from it can
+     * change the observed width — the classic loop is: narrow layout is taller
+     * → an ancestor with `overflow:auto` gains a vertical scrollbar → the
+     * container loses ~15-17px → it crosses back over the threshold → repeat.
+     * A band wider than a scrollbar (24px is comfortable) breaks that cycle.
+     * (`isNarrowerThan` is deliberately raw — it holds no per-width state.)
+     */
+    hysteresis?: number;
+    /**
+     * Width assumed before the first measurement, and permanently where there
+     * is no `ResizeObserver` (SSR, or a very old browser).
+     *
+     * Defaults to `0` — i.e. "assume the narrowest until proven otherwise", so
+     * an unmeasured render picks the STACKED layout. That is the mobile-first
+     * choice and the safe one: a stacked layout is legible at every width,
+     * whereas a wide layout guessed wrongly truncates content. It also means
+     * the server-rendered markup matches the first client render.
+     */
+    initialWidth?: number;
+    /**
+     * Which box to report. `content-box` (default) is the space actually
+     * available to children — what a layout decision usually wants.
+     * `border-box` matches `getBoundingClientRect().width`.
+     */
+    box?: "content-box" | "border-box";
+    /**
+     * Extra debounce (ms) before publishing a new width. Defaults to `0`:
+     * `ResizeObserver` already batches to one delivery per frame, and the
+     * callback reads the size the observer *hands* it (no forced layout), so
+     * there is nothing to thrash. Set it only for genuinely expensive
+     * downstream work — a timer adds a frame of visible lag.
+     */
+    debounce?: number;
+}
+export interface UseContainerWidthReturn {
+    /** Bind to the element you want measured (`<div ref="containerRef">`). */
+    containerRef: Ref<HTMLElement | null>;
+    /** The observed width in px. `initialWidth` until first measured. */
+    width: Readonly<Ref<number>>;
+    /** False until a real measurement has landed (always false without a `ResizeObserver`). */
+    hasMeasured: Readonly<Ref<boolean>>;
+    /** `width < threshold`, with `hysteresis` applied. False when no `threshold` was given. */
+    isBelow: Readonly<Ref<boolean>>;
+    /** Raw `width < px`, for driving other decisions off the same observer. */
+    isNarrowerThan: (px: number) => boolean;
+    /** Disconnect early. Called automatically when the owning scope is disposed. */
+    stop: () => void;
+}
+export declare function useContainerWidth(options?: UseContainerWidthOptions): UseContainerWidthReturn;
+export declare function useContainerWidth(target: ContainerWidthTarget, options?: UseContainerWidthOptions): UseContainerWidthReturn;