@omnitend/dashboard-for-laravel 0.16.3 → 0.17.0

package/resources/js/composables/useToast.ts

@@ -1 +1,53 @@
-export { useToast } from 'bootstrap-vue-next';
+import { isRef } from "vue";
+import { useToast as useBvnToast } from "bootstrap-vue-next";
+import type {
+    OrchestratorCreateOptions,
+    ToastOrchestratorCreateParam,
+} from "bootstrap-vue-next";
+
+// Bootstrap Vue Next maps a toast's `variant` prop straight to Bootstrap's
+// `.text-bg-{variant}` utility class, which sets background/text colour
+// `!important` (all Bootstrap utilities are `!important` by design) — so
+// restyling it can only ever fight that with `!important` too. The variants
+// this theme restyles (see theme.scss) are instead applied as a `toast-{variant}`
+// class, driving Bootstrap's own `--bs-toast-*` variables cleanly. An
+// unrecognised variant (e.g. "primary", "dark", or none) falls through to
+// BVN's default `.text-bg-*` styling unchanged.
+const THEMED_TOAST_VARIANTS = new Set(["success", "danger", "warning", "info"]);
+
+function themeToastParam(param: Record<string, unknown>): Record<string, unknown> {
+    const variant = param.variant as string | null | undefined;
+    if (!variant || !THEMED_TOAST_VARIANTS.has(variant)) return param;
+
+    const { variant: _variant, toastClass, ...rest } = param;
+    return {
+        ...rest,
+        toastClass: [toastClass, `toast-${variant}`],
+    };
+}
+
+/**
+ * Thin wrapper around Bootstrap Vue Next's `useToast()`. Public API is
+ * identical (`create({ title, body, variant })`, `show(...)`) — a themed
+ * `variant` is translated internally into a `toast-{variant}` class instead
+ * of being passed through to BVN, so it's styled via `--bs-toast-*` variables
+ * (see theme.scss) rather than an `!important`-overridden utility class.
+ */
+// A ref-wrapped param (rare — most callers pass a plain object) is forwarded
+// untouched: reading through it once here would snapshot every field, losing
+// reactivity for the rest of the toast, not just its variant.
+function maybeThemeParam(obj?: ToastOrchestratorCreateParam): ToastOrchestratorCreateParam | undefined {
+    if (!obj || isRef(obj)) return obj;
+    return themeToastParam(obj as Record<string, unknown>) as unknown as ToastOrchestratorCreateParam;
+}
+
+export function useToast(): ReturnType<typeof useBvnToast> {
+    const toast = useBvnToast();
+
+    return {
+        ...toast,
+        create: (obj?: ToastOrchestratorCreateParam, options?: OrchestratorCreateOptions) =>
+            toast.create(maybeThemeParam(obj), options),
+        show: (obj?: ToastOrchestratorCreateParam) => toast.show(maybeThemeParam(obj)),
+    };
+}

package/resources/js/types/index.ts

@@ -61,6 +61,23 @@ export interface FieldOption extends Record<string, unknown> {
  */
 export type OptionsLoader = (model: any) => Promise<FieldOption[]>;
 
+/**
+ * Label column width for horizontal layout, mirroring Bootstrap Vue Next's
+ * `BFormGroup` `labelCols`/`labelCols*` props: either a single width applied
+ * at all breakpoints, or a per-breakpoint object (omitted breakpoints fall
+ * back to BFormGroup's own defaults, which is how "collapse to vertical
+ * below a breakpoint" comes for free — e.g. `{ md: 3 }` stacks below `md`).
+ *
+ * Deliberately excludes `boolean` (which BFormGroup's own `labelCols` prop
+ * accepts): Vue's type-based `defineProps` auto-defaults an omitted prop to
+ * `false` (not `undefined`) whenever its declared type includes `boolean`,
+ * which would silently break the `field.labelCols ?? formLabelCols ?? 3`
+ * fallback chain used to resolve this value.
+ */
+export type LabelCols =
+    | number
+    | { sm?: number; md?: number; lg?: number; xl?: number };
+
 /**
  * Field definition shared by every form renderer.
  *
@@ -172,10 +189,24 @@ export interface FieldDefinition {
 
     /**
      * Render the field full-width with no label wrapper, delegating its
-     * content to the `#span(<key>)` slot. Useful for custom blocks.
+     * content to the `#span(<key>)` slot. Useful for custom blocks. Also
+     * doubles as the "fill both columns" escape hatch in horizontal layout —
+     * a span field always bypasses the label/content column split.
      */
     span?: boolean;
 
+    /**
+     * Per-field override of DXForm's `layout` prop ("vertical" | "horizontal").
+     * Falls back to the form-level `layout` when omitted.
+     */
+    layout?: "vertical" | "horizontal";
+
+    /**
+     * Per-field override of DXForm's `labelCols` prop, for horizontal
+     * layout. Falls back to the form-level `labelCols` when omitted.
+     */
+    labelCols?: LabelCols;
+
     /**
      * Component rendered for `type: "component"` fields. Receives
      * `modelValue`, `field`, `model` props and emits `update:modelValue`.
@@ -199,6 +230,26 @@ export interface FieldDefinition {
     minItems?: number;
     maxItems?: number;
 
+    /**
+     * For `repeater` fields: `"cards"` (default) stacks each row as its own
+     * card with sub-fields listed vertically — best for rows with several
+     * or complex sub-fields. `"table"` renders one row per item with
+     * sub-fields as columns — far more compact for simple child-row lists
+     * (e.g. 2-3 short sub-fields). Named `repeaterLayout` (not `layout`) to
+     * avoid colliding with the unrelated form-level `layout` prop
+     * ("vertical" | "horizontal") every field type accepts.
+     */
+    repeaterLayout?: "cards" | "table";
+
+    /**
+     * For `repeater` fields in `cards` layout: show each row's 1-based
+     * position (e.g. "1", "2") next to its Remove button. Off by default —
+     * only meaningful once a consumer explicitly wants it (e.g. rows the
+     * user thinks of as numbered/ordered); most repeaters don't need it.
+     * Not applicable to `table` layout, which has no equivalent column.
+     */
+    showRowIndex?: boolean;
+
     /**
      * For `repeater` fields backed by an upsert-children API contract (rows
      * carrying a persisted `id` are only deleted server-side when submitted