@omnitend/dashboard-for-laravel 0.34.0 → 0.35.0

package/resources/js/components/extended/DXTable.vue

@@ -163,6 +163,35 @@
                                     <div class="fw-semibold">{{ headerLabel(field, label) }}</div>
                                     <small v-if="field.hint" class="text-muted d-block" style="font-weight: normal;">{{ field.hint }}</small>
                                 </div>
+
+                                <!-- ADDITIVE per-column header content (#99), rendered
+                                     INSIDE DXTable's own header cell rather than as a
+                                     `head(<key>)` override — an override would silently
+                                     drop the sort indicator and the field hint, which is
+                                     exactly why `head(...)` is not forwarded (see
+                                     `isTableSlot`). Placed after the label block and
+                                     BEFORE the sort indicator so a period total sits at
+                                     the top-right of the text area without displacing the
+                                     sort arrows, and lands in the same place whether or
+                                     not the column happens to be sortable. The wrapper is
+                                     only emitted when the slot exists, so a table without
+                                     one renders exactly as before. -->
+                                <div
+                                    v-if="$slots[`head-end(${field.key})`]"
+                                    class="dx-head-end flex-shrink-0 text-end"
+                                >
+                                    <!--
+                                      @slot head-end(<fieldKey>) Additive content at the end of a column's own header — a period total above a numeric column, a small badge — keeping DXTable's sort indicator and field hint. Not a `head()` override.
+                                      @binding {object} field The column's field definition.
+                                      @binding {string} label The column's resolved header label.
+                                    -->
+                                    <slot
+                                        :name="`head-end(${field.key})`"
+                                        :field="field"
+                                        :label="headerLabel(field, label)"
+                                    />
+                                </div>
+
                                 <div v-if="field.sortable" class="sort-indicator text-muted flex-shrink-0" style="font-size: 0.75rem; line-height: 1.1; display: flex; flex-direction: column; align-items: center;">
                                     <span :style="{ opacity: getFieldSortState(field.key) === 'asc' ? 1 : 0.3 }">▲</span>
                                     <span :style="{ opacity: getFieldSortState(field.key) === 'desc' ? 1 : 0.3 }">▼</span>
@@ -359,6 +388,22 @@ export interface TableField {
     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
@@ -559,6 +604,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;
 
@@ -585,8 +643,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
@@ -1020,16 +1083,7 @@ const clientSideFilteredItems = computed<T[]>(() => {
         return filterKeys.every(key => {
             // Resolve by the FILTER key, which may differ from the column's key.
             const field = props.fields.find(f => filterKeyFor(f) === key);
-            // `filterKey` names the param the SERVER filters on; a local row may
-            // not carry it at all (a `customer_name` row filtered on
-            // `customer_id`). Match on the filter key when the row has it,
-            // otherwise fall back to the column's own value — which is also the
-            // one the user can actually see and type against.
-            // Both lookups are dot-path aware, so a nested payload filters (#121).
-            const itemValue =
-                field && hasFieldValue(item, key)
-                    ? fieldValueOf(item, key)
-                    : fieldValueOf(item, field?.key ?? key);
+            const itemValue = clientSideFilterValueOf(item, field, key);
 
             const matchesCandidate = (candidate: string): boolean => {
                 // The "no value" option (e.g. Unassigned) is the one filter that
@@ -1151,6 +1205,28 @@ const hasFieldValue = (item: unknown, key: string): boolean => {
     return getByPath(item as Record<string, any>, key) !== undefined;
 };
 
+/*
+ * The value a client-side filter compares against, for one row and one column.
+ *
+ * `filterKey` names the param the SERVER filters on; a local row may not carry
+ * it at all (a `customer_name` row filtered on `customer_id`). Read the filter
+ * key when the row has it, otherwise fall back to the column's own value —
+ * which is also the one the user can actually see and type against. Both
+ * lookups are dot-path aware, so a nested payload filters (#121).
+ *
+ * Extracted so the client-side row filter and the DERIVED select options (see
+ * `derivedFilterOptions`) resolve values through exactly the same rule — a
+ * derived option must never be a value the filter then fails to match.
+ */
+const clientSideFilterValueOf = (
+    item: unknown,
+    field: TableField | undefined,
+    filterKey: string,
+): any =>
+    field && hasFieldValue(item, filterKey)
+        ? fieldValueOf(item, filterKey)
+        : fieldValueOf(item, field?.key ?? filterKey);
+
 /*
  * Dotted-key columns DXTable must render itself, because bvn renders them empty
  * (see `fieldValueOf`). A consumer's own `cell(<key>)` slot always wins — it is
@@ -1235,6 +1311,115 @@ const filterAllLabelFor = (field: TableField): string =>
 const headerLabel = (field: TableField, slotLabel?: string): string =>
     field.label !== undefined ? field.label : (slotLabel || field.key);
 
+/**
+ * A select filter option's LABEL, honouring the column's own value→label
+ * formatting so the dropdown reads the way the column does (a `formatter`
+ * turning `19.99` into `$19.99`). The option's `value` stays RAW — that is what
+ * the client-side filter compares against (`String(itemValue) === candidate`),
+ * so formatting must never leak into it.
+ *
+ * `formatter` is bootstrap-vue-next's field formatter, `(value, key, item)`, and
+ * its first argument is by contract the value of `field.key` — the DISPLAYED
+ * column value. That matters when `filterKey` names a different property: the
+ * option's value must stay the FILTER value (that is what the row filter
+ * compares), but the formatter must still be handed the display value it was
+ * written against. Passing the filter value here fed a `customer` column's
+ * `(customer) => customer.name` formatter a numeric `customer_id`, which
+ * mislabels at best and throws at worst.
+ */
+const formattedFilterLabel = (field: TableField, item: unknown): string | null => {
+    if (typeof field.formatter !== 'function') return null;
+    const formatted = field.formatter(fieldValueOf(item, field.key), field.key, item);
+    if (formatted === null || formatted === undefined) return null;
+    return String(formatted);
+};
+
+/**
+ * Client-side auto-derived `filter: "select"` options, keyed by field key.
+ *
+ * Without this a client-side select column with no `filterOptions` and no
+ * server `filterValues` rendered an EMPTY dropdown — dead UI that can only be a
+ * bug — so this is on by default (opt out per column with
+ * `deriveFilterOptions: false`).
+ *
+ * It derives from `resolvedItems` (the FULL loaded row set) and deliberately
+ * NOT from `clientSideFilteredItems` or `clientSidePaginatedItems`:
+ *  - filtered set → picking a value would collapse the dropdown to that one
+ *    value, and the user could never get back to any other one;
+ *  - current page → the offered values would silently change as you page.
+ * Being a computed over `props.fields` + `resolvedItems` only, it is also
+ * structurally incapable of depending on the active filters — the cache is the
+ * guard, not just the comment.
+ */
+const derivedFilterOptions = computed<Record<string, FilterOption[]>>(() => {
+    // Only client-side mode has the complete row set. Provider/API and Inertia
+    // hold one page, so they take their options from the server instead.
+    if (!isClientSideMode.value) return {};
+
+    const rows = resolvedItems.value;
+    if (!rows || rows.length === 0) return {};
+
+    const optionsByFieldKey: Record<string, FilterOption[]> = {};
+
+    for (const field of props.fields) {
+        if (field.filter !== 'select') continue;
+        if (field.deriveFilterOptions === false) continue;
+        // Explicit options win outright (see `getFieldFilterOptions`), so don't
+        // spend a pass over every row producing a list nothing will read.
+        if (field.filterOptions && field.filterOptions.length > 0) continue;
+
+        const filterKey = filterKeyFor(field);
+
+        // Distinct values keyed by their STRING form, because that is exactly
+        // what the client-side select filter compares — so `1` and `"1"` are one
+        // option, and every option offered is one the filter can match. The
+        // first row carrying a value is kept alongside it, as the `item`
+        // argument the column's formatter expects.
+        const firstRowByValue = new Map<string, { rawValue: any; item: unknown }>();
+
+        // Candidates the filter reads as CONTROL values rather than data, so a
+        // row whose value collides with one can never be matched by selecting it
+        // (`handleSelectFilterChange` turns the "all" sentinel back into "no
+        // filter", and the null sentinel is intercepted upstream of the select's
+        // exact-match arm, where it means "has no value"). Offering such an
+        // option would be a dropdown entry that returns zero rows, and the null
+        // one would also duplicate the `filterNullText` entry's value.
+        const reservedCandidates = new Set<string>([FILTER_ALL_VALUE]);
+        if (field.filterNullText) reservedCandidates.add(filterNullValueFor(field));
+
+        for (const item of rows) {
+            const value = clientSideFilterValueOf(item, field, filterKey);
+            // null / undefined / '' are skipped deliberately: "has no value" is
+            // already a first-class, LABELLED option via `filterNullText`, and
+            // an unlabelled blank row in the list would be unusable.
+            if (value === null || value === undefined || value === '') continue;
+            const stringValue = String(value);
+            if (reservedCandidates.has(stringValue)) continue;
+            if (!firstRowByValue.has(stringValue)) {
+                firstRowByValue.set(stringValue, { rawValue: value, item });
+            }
+        }
+
+        const entries = [...firstRowByValue.entries()];
+
+        // Stable, human ordering: numeric when both values are numbers,
+        // otherwise a locale compare — the same rule the client-side sort uses,
+        // with `numeric: true` so "Item 2" precedes "Item 10".
+        entries.sort(([leftText, left], [rightText, right]) =>
+            typeof left.rawValue === 'number' && typeof right.rawValue === 'number'
+                ? left.rawValue - right.rawValue
+                : leftText.localeCompare(rightText, undefined, { numeric: true, sensitivity: 'base' }),
+        );
+
+        optionsByFieldKey[field.key] = entries.map(([stringValue, { item }]) => ({
+            value: stringValue,
+            text: formattedFilterLabel(field, item) ?? stringValue,
+        }));
+    }
+
+    return optionsByFieldKey;
+});
+
 const getFieldFilterOptions = (field: TableField): FilterOption[] => {
     const options: FilterOption[] = [];
 
@@ -1274,6 +1459,15 @@ const getFieldFilterOptions = (field: TableField): FilterOption[] => {
         return [...options, ...serverValues.map(value => ({ value, text: value }))];
     }
 
+    // Last resort, CLIENT-SIDE only: the distinct values present in the loaded
+    // rows. Precedence is deliberate — explicit `filterOptions`, then the
+    // server's `filterValues`, then what the data itself says. See
+    // `derivedFilterOptions` for why it derives from the unfiltered row set.
+    const derived = derivedFilterOptions.value[field.key];
+    if (derived && derived.length > 0) {
+        return [...options, ...derived];
+    }
+
     // No values to choose from — don't offer a lone "All x" that filters nothing.
     return [];
 };
@@ -1549,7 +1743,12 @@ const shouldShowPerPageSelector = computed(() => {
     return total >= smallestOption;
 });
 
-// Detect which fields need server filter values
+// Detect which fields need server filter values.
+//
+// Client-side derived options (`derivedFilterOptions`) deliberately do NOT
+// shrink this list: it is only ever read by `internalProvider`, i.e. API mode,
+// and `isProviderMode` requires `!resolvedClientSide` — the two modes are
+// mutually exclusive, so a client-side derived column can never appear here.
 const fieldsNeedingFilterValues = computed(() => {
     return props.fields
         .filter(field => field.filter === 'select' && (!field.filterOptions || field.filterOptions.length === 0))
@@ -1956,6 +2155,12 @@ const refresh = () => {
  * - `head(<key>)` — DXTable draws its own column headers (sort indicators,
  *   field hints). Forwarding a consumer's would silently drop those.
  * - `thead-top`   — DXTable renders the inline filter row there.
+ *
+ * `head-end(<key>)` is DXTable's OWN additive header slot (#99) and is likewise
+ * not forwarded: the inner table has no such slot, and the prefixes below are
+ * matched with `startsWith`, so it must not begin with `cell(`/`foot(` either —
+ * `head-end(` satisfies both. It is also excluded from `tableSlotSignature`
+ * (which filters on `isTableSlot`), so adding one never remounts the table.
  */
 const TABLE_SLOT_PREFIXES = ['cell(', 'foot('];
 const TABLE_SLOT_NAMES = new Set([

package/resources/js/components/extended/DXTableEditorModal.vue

@@ -208,8 +208,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/resources/js/components/extended/DXTablePagination.vue

@@ -135,7 +135,7 @@ const emit = defineEmits<{
 // except a single-page gap which shows the page itself (an ellipsis hiding one
 // page is silly). Client-computed from current + last page so it works in every
 // DXTable mode (provider / client-side / inertia) — not just where a server
-// `links` array exists. Reproduces custard's `1 2 … 8 9 10 [11] 12 13 14 … 44 45`.
+// `links` array exists. Reproduces the house style: `1 2 … 8 9 10 [11] 12 13 14 … 44 45`.
 const BOUNDARY = 2;
 const AROUND = 3;
 
@@ -192,9 +192,25 @@ const goToPage = (page: number) => {
 </script>
 
 <style scoped>
+/*
+  In `DXTable`'s card mode the card is rendered `no-body` so the table can sit
+  flush against the card border, which makes this footer a direct child of
+  `.card` — it no longer inherits any `.card-body` padding. Re-instate the inset
+  the card body used to give it, so the pager lines up with the padded card
+  header above it and keeps a bottom margin inside the (clipped) card.
+
+  Top padding is deliberately 0: the `mt-3` on the root already separates the
+  footer from the table above. `.dx-table-card` is DXTableShell's element and
+  needs no scope id — a scoped selector only stamps its LAST compound selector,
+  which here is this component's own root.
+*/
+.dx-table-card > .dx-table-pagination {
+    padding: 0 var(--bs-card-spacer-x) var(--bs-card-spacer-y);
+}
+
 /* Windowed pager (#155). The buttons are DButtons; give the numbered ones a
-   consistent min-width so they read as an even row of keys (like the house
-   custard pager), and let the whole row wrap on narrow widths rather than
+   consistent min-width so they read as an even row of keys (the house pager
+   style), and let the whole row wrap on narrow widths rather than
    overflow. `:deep(.btn)` is anchored on the plain `.dx-pager` host, so the
    scope-id has a deterministic element to attach to. */
 .dx-pager :deep(.btn) {

package/resources/js/components/extended/DXTableShell.vue

@@ -9,9 +9,27 @@
   - `#header` — the title / action row. In card mode it fills `DCard`'s header;
     in plain mode it renders above the table with a subtle bottom rule.
   - default — the table body (spinner/error/table/pagination).
+
+  Card mode renders `DCard` in **`no-body`** mode so the table sits FLUSH against
+  the card border. With a `.card-body` in between, a striped table's rows were
+  inset by `--bs-card-spacer-x` (24px) and left a white gutter between the
+  stripes and the border. Without it, DXTable's children — error alert, loading
+  block, table, pagination — become direct children of `.card`, which is already
+  a `flex-direction: column` container, so they still stack in order:
+
+      .card (overflow: hidden)
+      ├─ .card-header          (padded by Bootstrap's card-cap padding)
+      ├─ .table-responsive     ← FLUSH
+      │   └─ table
+      └─ .dx-table-pagination  (pads itself — see DXTablePagination.vue)
+
+  Bootstrap 5 has no `.card > .table` rounding rules (that was BS4), so the
+  clipping is done with `overflow: hidden` on the card: the flush table's square
+  top corners then follow the card's radius whether or not a header is present.
+  bvn's popups position `fixed` by default, so they are not clipped by it.
 -->
 <template>
-  <DCard v-if="card">
+  <DCard v-if="card" no-body class="dx-table-card">
     <template v-if="$slots.header" #header>
       <slot name="header" />
     </template>
@@ -52,3 +70,54 @@ withDefaults(defineProps<Props>(), {
   border-bottom: 1px solid var(--bs-border-color);
 }
 </style>
+
+<style>
+/*
+  GLOBAL, not scoped, on purpose: these rules target slot content supplied by
+  `DXTable`, which is compiled in *DXTable's* scope. A scoped selector here would
+  get this component's `data-v-*` appended to its last compound selector and so
+  would match nothing — the same silent-inertness trap documented in CLAUDE.md.
+  Every selector is namespaced under `.dx-table-card`, a class only this
+  component applies, so nothing leaks into a consumer's own cards.
+*/
+
+/*
+  Clip the card to its radius so the flush table's square corners follow the
+  border. Kept in this global block with the rest of the card-mode layout: a
+  scoped rule WOULD reach DCard's root (the renderer walks the component-root
+  chain), but that forwarding is the exact thing CLAUDE.md records as unreliable
+  across build pipelines, and a silently-unclipped card is invisible in review.
+  The lower specificity also leaves consumers free to override it.
+
+  KNOWN LIMITATION (#166): this clips the WHOLE card, so a consumer's own
+  non-teleported `position: absolute` overlay in a slot is cut off at the card
+  edge. dfl's own components are fine — DDropdown teleports to <body>, the
+  filter menus are `fixed` — so the residual case is a hand-rolled popover.
+  The fix is to move the radius clipping onto the flush table region, which
+  `.table-responsive`'s `overflow-x: auto` complicates; see the issue.
+*/
+.dx-table-card {
+  overflow: hidden;
+}
+
+/*
+  The error alert is a full-width child of the card now that there is no
+  `.card-body`. Give it back the inset the card body used to provide, so it
+  doesn't bleed into the card's rounded corners.
+*/
+.dx-table-card > .alert {
+  margin: var(--bs-card-spacer-y) var(--bs-card-spacer-x);
+}
+
+/*
+  Nothing may leave a trailing margin at the bottom of the card. bvn already
+  zeroes `.table-responsive > .table`, but the responsive wrapper itself carries
+  `margin-bottom: 1rem` (and an un-responsive `.table` carries Bootstrap's own),
+  which used to be absorbed by the card body and now shows as a white band
+  inside the clipped card whenever the table is the last child (no pager). The
+  gap ABOVE the pager is unaffected — that margin only drops on the last child.
+*/
+.dx-table-card > :last-child {
+  margin-bottom: 0;
+}
+</style>