@persona/design-system 0.1.7 → 0.1.9

package/dist/utils.d.mts

@@ -1,9 +1,26 @@
-//#region components/DataTable/dnd/utils.d.ts
+import { u as FilterRuleValue } from "./types-D58IoRx6.mjs";
+
+//#region components/DataTable/TableControls/FiltersV2/value-controls/utils.d.ts
 /**
- * reorder returns a reordered version of the inputed list by swapping the element
- * at startIndex with the one at endIndex
+ * Debounce window (ms) shared by the input-backed value controls
+ * (`IntegerValueControl`, `FloatValueControl`) so they commit `onChange`
+ * on the same cadence. Mirrors the V1 `InputFilter` 300ms pattern.
  */
-declare function reorder<A>(list: A[], startIndex: number, endIndex: number): A[];
+declare const DEBOUNCE_MS = 300;
+/**
+ * Coerce a `FilterRuleValue` into a string suitable for an `<input>`'s
+ * `value` prop. Used by `IntegerValueControl` and `FloatValueControl` so
+ * both share identical display-coercion semantics — without this, drift
+ * (e.g. different handling of `''`) would let the two controls disagree
+ * about how to render the same hydrated rule.
+ *
+ * `Number.isFinite` rules out `NaN` / `±Infinity` (a hydrated state that
+ * round-tripped through JSON should never carry those, but the guard is
+ * cheap defense). Empty strings collapse to `''` rather than falling
+ * through to `'undefined'` / `'null'` if the rule arrives in a malformed
+ * shape.
+ */
+declare function numericDisplayValue(value: FilterRuleValue): string;
 //#endregion
-export { reorder };
+export { DEBOUNCE_MS, numericDisplayValue };
 //# sourceMappingURL=utils.d.mts.map

package/dist/utils2.d.mts

@@ -0,0 +1,9 @@
+//#region components/DataTable/dnd/utils.d.ts
+/**
+ * reorder returns a reordered version of the inputed list by swapping the element
+ * at startIndex with the one at endIndex
+ */
+declare function reorder<A>(list: A[], startIndex: number, endIndex: number): A[];
+//#endregion
+export { reorder };
+//# sourceMappingURL=utils2.d.mts.map

package/dist/validation-vLh3t2dk.d.mts

@@ -0,0 +1,51 @@
+import { f as FilterStateV2, l as FilterRule } from "./types-D58IoRx6.mjs";
+import { t as FieldRegistry } from "./FieldRegistry-rqSkjchY.mjs";
+
+//#region components/DataTable/TableControls/FiltersV2/validation.d.ts
+/**
+ * Returns `true` when `value` is a structurally-valid `FilterStateV2`,
+ * including per-rule content validation. A `topLevelRules` element
+ * with a non-string `fieldId`, an operator not in the known
+ * vocabulary, or a value of an unsupported type is rejected — a
+ * shallow shape sniff would let those reach the adapter.
+ */
+declare function isFilterStateV2(value: unknown): value is FilterStateV2;
+/**
+ * Strip rules referencing unregistered `fieldId`s from a decoded state.
+ * Pairs with `isFilterStateV2` for defense-in-depth: even after the
+ * shape guard passes, a rule with a `fieldId` that doesn't exist in the
+ * current resource's registry would silently render nothing in the UI
+ * but still reach the adapter and ship to the backend. Pruning closes
+ * that gap.
+ *
+ * Empty AND-groups created by pruning are also dropped, since the
+ * adapter prunes them on serialize anyway and the editor UI hides
+ * empty groups too.
+ *
+ * Skips its own work and returns the input unchanged when `registry`
+ * is `undefined` — useful for callers that hydrate before the registry
+ * is built.
+ *
+ * For valueless operators (`is_empty`, etc.) the value contract is
+ * `null`. Non-valueless operators keep in-progress draft values (an empty
+ * string / empty array) so a pill the user is mid-editing survives the
+ * report/hydrate round-trip and stays visible — top-level and compound
+ * rules are treated alike here, and the serialize boundary
+ * (`hasCompleteValue`) is what drops incomplete rules from the request.
+ */
+declare function pruneToRegistry(state: FilterStateV2, registry: FieldRegistry | undefined): FilterStateV2;
+/**
+ * Whether `rule` carries a complete value for its field type — the
+ * serialize-boundary predicate `pruneEmptyRulesForSerialize` uses to drop
+ * half-edited rules from the request (a value-requiring operator like
+ * `is_not` with no value yet makes the backend reject the whole request).
+ *
+ * Deliberately stricter than `isRuleAllowed`'s hydration policy, which keeps
+ * an empty string so an in-progress pill survives the state round-trip and
+ * stays visible for the user to finish. Checks value completeness only — it
+ * does not gate operator vocabulary or registry membership.
+ */
+declare function hasCompleteValue(rule: FilterRule, registry: FieldRegistry): boolean;
+//#endregion
+export { isFilterStateV2 as n, pruneToRegistry as r, hasCompleteValue as t };
+//# sourceMappingURL=validation-vLh3t2dk.d.mts.map

