@omnitend/dashboard-for-laravel 0.42.0 → 0.42.1

package/docs/public/api-reference.json

@@ -1,8 +1,8 @@
 {
-  "generated": "2026-10-04T09:15:57.974Z",
+  "generated": "2026-10-05T05:06:30.259Z",
   "package": {
     "name": "@omnitend/dashboard-for-laravel",
-    "version": "0.42.0"
+    "version": "0.42.1"
   },
   "components": {
     "base": [

package/docs/public/docs-map.md

@@ -1,7 +1,7 @@
 # Documentation Map
 
 > Auto-generated hierarchical overview of all documentation
-> Last updated: 2026-10-04T09:15:58.053Z
+> Last updated: 2026-10-05T05:06:30.315Z
 
 This file provides a complete map of all available documentation for AI agents and developers.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@omnitend/dashboard-for-laravel",
-  "version": "0.42.0",
+  "version": "0.42.1",
   "description": "Vue 3 dashboard components for Laravel with Bootstrap Vue Next",
   "type": "module",
   "main": "./dist/dashboard-for-laravel.umd.cjs",

package/resources/css/theme.scss

@@ -562,6 +562,47 @@ h6,
   }
 }
 
+// A horizontal row whose content column holds NO form control shows a
+// display-only value: text, a link, a badge, a flex row of text, a small
+// table, a stack of lines. Such a row is baseline-aligned instead of
+// top-aligned, so the first line of text in the value, whatever its shape,
+// sits on the label's first line (the label's padding just moves the shared
+// baseline down). No class or field flag is needed; `.dx-form-plaintext`
+// below still works and is now redundant inside a horizontal form.
+//
+// Every row that holds a control keeps the top alignment above: a checkbox,
+// switch or file input exposes a synthesized or box-edge baseline, so
+// baseline alignment would move them. The list is what the library renders
+// as a control plus the native ones; a `.btn` counts because it is
+// input-height and already lines its text up with the label when
+// top-aligned. Content with no text at all (an image, an icon) sits its
+// bottom edge on the label's baseline, as an inline image would in a line of
+// text. The rule needs `:has()` (Chrome 105, Safari 15.4, Firefox 121); a
+// browser without it falls back to the top alignment.
+$dx-display-only-row: '.dx-form--horizontal .row:has(> .col-form-label):not(:has(> .col-form-label ~ * :is(input:not([type="hidden"]), select, textarea, button, .btn, .form-control, .form-select, .form-check, .input-group, [contenteditable])))';
+
+#{$dx-display-only-row} {
+  align-items: baseline;
+
+  // A table's baseline is its first row's, and a row's baseline is its
+  // first BASELINE-aligned cell's; with every cell `middle` (the theme's
+  // default) CSS falls back to the bottom of the cell, ~6px below the text.
+  // Baseline-align the first row's cells so the table offers its text.
+  > .col-form-label ~ * table tr:first-child > * {
+    vertical-align: baseline;
+  }
+
+  // A badge's own baseline is its smaller text's, which lands its box ~2px
+  // off the label's centre; centre it on its line instead, as
+  // `.dx-form-plaintext .badge` does below.
+  > .col-form-label ~ * .badge {
+    vertical-align: top;
+    margin-top: calc(
+      (#{math.div($input-line-height, math.div($badge-font-size, 1em)) * 1em} - 1em - #{$badge-padding-y * 2}) / 2
+    );
+  }
+}
+
 // A display-only value in a form row: a badge, a line of text, a short stack
 // of lines. It has no input box, so on its own it sits at the top of the row
 // while the label column (`.col-form-label`) is padded down to an input's text
@@ -1125,13 +1166,18 @@ fieldset:disabled .btn {
   }
 }
 
-// The one exception: DXSaveButton's saved state ("✓ Saved") is a REAL
-// disabled button, but it is a confirmation, not an unavailable action, so it
-// keeps its variant's own colours (by default the navy primary fill, #151e2d /
-// #e9f0f8) at full opacity rather than the neutral grey above, so saving
-// changes the label and the disabled state but not the colour. Three classes
-// plus the state, so it outranks the neutral rule (and `fieldset:disabled .btn`).
-.btn.dx-save-button--saved:is(:disabled, .disabled) {
+// The exceptions: two states that are REALLY disabled but are not unavailable
+// actions, so they keep their variant's own colours (by default the navy
+// primary fill, #151e2d / #e9f0f8) at full opacity rather than the neutral grey
+// above:
+// - a busy button (DButton `loading`, marked `aria-busy="true"`), disabled only
+//   so it can't be pressed twice. Greying it made every save blink navy → grey
+//   → navy, since the grey lasted exactly as long as the request;
+// - DXSaveButton's saved state ("✓ Saved"), a confirmation.
+// So saving changes the label and the disabled state but never the colour.
+// `.btn` + the `:is()` (its most specific argument counts) + the state outranks
+// the neutral rule (and `fieldset:disabled .btn`).
+.btn:is(.dx-save-button--saved, [aria-busy="true"]):is(:disabled, .disabled) {
   --bs-btn-disabled-opacity: 1;
   --bs-btn-disabled-bg: var(--bs-btn-bg);
   --bs-btn-disabled-color: var(--bs-btn-color);

package/resources/js/components/base/DAutocomplete.vue

@@ -9,7 +9,7 @@
  * searchable single-select can always reach "none" in-list (#138).
  */
 <script setup lang="ts">
-import { computed, useAttrs } from "vue";
+import { computed, ref, useAttrs, watch } from "vue";
 import { BAutocomplete } from "bootstrap-vue-next";
 import type { SelectOption } from "bootstrap-vue-next";
 
@@ -127,6 +127,75 @@ const hasValue = computed(() => {
 const noClearButton = computed(
   () => attr("noClearButton", "no-clear-button") === true || !hasValue.value,
 );
+
+/*
+ * Late options (0.42.1). bvn's BAutocomplete writes the input's text from the
+ * model value through reka-ui's ComboboxInput, which does so on mount and
+ * again only when the MODEL changes. A value set before its options load (a
+ * DXTable select filter seeded from the URL while the option list is still
+ * being fetched) therefore kept showing the raw value ("78") after its label
+ * ("Alcopop") arrived. bvn exposes no "resync" method, but the input's text
+ * is its `search` v-model, so this wrapper owns that model and, whenever the
+ * options change, puts the matching option's label in it.
+ *
+ * It never overwrites a search the user is typing: while the input has
+ * focus, it relabels only text that is still exactly the raw value. Multiple
+ * mode needs nothing (bvn derives the chips from the options on every
+ * render). A consumer that binds its own `search` owns the text, so it is
+ * left alone. A `:key` remount would also work but drops focus and the open
+ * menu, so the `search` model is the cleaner hook.
+ */
+const rootElement = ref<HTMLElement | null>(null);
+const searchText = ref("");
+const consumerOwnsSearch = computed(() => attr("search", "search") !== undefined);
+const boundSearch = computed<string>(() =>
+  consumerOwnsSearch.value ? String(attr("search", "search")) : searchText.value,
+);
+
+const optionValueAndText = (option: unknown): { value: unknown; text: unknown } => {
+  if (option === null || typeof option !== "object") return { value: option, text: option };
+  const valueField = (attr("valueField", "value-field") as string | undefined) ?? "value";
+  const textField = (attr("textField", "text-field") as string | undefined) ?? "text";
+  const record = option as Record<string, unknown>;
+  return { value: record[valueField], text: record[textField] };
+};
+
+// The same equality bvn uses to find the selected option (strict, or by key).
+const sameValue = (optionValue: unknown, modelValue: unknown) => {
+  const by = attr("by", "by");
+  if (typeof by === "string") {
+    return (
+      (optionValue as Record<string, unknown> | null)?.[by] ===
+      (modelValue as Record<string, unknown> | null)?.[by]
+    );
+  }
+  return optionValue === modelValue;
+};
+
+// A bare `multiple` in a template arrives as "" (it is not a declared prop).
+const isMultiple = computed(() => {
+  const multiple = attr("multiple", "multiple");
+  return multiple !== undefined && multiple !== null && multiple !== false;
+});
+
+const relabelFromOptions = () => {
+  if (isMultiple.value || consumerOwnsSearch.value) return;
+  const modelValue = attr("modelValue", "model-value");
+  if (modelValue === null || modelValue === undefined || modelValue === "") return;
+  const match = computedOptions.value
+    .map(optionValueAndText)
+    .find((option) => sameValue(option.value, modelValue));
+  if (!match) return;
+  const label = String(match.text ?? "");
+  if (searchText.value === label) return;
+  const input = rootElement.value?.querySelector("input");
+  const userIsTyping =
+    input !== null && input !== undefined && document.activeElement === input;
+  if (userIsTyping && searchText.value !== String(modelValue)) return;
+  searchText.value = label;
+};
+
+watch(computedOptions, relabelFromOptions);
 </script>
 
 <template>
@@ -138,12 +207,14 @@ const noClearButton = computed(
     root, so `[data-v-x] .input-group` matches nothing in a consumer build
     (#53). A plain element root makes it deterministic.
   -->
-  <div class="d-autocomplete">
+  <div ref="rootElement" class="d-autocomplete">
     <BAutocomplete
       v-bind="$attrs"
+      :search="boundSearch"
       :options="computedOptions"
       :filter-function="effectiveFilterFunction"
       :no-clear-button="noClearButton"
+      @update:search="searchText = $event"
     >
       <!-- Dynamically pass through all named slots with their props -->
       <template v-for="(_, name) in $slots" :key="name" #[name]="slotProps">