package/dist/validation.d.mts

@@ -0,0 +1,2 @@
+import { n as isFilterStateV2, r as pruneToRegistry, t as hasCompleteValue } from "./validation-vLh3t2dk.mjs";
+export { hasCompleteValue, isFilterStateV2, pruneToRegistry };

package/dist/value-control-resolver-CE-bqdAl.d.mts

@@ -0,0 +1,46 @@
+import { a as FilterField, c as FilterOperator, u as FilterRuleValue } from "./types-D58IoRx6.mjs";
+import { ReactNode } from "react";
+
+//#region components/DataTable/TableControls/FiltersV2/FilterBar/value-control-resolver.d.ts
+/**
+ * Single dispatch point that picks the right type-aware value control for a
+ * given `FilterField`. Used by both the simple-rule `FilterPopover` and the
+ * Advanced Filter Rules editor so the per-type input behavior stays
+ * consistent across surfaces.
+ *
+ * Adding a new field type:
+ *
+ *   1. Add the type to `FilterFieldType` in `../types.ts` (and decide its
+ *      operator vocabulary in `../operators.ts`).
+ *   2. Implement a control under `../value-controls/<NewType>ValueControl/`
+ *      that accepts `ValueControlProps` from `../value-controls/types.ts`.
+ *   3. Add the new branch to `RESOLVERS` below. TypeScript will require it
+ *      because the `Record<FilterFieldType, …>` keying makes the table
+ *      exhaustive.
+ *
+ * `layout` is forwarded to the underlying control so the same component
+ * can render differently between the two surfaces — see
+ * `ChoicesValueControl` in `multiple` mode ("popover" → inline checkbox
+ * list, "inline" → compact Combobox with chips).
+ */
+interface ResolveValueControlOptions {
+  field: FilterField;
+  operator: FilterOperator;
+  value: FilterRuleValue;
+  onChange: (value: FilterRuleValue) => void;
+  onCommit?: () => void;
+  ariaLabel?: string;
+  /**
+   * Where the control is being rendered. `popover` (default) is the
+   * simple-pill `FilterPopover` surface — dedicated to one rule with
+   * room for an inline checkbox list. `inline` is the Advanced Filter
+   * Rules `LogicRow` dropdown surface — compact, prefers a Combobox
+   * with chips over a vertically expansive list.
+   */
+  layout?: 'popover' | 'inline';
+}
+type ValueControlResolver = (opts: ResolveValueControlOptions) => ReactNode | undefined;
+declare function resolveValueControl(opts: ResolveValueControlOptions, hostResolver?: ValueControlResolver): ReactNode;
+//#endregion
+export { ValueControlResolver as n, resolveValueControl as r, ResolveValueControlOptions as t };
+//# sourceMappingURL=value-control-resolver-CE-bqdAl.d.mts.map

package/dist/value-control-resolver.d.mts

@@ -0,0 +1,2 @@
+import { n as ValueControlResolver, r as resolveValueControl, t as ResolveValueControlOptions } from "./value-control-resolver-CE-bqdAl.mjs";
+export { ResolveValueControlOptions, ValueControlResolver, resolveValueControl };